Use approval policies for token operations

Token operations reuse the existing Qustody approval-policy 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:

{
  "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.

{
  "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:

{
  "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:

{
  "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:

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

Or update later:

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

Integration

Operations

Tokens

Use approval policies for token operations

Available rule types

Pattern 1 — Strict deployment

Pattern 2 — Conservative mint cap

Pattern 3 — Approver quorum for sensitive role changes

Pattern 4 — Off-hours block for production

Wiring policies to tokens

What happens when a rule matches

​Available rule types

​Pattern 1 — Strict deployment

​Pattern 2 — Conservative mint cap

​Pattern 3 — Approver quorum for sensitive role changes

​Pattern 4 — Off-hours block for production

​Wiring policies to tokens

​What happens when a rule matches

​Related

Available rule types

Pattern 1 — Strict deployment

Pattern 2 — Conservative mint cap

Pattern 3 — Approver quorum for sensitive role changes

Pattern 4 — Off-hours block for production

Wiring policies to tokens

What happens when a rule matches

Related