# permit

Source: https://docs.settlemint.com/docs/api-reference/token-features/permit
API reference for the DALP permit token feature, which enables EIP-2612 signature-based approvals on the asset.



The `permit` token feature implements EIP-2612 signature-based approvals. Holders sign a message off chain; you then submit the signed authorization 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](/docs/operators/token-features/permit). For the architecture model, see [Permit architecture](/docs/architects/components/token-features/permit).

## Configuration [#configuration]

No `featureConfigs` entry is required. The feature is self-contained and carries no configurable parameters.

## EIP-712 domain [#eip-712-domain]

Each asset exposes its EIP-712 domain at:

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

The response includes the asset's `name`, `version`, `chainId`, and `verifyingContract` fields. Use these values to build the EIP-712 domain separator when constructing the typed-data payload.

## Signing a permit [#signing-a-permit]

The EIP-2612 message payload requires these five fields. Fetch the holder's current nonce from `GET /api/v2/token/{address}/features/permit/nonce/{owner}` before building the payload.

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

The holder signs the payload with `eth_signTypedData_v4` and passes the resulting signature with the spending transaction. A reused or expired nonce causes the on-chain call to revert.

## Submitting a signed permit [#submitting-a-signed-permit]

The standard EIP-2612 `permit(owner, spender, value, deadline, v, r, s)` call format applies. You can also use the Platform API convenience endpoint that combines the authorization and the 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 [#behaviour]

* The chain rejects replayed authorizations (same `nonce`).
* The chain rejects expired authorizations (`deadline` in the past).
* A permit does not bypass compliance modules. The resulting transfer evaluates through the full compliance stack.

## Related [#related]

* [Token permits](/docs/api-reference/tokens/token-permits) for the holder-facing permit operations.
* [Managed permits](/docs/api-reference/tokens/managed-permits) for signing a permit with a holder's managed key and relaying it later as the custodian.
* [Permit architecture](/docs/architects/components/token-features/permit)