Security Model

Axon's security model is built on a clear trust hierarchy: the owner holds ultimate authority, bots have narrowly scoped signing power, and the relayer has no independent ability to move funds. Each actor's blast radius is bounded by design.

Trust Hierarchy

Why Bots Are Safe

Bot keys have the narrowest possible attack surface in Axon:

Bots cannot call the contract directly. Only the relayer (delegator address) can call executePayment(). A compromised bot key cannot submit transactions on-chain -- it has no ETH for gas and the contract would reject calls from non-relayer addresses anyway.

Bot signatures expire. Every PaymentIntent includes a deadline field, typically set to 5 minutes. A stolen signature becomes useless after the deadline passes.

Bot limits are enforced on-chain and off-chain. The maxPerTxAmount is enforced with a require statement in the contract. Daily limits and velocity caps are enforced by the relayer. A compromised bot cannot exceed its configured spending limits even if it signs intents continuously.

AI verification catches anomalies. If a compromised bot starts behaving differently -- unusual amounts, new destinations, unexpected timing -- the Behavioral agent flags it. If the bot's memo contains prompt injection, the Reasoning agent catches it.

Bots hold no ETH. There is nothing to drain from a bot address itself. The bot is a signing key, not a wallet.

Worst case for a compromised bot key: The attacker can sign payment intents up to the bot's per-transaction limit, at the bot's daily limit rate, to destinations in the bot's whitelist (if configured), until the owner notices and calls removeBot(). If AI verification is enabled, anomalous transactions are flagged automatically.

Bot Key Storage

Bot private keys are generated client-side in the dashboard or by the operator — Axon never stores or has access to them. The SDK supports encrypting keys into standard Ethereum V3 keystore files (scrypt + AES-128-CTR) for safe backup. The keystore file is useless without the passphrase, making it safe to store in cloud backups, password managers, or version control.

Given the bounded blast radius described above, the encrypted keystore is a recommended second layer of protection — primarily guarding against accidental exposure (clipboard leaks, accidental git commits, Slack pastes) rather than being a hard security requirement. Even if a bot key leaks in plaintext, the damage is already bounded by on-chain caps and spending limits, and the owner can revoke the bot instantly. The keystore simply makes accidental leaks much less likely.

For best security, store the keystore file and passphrase in separate systems (e.g. file on disk, passphrase in a secrets manager like AWS Secrets Manager or 1Password CLI). An attacker would need both to recover the key.

Why Relayer Compromise Is Low Risk

The relayer is a relay -- it forwards signed payloads, it does not create them.

The relayer cannot forge bot signatures. The vault contract verifies EIP-712 signatures on-chain. The relayer does not hold bot private keys.

The relayer cannot exceed bot limits. Even if the relayer submits a transaction, the contract enforces maxPerTxAmount and destination whitelist checks independently.

The relayer cannot withdraw funds. Only the vault owner can call withdraw().

The relayer cannot modify bot configuration. Only the owner and operator can call addBot, removeBot, and updateBotConfig.

What a compromised relayer could do:

• Refuse to relay transactions (denial of service, not fund loss)
• Attempt to replay an intent (blocked by on-chain intent hash tracking and deadline expiry)
• Submit a valid intent at a time the bot did not intend (but the intent was already signed with a valid deadline, and the contract validates everything independently)

The relayer is designed to be replaceable. If Axon's relayer infrastructure is compromised, owners can deploy new vaults pointing to a new AxonRegistry and migrate funds.

Operator Blast Radius

The operator role exists for day-to-day bot management without exposing the owner's cold wallet. The operator's maximum damage is bounded by OperatorCeilings:

Max operator drain (daily) = min(
    maxOperatorBots * operatorCeilings.maxBotDailyLimit,
    operatorCeilings.vaultDailyAggregate
)

The operator cannot:

• Raise bot limits above the ceilings set by the owner
• Add destinations to the whitelist (loosening)
• Unpause the vault
• Withdraw funds
• Change the operator address
• Transfer ownership

The operator can:

• Add bots (up to maxOperatorBots ceiling, with limits capped by ceilings)
• Remove bots
• Lower existing bot limits
• Remove destinations from the whitelist (tightening)
• Pause the vault (emergency brake)

The dashboard displays the calculated "Maximum Operator Drain" prominently so the owner always knows the worst-case exposure of their operator configuration.

Non-Custodial Guarantees

Axon never has custody of owner funds. This is enforced at the contract level:

Only the owner can withdraw. The withdraw() function has an onlyOwner modifier. The relayer address, operator address, bot addresses, and Axon's own addresses cannot call it.

Ownership transfer requires two steps. Ownable2Step means the owner must propose a new owner, and the new owner must accept. This prevents accidental ownership transfer to a wrong address.

The contract is not upgradeable. There is no proxy, no DELEGATECALL, no admin key that can change the contract logic. The code the owner sees at deployment is the code that runs forever.

The AxonRegistry is immutable. The vault references a specific AxonRegistry address set at deployment. Axon cannot change which relayer addresses are authorized for an existing vault.

Deposits are open, withdrawals are restricted. Anyone can deposit into a vault (needed for bot-to-bot payments), but only the owner can withdraw.

Emergency Controls

Global Pause

The vault owner (or operator) can pause the entire vault at any time:

vault.pause(); // Owner or Operator

When paused:

• executePayment() reverts
• executeProtocol() reverts
• executeSwap() reverts
• deposit() still works (funds can still be added)
• withdraw() still works (owner can still remove funds)

Only the owner can unpause:

vault.unpause(); // Owner only

This asymmetry is intentional. The operator can hit the emergency brake, but only the owner (presumably on a hardware wallet or multisig) can restart operations.

Bot Removal

Any bot can be immediately deactivated:

vault.removeBot(botAddress); // Owner or Operator

Once removed, the relayer will reject any new intents signed by that bot, and the contract will reject any pending intents from that bot that have not yet been executed.

Off-Chain Bot Pause

The relayer also supports pausing individual bots at the off-chain level (PostgreSQL flag) without an on-chain transaction. This is faster than an on-chain removeBot call and useful for temporary suspensions during investigation.

Since the relayer is the only entity that can call executePayment(), an off-chain pause is effective immediately -- the compromised bot's signed intents never reach the contract.

Intent Replay Protection

Two layers prevent intent replay:

Deadline expiry. Every PaymentIntent has a deadline timestamp (default: 5 minutes). After the deadline, the intent is invalid and the contract rejects it.

Intent hash tracking. The contract stores a mapping of executed intent hashes. Submitting the exact same intent twice is rejected on-chain.

Together, these make replay attacks impractical: an attacker would need to resubmit an intent within its short validity window, past the relayer's own deduplication (idempotency key), past the on-chain hash check -- and the payment would still be bounded by the bot's configured limits.

Recommendations for Owners

• Use a hardware wallet or multisig for the vault owner address
• Download encrypted keystores for bot keys — store the file and passphrase separately
• Set OperatorCeilings conservatively -- calculate the maximum daily drain and ensure it is acceptable
• Enable destination whitelists for bots that pay a known set of addresses
• Enable requireAiVerification for newly registered bots until they build a behavioral baseline
• Monitor the dashboard review queue and bot activity feeds regularly