permit

The permit token feature implements EIP-2612 signature-based approvals. Holders sign a permit message off chain; integrators submit the signed permit with the spending transaction in one call. The feature attaches without operator input on almost every template.

For the operator how-to, see Permit how-to. For the architecture model, see Permit architecture.

Configuration

No featureConfigs entry required. The feature is self-contained.

EIP-712 domain

Each asset exposes its EIP-712 domain through:

GET /api/v2/token/{address}/features/permit/domain

Returns the asset's name, version, chainId, and verifyingContract fields used in the EIP-712 domain separator.

Signing a permit

The permit message follows the EIP-2612 standard:

{
  "owner": "0x...",
  "spender": "0x...",
  "value": "...",
  "nonce": "...",
  "deadline": "..."
}

Read the holder's current nonce through:

GET /api/v2/token/{address}/features/permit/nonce/{owner}

The holder signs the message with EIP-712 (eth_signTypedData_v4) and submits the signature with the spending transaction.

Submitting a signed permit

The standard EIP-2612 permit(owner, spender, value, deadline, v, r, s) call format applies. Integrations can also use the dapi convenience endpoint that combines permit + transfer in one request:

POST /api/v2/token/{address}/permit-and-transfer
{
  "owner": "0x...",
  "spender": "0x...",
  "value": "...",
  "deadline": "...",
  "signature": { "v": ..., "r": "0x...", "s": "0x..." },
  "to": "0x...",
  "amount": "..."
}

The platform validates the signature, applies the approval, and submits the transfer in one async blockchain mutation.

Behaviour

• Replayed permits (same nonce) are rejected on chain.
• Expired permits (deadline in the past) are rejected on chain.
• Permits do not bypass compliance modules. The resulting transfer evaluates normally.

Related

• Token permits for the holder-facing permit operations.
• Permit architecture