Simulate, Then Sign: The Validation Step That Would Have Saved $7.5M

1Claw now runs Tenderly simulations on every EVM transaction your agent submits, so it can see the outcome before it ever signs.

In June 2026, the most profitable sandwich bot on Ethereum lost at least $7.5 million in a single weekend.

JaredfromSubway.eth had spent years pulling value out of other people's trades. Then an attacker deployed 66 fake token contracts, dressed them up to look like easy sandwich targets, and waited. The bot did exactly what it was built to do. It moved fast, granted token-spending approvals, and never once stopped to check who was on the other side. The approvals piled up, and none were revoked. When enough had accumulated, a single coordinated transaction swept the wallets clean. The funds were converted to ETH, pushed through Tornado Cash, and never recovered.

The size of the loss is not really the point. The cause is. The bot signed transactions it never validated, against contracts it never vetted, using approvals it never revoked. It was tuned for speed, so it skipped the one step that would have caught the trap.

That failure mode is precisely what we built the Intents API to prevent, and it is why we integrated Tenderly, the simulation company for onchain operations.

Agents lose money in two ways

Any autonomous agent that touches funds is exposed on two fronts, and you have to close both.

The first is key exposure. Private keys and API keys end up pasted into prompts, written to .env files, captured in logs, and left sitting in context windows and chat history. Once a secret lands in any of those places, you cannot take it back. You can only rotate it and hope nothing read it first. This is the problem 1Claw was founded to solve: secrets live inside a hardware security module, and agents use them at runtime without ever seeing the raw value.

The second front is unvalidated execution, and it is the one the industry keeps underestimating. You can protect a key perfectly and still lose everything, because the agent signs a transaction it should never have signed. Models hallucinate. They read parameters from unverified sources. They add their own interpretation to a request. In a world of irreversible transactions, a single wrong approval or a swap into a poisoned pool is all it takes. A locked key on a transaction that drains your wallet is still a drained wallet.

Jared's bot had the first problem handled. Its keys were not leaked. It lost the money on the second front.

How 1Claw and Tenderly close both fronts

The Intents API handles the key. When your agent wants to move funds, it submits an intent (chain, recipient, value, calldata) rather than a signature. The vault decrypts the signing key inside the HSM boundary, builds and signs the transaction there, broadcasts it, and returns a transaction hash. The agent never touches the raw key. If a key is enabled for the Intents API, direct reads of that key through the standard secrets endpoint are blocked outright, so the only way to use it is through the proxy, on the record, every time.

That solves custody. It does not, on its own, tell you whether the transaction is a good idea. So we brought in Tenderly, the simulation company already powering onchain finance.

Tenderly's simulation engine runs a transaction against the current chain state and shows the expected outcome, with decoded traces, balance changes, asset transfers, emitted events, gas estimates, and human-readable reasoning for failed transactions. Tenderly simulates the transaction against a full-fidelity replica of production chains, synced with live oracle prices, current liquidity, and real protocol positions, but without gas costs, public exposure, or real risk.

This way, Tenderly enables the validation step that Jared's bot skipped, running it automatically before anything is signed. We wired it straight into the signing path, so your agent does not have to call a separate service or reason about whether validation is needed. It happens in the same request.

One flow: simulate, then sign

The flow looks like this. The agent decides to act. 1Claw simulates the transaction through Tenderly and reads back the real outcome. Guardrails check the transaction against your limits. Only if all of that passes does the HSM sign and broadcast. Every step lands in the audit log with a transaction ID.

The simplest version is a single flag. Add simulate_first: true to a transaction, and 1Claw simulates it through Tenderly first. If the simulation reverts, the API returns a 422 and refuses to sign or broadcast. Nothing hits the chain.

curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/transactions" \
  -H "Authorization: Bearer $AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "base",
    "to": "0xRecipientAddress",
    "value": "0.5",
    "simulate_first": true
  }'

If your agent runs over MCP, it is the same idea with the submit_transaction tool:

Tool: submit_transaction
Args:
  chain: "base"
  to: "0xRecipientAddress"
  value: "0.5"
  signing_key_path: "wallets/hot-wallet"
  simulate_first: true

You do not have to trust each agent to opt in. An org admin can set intents_api.require_simulation to true, and every transaction gets simulated whether or not the agent asked for it. A revert blocks the signature. Validation stops being a suggestion and becomes policy.

