Ethereum RLP Encoding Explained: Prefix Rules, Lists, and Transactions

An Ethereum explorer can show you a neat transaction form, but a node receives bytes. Every implementation must split those bytes at exactly the same boundaries or the network cannot agree on what was sent. The deceptively small set of rules behind much of that execution-layer structure is Recursive-Length Prefix (RLP) encoding.

This guide places RLP inside blockchain basics, then works through its prefixes, nested lists, transaction envelopes, and failure cases. RLP is technical plumbing—not a trading signal—and learning it cannot predict ETH's price.

What Is Ethereum RLP Encoding?

RLP is a serialization method for byte strings and recursively nested lists of byte strings. Serialization means turning structured data into one deterministic byte sequence that can be stored, transmitted, hashed, and decoded later.

Think of nested luggage at an airport. Each bag carries a compact tag saying how much content follows; a suitcase can contain smaller tagged bags. The tag does not say whether an item is a passport, a shirt, or a transaction nonce. It only marks byte or list boundaries. A higher-level Ethereum rule supplies the meaning and field order.

That limited job is intentional. The official Ethereum documentation says RLP primarily encodes structure and delegates most data types to higher-order protocols. It does not natively know strings, addresses, booleans, signed integers, field names, or schemas. In the RLP definition, a “string” is simply a byte array.

The Five RLP Prefix Ranges

The first byte tells a decoder whether it is looking at a byte string or list and how to find the payload length.

For long strings and lists, the prefix first gives the byte length of the length field. That length field then gives the payload length. This two-stage pattern avoids reserving a fixed large field for small objects.

The boundary is based on payload bytes, not the number of list items. A list containing two large items can cross the 55-byte threshold even though it has only two children.

Encoding Small Values Step by Step

Start with the ASCII bytes for dog: 0x64 0x6f 0x67. The payload is three bytes, so its short-string prefix is 0x80 + 3 = 0x83.

dog -> 83 64 6f 67

A single byte from 0x00 through 0x7f encodes as itself. Therefore the one-byte value 0x0f stays 0x0f; wrapping it as 0x81 0x0f is longer and non-canonical.

Empty values reveal an important distinction:

empty byte string -> 80
empty list        -> c0
integer zero      -> 80  (after canonical integer-to-bytes conversion)
byte 0x00         -> 00

RLP does not itself declare that a byte string represents an integer. When a higher-level Ethereum protocol does interpret one as a positive integer, the official rules require the shortest big-endian representation with no leading zeroes. Zero maps to the empty byte array before RLP encoding.

Now place cat and dog in a list. Each three-byte word encodes to four bytes including its prefix. Their combined encoded payload is eight bytes, so the list begins with 0xc0 + 8 = 0xc8.

[cat, dog] -> c8 83 63 61 74 83 64 6f 67

This is the “recursive” part: encode each child first, concatenate those encodings, then prefix the resulting list payload.

Where Ethereum Uses RLP

RLP appears throughout Ethereum's execution layer, but saying “Ethereum uses RLP” without naming the object is too broad.

Legacy and typed transactions

EIP-2718 defines two transaction families. A legacy transaction is an RLP list containing fields such as nonce, gas price, gas limit, destination, value, data, and signature values. A typed transaction instead starts with a transaction-type byte followed by a payload defined by that type.

Many current typed transaction payloads are also RLP lists, but EIP-2718 deliberately treats the payload as opaque. The envelope can support a different encoding if a future transaction type specifies one. Do not run a generic RLP decoder over the entire typed transaction and assume the first byte belongs to an RLP list.

Accounts, tries, and receipts

Ethereum's modified Merkle Patricia tries use RLP around keys and node values. Account state is represented by an ordered structure containing nonce, balance, storage root, and code hash. Trie nodes are encoded before being embedded directly or referenced by a hash. Our Merkle Patricia trie guide explains that authenticated structure.

Transaction receipts also use legacy or typed envelopes and commit into a receipts trie. To understand the fields and what a receipt proves, see Ethereum transaction receipts.

