Spend Lifecycle

On the runtime plane, governed_fetch is the default paid-call entrypoint. For each governed request, AXON creates or updates several entities that form the complete audit trail.

Lifecycle Entities

Entity	Purpose
Spend Request	The business request and original intent
Decision Events	Deterministic, risk, and final decisions
Payment Receipt	x402 challenge and settlement artifacts
Transaction	Payment execution record when a spend settles
Balance Snapshot	Cached on-chain balance for dashboard views
Chain Events	Observed Base transfer history
Spend Approval	Pending or resolved human approval

SSAR Pipeline

Every governed request flows through the 4-stage SSAR pipeline:

Sense

Parse the request context: URL, intent, wallet, headers, idempotency key, and task metadata.

Strategize

Run deterministic policy checks (mandate, budget, allow/block list, network) followed by risk scoring. If risk exceeds the threshold, escalate to human approval.

Act

If approved, sign the EIP-3009 payment and retry the original request with the payment signature. Record the transaction.

Report

Store the decision, receipt, and transaction. Emit forensic webhooks. Update balance snapshots.

Decision Stages

Each spend request generates up to three decision events:

Stage	What it checks
Deterministic	Wallet active, mandate present, idempotency, allow/block list, limits, network
Risk	Risk scoring, alignment checking, approval thresholds
Final	Combined outcome after all stages + approval (if applicable)

Transaction States

Status	Description	x402 Phase
`signed`	EIP-3009 signature created	PAYMENT-SIGNATURE sent
`pending`	Awaiting on-chain confirmation	Facilitator processing
`confirmed`	Finalized on-chain	PAYMENT-RESPONSE received
`failed`	Transaction reverted	On-chain failure
`expired_unconfirmed`	Transaction not confirmed before timeout	On-chain confirmation delay
`blocked_policy`	Denied by mandate	Before signing
`blocked_liquidity`	Insufficient funds	Before signing

Approval Flow

When AXON decides a request needs human review:

Agent submits spend → AXON returns APPROVAL_REQUIRED
Operator reviews in dashboard (intent, host, amount, risk score)
Operator approves or denies
Caller checks approval status (REST or runtime tool) until approved
Caller consumes approval token (POST /v1/approvals/:id/consume) or retries with the returned token
Caller retries the same governed request with the same idempotency_key + approval_token

Prefer check_approval_status or wait_for_approval_resolution on the runtime surface. Consume the token only when you are ready to perform the retry.

Approval States

State	Description
`pending`	Awaiting operator review
`approved`	Approved, token available for consumption
`denied`	Rejected by operator
`expired`	Not consumed before TTL (default 5 minutes)

Approval tokens are single-use, request-scoped (wallet/host/path/method/idempotency), and short-lived.

Getting Started

CLI

Core Concepts

Integrations

Operations

Spend Lifecycle

Lifecycle Entities

SSAR Pipeline

Decision Stages

Transaction States

Approval Flow

Approval States

​Lifecycle Entities

​SSAR Pipeline

​Decision Stages

​Transaction States

​Approval Flow

​Approval States

Lifecycle Entities

SSAR Pipeline

Decision Stages

Transaction States

Approval Flow

Approval States