Onchain Verify Transaction#

Simulate an EVM transaction against a forked chain state using Tenderly, and verify that the resulting asset changes match stated intent. Intended to be invoked by other skills as a pre-execution safety gate.

When to use#

This skill should be invoked before any onchain transaction is sent when:

• A transaction payload was produced by an external API or untrusted source
• The calldata is opaque (e.g. a raw data hex string from a swap router)
• The user has not explicitly waived verification

If this skill is not installed, calling skills should warn the user that pre-execution verification is unavailable and ask for explicit confirmation before proceeding.

Setup#

One environment variable is required:

bash

export TENDERLY_NODE_ACCESS_KEY="your-key-here"

Obtain a key from Tenderly — the free tier supports approximately 62,500 simulations per month (400 TUs per simulation, 25M TU/month free).

Supported chains#

The Tenderly gateway uses a per-chain subdomain. Route to the correct endpoint based on the transaction's chainId. The access key is passed as a header — do not embed it in the URL:

ChainchainIdEndpointBase8453``https://base.gateway.tenderly.coEthereum1``https://mainnet.gateway.tenderly.coOptimism10``https://optimism.gateway.tenderly.coArbitrum One42161``https://arbitrum.gateway.tenderly.coPolygon137``https://polygon.gateway.tenderly.co

If the chainId is not in this list, skip verification, warn the user that the chain is unsupported, and require explicit confirmation before proceeding.

Add new entries as additional chains become supported.

Verify a transaction#

Input#

The calling skill provides a transaction payload with the following fields:

FieldTypeNotesfromaddressThe wallet sending the transactiontoaddressThe contract being calleddatahex stringEncoded calldatavaluehex stringNative token value (e.g. "0x0")chainIdintegerUsed to select the correct Tenderly endpoint

For cross-chain swaps, chainId refers to the source chain — the chain where the transaction is sent. Verify the outbound leg only.

Request#

bash

TENDERLY_URL="https://base.gateway.tenderly.co"

curl -sS -X POST "$TENDERLY_URL" \
  -H "Content-Type: application/json" \
  -H "X-Access-Key: $TENDERLY_NODE_ACCESS_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tenderly_simulateTransaction",
    "params": [
      {
        "from": "0xYourWalletAddress",
        "to": "0xContractAddress",
        "data": "0xCalldata",
        "value": "0x0"
      },
      "latest"
    ]
  }'

Response fields#

FieldDescriptionresult.assetChangesERC-20 token transfers: token address, from, to, amountresult.balanceChangesNative token (ETH) balance changes per address

Verification logic#

After Tenderly simulation, check the following before approving execution:

1. Token destination — do output tokens land in the expected recipient address? Flag any tokens going to an unexpected address.
2. Token identity — is the output token what was requested? Flag substitutions.
3. Output amount — is the output within the expected range (accounting for slippage)? Flag if materially lower than quoted.
4. Input drain — does the simulation drain more input token than authorized? Flag any excess.
5. Unexpected approvals — does the calldata grant approvals beyond what was declared? Flag unlimited or unexpected approvals.

If any check fails, stop and surface the discrepancy clearly. Do not proceed to execution without explicit user confirmation.

Narration#

text

"Verifying transaction on Base via Tenderly..."
"Verification complete. Asset changes:"
"  → Send 5 USDC from 0xYour... to 0xRouter..."
"  ← Receive 0.00242 WETH at 0xYour..."
"All checks passed. Proceeding to execution."

If a check fails:

text

"Verification flagged an issue:"
"  Output token destination is 0xUnexpected... — expected 0xYour..."
"Do not proceed until this is resolved. Aborting."

Error handling#

ConditionActionTENDERLY_NODE_ACCESS_KEY not setWarn that verification is unavailable; require explicit user confirmation before proceedingchainId not in supported listWarn that chain is unsupported for verification; require explicit user confirmationTenderly returns an errorSurface the error message; treat as verification failure and require confirmationRate limit hit (HTTP 429)Warn the user; do not retry automatically; require confirmation to proceed without verificationVerification passes all checksReturn control to the calling skill to proceed with executionVerification fails a checkHalt; surface the specific discrepancy; do not execute