Agents and integrations

An agent, whether an AI agent, a bot or a script, can use every pool, vault and swap the app offers by calling Levee's contracts with its own wallet. Levee never holds its key: nothing on levee.trade can sign or send a transaction for anyone. This chapter is the integrator's view of the app: which function to call, which approval comes first, which minimum to pass, and where the addresses and ABIs are published. To set an agent up step by step, use Connect your agent: an instruction to paste into a chat agent, a script to start from, and a way to watch the agent's wallet.

Where everything lives

All of them are generated from the same manifest and ABIs the app itself uses, at build time. The sources are verified on the explorer, robinhoodchain.blockscout.com. The addresses this site was built with:

Chain 4663, deployed from block 82,431,214. Each address opens on the explorer.

The loop

1. 01
   Read

   Addresses from the manifest, ABIs from /abi, and the state you need from view calls: previewDeposit, maxDeposit, paused, a pool's slot0, Router.quoteExactIn.
2. 02
   Build

   Encode the call: to, data, value and chain id 4663. Set every minimum and deadline the function takes; the next sections say which.
3. 03
   Check

   The to must be in the manifest or the chain constants, and an approval's spender must be the contract the next call goes to. Anything else is a mistake or an attack.
4. 04
   Simulate

   An eth_call from your own address, or one eth_simulateV1 request for an approval and the call that follows it. A revert here costs nothing.
5. 05
   Sign and send

   With the agent's own key, through any RPC. Wait for the receipt before the next step.
6. 06
   Confirm

   Read the receipt's events (Swapped, ZapMint, Deposit) rather than trusting the simulation's numbers.

What an agent can call

Routes through the Router

A route is up to three swap hops, each a Hop of a kind and its ABI-encoded data. The Router checks that the hops chain token to token (routeTokens) and treats ETH and WETH as the same token.

Quote a route with quoteExactIn(hops, amountIn) through eth_call. It is not a view function: it runs each v4 hop and reverts with the result, so it costs nothing as a call and must never be sent as a transaction. Levee's pools are listed under Levee pools and how the app picks a route under Swaps and routing.

The rules

1. Exact approvals. Approve the amount of this one call, to the contract that pulls it, never type(uint256).max. When a token already has a different non-zero allowance, set it to 0 first: some tokens refuse a change from one non-zero value to another. This is what the app does (apps/web/lib/trade/approvals.ts).
2. A real minimum. The zaps' maxSlippageBps is measured against the pool price inside the same transaction, so a price moved before yours moves that bound with it. minLiquidity is the only bound fixed when you sign: derive it from previewZap at a price you trust, less your slippage. The same goes for minAmountOut from a fresh quote. See One-token deposits.
3. Short deadlines. Minutes, where a function takes one. ERC-4626 deposit and redeem take none, so a signed vault transaction stays valid until it is mined: send it at once, never hold it.
4. Vault decimals. LP, hedged and structured vault shares carry 3 more decimals than their asset (OpenZeppelin virtual shares). Read the vault's own decimals(), never the asset's.
5. Vaults can say no. Deposits and withdrawals revert while the pool's spot price is more than 3 % from its 30-minute average (TwapGuard). A hedged vault pauses both when its last hedge report is over an hour old or its equity jumped more than 15 %; read paused(). A vault with a cap reports what it still takes in maxDeposit, and Income NVDA takes nothing. See Vaults and Hedged vaults.
6. Check every address. Before signing, the to of the transaction and the spender of every approval must appear in /deployments/robinhood.json or /deployments/robinhood-external.json.

Simulating a sequence

Most actions are two transactions: an approval, then the call that uses it. A plain eth_call of the second fails until the first is mined. eth_simulateV1 runs calls in order inside one simulated block, so the second sees the first. As of 14 October 2026 both the public RPC and Alchemy's Robinhood Chain endpoint answer it.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_simulateV1",
  "params": [
    {
      "blockStateCalls": [
        {
          "calls": [
            { "from": "<agent>", "to": "<USDG>", "data": "<approve(vault, amount)>" },
            { "from": "<agent>", "to": "<USDG Vault>", "data": "<deposit(amount, agent)>" }
          ]
        }
      ],
      "validation": false
    },
    "latest"
  ]
}

Each call comes back with a status, its returnData and gasUsed. A status of 0x1 on both means the pair would succeed against the current block. Simulate again right before you send: the chain moves.

Referrals for agent builders

An agent built for other people can earn from their activity without touching their funds. Register a code once with ReferralRegistry.register(bytes8 code). A user who calls bind(code) is tied to you for life, and 20 % of every protocol fee their activity pays goes to you, through FeeRouter. The share comes out of the protocol fee, not out of the user's trade. A binding can never be changed, so never bind a user who has not asked for it. See Fees and referrals.

Reading data

The chain is the source of truth, and everything an agent needs before it signs is a view call: vault previews and limits, pool prices, Router.quoteExactIn, LeveeZapV3.previewZap, token balances and allowances. Multicall3 (in the chain constants) batches them.

The app's own API serves ranked markets, vault and pool lists and a portfolio by address; its routes are listed in Indexer, API and bots. Treat them as beta: they are unversioned and follow what the app needs, and the API gets a stable public address before it is documented for agents.

Not for agents, for now

• Perps. A Lighter order is signed by Levee's signer service with a key bound to the user's Lighter account. That is one of Levee's two custodial exceptions, and it exists for a person clicking in the app. An agent opens its own Lighter account and trades through Lighter's API with its own key. See Perpetuals. Perps for agents are coming soon; see Coming next.
• Keeper enrolment. PositionKeeper needs setApprovalForAll on the position manager, which covers every position the wallet holds. See Position automation.
• Launches and range orders. App flows with their own rules; read Launch a token and Limit orders before calling those contracts.

Coming next

Two things are coming soon for every agent and the people who run them. Neither is live yet.

• An MCP server. Agent connect is a hosted tool server, over MCP and plain JSON, whose read tools answer market, vault, pool and portfolio questions and whose build tools return the transactions above as unsigned, simulated plans for your agent to sign. It will keep every rule on this page, and its address will appear in /llms.txt when it ships.
• Perps for agents. Perps for every agent and the people who run them. Until they ship, perps stay an app flow: see Not for agents, for now.