Final core EIP that defines the wrapper format `TransactionType || TransactionPayload`, enabling the EVM to support multiple transaction formats (legacy, 2930 access lists, 1559 fee market, 4844 blobs, 7702 set-code) without breaking backward compatibility.
- 01transaction encoding / decoding
- 02wallet libraries supporting multiple tx types
- 03indexers / explorers
- 04RPC clients
- 05multi-chain EVM tooling
- pnpm add viem
- pnpm add @ethereumjs/tx
- pnpm add ethers
When encoding/decoding raw transactions, branch on the first byte: `0x00`–`0x7f` is a typed transaction (Type-1=2930, Type-2=1559, Type-3=4844, Type-4=7702) where the byte is followed by an RLP-encoded type-specific payload, while `0xc0`–`0xfe` is a legacy RLP-encoded transaction. The same envelope rule applies to receipts. Use `viem.parseTransaction` / `serializeTransaction` or `@ethereumjs/tx`'s `TransactionFactory.fromSerializedData` rather than rolling your own RLP — both honor the type-prefix byte. Always include the TransactionType as the first byte of the signed digest (`keccak256(type || rlp(payload))`) so signatures cannot be replayed across types.
- ⚑Pre-EIP-2718 (Berlin) clients reject typed transactions — when targeting older chains or forked networks, fall back to legacy Type-0 with `chainId` baked into `v` (EIP-155).
- ⚑Signature reuse across transaction types: signing only `keccak256(rlp(payload))` (without the type prefix) lets an attacker replay the same signature as a different tx type; always prefix the type byte before hashing.
- ⚑RLP decoders that auto-detect by structure mis-parse typed txs as garbage RLP — sniff the first byte first, then dispatch to the type-specific decoder.
- ⚑Receipt envelopes must match the tx type — indexers that special-case logs by `tx.type` but read receipts as legacy will drop status/logs for typed txs.
- ⚑TransactionType is reserved up to `0x7f`; values `0x80`–`0xbf` are RLP single-byte strings and `0xc0`+ are RLP lists — never assign a custom type outside `0x00`–`0x7f`.
- ⚑Some L2s (Arbitrum Nitro) define their own transaction types (e.g. ArbitrumDeposit `0x64`) — generic EVM tooling needs a chain-aware type registry to decode them.