Network messages

Ethereum's execution networking stack has historically used RLP for structured protocol messages. The precise message schema comes from the relevant networking protocol—not from RLP alone.

RLP vs ABI Encoding vs SSZ

These formats solve different problems.

RLP may wrap a transaction whose data field contains ABI-encoded contract input. The layers should not be decoded interchangeably. First identify the transaction envelope and fields; only then interpret data using the target contract's ABI. Our calldata guide covers that inner layer.

SSZ is also not “new RLP everywhere.” It is central to consensus-layer objects and proofs, while RLP remains present in execution-layer structures. Check the active specification for the exact object rather than inferring deployment from a proposal.

A Safe Decoding Workflow

1. Identify the container first. Determine whether the bytes are a legacy transaction, typed transaction, trie node, receipt, or network message.
2. Select the matching protocol schema. RLP only returns byte strings and lists; it cannot name or type the fields.
3. Read the prefix and bounds-check. Never trust a declared length beyond the remaining input.
4. Reject non-canonical forms. Short values must not use unnecessarily long encodings, and protocol integers must not have leading zeroes.
5. Require complete consumption. Unexpected trailing bytes can indicate the wrong schema or malformed input.
6. Test official vectors and edge cases. Include empty bytes, empty lists, the 55/56-byte boundary, nested lists, and oversized length declarations.

Use a maintained library for production systems. A toy decoder is valuable for learning, but malformed recursive input, allocation limits, and fork-specific transaction rules make protocol code a poor place for casual parsing.

Risks, Limits, and Common Mistakes

• RLP is not self-describing. Correct bytes decoded under the wrong schema can be assigned the wrong meaning.
• Canonical encoding matters. Two encodings of one logical value would undermine deterministic hashing, so decoders must enforce minimal forms required by the higher-level protocol.
• Recursion needs limits. Attackers can supply deeply nested or length-manipulated data to consume memory or stack depth if a parser lacks bounds.
• Typed envelopes need dispatch. The transaction type must be read before applying that type's payload rules.
• RLP is not ABI. Decoding a transaction envelope does not explain a contract call's arguments.
• RLP is not encryption. It provides structure, not secrecy, authentication, or authorization.
• A valid decode is not a valid transaction. Signature checks, nonce rules, gas constraints, fork rules, and state transition validation still apply.

When tooling can sign or broadcast transactions, compare decoded fields with the user's intent and test on a safe environment first. Smart-contract and asset interactions can fail or lose funds even when serialization is correct. Use only amounts you can afford to lose and do your own research (DYOR).

FAQ

Why is it called Recursive-Length Prefix?

Each byte string or list is preceded by information that identifies its payload length, and list elements are themselves RLP-encoded items. Lists can therefore nest recursively.

Does RLP include field names or data types?

No. It distinguishes byte strings from lists and preserves their boundaries. A separate Ethereum specification defines field order, integer interpretation, address length, and other semantics.

Are all Ethereum transactions plain RLP lists?

No. Legacy transactions are RLP lists. EIP-2718 typed transactions begin with a type byte and then a type-specific opaque payload; several deployed types define that payload using RLP, but the envelope does not require every future type to do so.

Is RLP used on Ethereum's consensus layer?

The modern consensus layer primarily uses SSZ for typed consensus objects. RLP remains associated mainly with execution-layer structures and parts of networking. Always identify the exact protocol boundary.

Primary Sources

Sources accessed September 1, 2026:

• Ethereum.org: Recursive-Length Prefix serialization
• Ethereum Yellow Paper, Appendix B: Recursive Length Prefix
• EIP-2718: Typed Transaction Envelope
• Ethereum.org: Transactions and typed envelopes
• Ethereum.org: Merkle Patricia Trie

RLP is small by design: canonical byte strings, canonical lists, and enough length information to separate them. The surrounding Ethereum specification provides the meaning. This article is educational and not financial advice (NFA).