Skip to content
Financial Context Wiki

Wallet signature

A wallet signature proves that a key or contract account approved exact data under specific verification rules. Learn how messages, transactions, permits, replay protection, and phishing risk differ.

Updated

For educational purposes only; not investment or security advice. A malicious signature request can lead to irreversible loss.

Direct answer

A wallet signature is cryptographic evidence that a private key, or a smart-account policy, approved a particular encoded message. Verification can establish the signing account for those exact bytes and rules; it does not prove the signer’s legal identity, understanding, or that a website described the action honestly.

Signing is not one uniform action. A transaction signature directly authorizes a network transaction. An off-chain message may be a login challenge with no asset authority, or it may be an executable order, token permit, governance instruction, or other authorization that a relayer can submit later. No gas prompt does not mean no risk.

Before signing, identify the request type, human-readable action, domain or intended validator, chain, verifying contract, addresses, amounts, nonce, and expiry. Reject an unexplained hash, unreadable bytes, unexpected fields, or any request that the wallet cannot display well enough to verify independently.

Wallet signature
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

  1. The application encodes a transaction, plain message, or typed-data object. Even a tiny change in the encoded data produces a different digest.
  2. The wallet shows what it can decode and asks the signer to approve. The private key stays inside the wallet or signing device; the wallet signs the digest and returns a signature.
  3. A verifier reconstructs the same digest. For an externally owned account it commonly recovers or checks the public-key address; a contract account can apply its own current validation policy through ERC-1271.
  4. The verifier interprets the result according to application rules. A server may create a session, while a contract may consume a permit, fill an order, change governance state, or execute another authorized call.
  5. Replay protection is application-specific. EIP-712 supplies typed encoding and domain separation but explicitly does not provide replay protection; the application must enforce a nonce, deadline, intended validator, chain, or other one-use boundary.

ERC-191 separates signed data from ordinary Ethereum transaction encoding and defines formats including personal_sign messages. EIP-712 binds structured fields to a domain that can include name, version, chainId, and verifyingContract, making meaningful review possible. ERC-4361 login messages add fields such as domain, URI, chain ID, nonce, and issued time, but the relying service must still validate them.

Example

Leah visits the official service and receives an ERC-4361 login request for the expected domain and URI, with a fresh nonce and short-lived timestamps. The message asks only to authenticate. After checking the domain and account, she signs; the server verifies the message and creates a session. No token allowance or on-chain transaction is created by that login message.

On a look-alike site, the button still says “Sign in,” but the wallet displays EIP-712 Permit data containing a token, spender, amount, nonce, and deadline. That signature can let a relayer create spending authority under the token contract’s rules. Leah should reject it: the button text is irrelevant to the bytes being signed.

Risks and controls

  • Deceptive meaning: a page can label a permit or order as a login. Trust the decoded payload and verified contract, not the button or pop-up explanation.
  • Blind signing: raw hashes and opaque bytes prevent informed review. Cancel unless the exact preimage and its execution path can be reproduced through a trusted tool.
  • Wrong domain: a familiar brand name does not authenticate chainId, verifyingContract, website domain, or URI. Check each field and the full address independently.
  • Replay or delayed execution: a valid signature may be usable by anyone who obtains it until its nonce is consumed or its deadline expires. Prefer fresh nonces and short deadlines, and never publish a signature.
  • Broad authority: permits, orders, session keys, and smart-account operations can authorize later actions without another wallet prompt. Verify asset, spender, recipient, amount, scope, and cancellation rules.
  • Compromised signer: a hardware wallet protects key extraction but cannot make a malicious message safe. If a seed phrase or private key was exposed, signatures are only one part of a full account compromise.

If you signed a suspicious request, save the decoded payload and signature without posting them publicly, disconnect from the site, and determine the exact scheme. For an on-chain approval or executed transaction, verify state on the correct chain and use the protocol’s documented revocation, nonce invalidation, or asset-migration procedure. There is no universal way to revoke every off-chain signature, and disconnecting a site does not invalidate one.

Common misconceptions

  • “Every signature moves funds.” Many signatures only authenticate or express intent, but some authorize an action that can move funds later.
  • “No gas means harmless.” A relayer can pay gas to submit a signed permit, order, or other authorization.
  • “EIP-712 guarantees safety.” It improves structured display and domain separation; it does not provide replay protection or verify the application’s claims.
  • “The recovered address proves who signed knowingly.” It links exact data to a key under a verification rule, not to legal identity, comprehension, or free consent.
  • “Contract-wallet signatures behave like ordinary account signatures.” ERC-1271 validity can depend on current contract state and policy, so the verifier must call the contract rather than assume key recovery is enough.

Sources

Navigation

Search the wiki...