Solana Transaction Decoder

What is a serialized Solana transaction?

A serialized Solana transaction is a compact byte array: a count-prefixed list of 64-byte ed25519 signatures followed by the message, which holds a header (number of signers and read-only accounts), the account addresses as 32-byte keys, a recent blockhash and the instructions, each referencing its program and accounts by index. Wallets and RPC nodes exchange it as base64 or base58; the first signature doubles as the transaction ID.

Reading the result

Accounts are listed in message order: signers first, then writable, then read-only. The fee payer is account 0.
Instructions show the program, the decoded name and fields, and under "Accounts and data" the exact account list and data bytes.
Transfers at the top summarise what moves: SOL via the System Program and tokens via Transfer / TransferChecked.

Legacy vs. versioned (v0) messages

Property	Legacy	v0 (versioned)
Message prefix	none; starts with the header	0x80 version byte before the header
Accounts	all listed inline, up to the 1232-byte limit	inline plus indexes into address lookup tables
Resolvable offline	yes, every account is in the message	lookup-table entries need on-chain data
Typical producers	simple wallets, older SDKs	DEX aggregators, anything with many accounts

Worked example

A SOL transfer message has 3 accounts: the sender (signer, writable), the recipient (writable) and the System Program 11111111111111111111111111111111. Its single instruction points at account index 2 with data 02000000 (instruction 2 = Transfer, as a little-endian u32) followed by the amount as a little-endian u64, so 00e1f50500000000 is 100,000,000 lamports = 0.1 SOL. A USDC transfer instead targets the Token program with a TransferChecked instruction carrying the amount and decimals = 6.

Checking a wallet prompt

When a dApp requests a signature, wallets often display a simulation. If you want the ground truth, log the serialized message from the dApp (most libraries expose transaction.serialize({ requireAllSignatures: false })) and paste it here: you will see every instruction, including Compute Budget settings and any SetAuthority or Approve that a simulation summary might hide.

Frequently asked questions

What formats work?

The base64 from getTransaction with encoding base64, from a wallet's signTransaction, or from Transaction.serialize(); base58 as used by sendTransaction; raw hex. A bare message (without the signature array) is also accepted, which is what some wallets show before signing.

What is a v0 transaction?

Versioned transactions (v0) can reference accounts stored in address lookup tables to fit more accounts in the 1232-byte limit. The decoder shows the table addresses and indexes, but the actual accounts behind them live on-chain and cannot be resolved offline; they appear as 'lookup-table account #n'.

Is the transaction signature the same as a hash?

On Solana the first signature serves as the transaction ID. It is shown when the signature slot is non-zero; an unsigned transaction has no ID yet.

Which instructions are decoded?

System Program transfers and account creation, SPL Token and Token-2022 transfers, approvals, mints, burns and closes (checked variants show the amount with decimals), Associated Token Account creation, Compute Budget limits and prices, and Memo text. Other programs are shown by name where known (Jupiter, Raydium, Orca, Metaplex) with raw accounts and data.

What is the 1232-byte limit?

Solana transactions must fit in one network packet: 1280 bytes of IPv6 MTU minus headers leaves 1232 bytes for the serialized transaction. Each account costs 32 bytes and each signature 64, which is why large transactions use lookup tables.

Why are amounts in raw units for SPL Transfer?

The plain Transfer instruction does not carry decimals, only TransferChecked does. Convert raw units with the decimals converter once you know the mint's decimals.