> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axon402.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Spend Lifecycle

> From request to settlement — every step of a governed payment

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:

**1. Sense**

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

**2. Strategize**

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

**3. Act**

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

**4. 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:

```
1. Agent submits spend → AXON returns APPROVAL_REQUIRED
2. Operator reviews in dashboard (intent, host, amount, risk score)
3. Operator approves or denies
4. Caller checks approval status (REST or runtime tool) until approved
5. Caller consumes approval token (POST /v1/approvals/:id/consume) or retries with the returned token
6. 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) |

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.