Failed transaction in.
Working transaction out.
TxWhy finds the exact reason a Solana transaction failed, rebuilds it, and proves the rebuilt one works by simulating it against live chain state. For people, bots and AI agents.
a real mainnet failure, repaired on Oct 7, 2026
Why this exists
Every tool explains the failure. None of them fixes it.
On a busy day somewhere between one in eight and one in two Solana transactions fail. Bots and agents fail more than half of what they send, and the priority fee is burned every time. What they get back is a code like Custom(6001). Explorers and AI explainers tell you what happened. TxWhy hands you the transaction that works, and proves it.
Before and after
What your bot sees today, and what it gets back from TxWhy
The same failed Jupiter swap, both ways. Switch between them.
SendTransactionError: Simulation failed.
Message: Transaction simulation failed: Error processing
Instruction 2: custom program error: 0x1771
Logs:
Program JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 invoke [1]
Program log: AnchorError occurred. Error Code:
SlippageToleranceExceeded. Error Number: 6001.
Program JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 failed:
custom program error: 0x1771
→ retry blind, widen slippage, or give up. The fee is gone either way.How it works
Six stages, about a second, one rule at the end
Pick a stage to see what it does and, just as important, what it refuses to do. The last stage runs on your machine, not ours.
What it does
Applies only the fix that matches: budget, blockhash, fee, a re-quoted Jupiter swap, or a direct swap's limit moved to the price the chain itself computed.
What it refuses
A route above 3% price impact, a quote or limit more than 25% worse, a chained swap: refused, with the reason.
The rebuilt transaction comes back unsigned. You sign it with your own wallet. TxWhy never sees a key.
Right now on mainnet
What is failing, measured every 90 seconds
A worker samples the nine busiest programs around the clock, classifies each failure with the same engine you get, and replays a slice through the repair path. The numbers on this page are read from it, not typed in.
Share of sampled transactions that failed, last pass. Most of the failures on the big exchanges are bots built to miss; the failure index separates them and says exactly what happened to each one TxWhy tried.
Coverage
What it handles today
Fixes
Blockhash expired
Replaced with a current one, after checking the original had really expired.
Compute budget exceeded
Run at the maximum budget, read what it truly used, set the limit to that plus headroom.
Dropped under load
Priority fee set from what the network recently charged for the exact accounts you write to, capped at 0.001 SOL.
Loaded account data limit too small
Lifted when the transaction declares less than it actually loads.
Slippage on a Jupiter swap
Only the swap instruction is replaced with a fresh quote for the same tokens, amount and tolerance. Refused above 3% price impact.
Slippage on a direct Pump.fun, PumpSwap, Raydium or Meteora swap
Amount and accounts stay as written. Only the limit moves to the price the chain itself computed, never more than 25% against you.
Version 1 transactions
Solana's new format since Sep 15, 2026. Read and rebuilt natively, including the compute settings in the header.
Explains, and says so
Your wallet's safety guard tripped
A Lighthouse assertion shares the number 0x1771 with Jupiter's slippage error, so explorers call it slippage. TxWhy decodes the guard and names the exact requirement that failed.
Not enough SOL, or not enough tokens to sell
The exact shortfall: what the account holds, what the swap needs, in SOL or in the token's units.
A program rejected it
The named cause and fix from the program's own published errors, where they exist.
When a rebuild cannot fix it, TxWhy says so, with the exact reason. It never hands back a transaction that would fail again, and it refuses a repair you should not sign: a thin route, a price that moved too far.
Integrate
One line in your send loop. Three languages, one rule.
Most failures happen at simulation, before anything is sent, so that is where the repair belongs. If your transaction passes, it is signed and sent and TxWhy is never contacted. If it would fail, it comes back rebuilt, is checked on your machine, and only then reaches your signer.
npm i @txwhy/sdk
import { sendWithRepair } from "@txwhy/sdk";
// simulate -> repair if it would fail -> verify locally -> sign -> send
const { signature, repairs } = await sendWithRepair(
connection,
transaction,
(tx) => wallet.signTransaction(tx), // your keys never leave your process
);From a terminal: npx @txwhy/sdk <signature>. On @solana/kit, including version 1 transactions: import { sendWithRepair } from "@txwhy/sdk/kit".
Validation
Tested by builders, fixed the same day
“Explanation 3 of 3 correct, would sign 0 of 3 as presented. The CLI output itself is excellent (blockhash/quote/CU diff, ‘nothing else was touched’).”
Four days and four rounds later: “A hard 3% impact cap and a NO REPAIR headline is exactly what I’d want as a signer. Four rounds, every point fixed the same day.”
What he found and what changed, round by round, is in TESTERS.md. Run one of your own failed signatures and tell me what is wrong with the answer.
In the explorer
Where you actually land when something fails
The first thing anyone opens is the explorer page, and the explorer stops at custom program error: 0x1771. The TxWhy browser extension adds the missing paragraph on Solscan, Solana Explorer, SolanaFM and Orb: the failing instruction, the cause in plain words, what to do, and whether a rebuilt version passes right now. It reads only the signature from the URL and talks only to this site.
Free and open source, in extension/ in the repo. Load it unpacked from chrome://extensions until it is on the Web Store.
Proof, on chain
Two transactions on mainnet you can open yourself
Every other claim on this site, next to the one link that checks it: txwhy.vercel.app/proof
A repaired transaction that landed
An agent built a swap on a stale quote. Without TxWhy it failed simulation with
5BaKDPgC…zXhymq on Solscan →0x1771. With one line, it was rebuilt from a fresh quote for the same trade, verified locally, signed by the agent, and landed in slot 449,732,359.An agent that paid for a repair
$0.001 in USDC over x402 for a verified slippage repair, settled only after the answer came back, network fee paid by the facilitator. No account, no API key.
2t4hz3zm…AcAUzrA on Solscan →
Trust
You never have to trust us
Signing a transaction that a server rebuilt should make you nervous. So every repair comes with a proof, and the check behind it is open source, has no network access, and runs on your machine, in TypeScript, Rust or Python. A repaired transaction may differ from yours only in these ways:
- compute budget settings: limit, priority fee, loaded data size
- the recent blockhash
- one Jupiter swap replaced by another for the same wallet, the same source and destination token accounts, the same output token, the same amount, the same slippage tolerance, and a quote no more than 25% worse
- one direct swap with only its limit moved, never more than 25% against you
- a SOL wrap into that swap’s own input account raised by no more than the maximum rose
Same fee payer, same signers, every other instruction byte for byte and in the same order. Anything else is refused. The test suite attacks the rule 48 ways: an extra transfer, a redirected fee, a new signer, a widened slippage, proceeds sent to a stranger, a quote 26% worse. All are caught, and the three verifiers are tested against the same real-repair fixtures. TxWhy runs the same check on its own output and will not return a transaction that fails it.
import { verifyRepair } from "@txwhy/sdk";
const check = await verifyRepair(connection, original, repaired); // no network call
if (!check.ok) throw new Error(check.violations.join(" ")); // never sign itPricing
Free for people. A tenth of a cent for agents.
The website, the bot and /api/v1/repair are free and rate limited. Agents that need guaranteed capacity call /api/x402/repair instead: $0.001 in USDC per repair over x402, no account, no API key, charged only when the answer succeeds. A repaired transaction that lands costs less than the priority fee on one that does not.
API and MCP
For agents and bots
One call inside your send loop. When your RPC rejects a transaction at simulation, pass it here and get back a version that passes, typically in under a second. Most failures never reach the chain. They happen at this step, and this is where TxWhy sits.
curl -X POST https://txwhy.vercel.app/api/v1/repair \
-H "content-type: application/json" \
-d '{"transaction": "<base64, signed or unsigned>"}'{
"status": "repaired",
"cause": { "title": "Compute budget exceeded", ... },
"changes": [
{ "type": "compute_unit_limit", "before": "100", "after": "518", "reason": "..." }
],
"repairedTransaction": "<base64, unsigned>",
"simulation": { "passed": true, "unitsConsumed": 450 },
"verification": { "ok": true, "kept": 3 }
}Or plug it into any agent as a tool
TxWhy is an MCP server. Add the URL and your agent gets three tools: repair_transaction, diagnose_transaction and explain_error. No key, no account.
{
"mcpServers": {
"txwhy": { "url": "https://txwhy.vercel.app/api/mcp" }
}
}You can also pass {"signature": "..."} for a transaction that already landed and failed. Status is one of repaired, valid, needs_requote or not_repairable.