Did you know? A wallet can ask you to sign a message without asking you to send a blockchain transaction. That message might simply help a website check that you control an account. But it might also authorise an action that another party could later submit. The absence of a network-fee popup is not a guarantee that the signature is harmless.
This distinction is important for anybody reading a “Connect,” “Sign in,” “Approve” or “Confirm” button. An on-chain transaction asks a blockchain network to process a defined action. A message signature produces cryptographic evidence associated with particular data and an authorising key. What another system is allowed to do with that evidence depends on the content and the verification rules.
Imagine Alicia joining a fictional digital science club. Kai Kai asks her to sign a statement to prove that she is controlling the classroom account. Tricia later asks her to sign permission for the club to collect ten pretend credits. Both requests could display the word “sign.” Yet their intended consequences are very different.
In this guide, we will learn how blockchain technology works by comparing login challenges, Ethereum-style personal messages, structured data under EIP-712, permit-style token approvals, actual transactions, replay protection and the privacy implications of signing. The examples require no cryptocurrency, live wallet or real digital signature. Their purpose is literacy, not encouraging readers to test unfamiliar requests.
The one-minute answer: signing a message usually creates a signature over particular data without, by itself, submitting a state-changing transaction to the blockchain. A transaction signature can authorise a transaction that later changes on-chain state when properly submitted and accepted. Some off-chain message signatures can also authorise consequential actions when a compatible service or smart contract uses them. To judge risk, read what the signature says and who can use it, not just whether an estimated gas fee is shown.
For the general foundation, read What Is Blockchain?. For wallet keys, see Why a Wallet Password Is Not a Recovery Phrase. This article owns one narrower, practical question: what exactly am I authorising when the wallet asks me to sign?
A signature is evidence about specified data, not a magic approval
A digital signature can let a verifier check that a particular message was signed under the cryptographic authority associated with a public identity. That is useful for authentication and data integrity. It does not, by itself, tell the verifier that every statement within the message is factually true or that the person understood its consequences.
Consider a paper declaration at school: “I am the elected club treasurer.” Signing the declaration shows that somebody applied a signature to those words. It does not automatically prove a valid election occurred. The club must still check its own election records and identity process.
Cryptographic signatures make it feasible to perform defined verification without handing over the private signing key. But the content and context remain essential. A verifier must know which bytes were signed, which signature scheme and public identity apply, and what claim that signature is intended to support.
A person can sign a completely harmless greeting, a login challenge or a serious spending authorisation. A signature’s mathematical correctness does not distinguish a fair agreement from a scam. Its semantic meaning comes from the signed message and the rules of the system relying on it.
This is why an attractive “sign to continue” button is not an adequate explanation. It hides the subject of the signature. Good interfaces show the relevant domain, action, limits and intended use in readable form.
The useful reader habit is to replace “I signed something” with “I signed these specified data for this defined purpose, and this application may use the signature in this defined way.” If you cannot finish that sentence, you do not yet know what the request means.
What an on-chain transaction actually does
A blockchain transaction is data prepared under a network’s rules and authorised through the required signing or account-control mechanism. When a network accepts it, the transaction may alter balances, contract state or other protocol-defined information. It can also fail during execution while still being recorded under the relevant protocol.
A conventional Ethereum transaction can contain a destination, value, gas and fee parameters, nonce and input data. The network’s execution and consensus processes determine whether and how it is included and what outcome it produces. Ethereum uses transaction signatures as one element of its authorisation model for externally owned accounts.
The key step is submission for network processing. A transaction may be signed locally before it is broadcast. A signature does not teleport the data into every node. Software must transmit a suitable signed transaction, and the network must accept it under the applicable rules.
A wallet asking “Send transaction?” is generally asking the user to authorise a state-changing or network-submitted operation under a specific transaction format. The fee requirement, recipient and contract call deserve review, because an accepted action can produce lasting effects.
For contrast, a conventional message-signing request may simply return signature bytes to a website. That website can verify the signature without creating a blockchain transaction. It may then log the user in or use the signature in a further protocol.
The terms “signed” and “confirmed” therefore need care. A transaction may be signed but not submitted; submitted but pending; included but failed; or included and successful but not settled under the recipient’s finality policy. A signed message lives in another workflow unless and until an application uses it in an accepted network action.
Why a login may ask for a message signature
A website may want to authenticate a blockchain account without collecting a password tied to that account. It can issue a unique challenge message and ask the account’s authorised signer to produce a signature. The site checks the signature and relevant challenge details, then creates a separate login session.
Imagine Alicia opening the fictional science-club portal. The site wants to know whether she currently controls the account that registered for an experiment. It generates an unpredictable one-time challenge and asks her to sign it. When the site verifies the signature, it can associate a temporary session with that account, subject to its chosen authentication policy.
This can be useful because Alicia need not give the site her private key or recovery phrase. The signature gives defined evidence that an appropriate signing capability was exercised. But it does not automatically prove Alicia’s legal name, age or eligibility to use a laboratory. Those may require separate credentials.
A proper login challenge should identify the requesting service and include protections against reuse. Otherwise, an attacker could capture an old signed challenge and try to replay it to impersonate the account holder at the same service.
The Ethereum ecosystem has a standard called Sign-In with Ethereum, or SIWE, specified by ERC-4361. Its message format includes a requesting domain, account, chain identifier, nonce and other fields that help a verifier interpret the challenge in context.
The reader’s lesson is that a “sign in” message has a narrow goal: establish a defined authenticated session under that site’s rules. It is not a guarantee that the site is legitimate or that the account holder has a particular real-world identity.
The difference between a public address and proof of control
A public blockchain address can be read, copied and displayed by anyone. A stranger can paste an address into a profile or website without controlling the account. A correctly verified challenge signature may provide stronger evidence that a signer had the relevant cryptographic authority for that exact challenge under the applicable account rules.
That proof has a limited scope. It says something about control at the time of the signed challenge under its assumptions. It does not guarantee that the signer is the person pictured in a profile image or that the controller will remain the same forever.
A club could therefore use message signing to verify access to an account while separately checking membership from its internal register. The two systems answer different questions. An address is an identifier; a valid challenge response supports control; institutional records support membership.
The distinction becomes more complex with smart contract accounts. Such accounts can define signature validation through contract rules, and those rules may evolve as authorised signers or guardians change. Some standards, such as ERC-1271, define a way to ask a contract whether a signature is valid under its rules.
A message signed under one account type should not automatically be interpreted through the verification logic of another. The relying service must understand which chain and account model apply.
This is also a good reason not to publish a signed login challenge as though it were a permanent identity document. Authentication for one domain is different from legal identity proof, and sensitive user data should not be collected or displayed without a legitimate need.
What EIP-712 structured signing adds
Some messages contain more than a plain sentence. A smart contract or application might require specific fields such as spender, amount, expiry and an address that identifies the verifying contract. EIP-712 defines a standardised approach to hashing and signing typed structured data for Ethereum-compatible use cases.
Instead of asking the user to sign an unexplained sequence of hexadecimal bytes, an application can provide fields that a wallet is better positioned to display meaningfully. That is valuable. A typed-data prompt can tell the user which token, spender or order the signature refers to, assuming the interface correctly interprets the data.
However, structured does not automatically mean safe. A dishonest app can ask for authority over a large amount, choose a misleading spender or present a frighteningly long message in a small scrolling window. The cryptographic format still needs a truthful, understandable explanation.
An important technical detail is that EIP-712 itself describes structured signing and hashing; it does not supply universal replay protection for all applications. Developers must handle nonces, expiries and other relevant checks where the signed message is intended to authorise an action.
A student can practise reading a fictional typed message with these fields: account owner, permitted student assistant, maximum 20 ART credits, fictional contract, deadline and unique request number. No real cryptographic signing is needed.
Ask: which field names the authority? Which limits the amount? Which limits reuse? Which identifies the system that should accept the signature? A person who can answer those questions is less likely to mistake a long structured message for a harmless decoration.
Read the primary EIP-712 specification for the exact standard. It is a format for meaningful structured data, not a universal security certificate for every signable request.
Why a free signature can still have financial consequences
A website might tell the user, “This signature costs no gas.” In many message-signing workflows, producing an off-chain signature does not submit a blockchain transaction immediately, so the act itself does not incur an on-chain execution fee. That is the narrow claim.
The consequence of the signed data can be much broader. Some applications accept cryptographic authorisations that a different party can submit later in a transaction. When the relevant contract validates the signature and conditions, it may perform a transfer or update a permission. The signer might not be the participant paying the network fee at that later stage.
EIP-2612, for example, defines a permit-style approval mechanism for compatible ERC-20 tokens. The owner’s signed permit can authorise an allowance under the relevant rules. The required parameters and replay-prevention mechanisms must be correctly implemented. A user who thinks “no gas means no spending authority” could misunderstand what is happening.
Not every signed message has that effect. A casual plain-text greeting may not be accepted by any contract. The essential question is whether a verifier or contract has rules that treat this particular signature as authority for another action.
Return to the school-club example. Alicia signs a one-time proof that she controls her account. Tricia asks her to sign an instruction permitting an approved club spender to use 20 credits. The signing action might look similar, but the second message contains a meaningful delegated power.
This is why wallets should help users distinguish authentication, agreement, delegated approval and transaction authorisation. One label—“Sign”—is not enough. Our Token Approvals guide explains why some delegated permissions remain after a website connection ends.
The role of the domain, chain and intended recipient
A well-designed signing request makes its context explicit. For a login, the requesting web domain matters. For structured contract authorisation, the verifying contract, network and domain separator can matter. For a transaction, the destination, chain identifier and authorisation fields are essential.
Imagine that two schools have a digital club called “Science Society.” Alicia signs a challenge from the first school’s portal. It should not automatically function as a login token for the second school’s portal merely because both display the same club name. Domain separation and one-time challenge design help prevent that kind of unintended reuse.
Likewise, a permission intended for one contract should not casually be accepted by an unrelated contract or chain. Designs need precise verification rules to avoid treating a genuine signature as authority in the wrong context.
For the reader, check the actual website domain independently, especially when the signature appears after clicking a link in a direct message. A convincing logo or school name in a popup is weaker evidence than an authenticated connection to the expected origin.
A legitimate-looking request can also originate from a compromised or impersonated website. Cryptography proves that certain bytes were signed under a key. It does not guarantee the website’s operator was honest or that the user understood a disguised field.
When teaching this, write one sentence beside every signature: “This request is for [service or contract] on [relevant network] concerning [specific action].” If any of those pieces is absent or contradictory, the student should mark the claim incomplete rather than assuming the missing context is harmless.
Why a nonce matters
A nonce in an authentication or authorisation design is a value used under specified rules to distinguish a particular request or constrain reuse. The word also appears in blockchain transaction sequencing, but the exact meaning and mechanism depend on the system. A login nonce should not simply be confused with Ethereum’s account transaction nonce.
Suppose Kai Kai sends Alicia the same login challenge every day. An attacker who obtains yesterday’s signed response might try to use it again. A proper service can issue an unpredictable fresh challenge and reject reuse. It also checks that the response belongs to the expected account, domain and relevant session.
For a signed spending permission, a contract may track a nonce associated with the signer or authorisation. A successfully used signature changes the relevant expected state, so the exact same signed authorisation cannot be replayed under the rules. Other designs use cancellation, expiry or operation identifiers.
These protections must actually be implemented and verified. Including a field named “nonce” in a screenshot does not by itself prove the application checks it correctly. A program could ignore the field or reuse values improperly.
The practical lesson is simple: a signature is reusable data unless the receiving system imposes appropriate limits. Good design states who can present it, what it permits, which context it belongs to, when it expires and how repeated use is handled.
For a general reader, you do not need to calculate nonces. You should understand why a repeated challenge or a permission without clear limits deserves scrutiny. An authorised statement can become dangerous when other software interprets it more broadly than the signer intended.
Expiry dates and session limits are separate from signature validity
A signature can remain mathematically verifiable even after the relying service decides that its authorisation should no longer be accepted. A login challenge may include an expiration date, and a server can reject a signature after that date. The cryptographic bytes do not spontaneously vanish; the application enforces the validity policy.
Similarly, a signed permit might include a deadline checked by the relevant contract. The contract can reject a late submission under its rules. The exact timestamp semantics and network execution order matter. A date printed in a friendly wallet display is not necessarily a guarantee about the moment of physical signing.
A website may also create a session after checking a signature. Logging out should invalidate the relevant website session according to its policies. That action does not necessarily cancel unrelated on-chain approvals or unused signed authorisations held elsewhere.
Imagine Alicia signs in to the fictional science-club website, logs out, and later signs a separate instruction for Tricia to spend classroom credits. The login session and the spending authorisation are different records and permissions. Terminating one does not inherently invalidate the other.
This connects to a broader theme: cryptographic validity, application acceptance and current user intent are related but different. The correct security design aligns all three under explicit rules.
For the deadline boundary, read Why Block Timestamps Are Not Exact Clocks. It explains why inclusion time and human action time should not be collapsed into one vague “before noon” claim.
Personal-sign, typed data and transaction prompts are not interchangeable
Wallets may implement different signing methods with different expected inputs and display styles. An Ethereum personal message commonly uses a defined prefix to distinguish message signing from other forms of signing. EIP-712 structured data uses a domain and typed-field structure to encode complex messages.
That separation helps prevent accidental confusion between a signed piece of text and the data structure of a raw transaction. Developers should use methods designed for their purpose and make the meaning visible to the user. Interfaces that ask people to sign opaque binary data without explanation undermine informed consent.
A signed Ethereum transaction has its own format and network validation semantics. It may include a contract call that a user does not immediately recognise from the recipient line alone. A wallet can present decoded details, but complex interactions may still require care.
A typed-data approval can have a meaningful on-chain effect if submitted through a compatible mechanism. Conversely, a personal-sign challenge for an ordinary login might create no on-chain state change at all. The visible method is a clue, not a complete risk assessment.
Readers should always examine the content, domain, contract and the purpose stated by the trusted application. An unexpected approval, unknown spender, overly broad amount or unexplained signature request is a reason not to proceed.
For documentation, EIP-191, EIP-712 and MetaMask’s message-signing guide describe different signing formats and common implementation choices. The standards do not certify individual websites.
A dangerous misunderstanding: “It is only a signature”
A scammer may display “Sign this harmless verification” while the structured request contains an authorisation to move tokens or create a broad allowance. If the user does not inspect the actual fields, a genuine wallet can faithfully sign the wrong instruction.
The scam does not require forging a cryptographic signature. It relies on persuading the account holder to produce a valid signature over harmful data. Once issued, a compatible contract may treat that signature as legitimate authority under its rules.
This is particularly important where the application offers a “gasless” user experience. The signer may pay no immediate transaction fee, but a separate relayer or another participant may later submit the signed authorisation. The absence of a gas prompt proves very little about the message’s intended consequences.
A second deception is claiming that a signature will “verify ownership” when the destination website is unrelated to the real service. A signature-based login can help establish control of an account to the requesting domain; it does not establish that the domain deserves trust.
Do not sign an unexpected request merely because someone says you must act within minutes. Do not paste a recovery phrase into a site to “finish” signature verification. A normal signature flow should not reveal the private key or seed phrase to the requesting application.
Students can learn to recognise these risks with fictional screenshots drawn on paper. Identify the claimed action, actual fields, recipient, limits and verifier. It is not necessary to create live digital signatures or expose any account to practise the reasoning.
A classroom exercise: three requests, three meanings
Give Alicia three fictional cards. Card A says: “Science Club would like to confirm that this account is yours for today’s login challenge.” Card B says: “Send ten ART credits to Tricia now.” Card C says: “Authorise contract C to use up to 200 ART credits until Friday.”
Ask which one looks like an authentication message, which requests a transaction and which could represent a signed delegated permission. Discuss how each should be displayed to a learner. Card A needs an identifiable requester and one-time challenge. Card B needs a recipient, asset, amount, network and fee explanation. Card C needs a clearly identified spender, bound amount, contract and duration.
Now change Card A’s website name to a lookalike domain. The mathematical signature could still verify for whatever bytes the user signs, but the user may be authenticating to an impostor. The class should recognise the origin problem.
Change Card C’s amount from 200 to an enormous value. The instruction becomes broader even if the button still says “Sign.” Ask whether the user intended permission for one small experiment or a long-lived, high-value authorisation.
Finally, ask whether closing the browser cancels Card C. Not automatically; that depends on whether the relevant authority is recorded or accepted in an external system and whether a defined cancellation mechanism has been used.
The exercise teaches three different questions: Who am I proving control to? Which state-changing action am I authorising? Which capability am I granting for later use? Those distinctions are more valuable than memorising the shape of a popup.
How signed messages can improve privacy—and expose it
A signature-based login can reduce dependence on passwords stored by one website, but it does not automatically provide anonymity. A public blockchain address can reveal activity, and using the same address repeatedly across unrelated sites can allow those activities to be associated.
A website that receives a verified signature may learn which address was used. It may then combine that address with other publicly available blockchain information, profile data or service activity. The cryptography did not require the signer to disclose a legal name, yet the resulting correlations may still be privacy-sensitive.
Some systems aim to separate identities or use selective-disclosure credentials to reduce unnecessary exposure. Those approaches involve different architectures and trust assumptions. An ordinary signed login should not be marketed as a universal privacy shield.
Consider a student using the same fictional club account for two independent school projects. One site publishes a leaderboard; the other stores contact details. If both tie their records to the same account identifier, a curious observer may connect information that the student expected to remain separate.
A good service collects only what is necessary, explains the requesting domain and session, and avoids treating publicly observable account activity as consent to publish a person’s private details. Clear logout and session-expiry behaviour are important too.
The responsible takeaway is that proving account control can be useful without being proof of real-world identity, and without guaranteeing the confidentiality of every related activity. Security and privacy both depend on how the application uses the resulting identity.
When smart contract accounts sign differently
Some Ethereum-compatible accounts are controlled by smart contract code rather than one simple externally owned signing key. A contract account might allow several authorised signers or a threshold approval policy, and its rules for deciding whether a signature counts can be different from ordinary elliptic-curve signature recovery.
ERC-1271 defines a contract-based signature validation interface for this purpose. A relying application must use the appropriate verification method and network context. For some designs, a previously valid signature may cease to be accepted when the contract’s authorised signers or other state changes.
That is another reason a signed-message screenshot is not a universal proof of permanent account ownership. The authority mechanism may be dynamic, and the verifier needs to check it under the correct chain and state.
Imagine a school-club treasury that initially requires signatures from Alicia and Tricia together. Later the school appoints Kai Kai as an authorised committee member under the club’s published governance rules. Whether an older authorisation remains valid depends on the contract’s specified policy, not on a single eternal wallet secret.
A safe login system needs to consider session invalidation if the account’s relevant authorisation changes. The SIWE specification discusses the effect of ERC-1271 contract-state changes on session validity.
For general readers, the important message is narrow: not every blockchain account is controlled by one human-held key in the same way. When a signature is used for authentication or permission, the verifier must follow the actual account design.
A six-question signature check
1. What is being signed? Is the request a plain message, structured typed data, a complete transaction or a specialised account-operation payload? The exact category determines which rules apply.
2. Who requested it? Verify the website origin or application through a trusted route. A logo inside a popup is not identity proof.
3. What action can the recipient take with it? A harmless challenge, a login session, a permit, a token allowance, a trade order or another delegated permission may have different consequences.
4. What limits exist? Read the amount, spender, contract, chain, nonce, expiry and any resource scope the format provides. Don’t assume an unspecified limit exists.
5. What will happen next? Will the signature remain off-chain for login, be submitted in another transaction or immediately authorise an operation? A user should understand the intended workflow.
6. What does the signature not prove? Valid signing authority does not guarantee the truth of a school membership claim, legal identity, merchant reputation or actual delivery of goods.
If you cannot answer an essential question, the evidence is incomplete. A good interface should make decisions easier, not pressure the user to sign unknown data. Treat the checklist as a thinking exercise, not as a substitute for official product instructions.
Seven claims that sound reassuring but are incomplete
“Signing is free, so it cannot move funds.” A message signature may cost no immediate network fee yet authorise a later consequential action under a compatible contract.
“Any signature proves identity.” It can help verify control of the relevant account for the specified data. Legal identity and institutional membership need independent evidence.
“A login signature is always permanent.” A well-designed service can use nonces, expiry and session invalidation. A valid signature and an active session are different things.
“Typed data is always readable and safe.” EIP-712 structures fields, but a confusing wallet interface or malicious input can still conceal dangerous authority.
“Closing the browser cancels a signed permit.” Not automatically. A permit’s validity depends on the relevant nonce, deadline, contract and rules.
“All Ethereum accounts verify signatures identically.” Smart contract accounts may use ERC-1271 and state-dependent validation, unlike straightforward externally owned account signatures.
“A real signature means the website told the truth.” A correctly produced signature does not certify the requester’s honesty or the truth of all written claims.
Each corrected sentence is useful because it identifies the missing condition. That is exactly how technology literacy prevents false certainty.
Frequently asked questions
Is signing a message the same as sending a blockchain transaction?
No. A message signature can be generated off-chain and delivered to a verifier. A submitted transaction asks the network to process an authorised action. Some signed messages can later be used to authorise on-chain effects under compatible rules.
Does signing a message always cost gas?
Ordinary off-chain message signing generally does not itself submit an on-chain transaction. However, later use of the signature in an on-chain operation can involve gas paid by some participant.
Can signing a message give somebody token permissions?
Yes, in certain standards and application designs, such as compatible permit-based mechanisms. Other signatures are merely login challenges or harmless declarations. Read the signed content and verifier.
What is EIP-712?
It defines a structured approach to hashing and signing typed data for Ethereum-style applications. It helps describe fields and domain context, but replay protection and application security still need their own controls.
What is Sign-In with Ethereum?
ERC-4361 defines a format and security considerations for using Ethereum account signatures to authenticate with off-chain services. It is an account-control login mechanism, not proof of a person’s legal name.
What is a nonce in a login request?
It is a value used under the authentication design to distinguish a challenge and reduce replay risk. A well-designed verifier must check it appropriately.
Does my signature reveal my private key?
A properly designed digital signature does not disclose the private key under the scheme’s security assumptions. That does not make every signing request safe or justify sharing a recovery phrase.
Can a signed message be reused?
Possibly, unless the receiving system imposes appropriate replay limits, expiry and verification rules. EIP-712 alone does not provide a universal replay-protection guarantee.
Is a website safe just because my wallet displays the domain?
No. Verify that it is the intended service through a trusted source. A real domain may still be compromised or dishonest, and an impostor can imitate familiar branding.
Why might a smart account use ERC-1271?
Contract accounts can implement their own signature-validation rules. ERC-1271 provides a standard interface for checking validity according to those rules.
Does disconnecting a website invalidate a signed permit?
Not automatically. Disconnecting is a wallet–website interaction, while the permit’s use depends on the contract’s verification and cancellation rules.
What is the best question before signing?
What exact action does this signature authorise, which system can use it, and what limits prevent unintended reuse?
Primary sources and further reading
The EIP-712 standard defines typed structured data signing, including a clear warning that application-specific replay protection remains necessary. ERC-4361 defines Sign-In with Ethereum and its domain, nonce and session security considerations. EIP-2612 gives one concrete example of how a signed permission can authorise a token allowance in a compatible implementation. ERC-1271 describes contract-based signature verification.
For developer-focused context, see EIP-191 and MetaMask: Sign data. These are technical references, not endorsements of any particular wallet prompt, token or website.
Continue within eduKateSG to Why Disconnecting a Website Does Not Revoke Token Approvals, Why a Wallet Password Is Not a Recovery Phrase and Why a Blockchain Address Is Not a Verified Identity. Each studies a different boundary between interface, authority and identity.
The essential habit is simple: signing establishes defined cryptographic evidence. Whether that evidence logs you in, moves a token or grants a lasting capability depends on the actual content and rules of the receiving system. Read those before authorising anything.