# permit

Source: https://docs.settlemint.com/docs/developers/api-integration/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 permit message off chain; integrators submit the signed permit 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 required. The feature is self-contained.

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

Each asset exposes its EIP-712 domain through:

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

Returns the asset's `name`, `version`, `chainId`, and `verifyingContract` fields used in the EIP-712 domain separator.

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

The permit message follows the EIP-2612 standard:

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

Read the holder's current nonce through:

```
GET /api/v2/token/{address}/features/permit/nonce/{owner}
```

The holder signs the message with EIP-712 (`eth_signTypedData_v4`) and submits the signature with the spending transaction.

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

The standard EIP-2612 `permit(owner, spender, value, deadline, v, r, s)` call format applies. Integrations can also use the dapi convenience endpoint that combines permit + 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]

* Replayed permits (same `nonce`) are rejected on chain.
* Expired permits (`deadline` in the past) are rejected on chain.
* Permits do not bypass compliance modules. The resulting transfer evaluates normally.

## Related [#related]

* [Token permits](/docs/developers/api-integration/tokens/token-permits) for the holder-facing permit operations.
* [Permit architecture](/docs/architects/components/token-features/permit)