Decoding Raw RLP-Encoded Ethereum Transactions
A raw Ethereum transaction is a hex string in RLP (Recursive Length Prefix) encoding. It is what travels over the wire to a node, what you sign with a hardware wallet, and what shows up in mempool monitoring tools. Decoding raw transactions lets you verify exactly what was signed, before broadcast, regardless of what any UI claims.
Try it now
Transaction Decoder
Runs in your browser, nothing leaves your device.
Since EIP-2718, Ethereum transactions can be typed. A leading byte of 0x01 marks an EIP-2930 access-list transaction, 0x02 marks an EIP-1559 fee-market transaction. Anything starting with 0xc0 to 0xff is RLP-encoded directly and treated as a Legacy transaction. The fields inside differ by type, so the first thing to do is identify the type.
Every transaction has a nonce, gas limit, destination address, value (in wei), and calldata. EIP-1559 splits gas pricing into maxPriorityFeePerGas and maxFeePerGas. EIP-2930 and 1559 add a chain ID field directly in the structure (Legacy stores it inside v via EIP-155). The signature is always (r, s, v) at the end, where v encodes both the y-parity and historically the chain ID.
Hardware wallet flows: the device displays a summary, but the host machine constructs the RLP. Comparing what the device shows against the decoded RLP catches host-side tampering. Mempool research: pending transactions are raw RLP until included in a block. Replay protection: a transaction signed for chain ID 1 should not be valid on chain ID 137, decoding the chain ID confirms the binding.
Examples
Legacy transaction structure
0xf86c80850430e23400825208940123...01880de0b6b3a76400008026a0...a0...
Legacy tx: nonce=0, gasPrice=18 gwei, gasLimit=21000, to=0x0123..., value=1.0 ETH, v=0x26 (chain ID 1, parity 1)
EIP-1559 type prefix
0x02f8...
Type 0x02 = EIP-1559. Fields are chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, then v, r, s.
Security context
Hardware wallets exist because the host computer cannot be trusted to display the truth. The raw signed transaction is the contract you are entering into. If the device summary and the decoded raw transaction disagree, the host is compromised. Verifying matches takes seconds and prevents the entire class of clipboard-swapping malware that has stolen millions.
Frequently asked
Calldata is one field inside a transaction, the input to the contract being called. The raw transaction wraps calldata together with nonce, gas parameters, value, destination, and signature. You sign the raw transaction. Contracts only see the calldata.
Legacy transactions encode chain ID inside v (EIP-155): v = chainId * 2 + 35 or 36. A v of 37 means chain ID 1 (Ethereum mainnet). EIP-2930 and EIP-1559 carry chain ID as an explicit field, so no decoding trick is needed there.
Related techniques
Decoding EVM Transaction Calldata
Read Ethereum transaction calldata to identify which function is being called, what parameters were passed, and whether the transaction does what the UI claims.
Reverse Lookup of EVM Function Selectors
Identify unknown 4-byte function selectors by computing keccak256 of candidate signatures. Useful when reading calldata against unverified contracts.
Detecting Token Approval Phishing in Calldata
Spot malicious approve(), permit(), and setApprovalForAll() calls before signing. Learn the calldata patterns wallet drainers use to empty wallets in a single signature.