For the approval-and-swap pattern that caught Jared, bundle simulation runs a sequence in order and shows you the combined result. You can simulate an ERC-20 approve followed by the swap that uses it, and see the real balance changes before either one is signed:

curl -X POST "https://api.1claw.xyz/v1/agents/$AGENT_ID/transactions/simulate-bundle" \
  -H "Authorization: Bearer $AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transactions": [
      { "chain": "base", "to": "0xToken", "value": "0", "data": "0xapprove..." },
      { "chain": "base", "to": "0xRouter", "value": "0", "data": "0xswap..." }
    ]
  }'

Simulation is the sharp edge. Guardrails are the backstop. Per agent, you can restrict which chains it can use, allowlist the addresses it is allowed to pay, cap the value of any single transaction, and set a rolling daily spend limit. Anything outside those bounds is refused before signing.

curl -X PATCH "https://api.1claw.xyz/v1/agents/$AGENT_ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tx_allowed_chains": ["ethereum", "base"],
    "tx_to_allowlist": ["0xSafeAddress1", "0xSafeAddress2"],
    "tx_max_value_eth": "0.5",
    "tx_daily_limit_eth": "5.0"
  }'

There is one more layer worth calling out, because it maps directly to how Jared was drained. His bot handed out token approvals to contracts it never checked. On 1Claw, EIP-712 signing (which covers Permit and Permit2 approvals) is denied by default. The dangerous types have to be explicitly allowlisted before an agent can sign them. An agent cannot quietly approve a stranger's contract just because a prompt told it to.

What this looks like for each kind of agent

We build for a range of agent stacks, and validation earns its keep across most of them.

Trading bots.This is the Jared case, exactly. A DeFi agent plans a swap and the parameters look fine, but the outcome is uncertain until it hits the chain. With Tenderly's simulations as a required validation step, the bot previews token transfers and balance changes first. A honeypot that would drain it shows up as an unexpected transfer or a revert rather than a loss. The keys never leave the HSM, so even a fully compromised bot cannot walk off with the signing material.

Payment agents. Autonomous agents that settle invoices or move funds on-chain run inside hard limits. Recipient allowlists mean the agent can only pay addresses you approved, per-transaction caps bound any single mistake, and daily limits bound a bad day. Running a Tenderly simulation first confirms the payment lands where it should before it is sent.

Embedded wallets.Consumer apps with drop-in wallets get the same protections without asking end users to think about them. Spend policies and simulations sit under the login, so a user's wallet cannot be tricked into a transaction that does something other than what it claims.

Browser and research agents. These agents read untrusted content all day, which makes them the likeliest to be steered by a prompt injection hiding in a web page. Running their LLM traffic through Shroud filters the injection attempts, and routing any resulting transaction through simulate-then-sign means a malicious instruction cannot turn into a signed transfer without first passing a simulation and the guardrails.

Coding agents. Claude, Cursor, and Copilot pull their API keys from the vault at runtime instead of from a .env file sitting in the repo. If one of them also ships transactions, for example a deployment agent paying gas, the same simulate-then-sign path applies.

Support agents. Validation is not only a pre-flight check. When a user reports a failed transaction, a support agent can replay it in Tenderly and surface the revert reason in plain language, then simulate a corrected version to find out what would have worked. This enables faster resolutions, without handing the agent a live key.

Getting started

Start signing validated transactions in a few minutes.

1. Create an agent with intents_api_enabled: true from the dashboard or the API, and note the agent ID and API key.
2. Provision an HSM-backed signing key for your chain with POST /v1/agents/:id/signing-keys. The keypair is generated inside the HSM and the private key never leaves hardware.
3. Set your guardrails: allowed chains, a recipient allowlist, a per-transaction cap, and a daily limit. If you want simulation enforced across the board, turn on require_simulation at the org level.
4. Submit your first transaction with simulate_first: true, starting on Sepolia or Base Sepolia so you can watch the full flow before real value is involved. This sends all the transaction details to Tenderly's Transaction Simulation REST API.
5. Monitor everything through GET /v1/agents/:id/transactions and the audit log.

The honeypot that took $7.5 million worked because a fast, autonomous system signed first and never asked questions. Speed is not the enemy. Signing without looking is. With 1Claw and Tenderly, your agent still moves fast, it just gets to see where it is going first.

Read the Intents API guide or start free with 1,000 requests a month, no card required.