Overview

What Is Gao Payment#

Gao Payment is the non-custodial, capability-gated, deterministic settlement layer of the Gao Internet protocol stack. It provides the value-transfer primitive that all other layers — including AI agents (Layer 8) — use to move value between parties.

Every settlement is a user-signed blockchain transaction. No layer of the protocol holds, pools, or custodies funds at any point. AI agents cannot initiate payments directly — they submit requests to Layer 4, which validates against the agent’s capability grant (CAP token) and pauses for user authorization where required.

Gao Payment is infrastructure — not a financial platform.

Why Layer 4 Exists#

Value transfer in Web3 today has two failure modes:

Too permissive — contracts execute without capability scoping, budget limits, or audit trails
Too custodial — payment processors hold user funds, creating counterparty risk

Gao Payment addresses both:

Capability-scoped settlement — every payment requires a valid, bounded CAP authorization
Non-custodial execution — no protocol component holds user funds
Receipt-native accounting — every transaction produces a canonical, verifiable receipt
Deterministic routing — same inputs produce the same routing decision

What Gao Payment Is / Is Not#

Gao Payment is

Gao Payment is not

A non-custodial settlement protocol

A custodial payment processor

A capability-gated execution layer

A bank or financial institution

A receipt-native accounting system

A profit-sharing or yield instrument

A machine-to-machine payment primitive

A staking-for-interest protocol

A commerce lifecycle enabler (via Gao Commerce)

An investment contract

Gao Payment enforces policy and routes transactions. It does not hold, lend, or invest funds.

Architecture#

Layer 8 — AI OS  
├── Capability Engine  
├── Risk Classifier  
└── Policy Engine  
        ↓ (authorization)  
  
Layer 4 — Gao Payment  
├── Payment Intent Engine  
├── Capability Validator  
├── Currency Routing Engine  
├── Budget Enforcement  
├── x402 HTTP Layer  
├── Settlement Engine  
└── Receipt Engine  
        ↓ (optional)  
  
Gao Commerce Gateway  
        ↓  
  
External Settlement  
├── User Wallet (Non-Custodial)  
├── Blockchain Network  
└── Infrastructure Nodes

Layer 4 executes only when authorized by a valid CAP token or explicit human wallet approval. No settlement occurs without a user-signed transaction.

Two-Component Model#

Component

Role

Custodies Funds?

Gao Payment

Settlement primitive — capability validation, routing, execution, receipts

Gao Commerce

Commerce layer — order lifecycle, checkout, merchant adapters, refunds

Gao Commerce operates on top of Gao Payment. All value movement — including refunds and disputes — settles through the Layer 4 primitive. Neither component custodies funds.

Core Properties#

Non-Custodial by Design

The protocol enforces policy. Users sign transactions. No exceptions. No component holds private keys, requires pre-deposits, or maintains escrow balances.

Capability-Gated

Every payment requires either a valid CAP token from the payer’s domain or explicit human wallet approval. No payment proceeds without one of these two authorization paths.

Deterministic Receipts

Every execution — success or failure — produces a canonical receipt that is cryptographically signed, immutable after emission, replay-protected, and linked to the originating domain and CAP token.

Policy-Before-Settlement

Requests are validated against the active policy snapshot before execution begins. Policy changes take effect on the next request, never mid-flight.

Machine-to-Machine Ready

M2M autonomous payment flows require a dedicated payment:autopay capability, are limited to Tier 0–1, and are always budget-bound. Tier 2+ always requires human confirmation, even in M2M context. Domain owners may revoke M2M access or trigger emergency_deny_all at any time.

Risk Tier Model#

Tier

Label

Description

Authorization

0–1

Low

Microtransactions, routine flows

Auto-approved within policy

Moderate

Standard commerce amounts

In-band confirmation required

High

Large transfers, cross-chain bridge

Out-of-band human authorization + confirmed finality

Cross-chain bridge operations are always classified as Tier 3, regardless of amount. Optimistic settlement (1 confirmation) is permitted for Tier 0–1 only.

Capability Model#

All payment execution requires a valid capability grant or direct user approval. A minimal CAP token for payment looks like:

{  
  "capability": "payment:send",  
  "identity": "alice.gao",  
  "domain_scope": "shop.gao",  
  "max_amount": "25",  
  "currency": "USDC",  
  "expires_at": "2026-03-01T00:00:00Z"  
}

