# Permit

Source: https://docs.settlemint.com/docs/operators/token-features/permit
How the permit token feature enables EIP-2612 signature-based ERC-20 approvals on DALP assets, removing the need for a separate approval transaction.



The permit token feature implements EIP-2612 signature-based approvals on the asset. Instead of submitting a separate approval transaction before spending, a holder signs a permit message off chain and submits it with the spending transaction in one call. The feature reduces approval friction for integrators and removes the failed-because-not-yet-approved error class.

For the architecture reference, see [Permit](/docs/architects/components/token-features/permit).

## When it attaches [#when-it-attaches]

Almost every system template attaches permit. See the [system templates catalog](/docs/operators/asset-creation/system-templates).

## What you configure [#what-you-configure]

Nothing during asset creation. The feature has no operator-configurable parameters. The Asset Designer marks it as self-contained.

## What you operate [#what-you-operate]

After deployment, the feature runs without operator action:

* **Holders sign permits off chain** through their wallet. Wallets supporting EIP-2612 expose a signature flow for the permit message.
* **Integrators submit the signed permit** with the spending transaction. The asset contract verifies the signature, applies the approval, and executes the transfer in one call.
* **No explicit operator step** is required. The feature is part of the asset contract's standard behaviour after attachment.

## Operating considerations [#operating-considerations]

* Permits include a nonce, deadline, and EIP-712 domain separator. Replayed permits are rejected on chain.
* Permits do not bypass compliance modules. Identity verification, country restrictions, allow-lists, and transfer approval all evaluate normally on the resulting transfer.
* The permit signature is per-holder per-spender per-nonce per-deadline. A single permit cannot authorise multiple spenders or operations.

## Troubleshooting [#troubleshooting]

| What you see                                   | What to check                                                                                                         |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Permit submission fails with "deadline passed" | The signed permit included a `deadline` in the past. Sign a fresh permit.                                             |
| Wallet does not offer permit signing           | Confirm the wallet supports EIP-2612 signing. Older wallets may require a fallback to standard approve-then-transfer. |
| Permit accepted but transfer rejected          | The transfer hit a compliance module check unrelated to the permit. Inspect the configured compliance modules.        |

## Read next [#read-next]

* [Permit architecture](/docs/architects/components/token-features/permit)
* [System templates catalog](/docs/operators/asset-creation/system-templates)
* [Token permits API](/docs/developers/api-integration/tokens/token-permits) for the developer integration reference.