# Permit

Source: https://docs.settlemint.com/docs/operators/token-features/permit
Operate the permit token feature in the Console. Create custodial EIP-2612 approvals for a spender, set a deadline, and relay stored permits on-chain.



The permit token feature implements EIP-2612 signature-based approvals on an asset. A spender receives an allowance from a signed approval message instead of a separate `approve()` transaction, which removes the failed-because-not-yet-approved error class for integrators.

There are two ways to approve a spender with permit. In a wallet flow, a holder signs the permit in their own wallet and an integrator submits the signature with the spending transaction. In the Console custodial flow, the platform signs the permit with the holder's managed key, stores the signed permit, and relays it on-chain in a later step.

For the architecture reference, see [Permit](/docs/architects/components/token-features/permit). For the developer integration reference, see [Token permits API](/docs/api-reference/tokens/token-permits).

## 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.

## The custodial permit workflow [#the-custodial-permit-workflow]

Open the asset, then open its **Permit** page. The page has three parts:

* **Create permit approval** starts a new custodial approval for a spender.
* **Signed permits** lists every approval the platform has signed for the asset, each with a status of pending, relayed, or expired.
* **Permit replay activity** lists the on-chain `permit()` history for the asset.

A custodial approval moves through two steps. First a holder creates the approval. Creating the approval signs the permit and stores it as pending, and no transaction is sent yet. Later a custodian relays the stored approval on-chain, and the relay sets the allowance.

<Mermaid
  chart="`flowchart TB
Create[&#x22;Holder creates approval&#x22;] --> Sign[&#x22;Platform signs with holder key&#x22;]
Sign --> Pending[&#x22;Stored as pending signed permit&#x22;]
Pending --> Relay[&#x22;Custodian relays on-chain&#x22;]
Relay --> Allowance[&#x22;Allowance set, status relayed&#x22;]

style Create fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
style Sign fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
style Pending fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
style Relay fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
style Allowance fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
`"
/>

<Callout type="note" title="Creating an approval does not set an allowance">
  The approval is only signed and stored when a holder creates it. The on-chain allowance changes when a custodian
  relays the stored approval. Until then the spender cannot use the allowance.
</Callout>

## Create a permit approval [#create-a-permit-approval]

The approval owner is the holder who creates it. The platform resolves the owner from the signed-in wallet, so creating an approval acts on your own balance.

<Steps>
  <Step>
    ### Open the Permit page and start the approval [#open-the-permit-page-and-start-the-approval]

    Open the asset, open its **Permit** page, and choose **Create permit approval**.
  </Step>

  <Step>
    ### Choose the spender [#choose-the-spender]

    Enter the address that should be authorized to spend your tokens.
  </Step>

  <Step>
    ### Set the approval amount [#set-the-approval-amount]

    Choose one of three modes:

    * **Exact amount** approves a specific amount that you enter.
    * **Unlimited** approves the maximum amount the standard supports.
    * **Revoke (0)** sets the allowance to zero, which removes a prior approval after the approval is relayed.
  </Step>

  <Step>
    ### Set the deadline [#set-the-deadline]

    Choose a preset of 1 hour, 24 hours, 7 days, or 30 days, or choose **Custom** and pick a date and time. A custom deadline must be in the future. The Console rejects a deadline at or before the current time, because a permit that has already passed its deadline can never be relayed.

    The Console rechecks a custom deadline against the current time while the sheet stays open. If the time you picked passes before you sign, signing is disabled until you choose a later time, so the sheet never produces a permit that is already expired.
  </Step>

  <Step>
    ### Review and sign [#review-and-sign]

    Review the spender, amount, and deadline on the confirmation screen. Complete wallet verification and submit. The platform signs the approval and stores it as a pending signed permit. No transaction is sent at this step.
  </Step>
</Steps>

## Relay a permit approval [#relay-a-permit-approval]

Relaying applies a stored approval on-chain. The platform queue wallet pays the gas, so the holder sends nothing. After a successful relay, the allowance for the spender is set and the signed permit moves to relayed.

Relaying is a custodian action. A viewer without the custodian relay authority sees the signed permits list as read-only and cannot relay.

<Steps>
  <Step>
    ### Find a relayable approval [#find-a-relayable-approval]

    On the asset **Permit** page, review the **Signed permits** list. A pending approval that is still valid shows a **Relay** action.
  </Step>

  <Step>
    ### Confirm the holder and spender [#confirm-the-holder-and-spender]

    Choose **Relay**, then confirm the holder and spender on the review screen.
  </Step>

  <Step>
    ### Complete wallet verification and relay [#complete-wallet-verification-and-relay]

    Complete wallet verification and submit. The approval is relayed on-chain, the allowance is set, and the status changes to relayed.
  </Step>
</Steps>

## Signed permit status [#signed-permit-status]

| Status  | Meaning                                                                                           |
| ------- | ------------------------------------------------------------------------------------------------- |
| Pending | The approval is signed and stored but not yet relayed on-chain. The allowance is not set yet.     |
| Relayed | The approval has been relayed on-chain. The allowance for the spender is set.                     |
| Expired | The approval passed its deadline before it was relayed. Create a new approval to authorize again. |

## 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.
* A permit signature is per-holder, per-spender, per-nonce, and per-deadline. A single permit cannot authorize multiple spenders or operations.
* A permit relayed in a wallet flow can record an on-chain permit with no matching stored approval. The **Permit replay activity** list shows the on-chain history. The **Signed permits** list shows the custodial approvals the platform has signed.

## Troubleshooting [#troubleshooting]

| What you see                                  | What to check                                                                                                                                         |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| The deadline field rejects your custom value  | The deadline is at or before the current time. Pick a future date and time, or use a preset.                                                          |
| Sign becomes disabled while the sheet is open | Your custom deadline passed while the sheet was open. The Console disables signing once a custom deadline lapses. Pick a later time, or use a preset. |
| Create permit approval is not available       | Confirm the asset has the permit feature attached. See the [system templates catalog](/docs/operators/asset-creation/system-templates).               |
| A signed permit has no Relay action           | The approval is not relayable, or your account does not have the custodian relay authority. A relayed or expired approval has no Relay action.        |
| A signed permit shows Expired                 | The approval passed its deadline before it was relayed. Create a new approval with a future deadline.                                                 |
| Relay fails or the allowance is not set       | Confirm the approval is still pending and valid, then retry. Check the asset's transaction history for the relay result.                              |
| Wallet does not offer permit signing          | Confirm the wallet supports EIP-2612 signing. Older wallets may require a fallback to standard approve-then-transfer.                                 |

## Read next [#read-next]

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