Permit Types

Exec402 is built around the idea that payments should be authorized once and executed later, possibly by a third party (the executor). To do that safely, it relies on existing token standards that support off-chain permissions.

This page gives a high-level overview of the permit types currently in scope. In the SDK and contracts, these correspond to the PermitType values:

type PermitType = "eip3009" | "permit" | "permit2";

The exact set of supported standards may evolve over time. Always refer to the deployed core contracts and SDK for the final list.

EIP-3009 (transferWithAuthorization)

EIP‑3009 defines the transferWithAuthorization pattern:

• The token holder signs an authorization specifying:
  • from, to, value
  • valid time window
  • nonce
• Anyone can submit that authorization to the token contract.
• The token contract:
  • verifies the signature,
  • checks the time window and nonce,
  • performs the transfer exactly once.

In Exec402, EIP‑3009 is a natural fit for:

• single‑token flows where the token already implements this standard,
• clean, atomic “pull” payments that do not rely on changing allowances.

EIP-2612 (permit)

EIP‑2612 is an extension to ERC‑20 that introduces permit:

• The user signs a message authorizing a spender and allowance.
• A relayer (or any party) submits that permit on-chain.
• The token contract sets the allowance without requiring an approve transaction from the user.

Exec402 can use EIP‑2612 as:

• a way to grant the ExecCore contracts permission to pull amount + fee,
• part of a single execution flow where ExecCore:
  • calls permit to set allowance,
  • then immediately pulls tokens and executes the target call.

This pattern works well for tokens that support EIP‑2612 but not EIP‑3009.

Permit2

Permit2 is a generalized permit contract (popular in the Ethereum ecosystem) that:

• sits in front of many ERC‑20 tokens,
• handles shared logic for permits, allowance management, and spending restrictions.

In an Exec402 context, Permit2 enables:

• consistent handling of permits across many tokens,
• advanced features like shared allowances and more granular permissions,
• a path toward supporting tokens that do not natively implement EIP‑2612 or EIP‑3009.

Exec402 treats Permit2 as another permit type, with its own encoding and verification rules.

In practice:

• USDC and other tokens that natively support EIP‑3009 are a natural fit for the eip3009 permit type.
• Tokens with EIP‑2612 support can use the permit type.
• For broader ERC‑20 coverage or more advanced allowance patterns, permit2 can be used where supported, especially for tokens that do not natively implement permit-style standards. For how this fits into your code, see the examples in the Referrers guide.