Decodificador de transacciones de Ethereum online

What a raw transaction is

A raw Ethereum transaction is the exact byte string a wallet signs and a node relays with eth_sendRawTransaction. Nothing in it is human-readable: the recipient, the amount and the function call are RLP-encoded fields, and the sender is not written anywhere at all. Hardware wallets that cannot show what a contract call does ask you to sign blindly — blind signing — and that is how most wallet drains begin. This decoder takes the bytes apart in your browser before you sign or broadcast them.

Every envelope in use

The first byte tells the envelopes apart. A byte of 0xc0 or above opens an RLP list: a legacy transaction [nonce, gasPrice, gas, to, value, data, v, r, s]. Since EIP-155 the chain id is folded into v (chainId × 2 + 35 or + 36), so a signature made for one network cannot be replayed on another; a v of 27 or 28 means a pre-EIP-155 transaction that every EVM chain accepts. Any other first byte is a type (EIP-2718):

• 0x01 — an access list of addresses and storage slots the transaction pre-declares (EIP-2930);
• 0x02 — the dynamic fee transaction of EIP-1559: a maximum fee per gas and a priority tip instead of one gas price;
• 0x03 — a blob transaction (EIP-4844) that commits to blobs by their versioned hashes. On the peer-to-peer network it travels wrapped together with the blobs, their KZG commitments and proofs; since EIP-7594 the wrapper has a version byte and 128 cell proofs per blob. The decoder reads both wrappers, checks that each commitment hashes to its versioned hash, and decodes the inner transaction;
• 0x04 — a set-code transaction (EIP-7702) carrying authorizations that make accounts run a delegate contract's code.

Unsigned forms — what a wallet is asked to sign, including the legacy EIP-155 payload […, chainId, 0, 0] — are decoded too, as is the JSON object a node returns for eth_getTransactionByHash: it is rebuilt into bytes, and the hash and sender the node reported are compared with the ones computed from those bytes.

Where the sender comes from

The sender is recovered from the signature. The decoder hashes the signing payload — the type byte followed by the RLP of the unsigned fields — with Keccak-256, recovers the secp256k1 public key from r, s and the parity bit (public key recovery, the same operation as ecrecover) and takes the last 20 bytes of the key's hash as the address. It also applies the rules nodes apply to the signature: r and s inside the curve order, and s in the lower half (EIP-2), because a high-s twin of a valid signature would otherwise be a second valid encoding of the same transaction.

The rules nodes enforce

Every field is checked the way clients check it: integers must be minimally encoded and fit their width, addresses are 20 bytes, storage keys and blob hashes 32. The gas limit must cover the intrinsic cost — 21,000 plus 4 gas per zero and 16 per non-zero calldata byte, the access list, 25,000 per authorization — and, since the Prague upgrade, the calldata floor of EIP-7623. Contract creation code is limited to 49,152 bytes (EIP-3860); blob and set-code transactions cannot create contracts at all. Rules of the Osaka upgrade — the 2²⁴ gas cap per transaction of EIP-7825 and the limit of six blobs — are shown as warnings, since not every EVM chain has activated them. The field map lists each field with the byte offsets it occupies, so you can see exactly which bytes mean what.

The function call and its risks

Calldata starts with a four-byte selector, the first bytes of the Keccak-256 hash of the function's canonical signature. The decoder recognises the functions that move or expose tokens — ERC-20 transfer, approve, transferFrom and increaseAllowance, ERC-721 and ERC-1155 transfers and setApprovalForAll, ERC-2612 and DAI permits, Uniswap Permit2 approvals, WETH — and looks inside multicall, Multicall2 and Multicall3 batches. It then flags what endangers the signer:

• an unlimited approval (an amount of 2²⁵⁵ or more, or the maximum of a Permit2 allowance), which lets the spender take every token of that kind you hold now or later;
• an approval for all of an NFT collection, the usual mechanism of NFT drains;
• native currency sent along with a token function, which either reverts or means the recipient is not the token you think;
• tokens sent to the zero address, where they are burned;
• an EIP-7702 delegation, which hands the delegate contract full control of the account — the EIP-7702 decoder checks each authorization and names known delegates, including known sweepers.

A selector outside the table is shown as is: look it up in a signature database before you sign.

What runs locally, and what is sent

Decoding, signature recovery and every check run in your browser with audited libraries (@noble/curves, @noble/hashes); the transaction you paste is never sent anywhere. Two optional lookups use a public JSON-RPC node of the network you choose, or your own RPC URL, and only when you press their button: fetching a transaction by its hash (eth_getTransactionByHash, which sends the hash) and checking whether the recipient has code (eth_getCode, which sends its address) — calldata sent to an address without code runs nothing, a sign of a mistyped or look-alike address. Your own RPC URL stays on the page and is never put into share links.

The decoder does not simulate execution: it shows what a transaction asks for, not what a contract will do with it. KZG proofs of blob wrappers are counted but not verified, since that needs the KZG trusted setup a node holds. For messages rather than transactions, use the Ethereum signature verifier or the EIP-712 inspector, and read how EIP-712 typed data is signed.