Skip to main content

Permit

Instead of invoking the EVC directly, signed messages called Permits can also be provided to the EVC. Permits can be invoked by the specified sender (or anyone under certain circumstances), but they will execute on behalf of the signer of the permit message. They are useful for implementing "gasless" transactions.

Permits are EIP-712 typed data messages with the following fields:

  • signer: The address to execute the operation on behalf of.
  • sender: The address of the msg.sender which is expected to execute the data signed by the signer.
  • nonceNamespace and nonce: Values used to prevent replaying permit messages, and for sequencing (see below)
  • deadline: A timestamp after which the permit becomes invalid.
  • value: The value of ETH that is expected to be sent to the EVC
  • data: Arbitrary calldata that will be used to invoke the EVC. Typically this will contain an invocation of the batch method.

There are two types of signature methods supported by permits: ECDSA, which is used by EOAs, and ERC-1271 which is used by smart contract wallets. In both cases, the permit method can be invoked by any unprivileged address, such as a keeper. If the signature is exactly 65 bytes long, an ecrecover is attempted. If the recovered address does not match signer, or for signature lengths other than 65, then an ERC-1271 verification is attempted, by staticcalling isValidSignature on signer.

After verifying sender, deadline, signature, nonce, and nonceNamespace, the data will be used to invoke the EVC, forwarding the specified value of ETH (or the full balance of the EVC contract if max uint256 was specified). Although other methods can be invoked, the most general purpose method to use is batch. Inside a batch, each batch item can specify an onBehalfOfAccount address. This can be any sub-account of the owner, meaning a signed batch can affect multiple sub-accounts, just as a regular non-permit invocation of batch can. If the signer is an operator of another account, then the other account can also be specified - this could be useful for gaslessly invoking a restricted "hot wallet" operator.

Nonce Namespaces​

With nonces, Ethereum transactions enforce that transactions cannot be mined multiple times, and that they are included in the same sequence they were created (with no gaps).

permit messages contain two uint256 fields that can be used to enforce the same restrictions: nonceNamespace and nonce. Each account owner has a mapping that maps from nonceNamespace to nonce. In order for a permit message to be valid, the nonce value inside the specified nonceNamespace must be equal to the nonce field in the permit message. Using the permit increments the nonce by one.

The separation of nonceNamespace and nonce allows users to optionally relax the sequencing restrictions. There are several ways that an owner may choose to use the namespaces:

  • Always set nonceNamespace to 0, and sign sequentially increasing nonces. These permit messages will function like Ethereum transactions, and must be mined in order, with no gaps.
  • Derive the nonceNamespace deterministically from the permit message (for example, a hash of the message fields, excluding nonceNamespace), and always set the nonce to 0. These permit messages can be mined in any order, and some may never be mined.
  • Some combination of the two approaches. For example, a user could have "regular" and "high priority" namespaces. Normal orders would be included in the regular sequence, while high priority permits are allowed to bypass this queue.

Note that any time sequencing restrictions are relaxed, users should be aware that different orderings of their transactions can have different MEV potential, and they should prepare for their transactions executing in the least favorable order (for them).

Permit messages can be cancelled in three ways:

  • Creating a new message with the same nonce and having it included before the unwanted permit (as with Ethereum transactions).
  • Invoking the setNonce method. This allows users to increase their nonce up to a specified value, potentially cancelling many outstanding permit messages in the process. Note that there is no danger of rendering an account non-functional: Even if a nonce is set to the max uint256, there are an effectively unlimited number of other namespaces available.
  • Implicitly, by waiting until the deadline timestamp expires