SOLTidy

Explore & calculate

Decode a Solana transaction in plain language

Paste a transaction signature or an explorer link and see what it actually did: who paid, which balances changed, every instruction, and why it failed if it did.

How it works

  1. 1

    Paste a signature or link

    Enter the base58 transaction signature, or paste a Solscan, Solana Explorer or SolanaFM link and the signature is pulled out of the URL for you.

  2. 2

    Read the summary

    The decoder fetches the transaction from mainnet and shows its status, time, slot, fee, compute units, and a short account of what the fee payer sent and received.

  3. 3

    Inspect balances and instructions

    Check SOL and token balance changes per account, then open each instruction to see the program, the parsed fields or raw data, and any inner instructions it triggered.

  4. 4

    Open the logs when something failed

    Program logs are collapsed by default. Expand them to see error lines highlighted in red, next to a decoded explanation of the error code where one is known.

What is inside a Solana transaction?

A Solana transaction is a signed message with four parts: a list of every account it will touch, a recent blockhash that makes it expire after roughly a minute, one or more instructions, and the signatures that authorise it. The first signature doubles as the transaction id — the 87 or 88 character base58 string you paste into an explorer. The first account in the list is always the fee payer, and it must sign.

Each instruction names a program, the accounts that program may read or write, and an opaque blob of bytes that only the program knows how to interpret. A wallet transfer is one instruction to the System Program. A swap is usually two Compute Budget instructions, perhaps an Associated Token Account creation, and one call to a router such as Jupiter, which then calls several liquidity pools on your behalf. Those nested calls are inner instructions, and the decoder shows them indented under the instruction that caused them.

How to read balance changes instead of instructions

Instructions tell you what a transaction asked for. Balance changes tell you what happened. Every confirmed transaction records the SOL balance of each account before and after execution, plus the token balance of every token account involved. The decoder subtracts one from the other and lists only the accounts that changed, grouped by the wallet that owns each token account rather than by the token account address, so a swap reads as one wallet losing one token and gaining another.

The fee payer's SOL change always includes the network fee, so the decoder shows that row twice: the net change, and the change before the fee was taken. Small SOL movements of about 0.00204 SOL are nearly always rent: that amount is deposited when a token account is created and returned when it is closed. If a wallet's SOL went up by that amount, it closed an account; tools like the SOLTidy token account closer do exactly this in bulk.

Why did my Solana transaction fail?

A failed transaction still lands in a block and still pays its fee, but none of its instructions take effect — Solana transactions are atomic. The error names the instruction that stopped execution and a reason. Built-in reasons are readable, such as InsufficientFunds or ComputationalBudgetExceeded, which means the transaction ran out of compute units before finishing. Program-specific reasons arrive as a number, shown in hex in the logs, for example custom program error 0x1771.

That number only has meaning inside the program that raised it. 0x1771 is 6001 in decimal, which in Jupiter v6 is slippage tolerance exceeded: the price moved past the limit you set between signing and execution. In the SPL Token program, 0x1 means insufficient funds and 0x11 means the account is frozen. The decoder finds which program raised the error from the logs, since it is often an inner program rather than the one you called, and translates the codes it knows for the System, SPL Token, Token-2022 and Jupiter programs.

Fees, priority fees and compute units in a transaction

Every transaction pays a base fee of 5,000 lamports per signature. On top of that, a transaction can bid for faster inclusion with a priority fee, set by two Compute Budget instructions: one requests a compute unit limit, the other sets a price in micro-lamports per compute unit. The priority fee is the limit multiplied by the price — note that it is charged on the limit requested, not on the units actually consumed.

The decoder reads both instructions directly from their bytes, because RPC nodes do not parse the Compute Budget program, and splits the fee into base and priority parts. It also shows compute units consumed against the limit requested. A large gap between the two means the sender overpaid: requesting 1,400,000 units for a transaction that uses 60,000 costs more than twenty times the priority fee it needed. Use the priority fee tracker to see what the current market rate is.

