How ArbiSim works
The complete picture of what happens between "your agent wants to send a transaction" and "safe to proceed".
Your agent has a transaction to send
An AI agent — running inside Claude Desktop, a LangGraph graph, an Eliza framework, or your own code — decides it needs to execute an on-chain action. This could be:
- →Swapping tokens on a DEX (e.g. AVAX → USDC on TraderJoe)
- →Depositing into a lending protocol (e.g. Aave on Avalanche)
- →Paying another agent using the x402 protocol
- →Calling any smart contract on an EVM chain
Before the agent broadcasts anything, it first calls ArbiSim.
The request reaches the ArbiSim API
The request travels through the Cloudflare Worker edge layer, which validates the API key and checks rate limits in under 10ms. Valid requests are written to a Postgres job queue and assigned a job ID.
{
"network": "avalanche-fuji",
"agent_address": "0x...",
"transactions": [{"to": "0x...", "data": "0x..."}],
"max_slippage_tolerance": 2.0
}The Python worker picks it up and forks the chain
A Python simulation worker claims the job and uses Foundry Anvil to create an isolated fork of the live blockchain at the current block. This is a complete copy of chain state — real token balances, real liquidity pools, real contract storage.
Crucially, ArbiSim maintains a persistent Anvil process per chain. Instead of spawning a new process for each simulation (which takes 4+ seconds), it takes an EVM snapshot at the start and reverts to it after each run. This reduces startup latency to under 100ms.
Your transaction executes in the fork
The transaction is submitted to the forked chain via JSON-RPC. The EVM executes it completely — every opcode, every storage write, every token transfer. The execution trace is captured.
No real gas is spent. No money moves. The fork is completely isolated from mainnet.
The analytical engine runs 10 checks
The analytical engine processes the execution trace and runs each safety check independently:
You get back a structured verdict
The result is written back to the database and the gateway responds to the polling request. The agent reads the verdict and acts on it.
{
"status": "APPROVED",
"checks": { "would_revert": false, "price_impact_too_high": false, ... },
"gas_cost": "0.00018 AVAX",
"verdict": "SAFE — proceed"
}End-to-end latency
Median response time is under 400ms on both Avalanche and Arbitrum. This includes RPC fork state reads, execution, and all 10 checks.