Core Concepts

AXON governs how AI agents spend — buying x402 resources from providers using a policy-enforced runtime. The core SSAR pipeline (Sense → Strategize → Act → Report) controls what agents can buy, when, and for how much. Mandates, approvals, circuit breakers, and on-chain settlement make up the safety layer. Start with Mandates.

Two product planes

AXON separates responsibilities across two planes:

Control plane — dashboard and axon-op. This is where operators create wallets, mint keys, edit mandates, and fund treasury.
Runtime plane — MCP, OpenClaw, or runtime REST. This is where a worker agent uses one wallet-scoped credential to call governed_fetch, read policy, handle approvals, and fetch receipts.

If you are new to AXON, start with one of these:

Quickstart for the hosted runtime bootstrap
Live Onboarding for the self-hosted operator path

Runtime Hierarchy

Organization
  ├── Departments (optional)
  ├── Wallets
  │   ├── Vault wallets (master treasury)
  │   └── Agent Pocket wallets (per-agent)
  ├── Mandates (spend-side governance)
  ├── Spend Requests / Decision Events / Spend Approvals
  ├── Payment Receipts
  └── Provider Registry

Architecture

Layer	Technology	Purpose
API Gateway	REST	Management and configuration
MCP Server	Model Context Protocol	AI agent interface
Policy Engine	JSON Schema evaluation	Real-time mandate enforcement
Wallet Manager	HD Derivation (BIP-44)	Secure key management
x402 Client	EIP-3009 TransferWithAuthorization	Payment signing
Facilitator	CDP x402 Facilitator	Payment verification and settlement
Audit Ledger	PostgreSQL + Event Store	Proof-of-intent logging

AXON’s Role in x402

AXON doesn’t replace x402 — it governs it. AXON adds the policy layer, budget controls, and audit trail that enterprises require before giving agents autonomous spending authority.

┌─────────────────────────────────────────────────────────┐
│                    x402 ECOSYSTEM                        │
│                                                         │
│   ┌──────────┐    ┌──────────┐    ┌──────────────┐     │
│   │  Sellers  │◄──►│   AXON   │◄──►│  Facilitator │     │
│   │(x402 APIs)│    │(CFO Layer)│    │    (CDP)     │     │
│   └──────────┘    └──────────┘    └──────────────┘     │
│         │               │               │               │
│         └───────────────┼───────────────┘               │
│                         │                               │
│                ┌────────▼────────┐                      │
│                │  Base Network   │                      │
│                │  (eip155:8453)  │                      │
│                └─────────────────┘                      │
└─────────────────────────────────────────────────────────┘

Provider Registry

provider_registry stores known provider metadata such as host, path prefix, payee address, asset, and network. The runtime can operate in:

Soft mode (default): allow unmatched providers but surface warnings
Strict mode: reject unmatched providers (AXON_REQUIRE_PROVIDER_REGISTRY=true)

Next Steps

Organizations & Wallets

Vaults, departments, and agent pockets.

Mandates

Policy-as-code spending controls.

Spend Lifecycle

From request to settlement.

x402 Protocol

Payment headers and settlement flow.

Getting Started

CLI

Core Concepts

Integrations

Operations

Core Concepts

Two product planes

Runtime Hierarchy

Architecture

AXON’s Role in x402

Provider Registry

Next Steps

Organizations & Wallets

Mandates

Spend Lifecycle

x402 Protocol

​Two product planes

​Runtime Hierarchy

​Architecture

​AXON’s Role in x402

​Provider Registry

​Next Steps

Organizations & Wallets

Mandates

Spend Lifecycle

x402 Protocol

Two product planes

Runtime Hierarchy

Architecture

AXON’s Role in x402

Provider Registry

Next Steps