EVM Transaction Decoder

What is EVM Transaction Decoder?

Before you broadcast a signed transaction to the network — and especially before paying gas on it — you want to know exactly what you're about to send. Did your wallet correctly encode the function call? Is the to-address right? Is gas reasonable for current network conditions? Is this actually a Type 2 EIP-1559 transaction with proper maxFeePerGas, or did your dApp default to a legacy format that'll overpay? This decoder unpacks any raw signed transaction hex (the long 0xf86... string your wallet exports for signing offline or QR-relaying via Ledger Nano) into human-readable fields: type, chain ID, sender (recovered from signature), recipient, value, nonce, gas, calldata, and v/r/s signature components. Works for all EVM chains — Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche, Fantom, zkSync, Linea, Gnosis. Crucial for cold-wallet workflows, smart contract debugging, gas optimization audits, and verifying that your wallet's UI matches the bytes actually being signed.

Supported EVM Chains

What is a raw transaction hex?

A raw transaction hex is the serialized, signed transaction data in hexadecimal format. It contains all transaction information including sender, receiver, value, gas parameters, input data, and the cryptographic signature. This format is used to broadcast transactions to blockchain networks.

What information can I decode?

The decoder extracts: Transaction type (Legacy, EIP-2930, EIP-1559), Chain ID, From/To addresses, ETH value, Nonce, Gas limit and price, Input data (for smart contracts), and Signature components (v, r, s) used to verify the transaction.

Which blockchains are supported?

All EVM-compatible blockchains are supported, including Ethereum, BSC (Binance Smart Chain), Polygon, Arbitrum, Optimism, Avalanche C-Chain, Fantom, Base, Gnosis, zkSync Era, Polygon zkEVM, Linea, and any other chain that uses the Ethereum Virtual Machine.

What are transaction types (Type 0, 1, 2)?

Type 0 is the original legacy transaction format. Type 1 (EIP-2930) added access lists for gas optimization. Type 2 (EIP-1559) introduced the new fee market with base fee and priority fee, making gas prices more predictable.

Is my transaction data secure?

Yes! All decoding happens entirely in your browser using JavaScript. No transaction data is sent to any server. The tool only reads and displays the publicly visible information already contained in the signed transaction.

Why decode before broadcasting?

Defense against malicious dApps or compromised wallet UIs. A common attack: a phishing site shows you an innocent-looking 'approve' button but actually constructs a transaction that drains your token allowance to the attacker. By decoding the raw bytes before signing, you verify the to-address matches the expected contract, the function selector (first 4 bytes of data) calls the intended method (e.g., 0xa9059cbb for transfer, 0x095ea7b3 for approve), and the parameters are sane. Hardware wallet workflows often involve QR-codes carrying raw tx data — decode before approving on-device.

What's the difference between Type 0, 1, and 2 transactions in practice?

Type 0 (legacy): single gasPrice field, used pre-EIP-1559 and still required for L2s like BSC. Type 1 (EIP-2930): adds an accessList declaring which storage slots will be read — saves gas on complex contract interactions but rarely used now. Type 2 (EIP-1559): replaces gasPrice with maxFeePerGas + maxPriorityFeePerGas (tip to validators). Type 2 is dominant on Ethereum mainnet because it prevents overpaying — the base fee burns automatically, only the tip goes to the validator. If you see Type 0 on Ethereum, your wallet is outdated.

How do I get a raw transaction hex to decode?

Several sources: (1) MetaMask: open the activity tab, click a pending tx, expand 'Details', show raw — wallet versions vary. (2) Ledger Live: enable 'sign with QR' for cold-wallet workflows; the QR encodes the raw tx. (3) Etherscan: any confirmed tx page has a 'Raw Tx' tab. (4) ethers.js / web3.js: `wallet.signTransaction(tx)` returns the raw hex. (5) cast (Foundry CLI): `cast tx --raw <hash>`. (6) MyCrypto offline tool. Paste any of these (starts with 0x) into this decoder.

What is the function selector and how do I read the calldata?

Every contract call begins with a 4-byte function selector: the first 4 bytes of the input data, equal to the first 4 bytes of keccak256 of the canonical signature (e.g. keccak256('transfer(address,uint256)') starts with 0xa9059cbb). This decoder extracts those 4 bytes, labels them against common methods (transfer 0xa9059cbb, approve 0x095ea7b3, transferFrom 0x23b872dd, setApprovalForAll 0xa22cb465, deposit 0xd0e30db0, withdraw 0x2e1a7d4d, and more), and for ERC-20 transfer/approve/transferFrom it ABI-decodes the arguments — showing the EIP-55 checksummed recipient or spender address and the token amount as an exact integer in raw units (no float, no rounding). This is the concrete anti-phishing check: confirm an 'approve' is granting the spender and amount you intend, not an unlimited allowance to an attacker's contract.

What does the 'recovered from' address mean?

The signer's address isn't stored in the transaction directly — it's mathematically recovered from the v/r/s signature components combined with the transaction hash. This decoder runs the secp256k1 elliptic-curve recovery (the same algorithm Ethereum nodes use) to derive who signed. If 'Cannot recover address' appears, the signature is malformed or the wrong chain ID was used (chain ID is in the signing hash, so wrong chain = wrong recovered address). Verifying the recovered 'from' matches your expected wallet is the ultimate proof the tx wasn't tampered with.

How to Use

• Copy your signed raw transaction hex (starts with 0x)
• Paste it into the input field
• Click 'Decode' button to parse the transaction
• View all decoded transaction details including addresses, value, gas, and data