AI Transaction Simulation Agent: Simulate Before You Sign

An AI transaction simulation agent checks what a specific transaction will do, or already did, before anyone treats it as safe. It's not just verifying who owns the wallet.

Every agent that touches a wallet eventually faces the same choice: sign first and find out what happened, or check first and skip the surprise. Most ship with the first. You approve a transaction and hope nothing goes wrong. Maybe that's an unlimited token approval to a contract nobody vetted, or a transfer that quietly reverts and burns gas for nothing.

An on-call engineer pasted a transaction hash into Slack at 2:47 a.m. and asked if it was stuck or just slow. Someone opened a block explorer, squinted at the nonce, checked gas, wrote three sentences. Twelve minutes later the thread had moved on. The tx confirmed at 2:51 anyway.

Dashboards are good at aggregates. They are bad at the one-off question from a human who needs a yes/no and a recommended next step. That's the gap this example targets: not replacing Datadog or PagerDuty, but giving a wallet-connected agent a way to check before it signs, and explain after it's mined.

Key Takeaways

Who Is This Agent For?

This walkthrough is for:

• AI agent developers wiring transaction tools into an LLM loop
• Wallet developers who need pre-flight checks before a user signs
• Web3 infrastructure engineers building monitoring or safety layers
• Security engineers evaluating transaction risk before execution
• DeFi teams previewing swaps, transfers, and contract calls before broadcasting

If none of that is you, the simulation concepts below still apply. Feel free to skip straight to "How Do You Read the Simulation Result?"

Why Does an AI Transaction Simulation Agent Matter?

Answer: It moves the "will this succeed" question before you sign, so a failure costs nothing instead of wasted gas and a confusing revert.

Every signed transaction is a bet. You send it, and the chain either accepts the state change or throws it away. Most tooling only tells you which one happened after the fact. By then, the gas is already spent, and someone is stuck explaining why.

A transaction fails, or "reverts," when some condition inside the contract doesn't hold. Common causes: insufficient balance, a paused contract, slippage past a limit, an unmet require statement. The chain rolls back every intended state change. The gas spent attempting it is gone either way. Multiply that by an agent that signs and sends without checking. "We'll debug it after" becomes a real cost line, not just an inconvenience.

Simulation exists to move that check earlier. Run the exact same transaction against current chain state, without broadcasting it, and you can see in advance:

• Whether it would succeed or revert
• The estimated gas cost
• The exact revert reason, if any
• Every balance and token change it would cause
• The event logs and call trace it would emit

None of that requires a signature. None of it costs real gas.

Txid or Wallet Address: Which One Do You Need?

Two identifiers do all the work here, and mixing them up is the most common reason a first prompt to this agent gets a confusing answer:

• Transaction ID (txid): a 0x-prefixed, 64-character hex hash that uniquely identifies one transaction. This is what you hand to get_transaction_status or tenderly_explain_transaction. Block explorers sometimes call this the "transaction hash" or "tx hash." Same thing.
• Wallet address: a 0x-prefixed, 40-character hex identifier for an account, not a single transaction. get_balance and get_wallet_address work off this instead.

Why Does an AI Agent Make Simulation More Useful?

Answer: A simulation engine alone still returns raw JSON. An agent turns a plain-language question into the right tool call, and turns the result back into a recommendation.

Someone still has to know which endpoint to call, build the request payload correctly, and read a nested response to find the one field that matters. That's a lot of friction between "is this transaction safe?" and an actual answer.

An agent collapses that gap:

User
  ↓
Natural language
  ↓
Agent
  ↓
Simulation
  ↓
Plain English
  ↓
Recommended action

You ask a question in plain language: "will this transfer succeed?" The agent decides which tool to call, builds the request, runs the simulation, and reads the structured result back into a sentence a non-engineer can act on. The simulation is the mechanism. The agent is what makes it usable without reading API docs first.

How Does the Agent Predict Transaction Outcomes?

Answer: It runs the transaction against real chain state in a sandboxed EVM, without broadcasting it, using Tenderly's simulation API as one tool under the hood.

Before the agent signs anything, it can preview the outcome: run the exact transaction against current chain state, in a sandboxed EVM, without ever broadcasting it. Nothing is sent to the network: no signature, no gas spent, no on-chain footprint. That preview is powered by Tenderly's simulation API, called as one MCP tool among several the agent has access to.

It's a fair question to ask why this needs a third-party simulation engine instead of a standard RPC call:

eth_call will tell you a transaction reverted. It won't tell you why, what it would have cost, or what would have changed. An agent that has to explain a result to a human needs that richer structure. That's the difference this integration is built around, not brand loyalty to any one vendor.

Why Build This on Abstraxn?

Answer: Abstraxn's Agent Kit handles wallet provisioning, multi-chain routing, and response normalization, so the agent code stays focused on intent, not plumbing.

None of this requires hand-rolling wallet management or RPC plumbing. Agent Kit handles the parts that would otherwise be boilerplate in every agent that touches a chain:

