1 · Does it revert?
Simulated against state at the current block. The single largest class of agent failure is a transaction that simply fails — burning gas and achieving nothing. Gas-free, no footprint on chain.
Send the unsigned transaction. Get back what it would do, what it actually authorises,
and who is on the other side. POST /api/v1/base/tx-preflight
Preflight takes no private key and no signed payload. Simulation runs through
eth_call, where the sender is asserted rather than proven — so no signature is needed to
learn what a transaction would do.
That is the design, not a missing feature. A preflight service that could sign would be a more attractive target than the transaction it was asked to inspect: it could broadcast, front-run, or leak. There is no key material in the request, so there is nothing here to misuse and nothing to steal from us. You keep the signature, and with it the only thing that moves funds.
Simulated against state at the current block. The single largest class of agent failure is a transaction that simply fails — burning gas and achieving nothing. Gas-free, no footprint on chain.
The calldata is decoded. An agent that cannot read a selector cannot tell transfer from approve(spender, 2²⁵⁶−1) — an unbounded claim on your balance that outlives the trade by design.
The counterparty is checked against our own Base liquidity archive: removals observed against it, and the other tokens drained in the same transactions. History a simulator structurally cannot see.
The example below is an unlimited USDC approval to a router — the most common expensive mistake in the space. Nothing is signed and nothing is sent; the request is the same one an agent would make. First few calls a day are free, no wallet.
curl -X POST https://true402.dev/api/v1/base/tx-preflight \
-H 'content-type: application/json' \
-d '{
"from": "0xYourAgentWallet",
"to": "0xTokenOrContract",
"data": "0x095ea7b3…"
}'
# -> { risk: "high", verdict: "1 high-severity finding. Unlimited approval to 0x2626…",
# findings: [ { severity: "high", code: "unlimited_approval", detail: "…" } ],
# simulation: { ok: true, note: "Simulated against state at the current block." },
# limits: [ "No signature is taken, so this describes the transaction supplied…" ] } Machine-readable everywhere it should be: it is in the OpenAPI spec, the live catalog, and the MCP manifest — so an agent can discover and call it without anyone writing an integration. Pair it with liquidity history when you want the counterparty's full record rather than a summary.
A check you run on a transaction before you sign it. You send the unsigned transaction — from, to, calldata, value — and get back three things: a simulation against current chain state (does it revert?), the decoded intent (what does this calldata actually authorise?), and the counterparty's liquidity-removal history from true402's own Base archive. It is the last question an autonomous agent should ask itself before committing funds.
Because it does not need one, and taking one would make the service more dangerous than the transaction it inspects. Simulation uses eth_call, where the sender is asserted rather than proven, so no signature is required to find out what a transaction would do. A preflight service that held keys or accepted signed payloads could broadcast your transaction, front-run it, or leak it to someone who would. true402 structurally cannot: there is no key material in the request, so there is nothing to misuse and nothing to steal from us.
An ERC-20 approve grants a spender the right to move your tokens. Most integrations request the maximum possible amount because it saves a transaction later, but that grant does not expire when the trade finishes — it is a permanent, unbounded claim on your balance that can be drawn at any point in the future, including after the spender contract is upgraded or compromised. Preflight decodes the amount and flags it as high severity, so an agent can approve only what the trade requires.
No, and it never says so. A clean result means these specific checks found nothing, which is reported as risk "none-observed" rather than "safe". Every response carries a limits array stating the three real constraints: no signature is taken so the answer describes the transaction supplied rather than the bytes eventually signed, simulation reflects state at the current block and state can change before the transaction lands, and an absence of findings is not a guarantee.
History. A simulator sees current state, so a pool that was drained last month simulates perfectly today if someone re-seeded it. true402 checks the counterparty against its own archive of observed Base liquidity removals — including which other tokens were drained in the same transaction, which links pools to a single operator. That is a record you either kept as it happened or do not have.
No account, no API key, no signup. It is $0.008 per call paid in USDC over x402 — the agent gets a 402 with payment requirements, pays, and retries. The first few calls each day are free per IP so you can evaluate it without a wallet.