# Permit

Source: https://docs.settlemint.com/docs/architects/components/token-features/permit
EIP-2612 gasless approvals for DALPAsset tokens. Holders sign approval messages off-chain, while a relayer submits the permit on-chain without changing transfer compliance.



Use this feature when you need a holder to approve a spender without paying gas for a separate `approve()` transaction. The holder signs an EIP-2612 message off-chain; a relayer or application submits it on-chain. The token writes the ERC-20 allowance only after the signature matches the holder, the nonce and deadline are current, and the EIP-712 domain is valid.

Permit changes the approval step, not the transfer rules. The feature does not move tokens, bypass compliance modules, or add governance settings. Any later `transferFrom` still runs through the token's normal transfer checks. For architecture context, see the [token features catalog](/docs/architects/components/token-features) and [asset contracts](/docs/architects/components/asset-contracts).

## Where permit fits [#where-permit-fits]

A typical flow works as follows:

1. The application reads feature metadata and the holder's current nonce.
2. The holder signs an EIP-712 message that names the owner, spender, value, nonce, deadline, chain, and verifying contract.
3. A relayer submits the signed message through the API or directly on-chain.
4. The token verifies the signature and deadline, consumes the nonce, and writes the allowance.
5. A later `transferFrom` uses that allowance and still goes through the token's normal transfer checks.

This makes the feature useful for Console and API flows that combine approval with a later transaction. Permit is not a transfer mechanism.

## What permit validates [#what-permit-validates]

A submitted permit must match the holder's signed message. The validation covers:

| Check             | Why it matters                                                  |
| ----------------- | --------------------------------------------------------------- |
| Owner signature   | Proves the holder approved the spender and value.               |
| Nonce             | Prevents the same signature from being accepted more than once. |
| Deadline          | Rejects signatures after the holder-approved expiry.            |
| EIP-712 domain    | Binds the signature to the permit feature contract and chain.   |
| Spender and value | Ensures the submitted allowance matches what the holder signed. |

If any check fails, the submission reverts and the allowance is unchanged. You can treat a failed permit as having no approval side effect, so your integration does not need to roll back a partial state.

## Operational boundaries [#operational-boundaries]

The feature keeps the approval experience lighter, but the surrounding controls stay the same:

* A successful submission emits the standard ERC-20 `Approval(owner, spender, value)` event.
* EIP-2612 does not emit a separate permit-specific event.
* The feature has no governance or custodian configuration.
* The feature does not run token hooks.
* Transfer compliance still applies when a spender later attempts to move tokens.
* Integrations must show the holder the spender, value, deadline, chain, and token before asking for a signature.

A signed message can authorize spending. Before you ask for a signature, confirm the holder has seen the spender address, the approved value, and the expiry deadline.

## Failure modes and edge cases [#failure-modes-and-edge-cases]

| Condition              | Result                                                                                                   |
| ---------------------- | -------------------------------------------------------------------------------------------------------- |
| Expired deadline       | The transaction reverts with no allowance change.                                                        |
| Nonce mismatch         | The transaction reverts because the signature is no longer current.                                      |
| Wrong chain or token   | Domain verification fails.                                                                               |
| Reused signature       | Nonce replay protection rejects the second submission.                                                   |
| Later transfer blocked | The allowance can exist, but `transferFrom` can still fail if token transfer checks reject the movement. |

If a holder signs more than one message for the same nonce, only one can succeed. After the token consumes that nonce, older signatures for it are invalid.

## Replay-history projection [#replay-history-projection]

DALP maintains a replay-history projection for direct EIP-2612 `permit()` transactions that the indexer can identify from the transaction selector.

The projection records the owner, token, transaction hash, block number, block time, and a per-owner display counter. Treat replay history as a forensic view for analysis, not as the source of truth for the live allowance.

Approvals routed through account-abstraction or wallet execution paths may not appear in replay history. In those paths, the outer transaction selector is not the EIP-2612 permit selector. Use the live allowance view when you need current approval state. Use replay history when an operator needs to inspect direct submissions that the indexer can identify.

## Integration guidance [#integration-guidance]

For user-facing permit flows:

1. Read the holder's current nonce and the token's EIP-712 domain data.
2. Build the message from the exact owner, spender, value, nonce, deadline, chain, and verifying contract. Use the domain data as-is; do not reconstruct it.
3. Show the holder the spender, value, token, chain, and expiry before requesting a signature.
4. Submit the signed message before the deadline expires.
5. Treat the returned allowance and any replay-history rows as separate views: allowance reflects live state; replay history is audit context.

For API usage, see [Token permit API](/docs/api-reference/tokens/token-permits).

## See also [#see-also]

* [Token permit API](/docs/api-reference/tokens/token-permits) - read permit metadata and relay signed approvals
* [Token Features Catalog](/docs/architects/components/token-features) - return to the full feature catalog
* [Asset Contracts](/docs/architects/components/asset-contracts) - deployment architecture and role model
* [Compliance Modules](/docs/compliance-security/compliance) - transfer enforcement after an allowance exists