Transcript of proceedings
In the matter of one Solana transaction
Every signature tells a story.
We read it into the record.
Paste a transaction signature. Txplainer pulls it from a public Solana node and writes a plain-English transcript: who paid, what moved, which programs were called, what it cost and whether it succeeded.
- Court in session · slot
- —
- Transactions / sec (last min)
- —
- Status
- connecting…
The hearing
Enter a transaction signature (87–88 base58 characters). Or call a fresh witness: the example buttons fetch a transaction that landed on Solana seconds ago.
Order of procedure
Four steps, all in your browser. No account, no wallet, no server of our own.
-
1 · The filing
You paste a signature — the 64-byte fingerprint the fee payer's key put on the transaction, written in base58.
-
2 · The subpoena
Your browser asks a public Solana RPC node for
getTransactionin jsonParsed form, so many instructions arrive already decoded. -
3 · Cross-examination
We diff balances before and after, walk every top-level and inner instruction, name known programs and look up token symbols via Jupiter.
-
4 · The verdict
A one-paragraph summary, then exhibits: SOL and token changes, programs, each instruction in plain English, and raw logs for the curious.
What the record can tell you
“Did my swap go through?”
See success or failure at a glance, and if it failed, which instruction failed and the program's error code — instead of a wall of hex.
“Why did I get less?”
Token balance changes show exactly what left and what arrived, per owner, so you can compare the result against the quote you were shown.
“What did it really cost?”
The fee is split into the base signature fee and the priority fee you added, alongside compute units used versus the limit requested.
“What did I approve?”
Every program the transaction touched is listed, including ones called indirectly. Unknown programs are flagged so you can look them up.
Support tickets
Send a teammate or a project's support desk a link that opens the same transcript, instead of screenshots of a block explorer.
Learning by reading
Pull a fresh real swap, mint or memo and read how it was built. It is the fastest way to understand Solana's account model.
Anatomy of a Solana transaction
A brief for the court: what each part of a transaction is, and how to read it.
Signatures
A transaction carries one or more ed25519 signatures. The first signature is the transaction's ID — that is what you paste here — and the first signer is the fee payer. Additional signers appear when, for example, a new account's keypair must authorise its own creation.
Accounts
Solana programs hold no state of their own; everything lives in accounts that must be listed up front. Each account is marked signer and/or writable. Declaring this in advance is what lets the runtime execute non-overlapping transactions in parallel. Balances are reported as two arrays, preBalances and postBalances, in the same order as the account list; the difference is what changed.
Instructions
An instruction names a program, the accounts it may touch and an opaque byte string of data. Instructions run in order, and the whole transaction is atomic: if any one fails, every change is rolled back, but the fee is still charged.
Inner instructions (CPI)
Programs can call other programs — a cross-program invocation. An aggregator such as Jupiter calls a pool program, which calls the Token program to move funds. These appear under innerInstructions, grouped by the top-level instruction that caused them, with a stack height showing depth.
Compute budget
Every transaction gets a compute-unit (CU) budget, up to 1.4 million CU. Wallets usually request a tighter limit and a priority fee, priced in micro-lamports per CU. In legacy and v0 transactions this is done with ComputeBudget program instructions; the newer v1 format carries a transactionConfig with the limit and the priority fee directly.
Fees
The base fee is 5,000 lamports per signature (1 SOL = 1,000,000,000 lamports). The priority fee is extra, paid to the block producer to improve the odds of inclusion when blocks are busy. Rent deposits for new accounts are not fees: they show up as SOL moving into the new account and can be reclaimed when it is closed.
Versions and lookup tables
Legacy transactions list every account inline. Version 0 added Address Lookup Tables (ALTs), letting a transaction reference up to 256 addresses stored on chain, which is how complex multi-hop swaps fit in the 1,232-byte packet limit. Accounts loaded this way are tagged lookupTable in the parsed output.
Reading the logs
Logs read like a call stack. Program X invoke [1] means a top-level call; [2] means one level deep. Program log: lines are messages the program chose to print, consumed N of M compute units reports cost, and the call ends with success or failed: custom program error: 0x…. That hex number is the program's own error code — look it up in that program's documentation.
| Instruction | Program | What it means |
|---|---|---|
| transfer | System | Moves native SOL from one wallet account to another. |
| createAccount | System | Funds a new account with rent and assigns it to a program. |
| transferChecked | Token / Token-2022 | Moves tokens between token accounts, verifying mint and decimals. |
| create / createIdempotent | Associated Token Account | Opens the standard token account for a wallet + mint pair. |
| closeAccount | Token | Closes a token account and returns its rent SOL. |
| setComputeUnitPrice | ComputeBudget | Sets the priority fee in micro-lamports per compute unit. |
Questions from the gallery
Most wallets show it under “view transaction” or in an activity entry's details. Block explorers show it as “signature” or “transaction hash”. It is 87–88 characters of letters and digits (base58 excludes 0, O, I and l).
The free public node we read from keeps roughly the last day and a half of history. Older transactions have been pruned from it, even though they still exist on Solana. It can also mean the signature has a typo, belongs to devnet, or never landed.
Validators did the work of checking signatures and running the instructions, so the fee (base plus priority) is charged even when an instruction fails. Every other change is rolled back.
Each program defines its own error numbers. Anchor-based programs start custom errors at 6000; for many swap programs 6001 means slippage was exceeded. Txplainer shows the number and which instruction raised it; the program's docs or IDL hold the exact meaning.
Yes. A signature is public data already on the ledger. Txplainer never asks for a wallet connection, seed phrase or private key, and cannot move funds. If any site asks you for those to “explain a transaction”, leave.
We keep a short list of well-known program IDs. Anything else is shown by address, with a link out. Unrecognised does not mean malicious, but it is worth checking what you interacted with.
Pools, fee vaults, new token accounts and tip accounts all hold SOL. A swap moves lamports through several of them, and new accounts receive rent deposits. We label the fee payer so you can find your own row quickly.
Token symbols come from Jupiter's public token list and anyone can create a token with any name. Always check the mint address, shown next to each symbol. Txplainer does not show USD values for historical transactions.
Limits & honesty
- History window. We use the free node at solana-rpc.publicnode.com, which prunes old blocks. Transactions older than roughly 1–2 days may come back “not found on this public node”, even though they are permanently on Solana. That is why the example buttons fetch a fresh transaction each time instead of a fixed sample.
- Interpretation is heuristic. The verdict summarises balance changes and known programs. Exotic programs, multi-party transactions or unusual token setups can be summarised imperfectly. The exhibits below the verdict are the raw facts.
- Undecoded data. Instructions for programs the node cannot parse are shown as “opaque data”. We do not decode private IDLs.
- Token names come from Jupiter's public search API and can be spoofed by copycats; mint addresses are the ground truth.
- Rate limits. One RPC call and at most one Jupiter call per lookup; example buttons add one more RPC call. The shared node may throttle; just retry.
- Mainnet only. Devnet and testnet signatures will not be found.