Skip to main content
Permit3 manages token permissions with signed operations. A signature can authorize operations on one chain or commit to permits for several chains. Each chain executes its own transaction; a shared signature does not make those transactions atomic across chains.

​
Operations

A permit entry identifies a token, a recipient or spender, an amount, and an operation mode. The current interface uses tokenKey, a bytes32 value. For an ERC-20 token, this is its address left-padded to 32 bytes. NFT token keys use a different encoding; see the Permit3 interface.

​
Authorization

Token approval and a Permit3 signature are separate requirements. For an ERC-20 transfer, the owner must first approve Permit3 in the token contract. The signature then authorizes the specified operation through Permit3. Signed permits include an owner, salt, deadline, timestamp, and permit hash. The EIP-712 domain uses name: "Permit3", version: "1", and chainId: 1, including when execution occurs on another chain. The permits themselves identify the execution chain. For multi-chain permits, a Merkle root commits to the chain-specific permits. Submit the matching proof on each chain. Revoking or executing a permission on one chain does not itself submit a transaction on another.

​
Witnesses

Witness permits include additional typed data in the signature. Your application must validate what that data means before taking action. Adding a witness hash does not automatically enforce its business conditions.

​
Deployment

The Permit3 repository lists 0xEc00030C0000245E27d1521Cc2EE88F071c2Ae34 as the deterministic deployment address. Check that the expected contract is deployed on your execution chain before requesting approvals.

​
Next steps

Follow Integrate Permit3 for a TypeScript transfer example. For Routes API funding, use Submit Permit3 authorization, whose request format is separate from the direct contract interface.