• Unified wallet handling: Abstraxn WaaS (Wallet-as-a-Service) provisions a server wallet and binds it to the agent via an MCP token. The agent never needs its own key-management code.
• Agent execution: the system prompt decides which tool to call and when. You write intent, not a decision tree.
• Multi-chain support: one chain slug covers nine EVM networks (ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, arbitrum-one) instead of a config file per network.
• Easier blockchain interactions: the tool layer resolves the right EVM client and current block for you. The agent code never touches viem directly.
• AI-friendly workflows: every tool returns normalized, flat JSON instead of Tenderly's raw nested response shape, so the model can reason over it directly.

Simulation and explain sit alongside the plainer monitoring tools this agent also has:

Which of the Four Powers Does This Agent Lean On?

Answer: An agent that reasons about a wallet still needs a wallet it can act on and a way to keep that action in-bounds. This agent leans on Wallet and Policy first, with Identity and Payments in supporting roles.

Abstraxn provides four things a reasoning agent doesn't get by default: a verifiable Identity, a Wallet it controls, a way to Pay, and Policy that keeps it in-bounds. Which two carry the weight flexes per use case. For a simulation and monitoring agent, it's these two:

• Wallet, leading. Abstraxn WaaS provisions the server wallet this agent previews transactions for and binds it to the agent over MCP. Every tenderly_simulate_transaction call runs against that wallet's real state, not a mock.
• Policy, leading. Simulation is a pre-flight check; Policy is the backstop for what happens if someone skips it. Today Abstraxn ships three live controls: address whitelisting, address blacklisting, and per-transaction limits. Pair those with this agent's simulate-before-you-sign habit and you get two layers instead of one. Broader policy enforcement beyond those three controls is in active development, not shipped yet.
• Identity, supporting. This example doesn't register an on-chain agent identity (ERC-8004), but it runs on the same Agent Kit account model that does: registerAgentIdentity is one call away if you want simulation results traceable to an accountable, on-chain-registered agent instead of just a wallet address.
• Payments, supporting. This agent doesn't move funds today, but the same Abstraxn account that provisions its wallet is what a trading or shopping agent would use to actually pay, once a simulation says it's safe to.

How Does a Simulation Actually Run?

User
  ↓
Chat UI
  ↓
LLM
  ↓
Tool Router
  ↓
Abstraxn MCP
  ↓
Tenderly API
  ↓
EVM
  ↓
Simulation Result
  ↓
LLM
  ↓
Recommendation

A prompt goes in once and a recommendation comes out once. Everything in between is the agent doing the work a person used to do by hand: picking the tool, building the call, reading the trace, and writing the summary.

1. You supply a chain and to address (or a transaction hash, to explain one that already landed). Optional from, value, data, and gas default sensibly if you don't set them.
2. The tool validates the input before calling anything external. An unsupported chain returns TENDERLY_NETWORK_UNSUPPORTED, a missing address returns MISSING_TO_ADDRESS, malformed calldata fails an isHex check. Bad input fails fast instead of burning an API call.
3. Abstraxn resolves the EVM client and current block number for the requested chain. The simulation always runs against real, current state, not a stale snapshot.
4. Tenderly simulates execution against that state and returns a raw, deeply nested result.
5. The response is normalized into consistent field names (success, gasUsed, revertReason, callTrace, balanceChanges, assetChanges, simulationUrl), regardless of which Tenderly response shape came back.
6. The LLM turns that into an alert-style recommendation: status, risk notes, what to check next, per the agent's system prompt.

Every step exists to make sure the number the agent hands back traces to something real, not a guess.

How Do You Set Up the Tenderly Integration?

Answer: Create a free Tenderly account, grab three values from its dashboard, and paste them into the Abstraxn dashboard under Agent Kit → Integrations. No code required.

tenderly_simulate_transaction and tenderly_explain_transaction don't run against Abstraxn's own infrastructure. They call Tenderly's API on your behalf, which means Tenderly needs to know it's you.

1. Create a Tenderly account at dashboard.tenderly.co if you don't already have one. The free tier covers everything this agent uses.

2. Create or open a Project inside that account. Tenderly organizes simulations by project, and every project sits under an account.

3. Copy your Account slug and Project slug. Both are visible in the dashboard URL once you're inside a project: dashboard.tenderly.co/<account>/<project>.

4. Generate an Access Key from that project's settings (Settings → Access Tokens in the Tenderly dashboard). This is the credential that authenticates the API calls; treat it like a secret.

5. Open your agent in the Abstraxn dashboard under Agent Kit → Integrations and find the Tenderly card. Toggle it on, then fill in the three fields it asks for:

   Field	Where it comes from
   Account	Your Tenderly account slug
   Access key	The access token you generated in step 4
   Project	Your Tenderly project slug

6. Save. That's it, no redeploy, no code change. The toggle powers tenderly_simulate_transaction and tenderly_explain_transaction for every agent under that Abstraxn account.

Everything else in this walkthrough, the tool router, the normalized response shape, the system prompt, is already wired up. This integration step is the only manual setup a new user needs to do before simulation works end to end.

Try It From the Abstraxn-Labs/abstraxn-agent-examples Repo