Which programs does the decoder recognise?

Instructions to the System Program, SPL Token, Token-2022, the Associated Token Account program and the Stake Program are turned into one-line descriptions such as Transfer 1.5 SOL from one address to another, or Close token account and send its rent to the owner. Compute Budget and Memo instructions are decoded too. Token amounts are shown in human units using the decimals recorded in the transaction, not as raw integers.

Other well-known programs are labelled by name so you can see at a glance who was called: Jupiter v6, Raydium AMM v4, CLMM and CPMM, Orca Whirlpool, Meteora DLMM, Pump.fun and PumpSwap, Phoenix, OpenBook v2, Metaplex Token Metadata and Bubblegum, Magic Eden v2, Tensor, the BPF Upgradeable Loader, Address Lookup Table, Vote and others. Their instruction data is shown as raw base58 alongside the ordered account list, because decoding it properly requires each program's own interface definition. Every program id in the list was verified as an executable account on mainnet.

Questions & answers

How do I decode a Solana transaction?

Copy the transaction signature from your wallet's activity list or from an explorer URL, paste it into the box above and press Decode. The tool fetches the transaction from Solana mainnet with the getParsedTransaction RPC method and lays out the status, fee, balance changes, instructions and logs. You can also paste a full Solscan, Solana Explorer or SolanaFM link and the signature is extracted automatically.

Is the Solana transaction decoder free?

Yes. There is no fee, no account and no usage limit beyond what the RPC endpoint allows. The decoder only reads public blockchain data, so there is nothing to charge for and no transaction to attach a fee to. Most other SOLTidy tools that send transactions state their fee up front; the read-only tools, including this one, are free.

Is it safe to paste a transaction signature here? Do I need to connect a wallet?

It is safe, and no wallet is needed. A signature is a public identifier, not a secret — anyone can look up any transaction with it, and it cannot be used to move funds. The decoder never asks for a wallet connection, a seed phrase or a signature from you. The lookup goes from your browser to a Solana RPC node and the decoding happens locally in the page.

Why does it say the transaction was not found?

There are three common reasons. The transaction may be on devnet or testnet, while this tool reads mainnet. It may be very old: many RPC nodes keep only recent history, and an archive-backed explorer may still have it. Or it may never have landed — a transaction that expired or was dropped before confirmation has a signature but no on-chain record anywhere.

What does custom program error 0x1 or 0x1771 mean?

Custom errors are numbers defined by the program that failed, written in hexadecimal in the logs. In the SPL Token program 0x1 is insufficient funds: the token account did not hold enough to cover the transfer. 0x1771 equals 6001, which in Jupiter v6 means the swap exceeded your slippage tolerance. The same number means something different in another program, so the decoder first works out which program raised it.

Do I still pay a fee when a Solana transaction fails?

Yes. If a transaction is included in a block and fails during execution, the fee payer is charged the full fee, including any priority fee, because validators did the work of processing it. Every other effect is rolled back. Only transactions that never reach a block — expired blockhash, dropped by the network, rejected in your wallet — cost nothing.

What is an inner instruction?

An inner instruction is a call one program makes to another while your instruction is running, known as a cross-program invocation. When you swap through an aggregator you sign one instruction, but the aggregator calls several pools and each pool calls the token program to move funds. Those nested calls are recorded with the transaction, and the decoder lists them under their parent so you can see where tokens really went.

Can I share a decoded transaction?

Yes. After a successful lookup the page address changes to include the signature as a tx parameter, for example /tools/transaction-decoder?tx= followed by the signature. Anyone opening that link sees the same transaction decoded straight away. Nothing is stored on SOLTidy's side; the link simply tells the page which public transaction to fetch again.

Is this tool free?

The Transaction Decoder is free. It only reads public data from Solana mainnet, needs no wallet, and never asks you to sign anything.

Guides that go deeper

Built and maintained by Jacob, a Solana trader who uses these tools daily. Content reviewed . Every transaction is built in your browser and signed in your own wallet — see the terms for fees.