Explicit signing: UTXOs versus token approvals

Wonder

1. Why can a smart contract move your tokens years after you interacted with it?
2. What is the structural difference between signing a transaction and granting standing authority?
3. How does a file format make every input and output of a Bitcoin transaction visible before a signature is applied?

Explore

1. On EVM chains, the ERC-20 standard governs token transfers. To move tokens from an external wallet to a contract, the holder must first call `approve`, granting the contract permission to spend a specific amount of that token on their behalf. This allowance is recorded in the contract’s state and persists indefinitely until revoked or exhausted. A user who approves 10,000 tokens for a decentralized exchange retains that standing authority even after the swap completes.
2. EIP-2612 introduced `permit`, allowing users to sign an off-chain message that sets this allowance without submitting an immediate transaction. The signature stays valid until it is used or its deadline passes, and it grants the same spending power. Once an allowance exists, whoever controls the approved spender address can drain the allowance by calling `transferFrom`, even if the user has not interacted with that contract since.
3. Wallet drainers exploit this architecture. Phishing sites trick users into signing an unlimited `approve` or `permit` for a malicious address. Once signed, the attacker holds a standing permission to move tokens at will. Revoking these approvals requires additional transactions and gas fees, creating friction. The result is that a single signature can create a permanent vulnerability, invisible unless the user actively audits their active allowances using tools like Revoke.cash or Etherscan.
4. Bitcoin’s UTXO model operates differently. There are no standing permissions. Each transaction explicitly spends specific unspent transaction outputs (UTXOs) to create new ones. A signature authorizes the movement of a specific coin from a specific address to a specific destination, with no residual authority left behind. If a user signs a transaction sending 1 BTC to an exchange, that signature cannot be reused to send another 1 BTC later.
5. BIP-174 defines the Partially Signed Bitcoin Transaction (PSBT) format. Before signing, a PSBT contains all inputs and outputs, allowing software or hardware wallets to display exactly what is being spent and where it goes. The user sees the full transaction structure—inputs, outputs, fees—and signs that specific payload; with the default signature type, the signature commits to the whole transaction. Because no hidden permissions are created, a malicious signature can only move the coins specified in that single transaction; it cannot leave a backdoor for future transfers.
6. The trade-off is composability. EVM approvals enable complex multi-step interactions where contracts manage token balances on behalf of users across multiple actions. Bitcoin’s explicit model requires every movement to be signed individually, limiting the ability to delegate authority to smart contracts in the same fluid way. Users gain security through transparency and the absence of standing permissions but sacrifice the convenience of automated, persistent agent behavior.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• EIP-20: Token Standard (2015)
• EIP-2612: Permit Extension for EIP-20 Signed Approvals (2020)
• BIP-174: Partially Signed Bitcoin Transaction Format (2017)
• Scam Sniffer, annual Web3 phishing reports