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:

FieldTypeDescription
botaddressThe signing bot's address (must be active in the vault)
toaddressThe payment recipient
tokenaddressThe ERC-20 token to transfer (e.g., USDC)
amountuint256The payment amount in the token's smallest unit
deadlineuint256Unix timestamp after which the intent expires
refbytes32A 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:

AgentRole
Safety AgentAnalyzes the destination address and contract bytecode for known risks
Behavioral AgentCompares the payment against the bot's historical transaction patterns using Z-score analysis
Reasoning AgentInspects 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 with ContractNotApproved.
  • 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)

ChainChain IDEnvironment
Base8453Production
Arbitrum One42161Production
Base Sepolia84532Testnet

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