EIP-2612 Permit: The Approval That Never Sends a Transaction

The two transactions that became one signature

ERC-20’s approval model is a two-step dance. The owner calls approve(spender, value), which is a transaction and costs gas. Then the spender calls transferFrom(owner, recipient, value), which is another transaction. The allowance is the bridge between them, and the owner has to hold ETH to build it.

EIP-2612’s abstract describes the problem in exactly those terms: the approve function is defined in terms of msg.sender, so a user who needs to interact with a contract needs two transactions — the approve and the contract call that will internally call transferFrom — and, in the simple case of paying another person, still needs ETH for gas.

The extension adds three functions to ERC-20:

function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external
function nonces(address owner) external view returns (uint)
function DOMAIN_SEPARATOR() external view returns (bytes32)

A valid permit call sets allowance[owner][spender] to value, increments nonces[owner] by one, and emits the corresponding Approval event. No transaction from the owner is required. The owner signs; someone else submits.

What the signature actually covers

The permit is not a signature over “approve this token”. It is a signature over a structured message defined by EIP-712, and the fields are the whole of what the owner is agreeing to:

• owner — whose tokens the allowance applies to
• spender — who may move them
• value — how many
• nonce — the owner’s current permit nonce
• deadline — the last block time at which the permit is valid

The digest is constructed so that the domain separator, which binds the signature to a contract and a chain, is hashed together with the typed message. The EIP’s formula is:

keccak256(abi.encodePacked(
  hex"1901",
  DOMAIN_SEPARATOR,
  keccak256(abi.encode(
    keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)"),
    owner, spender, value, nonce, deadline
  ))
))

The DOMAIN_SEPARATOR is defined according to EIP-712, and the EIP says it should be unique to the contract and chain to prevent replay attacks from other domains. That is the property that stops a signature collected on a testnet contract from being replayed on mainnet, or on a fork.

A permit reverts unless four conditions hold: the current block time is less than or equal to the deadline, owner is not the zero address, the nonce supplied in the message equals nonces[owner] before the state update, and v, r and s form a valid secp256k1 signature from owner. Any failure is a revert, not a silent no-op.

The risks the EIP itself lists

EIP-2612’s security section is short and unusually candid. Read it as the specification’s own threat model.

Front-running is not a theft. The signer may have a particular party in mind, but another party can always call permit first. The end result is the same for the signer: the allowance is set to the signed value. The front-runner pays the gas and gets an allowance that was already going to exist. This is why “someone else submitted my permit” is not, by itself, an incident.

ecrecover fails silently. The precompile returns the zero address for malformed messages, so the owner != address(0) check is what prevents a permit from creating an approval over “zombie funds” attributed to the zero address. The check is in the specification, and a token implementation that omits it has a bug.

Permits are censorable. A relayer that receives a signed permit can choose not to submit it, withholding the option to submit it later. The deadline is the mitigation: a permit that is not submitted before its deadline becomes unusable. If the owner holds ETH, they can submit it themselves.

The ERC-20 race condition still applies. The EIP says the standard approval race condition (SWC-114) applies to permit as well. Changing an allowance from one non-zero value to another can be front-run by a spender who uses the old allowance before the new one lands. Permit does not fix that; it changes only the mechanism by which the allowance is set.

A static domain separator can replay across a chain split. If DOMAIN_SEPARATOR contains the chainId but is defined at deployment instead of reconstructed for every signature, the EIP warns of possible replay attacks between chains in the event of a future chain split. This is a contract-implementation issue, not a user-facing one, but it explains why some tokens recompute the separator on every call.

What a permit does not do

Three limits are worth stating plainly, because they are the source of most of the confusion around the standard.

It does not make the approval safe. A permit for an unlimited value to an unknown spender is the same grant as an approve transaction for the same values. The difference is that the user signs a typed message instead of sending a transaction, and a message-signing screen is easier to click through than a transaction confirmation. The review habits in token allowances: how to review and revoke approvals apply unchanged.

It does not work for every token. EIP-2612 is an extension. A token that does not implement permit will not accept one, and a front end that assumes support will fail at the call. Checking the contract for the three functions, or for a published interface, is part of using the feature.

It does not cover contract accounts by itself. The signature check is secp256k1 and ecrecover, which is an externally owned account operation. A smart contract wallet needs a different validation path, which is outside this EIP. The distinction is the same one that makes passkeys and account abstraction a separate design space rather than a feature of the token standard.

Reading a permit before signing

A permit request that a wallet displays should answer five questions, and the EIP’s fields map to them directly:

The nonce is the field users rarely see and wallets should show. A permit signed for a nonce higher than the current one cannot execute until the intervening nonces are used; a permit signed for the current nonce is a one-shot authorisation. If a wallet presents a permit without the nonce, it is hiding the one field that explains why the signature may or may not still be usable.

Why the standard exists at all

The EIP’s motivation is narrower than “better UX”. It is about removing the requirement that a user hold ETH to interact with a token, and about doing so with the smallest possible change to ERC-20. The authors explicitly reject adding *_by_signature counterparts for every ERC-20 function, on the grounds that the specifics vary by use case and can be built from permit plus helper contracts.

That minimalism is why permit is now a building block rather than a complete approvals system. It gives a contract a way to verify that an owner authorised a spender at a particular time, and it leaves the policy — how much, for how long, to whom — to the application. The security of the result depends on the application using that policy well, and on the wallet showing the user enough of the message to make the policy visible.

For the transaction-level view of what a signature can hide, see transaction simulation before signing. For the difference between a wallet that shows structured data and one that shows a hash, see clear signing versus blind signing. And for the account model that decides whether a signature is even the right primitive, see passkeys and account abstraction.

Risk note. The function signatures, digest construction, revert conditions and security considerations in this article were read from EIP-2612 on 2026-11-02, with EIP-712 and EIP-20 for the domain and approval context. Token implementations vary; the specification defines the minimum a compliant contract must do. Nothing here is investment advice.