MASTR · CRYPTO & WEB3
The signing boundary: a valid signature can authorise the wrong thing
The chain can execute a maliciously requested action perfectly. Read the authority being granted, not just the button label.
Chapter text and technical graphics are in English. Navigation is available in seven languages.
What power will exist after this signature is accepted?
Authentication is not an intention detector
A digital signature can demonstrate authorisation under a key or account’s rules. It does not establish that the signer understood the request, recognised the recipient or intended the economic result. A drainer can exploit that gap by making a harmful action look like verification, a reward claim or a routine connection. The transaction can be valid while the user’s understanding is wrong.
Approvals can persist
An ERC-20 allowance records permission for a spender to transfer tokens within the contract’s rules. It can survive the trade that motivated it. Revoking a browser connection and changing an onchain allowance are different actions. An application may also use signed permit mechanisms: the signature can authorise an allowance without the token holder first submitting a separate approval transaction. The absence of an immediate gas payment does not prove the request is harmless.
Read the context and scope
The chain, contract, spender, amount, deadline and nonce can affect the scope of an authorisation. Typed data makes fields structured, but a wallet’s presentation may still require interpretation. Verify whether the requested power matches the task. A small test transfer can check an address path, but it does not make an unrelated unlimited allowance safe. A familiar token symbol cannot substitute for the contract address.
Simulation has a state boundary
A simulation can help show effects under the state and environment used for the simulation. It is not a general proof of every future outcome, administrative change or later use of an allowance. The programme may have upgrade paths or conditions that change. Treat simulation as one piece of evidence, alongside code, permissions and source authenticity.
Separate the incident’s causes
A stolen seed, a malicious approval and a compromised frontend are different incidents. Their effects and containment differ. Revoking an allowance does not repair a stolen private key; moving to a new website does not change a dangerous authorisation already recorded onchain. A precise description of the failure is the first step toward choosing a relevant response and avoiding a second scam disguised as help.
Worked example
A fake reward page requests a permit with a large allowance for an unfamiliar spender. No tokens move at the instant of signing. A later transaction can use the authorised permission. “I only signed a message” does not describe the remaining risk.
Questions to take away
- Identify the authority after signing.
- Distinguish connection, authentication and spending.
- Match the response to the compromise type.