Run an eth_call against the chain's RPC to simulate a transaction without signing or broadcasting it. Returns { ok, returnData?, revertReason? }. Use this BEFORE prepare_*/send_transaction to verify a contract call does what you expect — e.g. does wrapping ETH by sending to WETH9's fallback succe...
AI agents invoke simulate_transaction to trigger actions in VaultPilot MCP. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
to | object | Yes | |
data | string | — | Hex-encoded calldata. Omit for a plain value transfer. |
from | string | — | msg.sender to simulate from. Omit for a state-independent call; include the user's wallet when the target contract's behavior depends on the caller (e.g. WETH9. |
chain | string | — | |
value | string | — | Value to send with the call, in wei as a decimal string. Omit for 0. Example: "500000000000000000" for 0.5 ETH. |
Parameters from the server's own tool schema.
simulate_transaction triggers real processes with real consequences. An agent gone sideways doesn't fire it once — it starts dozens of builds, sends mass notifications, or burns through compute before anyone looks up.
Attacks that exploit this kind of access
Run an eth_call against the chain's RPC to simulate a transaction without signing or broadcasting it. Returns { ok, returnData?, revertReason? }. Use this BEFORE prepare_*/send_transaction to verify a contract call does what you expect — e.g. does wrapping ETH by sending to WETH9's fallback succeed, does a custom calldata revert, what selector gets hit. For state-dependent calls (WETH deposit credits msg.sender, ERC-20 transfer debits msg.sender), pass the user's wallet as from. Prepared transactions are also re-simulated automatically at send_transaction time — this tool lets the agent check ahead. NEVER call this on a tx that depends on an approval you just submitted but haven't yet waited on: the approval must be included on-chain (poll get_transaction_status until confirmed) before the dependent tx will simulate correctly — otherwise you get a misleading 'insufficient allowance' revert. It is categorised as a Execute tool in the VaultPilot MCP MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
simulate_transaction accepts 5 parameters: to, data, from, chain, value. Required: to. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for simulate_transaction: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
simulate_transaction is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the simulate_transaction rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for simulate_transaction. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
simulate_transaction is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.