# Ava > The execution and verification layer between an untrusted agent's proposal > and a real on-chain effect. An agent proposes. A user-controlled signature > authorizes. Deterministic policy and a durable reservation gate it. An > isolated signer signs only the reserved artifact. Chain finality and effect > verification decide whether anything is reported as done. Generated live at 2026-11-10T02:26:47.616Z from https://api.getava.xyz. Every capability line below was read from the running API, not written by hand. ## What Ava is for A coding agent (Claude, Codex, Cursor, Grok) can propose moving real money. Nothing in that agent's output is evidence that a user wanted it, that a retry will not do it twice, or that it actually happened. Ava supplies the parts the agent cannot: authorization bound to a user-controlled key, an atomic reservation, and a receipt whose claims are checked against the chain. The distinction that defines the product: a transaction hash proves broadcast an included block proves inclusion neither proves the user asked for it, or that the effect survived a reorg ## Base URLs API https://api.getava.xyz MCP https://api.getava.xyz/mcp Site https://www.getava.xyz ## Authentication One unauthenticated POST creates a session and returns a bearer token once: curl -sS -X POST https://api.getava.xyz/v1/users/session \ -H 'content-type: application/json' -d '{}' Send it as `Authorization: Bearer ` on every later call. The token is stored only as a digest, so it cannot be read back. An anonymous session is deliberately enough to plan, preview and use paper mode. It is NOT enough to move real capital: that requires a verified principal, because a credential anyone can mint by curl is not a person. ## MCP tools Ava advertises a small default set because Cursor caps at 40 tools across every installed server combined and tool-picking accuracy degrades past roughly 30. Add `?toolsets=all` for the full surface, or `?toolsets=advisory`, `discovery`, `automations`, `hire` for one group. ava_copilot_turn ava_approve_execute ava_lend_execute ava_portfolio ava_session ava_create_agent ava_provision_wallet ava_preview_tx ava_plan_workflow ava_plan_standing ava_create_mandate ava_list_mandates ava_eval_mandate ava_agent_record ava_get_receipt Discover tools at runtime with `tools/list`. Never infer a tool from documentation, including this file. This file is the SUMMARY. It lists tool names without their arguments on purpose, which is enough to decide whether Ava is relevant and NOT enough to make a correct call. Before calling anything, read the spec: https://getava.xyz/llms-full.txt It carries every tool's real input schema (read live from tools/list), the two-phase confirmation sequence, the error codes with retry guidance, and the response arms that decide whether you may claim a fill. ## The two shapes of authorization ONE-SHOT. The user is present and approves an exact plan. ava_plan_workflow "Supply 300 USDC to Morpho on Base, bridge no more than 200 to Avalanche, then supply what arrives to Aave" Returns dependent legs. The third depends on the second and takes its amount from what the bridge actually delivered, because a bridge delivers less than it accepts and a plan-time number would be wrong by exactly the fee. STANDING. The user is absent and cannot be asked per action. ava_plan_standing "Every hour, rotate my USDC into the best yield on Base using Aave and Morpho, never more than 200 per rotation, never over 1000 total, stop after 30 days" Returns an envelope of BOUNDS the user signs once. Every later rotation is checked against the signed envelope by code rather than by a human, and anything outside it is refused rather than escalated. Asking a human at every rotation would defeat the purpose; relaxing the check would defeat the point. ## What Ava refuses, and why that is the feature no venue named it will not choose which market holds your capital no chain named it will not choose which chain your capital sits on a fraction ("half") it will not compute how much of your money to move one amount, two venues it will not decide how to split an allocation borrow, repay, approve operations it cannot execute are refused by name, never inferred into a similar-looking action a negative or zero a sign flip is the most dangerous silent edit there is over-budget plans a plan committing more than its allocation is not signable at all A plausible wrong plan is worse than a refusal, because a preview that looks reasonable is one a user approves. ## Live capabilities READ THESE, NOT THE TABLE. Two JSON endpoints carry the same registry the text below is rendered from, and they are the contract; this file's layout is not. https://getava.xyz/matrix.json chain -> category -> venue. Every blocked venue carries "readiness" (operator-gated, wired, dry-run, no-executor) and "nextStep", so a route that is one owner decision away is distinguishable from one nothing implements. https://getava.xyz/capabilities.json flat, one row per route Ask matrix.json what Ava can do on a chain, capabilities.json whether one specific route is a yes. Both state the executable rule in the payload: a route runs only when it is implemented, reachable, operator-enabled and live, and "mainnetProven" is excluded on purpose because a past transaction is history, not permission. The table below is the executable set only, formatted for a human skimming. EXECUTABLE OVER THE AUTHENTICATED API (5 of 68) These will accept a live execution request today. Everything else is listed in matrix.json with the reason it cannot run and the one step that would change that, which is a more useful answer than another table of nos. lend aave_v3 on arbitrum [implemented=true mainnetProven=false apiReachable=true mcpReachable=true operatorEnabled=true] lend aave_v3 on avalanche [implemented=true mainnetProven=true apiReachable=true mcpReachable=true operatorEnabled=true] lend morpho_blue on base [implemented=true mainnetProven=true apiReachable=true mcpReachable=true operatorEnabled=true] lend aave_v3 on bnb [implemented=true mainnetProven=true apiReachable=true mcpReachable=true operatorEnabled=true] lend aave_v3 on monad [implemented=true mainnetProven=true apiReachable=true mcpReachable=true operatorEnabled=true] NOT EXECUTABLE (63), by category swap 28 bridge 12 lend 11 perp 3 stake 3 compute 1 data 1 identity 1 memory 1 payment 1 storage 1 Traverse them at https://getava.xyz/matrix.json, keyed chain then category then venue, each blocked venue carrying `readiness` (operator-gated, wired, dry-run, no-executor) and `nextStep`. A mainnet proof is a historical fact about one transaction. It is never permission to execute now. ## Honest status Planning and authorization work and are covered by gates anyone can run: bash scripts/workflow-gates.sh 17 gates, cross-chain, same-chain, standing bash scripts/standing-e2e.sh signs with a key the server never sees node testbench/run.mjs a prompt file, run through the real MCP call EXECUTION WORKS, with one honest stop. A signed plan now reaches a signer: POST /v1/workflows/execute re-derives the legs from the original sentence, verifies a user-controlled EIP-712 signature over those re-derived legs, admits the plan whole or not at all, reserves each leg durably, and runs the live Morpho and Aave executors in dependency order. ava_lend_execute exposes that same path over MCP, so an agent can execute rather than only propose. Two-phase confirmation is not optional and is not satisfied by the agent. A call without a previewHash returns the exact artifact a human must approve plus its hash, and refuses. Only a re-send carrying that hash proceeds, because the agent making the call is not the person whose capital moves. Where it stops today, stated exactly: a wallet with no balance. The end of the path returns LEND_INSUFFICIENT_BALANCE from a live chain read rather than a simulated one, which means every gate before it (mandate, policy, human confirmation, capability allowlist, signer construction) has already run. What still does not work, and is not dressed up: nothing rotates a standing envelope. The deployed scheduler now evaluates every live envelope on its interval and logs, per envelope, whether it was due and why it did not run, so an authorization is no longer silent. But the pass is handed no executor, so a due envelope is reported DRIVER_DISABLED and no capital moves. Authorizing a standing envelope is a real authorization that still produces no rotation, and you should treat it that way rather than waiting for one every swap and bridge route reports no/no in the registry above. The executor, the 0x adapter translation and the leg binding exist and are tested, but no route binds them with a funded wallet, so nothing claims they execute The full list is kept in the repository at docs/production-architecture-review/WORKFLOW_MILESTONE.md and docs/LOOP_STATE.md. ## Source https://github.com/kamalbuilds/ava-4.0