The capability validator checks — in order: token validity and expiry, identity match, domain scope, settlement ceiling, risk tier compatibility, and budget limits. Any failure denies the payment and emits a failure receipt.

See Capability & Policy Model for the full production CAP schema, budget enforcement model, and routing logic.

Supported Assets#

USDC
USDT
Pay$ (optional Gao native stable — not required for protocol operation)
Future governance-approved stable assets

Asset availability varies by network support, jurisdiction, and integration configuration.

x402 HTTP Payment Protocol#

Enables payment-gated APIs — any HTTP endpoint can require proof of payment before serving a response. Designed for API monetization, AI agent autonomous payment, and machine-to-machine commerce.

Flow in brief:

Client requests resource → server returns HTTP 402 with payment details
Client creates intent → wallet signs → settlement confirmed
Client retries with X-Gao-Payment-Proof header (base64url-encoded receipt)
Server validates receipt → serves resource

See x402 Protocol for full server and client implementation including replay prevention.

Settlement Finality#

Tier

Finality Mode

Confirmation Depth

0–1

Optimistic

1 confirmation

Standard

Network default

Deep

6+ confirmations (or chain-specific equivalent)

Orders and downstream fulfillment cannot proceed before the required finality level is reached. See Payment Intent Lifecycle for the full state machine.

Gao Commerce Gateway#

Gao Commerce handles the commerce lifecycle on top of Gao Payment:

Order lifecycle and in-chat checkout
Merchant adapter integrations
Refund and dispute tracking

Order state flow:

INIT → QUOTE → RESERVED → PAID → FULFILLED  
                               ↘️ REFUND_REQUESTED → REFUNDED  
                               ↘️ DISPUTED

All settlement remains under Layer 4. Refunds generate receipts referencing the original and cannot exceed the original amount. Disputes affect reputation scoring only — no automatic fund seizure occurs.

Fee Model#

Total Payment =  
  Base Amount  
  + Network Fee          (gas; varies by network)  
  + Merchant Fee         (optional; set by merchant)  
  + Protocol Fee         (optional; bounded by governance)  
  + Affiliate Commission (optional)

All fees are disclosed before user signing and recorded in the receipt. No fee is charged on failed or rejected intents. No hidden fees.

Governance Model#

Governance is contribution-weighted, time-locked, and bounded in scope.

Governance may adjust: protocol fee bounds, confirmation thresholds by tier, routing preferences and bridge whitelist, approved asset list.

Governance cannot: modify completed receipts, access user funds or wallets, override user signatures, or alter active CAP token grants.

Layer Relationship#

Layer

Relationship to Payment

L3 — SDK

Developer interface for intent creation and receipt queries

L5 — Domain

Identity binding for payer and payee CAP tokens

L6 — Network

Transaction broadcast and confirmation monitoring

L7 — DePIN

Infrastructure node compensation flows

L8 — AI OS

Agent payment request submission; L4 validates under user authorization

Compliance Positioning#

Gao Payment is infrastructure, not a custodial service. It does not custody funds, guarantee returns, provide passive income, or distribute revenue. Compensation for infrastructure operators depends on independent operation, market demand, and verified service delivery.

Final regulatory interpretation depends on jurisdiction. Integrators and operators must assess applicable requirements with qualified legal counsel.

Legal Disclosures#

This document is informational only. It does not constitute investment advice, financial recommendation, legal counsel, or an offer of securities.

Participation involves technical risk, smart contract risk, market variability, and regulatory uncertainty. No guarantees are provided regarding transaction volume or economic outcomes. Users and operators are responsible for compliance with applicable laws in their jurisdiction.

Overview

Overview

What Is Gao Payment#

Why Layer 4 Exists#

What Gao Payment Is / Is Not#

Architecture#

Two-Component Model#

Core Properties#

Non-Custodial by Design

Capability-Gated

Deterministic Receipts

Policy-Before-Settlement

Machine-to-Machine Ready

Risk Tier Model#

Capability Model#

Supported Assets#

x402 HTTP Payment Protocol#

Settlement Finality#

Gao Commerce Gateway#

Fee Model#

Governance Model#

Layer Relationship#

Further Reading#

Compliance Positioning#

Legal Disclosures#