Skip to main content
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 outcomeOperation status
All rules passOperation continues to signing.
Approval neededPENDING_AUTHORIZATION and a approval.required event is published.
Rule deniesOperation rejected with POLICY_DENIED.