Clone examples/03-tx-monitoring, and enable Tenderly under Dashboard → Integrations, using the Account, Access Key, and Project from the setup steps above. Copy the MCP endpoint into Claude, Cursor, or your own runtime. Ask something concrete:

Simulate sending 0.01 ETH to 0x… on Base. Will it succeed and what will it cost?

You should see a tenderly_simulate_transaction tool call in the trace, then a plain-English answer with an estimated gas cost and a simulationUrl you can open to inspect the trace yourself, not generic agentic-AI language the model already knows. If that works, the hard part is done.

A couple more to try once that one lands:

What is my wallet balance and current gas info on Base?

Check status for 0x… Is it confirmed? Any risk notes?

Read-only. No transfers. For production, pipe tool results into Slack or your existing alerting. The Next.js example below is for teams that want a branded UI, custom prompts, and a repo their engineers can fork.

Docs: MCP tools reference

What Does the Agent's Code Look Like?

// examples/03-tx-monitoring/lib/agent.ts
export const agentConfig: AgentConfig = {
  name: "Tx Monitoring Agent",
  tools: "txMonitoring",
  system: `You monitor wallets and transactions.
When given a tx hash, call get_transaction_status for a quick raw status check, or
tenderly_explain_transaction for a decoded call trace and revert reason (use this when a
transaction failed or the user wants to know exactly what happened).
Before sending a transaction, call tenderly_simulate_transaction to preview whether it will
succeed, its gas cost, and any balance/asset changes.
When asked about balances or gas, use the matching tools.
Present alert-style summaries: status, risk notes, and recommended next checks.
Do not invent on-chain data.`,
};

txMonitoring: [
  "get_transaction_status",
  "tenderly_simulate_transaction",
  "tenderly_explain_transaction",
  "get_balance",
  "get_wallet_address",
  "get_gas_info",
  "get_token_info",
  "data_and_analytics",
  "token_chart",
]

Calling Tenderly's simulation endpoint itself is a plain POST with an access key header:

// web3-agent-kit-service/src/mcp/integrations/tenderly.integration.ts
const url = `${config.baseUrl}/account/${config.account}/project/${config.project}/simulate`;
 
const response = await fetch(url, {
  method: "POST",
  headers: {
    "X-Access-Key": config.accessKey,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    network_id: params.networkId,
    from: params.from,
    to: params.to,
    input: params.input,
    value: params.value,
    gas: params.gas ?? 8_000_000,
    block_number: params.blockNumber,
    simulation_type: "full",
  }),
});

pnpm --filter @abstraxn-examples/tx-monitoring dev

Open http://localhost:3003. Ask for a table of wallet health across chains. The shared UI renders markdown pipe tables when the model formats structured output that way.

Good prompts to try:

What is my wallet balance and current gas info?

Check status for tx 0x… Is it confirmed? Should I wait or bump gas?

Simulate a 0.01 ETH transfer to 0x… on Base Sepolia. Will it succeed?

Explain what happened in 0x… Did it revert, and why?

How Do You Read the Simulation Result?

Both tools return the same shape, whichever direction you're checking:

The agent doesn't hand you that table. It reads it and writes something closer to:

Simulation successful. Sending 0.05 ETH to 0x74C5…b91F on Base would succeed, at an estimated 21,000 gas. No balance risks detected.

or, for a failure:

This transaction would revert: "ERC20: transfer amount exceeds balance." No funds would move. Check the sender's balance before retrying.

That's the recommendation from the architecture diagram, not the raw JSON.

Extending the Agent

Tenderly's own platform goes well beyond what this agent uses today: a visual debugger, deeper transaction tracing, advanced monitoring and alerting, and forked/virtual test networks for full integration testing. This integration deliberately calls only two endpoints: simulate and explain. That's what answers "will this work" and "what happened": the two questions an agent actually needs answered inline, in a chat.

Wiring up more of Tenderly's surface is a natural way to extend this agent, not a gap in Tenderly.

What Are the Limitations?

• A simulation reflects chain state at the moment it runs. If the real transaction is mined later, and something else changes state first (another transaction lands, a price moves, a nonce shifts), the outcome can differ from what was simulated.
• Simulation cannot predict economic outcomes. Price movement, slippage beyond what you configured, and MEV/front-running are real-world effects a static simulation doesn't model.
• Tenderly's API has its own limits. Requests can time out (TENDERLY_TIMEOUT) or get rate-limited (TENDERLY_RATE_LIMITED) under heavy use. Plan for that if you're calling this from something more automated than a chat prompt.

Where This Agent Can Grow

Near term

• Batch and multi-transaction simulation
• Cross-chain simulation in a single call
• Gas optimization suggestions

Medium term

• Continuous transaction screening, not just on-demand checks
• Wallet risk scoring and reputation

Long term

• Auto-remediation: the agent proposes a fix, not just a diagnosis
• Security recommendations baked into the response
• Autonomous transaction approval, gated by policy

Frequently Asked Questions

Series

0. Hello Wallet
1. Firecrawl
2. Trading
3. Tx monitoring (this post)
4. Fraud policy