> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quantumapi.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Use approval policies for token operations

> Configure approval-policy rules to govern token deployments, mint, burn, role changes, and pause/freeze.

Token operations reuse the existing Qustody [approval-policy](/concepts/policies) engine. This guide shows how to express common token-governance patterns with the available rule types.

## Available rule types

**General:**

* `MAX_AMOUNT` — maximum transferred amount per transaction.
* `WHITELIST_ADDRESS` / `BLACKLIST_ADDRESS` — destination address controls.
* `REQUIRE_APPROVAL` — N-of-M approver quorum.
* `TIME_WINDOW` — only allow during defined windows.
* `DAILY_LIMIT` — aggregate daily throughput per asset.

**Token-specific:**

* `TOKEN_MINT_LIMIT` — per-mint and per-day cap.
* `TOKEN_BURN_LIMIT` — per-burn and per-day cap.
* `TOKEN_ROLE_CHANGE` — multi-approver requirement for `GRANT_ROLE` / `REVOKE_ROLE`.
* `TOKEN_COMPLIANCE_CHANGE` — multi-approver requirement for `UPDATE_COMPLIANCE` and allowlist changes.

## Pattern 1 — Strict deployment

Block every deployment that has not been approved by two senior operators:

```json theme={null}
{
  "name": "deploy-strict",
  "rules": [
    { "type": "REQUIRE_APPROVAL", "minApprovers": 2, "approverGroup": "senior_operators" }
  ]
}
```

Attach this policy to the token's `adminVaultAccountId`.

## Pattern 2 — Conservative mint cap

Limit mints to a maximum amount per call and cap daily throughput.

```json theme={null}
{
  "name": "mint-conservative",
  "rules": [
    { "type": "MAX_AMOUNT", "amount": "100000000000000000000000", "asset": "QRC-20" },
    { "type": "DAILY_LIMIT", "amount": "1000000000000000000000000", "asset": "QRC-20" },
    { "type": "REQUIRE_APPROVAL", "minApprovers": 2 }
  ]
}
```

Where available, replace `MAX_AMOUNT` and `DAILY_LIMIT` with the typed `TOKEN_MINT_LIMIT` rule.

## Pattern 3 — Approver quorum for sensitive role changes

Require three approvers for any role-grant or role-revoke. Until `TOKEN_ROLE_CHANGE` exists, attach a high-friction policy to the token's admin vault and surface every role transaction to the approver UI:

```json theme={null}
{
  "name": "roles-strict",
  "rules": [
    { "type": "REQUIRE_APPROVAL", "minApprovers": 3, "approverGroup": "platform_admins" },
    { "type": "TIME_WINDOW", "allowedWindows": [{ "from": "09:00", "to": "17:00", "tz": "UTC" }] }
  ]
}
```

## Pattern 4 — Off-hours block for production

Deny any token operation outside business hours:

```json theme={null}
{
  "name": "business-hours-only",
  "rules": [
    { "type": "TIME_WINDOW", "allowedWindows": [{ "from": "09:00", "to": "17:00", "tz": "UTC", "days": ["MON","TUE","WED","THU","FRI"] }] }
  ]
}
```

## Wiring policies to tokens

Attach a policy to a token at creation time:

```http theme={null}
POST /v1/tokens
{
  "standard": "QRC-20",
  "name": "…",
  "symbol": "…",
  "decimals": 18,
  "admin": { "vaultAccountId": "vault_123", "approvalPolicyId": "policy_456" }
}
```

Or update later:

```http theme={null}
PATCH /v1/tokens/{tokenId}
{ "admin": { "approvalPolicyId": "policy_strict" } }
```

## What happens when a rule matches

| Rule outcome    | Operation status                                                      |
| --------------- | --------------------------------------------------------------------- |
| All rules pass  | Operation continues to signing.                                       |
| Approval needed | `PENDING_AUTHORIZATION` and a `approval.required` event is published. |
| Rule denies     | Operation rejected with `POLICY_DENIED`.                              |

## Related

* [Approval policies (concept)](/concepts/policies)
* [Token security model](/qustody/token-management/security-model)
* [Lifecycle](/qustody/token-management/token-operation-lifecycle)
* [Approve transaction](/api-reference/endpoint/approve-transaction)