G

Capability & Policy Model

Capability & Policy Model

How CAP tokens, budget enforcement, and routing policy govern every payment on Gao Payment.

Overview#

Gao Payment does not execute any settlement without one of two authorization paths:

  1. A valid Capability Token (CAP) granting the payment scope — used by AI agents and automated flows

  2. Explicit human wallet approval — used for direct user-initiated payments

This document covers the CAP token schema for payment capabilities, the budget enforcement model, currency routing logic, and the policy snapshot mechanism.

Payment CAP Token Schema#

Payment capabilities are a specialized subset of the Gao Internet CAP token model. A payment CAP token grants an agent or automated flow the right to initiate payment requests within defined limits.

{  
  "cap_id": "cap_pay_abc123",  
  "aud": "payment.gao.systems",  
  "scope_id": "commerce:order-settlement",  
  "capability": "payment:send",  
  "agent_id": "seal:order-processor",  
  "payer_domain": "acme.gao",  
  "domain_scope": ["shop.gao", "supplier.gao"],  
  "issued_by": "domain_owner_address",  
  "issued_at": "2026-03-01T00:00:00Z",  
  "expires_at": "2026-06-01T00:00:00Z",  
  "nonce": "f3a2b1c9d8e7",  
  "risk_tier": 2,  
  "budget": {  
    "per_transaction": { "amount": "500", "currency": "USDC" },  
    "daily_aggregate": { "amount": "2000", "currency": "USDC" },  
    "monthly_aggregate": { "amount": "20000", "currency": "USDC" }  
  },  
  "allowed_currencies": ["USDC", "USDT"],  
  "allowed_networks": ["base", "polygon"],  
  "m2m_enabled": false,  
  "policy_version": "acme.gao:payment-policy:v2",  
  "domain_anchor_ref": "0x...",  
  "revocable": true,  
  "revocation_endpoint": "https://api.gao.systems/v1/cap/revoke",  
  "issued_chain": "base",  
  "signature": "0x..."  
}

Field Reference

Field

Description

aud

Intended runtime audience — validated by Payment layer before accepting

capability

Must be payment:send for outbound settlement, payment:autopay for M2M

payer_domain

Domain whose funds are being authorized

domain_scope

Allowlisted payee domains; ["*"] not permitted for payment capabilities

nonce

Anti-replay; unique per (payer_domain, cap_id)

risk_tier

Maximum tier this CAP authorizes without escalation

budget

Spending limits at transaction, daily, and monthly scope

allowed_currencies

Whitelist of accepted settlement currencies

allowed_networks

Whitelist of accepted settlement networks

m2m_enabled

Whether this CAP authorizes fully autonomous M2M payment

policy_version

Domain policy version this CAP was issued against

domain_anchor_ref

On-chain domain state reference at time of issuance

revocation_endpoint

Real-time revocation check; queried on every intent validation

M2M Capability Token#

Machine-to-machine autonomous payments require a separate payment:autopay capability with additional constraints:

{  
  "capability": "payment:autopay",  
  "m2m_enabled": true,  
  "m2m_constraints": {  
    "per_transaction": { "amount": "50", "currency": "USDC" },  
    "per_hour": { "amount": "200", "currency": "USDC" },  
    "allowlisted_payees": ["infra.gao", "relay.gao"],  
    "emergency_deny_all": false  
  }  
}

M2M payments are additionally restricted to:

  • risk_tier 0–1 only — Tier 2+ always requires human confirmation

  • No disputed payees

  • emergency_deny_all can be set by the domain owner at any time to halt all M2M activity immediately

Budget Enforcement#

The Budget Enforcement module tracks spending against all active CAP tokens for a domain and blocks intents that would exceed any limit.

Budget Accounting

Per-transaction check:  
  intent.amount ≤ cap.budget.per_transaction.amount → PASS  
  else → REJECTED (PAY_003)  
  
Daily aggregate check:  
  sum(settled_today, payer_domain, cap_id) + intent.amount  
    ≤ cap.budget.daily_aggregate.amount → PASS  
  else → REJECTED (PAY_004)  
  
Monthly aggregate check:  
  sum(settled_this_month, payer_domain, cap_id) + intent.amount  
    ≤ cap.budget.monthly_aggregate.amount → PASS  
  else → REJECTED (PAY_004)

Budget counters are updated after settlement confirmation, not at intent creation. This means concurrent in-flight intents could theoretically exceed budget if submitted simultaneously. Integrators managing high-volume flows should use sequential intent submission or set conservative per-transaction limits.

Budget Reset

  • Daily budget resets at 00:00 UTC

  • Monthly budget resets on the 1st of each month at 00:00 UTC

  • Resets do not apply to in-flight intents (those already in AUTHORIZED or CONFIRMING state)

Policy Snapshot#

The active domain payment policy is loaded as a snapshot at intent validation time. The snapshot hash is embedded in the receipt.

Policy changes take effect on the next payment intent, never mid-flight.

Policy Object Fields

Field

Description

allowed_tools

Permitted payment initiation contexts (SDK, Workspace, agent)

settlement_rules

Default currency and network preferences

risk_overrides

Per-payee or per-merchant risk tier adjustments

confirmation_thresholds

Per-tier confirmation depth requirements

notification_hooks

Post-settlement webhook endpoints

override_contacts

Human contacts for Tier 3 escalation

m2m_policy

M2M-specific budget and allowlist overrides

Currency Routing#

The Currency Router selects the settlement path deterministically using a prioritized rule set:

1. Merchant (payee) preferred network  
2. Lowest effective fee for intent.amount on available networks  
3. Payer wallet compatibility (available balance on network)  
4. Governance-approved network priority overrides

If no network satisfies all constraints, the intent is rejected with PAY_006.

Cross-Chain Settlement

Cross-chain settlement (e.g., payer on Base, payee on Polygon) is permitted only if:

  • The bridge is on the governance-approved bridge whitelist

  • Slippage is within the policy-defined tolerance

  • The additional bridge fee is disclosed in the intent before user signing

  • The user explicitly approves the cross-chain path

Cross-chain intents are automatically classified as Tier 3 regardless of amount, due to the additional confirmation complexity.

Invariants#

The following invariants are enforced by the Payment layer and cannot be overridden:

ID

Invariant

PAY-INV-01

No settlement executes without a valid, non-expired CAP token or explicit human wallet signature

PAY-INV-02

Policy snapshot is hashed and locked at intent validation; changes cannot affect in-flight intents

PAY-INV-03

Budget checks occur before authorization; overage intents are rejected, never queued

PAY-INV-04

Every intent produces exactly one receipt — success or failure

PAY-INV-05

Cross-chain intents are always Tier 3

PAY-INV-06

M2M autopay is limited to Tier 0–1; Tier 2+ always requires human confirmation

PAY-INV-07

Tier 3 intents require out-of-band human authorization before broadcast

PAY-INV-08

Governance cannot modify completed receipts or active CAP token grants

The Capability & Policy Model is the authorization backbone of Gao Payment. No settlement proceeds without a valid capability grant and policy compliance. See Payment Intent Lifecycle for the full execution flow.