G

Security Model

Security Model

Threat model, settlement invariants, and attack surface analysis for Layer 4 of the Gao Internet protocol stack.

Design Principles#

Gao Payment security rests on three properties that cannot be traded off:

  1. No settlement without explicit authorization — every payment requires either a valid, bounded CAP token or a direct user wallet signature

  2. Non-custodial at every layer — no component of the payment stack holds, pools, or manages user funds

  3. Receipt completeness — every execution produces a receipt; silent failure is not possible

Threat Model#

In-Scope Threats

Threat

Mitigation

Unauthorized payment initiation (no valid CAP)

PAY-INV-01: CAP validation required before any intent proceeds

Budget overflow via concurrent intents

Budget counters updated post-confirmation; concurrent ceiling via max_concurrent_intents limit

CAP token forgery

Domain-owner signed; validated against on-chain domain state at L5

CAP token replay

nonce field unique per (domain, cap_id); nonce log maintained per domain

Policy tampering mid-flight

Policy snapshot locked and hashed at validation start; PAY-INV-02

Receipt forgery

Runtime signature over full receipt payload; independently verifiable

Receipt replay (x402)

receipt_id deduplication on server side; enforced by x402 middleware

Settlement routing manipulation

Routing is deterministic and governance-constrained; no dynamic override by agents

Cross-chain bridge exploitation

Bridge whitelist governance-controlled; cross-chain auto-classified as Tier 3

M2M payment abuse

payment:autopay CAP limited to Tier 0–1; emergency_deny_all flag available

Governance capture of payment parameters

Governance scope bounded: cannot modify receipts, CAP grants, or user signatures

Out-of-Scope Threats

The following are outside the Gao Payment threat model:

  • Compromise of the domain owner’s private key → L5 threat; mitigation at Domain layer

  • Smart contract vulnerabilities in the on-chain settlement contract → independent audit scope

  • Front-running of broadcast transactions → network layer (L6) mitigation

  • Price oracle manipulation for cross-currency settlement → asset governance scope

  • Phishing of human authorization flow → application layer; outside protocol scope

Settlement Invariants#

The following invariants are enforced by the Payment layer and cannot be overridden by any agent, operator, or governance action:

ID

Invariant

Enforcement Point

PAY-INV-01

No settlement without valid CAP or direct wallet signature

Capability Validator

PAY-INV-02

Policy snapshot locked at validation; immutable for intent lifetime

Policy Gate

PAY-INV-03

Budget overage intents are rejected, never queued or partial-filled

Budget Enforcement

PAY-INV-04

Every intent — success or failure — emits exactly one receipt

Receipt Engine

PAY-INV-05

Cross-chain intents are always Tier 3 regardless of amount

Risk Classifier

PAY-INV-06

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

Capability Validator

PAY-INV-07

Tier 3 intents pause before broadcast; out-of-band human authorization required

Intent Lifecycle

PAY-INV-08

Governance cannot modify completed receipts or active CAP token grants

Ledger; CAP Registry

PAY-INV-09

No funds are held, pooled, or escrowed by any protocol component

Architecture-level

PAY-INV-10

Receipt receipt_id is globally unique; duplicates are rejected

Receipt Engine

Non-Custodial Architecture Verification#

The non-custodial property is verified at every layer of the payment flow:

Component

Funds Contact?

Explanation

Intent Engine

No

Creates records only; no wallet access

Capability Validator

No

Reads and validates token data only

Risk Classifier

No

Assigns tier; no value contact

Budget Enforcement

No

Reads settlement history; no wallet access

Currency Router

No

Selects path; does not execute

Settlement Engine

No

Submits pre-signed transactions; does not hold keys

Receipt Engine

No

Writes records only

No Gao Payment component has access to private keys or controls wallet signing.

CAP Token Security#

Validation Chain

Every payment intent validates the CAP token through a complete chain:

1. Signature valid (domain owner signed)  
2. aud == "payment.gao.systems"  
3. Domain ownership confirmed on-chain (L5)  
4. nonce not previously seen for this domain  
5. Not expired (expires_at > now)  
6. Not revoked (revocation_endpoint check)  
7. intent.amount ≤ cap.budget.per_transaction  
8. intent.payee_domain in cap.domain_scope  
9. intent.currency in cap.allowed_currencies  
10. intent.network in cap.allowed_networks

Any failure in this chain rejects the intent immediately with a specific error code.

Revocation

CAP tokens can be revoked immediately by the domain owner. The revocation_endpoint in the CAP token is queried on every intent validation. A revoked token causes immediate rejection of all subsequent intents, including those already in PENDING_AUTH state.

In-flight intents already in AUTHORIZED or CONFIRMING state at time of revocation are not cancelled — the user signature was already given and the transaction is in-flight on-chain.

Receipt Security#

Receipts are the tamper-evident audit record of the payment layer.

Property

Mechanism

Forgery prevention

Runtime keypair signature over full payload hash

Tamper detection

SHA-256 content hash in signature payload

Replay prevention

Globally unique receipt_id; append-only ledger

Post-emission immutability

Ledger is append-only; no update operation exists

On-chain verifiability

anchor_tx_hash on-chain is independently verifiable

Cross-version auditability

schema_version and runtime_version fields enable version-specific verification

Governance Security Boundary#

Governance is explicitly scoped to prevent it from becoming an attack vector against active payment flows.

Governance MAY:

  • Adjust protocol fee bounds (within defined maximum)

  • Update the bridge whitelist

  • Modify default confirmation thresholds

  • Update the approved asset list

Governance MUST NOT and technically cannot:

  • Modify completed receipts (ledger is append-only)

  • Alter active CAP token grants

  • Access user funds or wallets

  • Override settlement finality

  • Change the non-custodial invariants (architecture-level, not governance-controlled)

Known Limitations#

  1. Concurrent budget overage — if multiple intents are created simultaneously for the same CAP token, they may collectively exceed the daily budget before any settles. Mitigation: set conservative per-transaction limits or use sequential intent creation for high-frequency flows.

  2. CAP revocation of in-flight intents — intents already in AUTHORIZED or CONFIRMING state when a CAP is revoked are not cancelled. The user signature was already given. New intents are immediately blocked.

  3. Cross-chain confirmation latency — Tier 3 cross-chain settlements may take significantly longer than same-chain due to bridge confirmation requirements. The expires_in window for downstream fulfillment must account for this.

  4. Revocation endpoint availability — if the revocation endpoint is temporarily unavailable, the payment layer falls back to cached revocation state (TTL: 60 seconds). Revocations may take up to 60 seconds to propagate.

  5. Receipt ledger availability — the on-chain anchor hash is always verifiable independently. Full receipt payload retrieval depends on ledger availability; extended outages require operator intervention.

This security model covers Gao Payment (GP/1.1). Adjacent layer security models are documented separately for Gao Domain (L5), Gao Network (L6), and Gao AI OS (L8).