Key Concepts
Core terminology and concepts you need to know when building with Axon.
Key Concepts
This page defines the core terms and concepts used throughout Axon's documentation, SDK, and dashboard.
Actors
Owner
The vault owner and administrator. An owner deploys one or more vaults, registers bot addresses, defines spending policies, and reviews flagged transactions.
An owner typically uses a hardware wallet or multisig for vault ownership. They interact with Axon through the dashboard or directly via smart contract calls.
Bot / Agent
An autonomous AI agent that makes payments on behalf of an owner. Bots sign EIP-712 payment intents using their private key but never hold ETH and never submit transactions on-chain. Their attack surface is intentionally minimal: a compromised bot key can only produce signed intents that expire within minutes and are bounded by configured spending limits.
Relayer / Executor
The off-chain infrastructure operated by Axon that validates, simulates, and executes signed payment intents. The relayer pays gas on behalf of bots, runs the policy engine, and orchestrates AI verification when needed. Its on-chain identity (the delegator) is the only address permitted to call executePayment on a vault contract.
Operator
An optional hot wallet address that an owner can designate to handle day-to-day bot management. The operator can add bots, remove bots, lower limits, and pause the vault, but cannot raise limits above owner-set ceilings, add whitelisted destinations, unpause the vault, withdraw funds, or change the operator. This separation lets owners keep their key in cold storage while still managing their bot fleet.
Infrastructure
Vault
A non-custodial smart contract deployed per owner via the AxonVaultFactory. The vault holds ERC-20 tokens (primarily USDC), ERC-721 NFTs, and ERC-1155 multi-tokens. It enforces bot authorization and signature verification on-chain, and executes payments, protocol interactions, and swaps. Only the vault owner can withdraw funds and NFTs. Vaults are not upgradeable; new features ship as new vault versions that owners opt into.
Vault Factory
The AxonVaultFactory contract that deploys new vault instances. Each factory is tied to a specific vault template version. The factory emits a VaultDeployed(owner, vault, version) event for every deployment, enabling indexing and dashboard discovery.
Axon Registry
The AxonRegistry contract maintained by Axon that tracks authorized relayer (delegator) addresses. Each vault references a registry immutably at deploy time. The vault checks this registry on every executePayment call to confirm the caller is authorized.
Payment Primitives
Payment Intent
The core data structure that a bot signs to authorize a payment. It is an EIP-712 typed data structure containing:
| Field | Type | Description |
|---|---|---|
bot | address | The signing bot's address (must be active in the vault) |
to | address | The payment recipient |
token | address | The ERC-20 token to transfer (e.g., USDC) |
amount | uint256 | The payment amount in the token's smallest unit |
deadline | uint256 | Unix timestamp after which the intent expires |
ref | bytes32 | A reference linking the on-chain transaction to off-chain records |
The bot signs this struct; the vault contract verifies the signature on-chain.
Reference (ref)
A bytes32 value included in the signed intent and emitted in on-chain events. It links the on-chain transaction to off-chain records (invoices, job IDs, memos) stored in the relayer's database. The SDK's encodeRef() function hashes any string with keccak256 to produce a deterministic bytes32 value. The full original text is stored off-chain by the relayer.
Idempotency Key
A UUID submitted with every payment request to the relayer API. If the same key is submitted twice, the relayer returns the original response without re-executing. This prevents double-payments on network retries. Required on every POST /v1/payments call.
Policy and Verification
Policy Engine
The off-chain rules engine that the relayer runs before executing any payment. It reads policy configuration from the vault's on-chain BotConfig and enforces:
- Per-transaction limit (
maxPerTxAmount) — also enforced on-chain as a hard cap - Spending limits — rolling time-window limits (e.g., $500/day, $1000/week) tracked in Redis
- Velocity checks — detects unusual spending bursts within short windows
- Destination whitelist — restricts which addresses a bot can pay
AI Verification
A three-agent LLM verification layer triggered when a payment exceeds configured thresholds. Three independent agents analyze the payment in parallel:
| Agent | Role |
|---|---|
| Safety Agent | Analyzes the destination address and contract bytecode for known risks |
| Behavioral Agent | Compares the payment against the bot's historical transaction patterns using Z-score analysis |
| Reasoning Agent | Inspects the transaction memo for signs of prompt injection or manipulation |
Two out of three agents must approve for the payment to proceed. If consensus is not reached, the payment is routed to the owner's human review queue. All decisions are logged for auditing.
Human Review Queue
When AI verification fails to reach consensus, or when a bot is configured to always require manual approval, the payment enters the owner's review queue. The owner receives a push notification and can approve or reject the payment from the dashboard. The queue shows the bot identity, amount, destination, memo, AI agent scores, and recent bot activity.
Access Controls
Axon has three distinct access control mechanisms that restrict different operations. Understanding the difference is important when configuring your vault.
Destination Whitelist
Controls where bots can send payments (wallet addresses). Applied during executePayment().
- Global whitelist -- applies to all bots in the vault. Owner adds, operator can remove.
- Per-bot whitelist -- applies to a specific bot only. Owner adds, operator can remove.
- Empty whitelist (default) -- any destination is allowed. Adding an address switches to opt-in mode.
Evaluation order: global blacklist (always wins) -> global whitelist -> per-bot whitelist -> allowed.
Destination Blacklist
A vault-level blocklist that always takes priority. If an address is on the blacklist, no bot can pay it -- even if it is on a whitelist. Use this to permanently block known-bad addresses (scam contracts, sanctioned wallets).
Protocol Approvals
Controls which smart contracts the vault can interact with via executeProtocol(). This is completely separate from destination whitelists.
- The vault owner must call
approveProtocol(contractAddress)for each DeFi protocol the vault should be able to call (e.g., Uniswap Router, Ostium Trading, Lido stETH). - Without approval,
executeProtocol()reverts withContractNotApproved. - Common tokens (USDC, USDT, WETH, DAI) are pre-approved globally via the Axon registry, so you typically only need to approve the DeFi protocol contract itself.
Whitelists vs. Protocol Approvals -- what's the difference?
Destination whitelists gate who you pay -- they restrict wallet addresses that can receive payment transfers. Protocol approvals gate what contracts you call -- they restrict which smart contracts the vault can interact with for DeFi operations (swaps, lending, staking, etc.).
A whitelisted payment destination does not need protocol approval (it is a simple transfer). An approved protocol does not need to be on the destination whitelist (it is a contract call, not a payment).
Chains and Tokens
Supported Chains (v1)
| Chain | Chain ID | Environment |
|---|---|---|
| Base | 8453 | Production |
| Arbitrum One | 42161 | Production |
| Base Sepolia | 84532 | Testnet |
USDC
The canonical base asset for Axon vaults. USDC is the default token held in vaults and used for payments. For payments in other tokens, the relayer can execute a same-chain swap from USDC to the desired output token automatically. The bot does not need to know what token the vault holds.
Next Steps
- Quickstart — send your first payment in 5 minutes
- How It Works — the full payment flow explained
- Deploy a Vault — set up your own vault