A signature expresses intent
Practical checks for a signature expresses intent
A repeatable workflow matters more than memorizing a definition for “A signature expresses intent”. Use private-key proof, message, transaction, typed data as anchors for deciding whether the request matches what you intended to do and whether the result can be verified afterward.
For a signature expresses intent within Signature Requests, For irreversible actions or changes in permission, speed is not the priority. Read the recipient, network, amount, gas, signature text or approval target before continuing, because prevention is usually more effective than remediation.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on a signature expresses intent, verification should return to the concrete objects named above. Afterward, keep the public record needed for verification and review any connection or approval that is no longer required. Blockchain transactions are generally not reversible by the wallet alone, so the goal is a process you can explain, verify and review.
Message signatures
Practical checks for message signatures
From a wallet user’s perspective, “Message signatures” matters because login challenges, nonce, domain binding, replay risk can change the meaning or risk of the same-looking action. If one of those details is unexpected, stop and resolve the mismatch first.
For message signatures within Signature Requests, Do not treat similar names as proof that two objects are the same. Networks, addresses, contracts and permissions should be cross-checked with public information, and any signature should correspond to an action you deliberately initiated.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on message signatures, verification should return to the concrete objects named above. For repeated use, turn these checks into a personal routine. A consistent review process survives changes in network, device or DApp better than relying on a one-time warning banner.
- Check: login challenges
- Check: nonce
- Check: domain binding
Transaction signatures
Practical checks for transaction signatures
Treat “Transaction signatures” as a decision point rather than a label. The useful details are recipient, amount, contract method, gas. Together they explain what the wallet is being asked to do, what changes on-chain, and which public record can be used to verify the outcome.
Gas measures execution resources and their cost. The actual fee depends on network rules, execution and current demand. For transaction signatures within Signature Requests, A useful final review is purpose, target and result: confirm why you are acting, confirm the exact network or contract involved, and confirm that the outcome can be checked through a transaction hash, block explorer or wallet record.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on transaction signatures, verification should return to the concrete objects named above. If something looks suspicious, protect control first: stop signing, leave the questionable site, review approvals and the device, and verify public chain state from a trusted environment. Do not expose sensitive material through remote-control sessions.
Do not sign what you cannot explain
Practical checks for do not sign what you cannot explain
“Do not sign what you cannot explain” is easier to reason about when it is broken into concrete checks: opaque data, unknown domain, urgency pressure, remote guidance. A wallet interface can summarize an action, but the network, contract and permission context determine what the action actually means.
For do not sign what you cannot explain within Signature Requests, A useful final review is purpose, target and result: confirm why you are acting, confirm the exact network or contract involved, and confirm that the outcome can be checked through a transaction hash, block explorer or wallet record.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on do not sign what you cannot explain, verification should return to the concrete objects named above. For repeated use, turn these checks into a personal routine. A consistent review process survives changes in network, device or DApp better than relying on a one-time warning banner.
- Check: opaque data
- Check: unknown domain
- Check: urgency pressure
Checks after signing
Practical checks for checks after signing
Before acting on “Checks after signing”, identify the active network, the account in use and the purpose of the request, then review transaction hash, account state, approval records, revocation steps. This separates interface wording from facts that can be checked independently.
A transaction hash indexes a public on-chain record and can reveal status, block inclusion, fees, addresses and event logs. For checks after signing within Signature Requests, For irreversible actions or changes in permission, speed is not the priority. Read the recipient, network, amount, gas, signature text or approval target before continuing, because prevention is usually more effective than remediation.
Security decisions depend on control, permissions and verifiable records rather than promises of absolute protection. Because this section focuses on checks after signing, verification should return to the concrete objects named above. Afterward, keep the public record needed for verification and review any connection or approval that is no longer required. Blockchain transactions are generally not reversible by the wallet alone, so the goal is a process you can explain, verify and review.