# Permit

Source: https://docs.settlemint.com/docs/architecture/components/token-features/permit
EIP-2612 gasless approvals for DALPAsset. Users sign approval messages off-chain; anyone can submit the signature on-chain to set an allowance without the holder paying gas.



Permit adds EIP-2612 gasless approvals to DALPAsset tokens. A token holder signs an approval message off-chain, and a relayer or authorized application submits the signature on-chain to set the ERC-20 allowance without the holder sending the approval transaction.

Permit is independent of token transfer hooks and governance configuration. The feature sets an allowance only after it accepts a valid owner signature, deadline, nonce, and EIP-712 domain.

Related architecture pages: [token features catalog](/docs/architecture/components/token-features) and [asset contracts](/docs/architecture/components/asset-contracts).

***

## Interface (capabilities) [#interface-capabilities]

This feature exposes the following capabilities. It implements EIP-2612 gasless approvals as a UX utility. It has no hooks, lifecycle integration, or governance configuration.

| Capability            | Who can call                  | Inputs                                      | On-chain effect                | Emits      | Notes                                   |
| --------------------- | ----------------------------- | ------------------------------------------- | ------------------------------ | ---------- | --------------------------------------- |
| Approve via signature | Anyone (with valid signature) | Owner, spender, amount, deadline, signature | Sets ERC-20 spending allowance | `Approval` | Nonce-based replay protection; no hooks |
| Query nonce           | Anyone                        | Account address                             | None (view-only)               | None       | Required to construct valid signatures  |

***

## Business impact [#business-impact]

* **Holders:** Can approve spending without paying gas. Enables single-transaction "approve-and-transfer" flows where the dApp submits the permit and transfer in one transaction.
* **Issuer / platform:** Improves onboarding UX for integrations requiring allowances (e.g., DeFi protocols, capability contracts). No economic impact.
* **Economics:** No token movement. Pure UX utility feature.

***

## Risks & abuse cases [#risks--abuse-cases]

* **Phishing:** Users who sign permit messages without checking the spender, amount, deadline, and chain ID can inadvertently authorize malicious spenders. Wallet UX must clearly display permit details.
* **Signature replay across chains:** Permit signatures are domain-separated (chain ID + contract address). A signature from one chain cannot be replayed on another, but users should be aware that signing is irreversible until the deadline expires.
* **Expired permits:** Permit signatures include a deadline. Submitting after the deadline reverts. Callers must check deadline before submission.

***

## Controls & guardrails [#controls--guardrails]

| Role | Actions                                             |
| ---- | --------------------------------------------------- |
| None | No `GOVERNANCE_ROLE` or `CUSTODIAN_ROLE` parameters |

Permit has no on-chain configuration. Nonce-based replay protection is automatic. Each signature can only be submitted once.

***

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

* **Deadline expired:** Submitting a valid signature after the deadline reverts with no effect.
* **Nonce mismatch:** If the holder submits any transaction that changes their nonce (including another permit), all outstanding permits for older nonces become invalid.
* **Wrong chain ID:** Signatures from another chain (or testnet) will fail domain verification.

***

## Auditability & operational signals [#auditability--operational-signals]

* `Approval(owner, spender, value)` - standard ERC-20 event emitted when permit is submitted successfully. Indistinguishable from a regular approval in event logs.
* No permit-specific event in base EIP-2612. Submitter address is in transaction calldata, not event logs.

***

## Dependencies [#dependencies]

* No external dependencies.
* No other features required.
* No hooks: completely independent of the feature hook execution chain.

***

## Compatibility & ordering notes [#compatibility--ordering-notes]

* **No hooks**: does not interact with `onMinted`, `onBurned`, `onTransferred`, or `onRedeemed`.
* Order in the feature array is irrelevant.
* Compatible with all other features. Low-risk utility.
* Compatible with compliance modules: permit sets an allowance; the subsequent transfer still goes through compliance checks.

***

## Change impact [#change-impact]

* **Enable after launch:** Immediately enables gasless approvals. No retroactive effect.
* **Disable:** Outstanding signed-but-not-submitted permits are no longer valid. Any integration relying on permit-based flows must fall back to standard `approve()`.
* **No configuration to change.**

***

## See also [#see-also]

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