Skip to main content

Try it Live

Run RLP examples in the interactive playground
Conceptual Guide - For API reference and method documentation, see RLP API.
RLP (Recursive Length Prefix) is Ethereum’s serialization format for encoding arbitrarily nested arrays of binary data. This guide teaches RLP fundamentals using Tevm.

What is RLP?

RLP is a binary encoding scheme that serializes:
  • Byte strings - Raw binary data (addresses, hashes, numbers)
  • Lists - Ordered collections of byte strings or nested lists
  • Nested structures - Recursive lists containing other lists
RLP encodes only structure (bytes vs lists) and length - no type information, field names, or metadata. This simplicity makes it fast and compact for Ethereum’s performance-critical operations.

Why Ethereum Uses RLP

Deterministic serialization - Same data always produces identical encoding, critical for:
  • Transaction signing (hash must be consistent)
  • Merkle tree construction (state/transaction/receipt tries)
  • Network protocol messages (devp2p)
Compact representation - Minimal overhead:
  • Single byte values encode as themselves (no prefix)
  • Short strings use 1 byte prefix
  • Only long data needs multi-byte length encoding
Simple parsing - No schema required:
  • Decode without knowing data structure
  • Parse incrementally from byte stream
  • Validate structure without semantic knowledge

RLP vs Other Formats

Pros: Deterministic, compact, fast parsing Cons: No type information, requires knowledge of data structure

Encoding Algorithm

RLP encoding follows a simple recursive algorithm based on input type:
The challenge: determining whether output represents a byte string or list. RLP uses prefix bytes to encode this distinction.

Encoding Rules

RLP uses five encoding rules based on data type and length:

Rule 1: Single Byte (0x00-0x7f)

Bytes with values less than 0x80 encode as themselves - no prefix needed.
Why this works: Prefix bytes for other rules start at 0x80 or higher, so single bytes < 0x80 cannot be confused with prefixes.

Rule 2: Short Strings (0-55 bytes)

Byte strings of 0-55 bytes: [0x80 + length, ...bytes]
Prefix range: 0x80-0xb7 (128-183) Data follows immediately after the prefix byte

Rule 3: Long Strings (56+ bytes)

Byte strings of 56+ bytes: [0xb7 + length_of_length, ...length_bytes, ...bytes]
Prefix range: 0xb8-0xbf (184-191) Length encoding: Big-endian unsigned integer Maximum supported: Theoretically 2^64 bytes (practically limited by memory)

Rule 4: Short Lists (0-55 bytes total payload)

Lists with total payload < 56 bytes: [0xc0 + length, ...encoded_items]
Prefix range: 0xc0-0xf7 (192-247) Payload = sum of all encoded item lengths

Rule 5: Long Lists (56+ bytes total payload)

Lists with total payload >= 56 bytes: [0xf7 + length_of_length, ...length_bytes, ...encoded_items]
Prefix range: 0xf8-0xff (248-255) Length encoding: Same as Rule 3 (big-endian)

Visual Encoding Examples

Example 1: Encoding “dog”

Visual representation:

Example 2: Encoding [ “cat”, “dog” ]

Visual representation:

Example 3: Nested Structure

Visual representation:

Encoding Numbers

RLP treats numbers as byte strings - you must convert to bytes first:
Canonical number encoding rules:
  1. Zero encodes as empty byte string: [0x80]
  2. No leading zeros (except for zero itself)
  3. Big-endian byte order
  4. Minimal byte representation

Decoding Process

Decoding reverses the encoding process by examining prefix bytes:

Decoding Algorithm

Streaming Decoding

Process multiple RLP-encoded items from a byte stream:

Complete Example: Transaction Encoding

Ethereum transactions use RLP encoding for signing and transmission:

Transaction Encoding Breakdown

Use Cases in Ethereum

Transactions

All transaction types use RLP:
  • Legacy transactions (9 fields)
  • EIP-2930 (access list transactions)
  • EIP-1559 (fee market transactions)

Block Headers

Block headers are RLP-encoded lists of 15+ fields:

Merkle Patricia Tries

State, transaction, and receipt tries use RLP for node encoding:

Network Protocol (devp2p)

Ethereum’s peer-to-peer protocol messages use RLP:

Validation

Ensure RLP encoding is valid before decoding:

Canonical Encoding

RLP has canonical form requirements:
  • Numbers must not have leading zeros (except zero itself)
  • Shortest encoding must be used
  • Empty byte string is [0x80], not []

Common Patterns

Working with Addresses

Working with Hashes

Encoding Variable-Length Data

Resources

Next Steps

  • Overview - Type definition and API reference
  • Encoding - Encode bytes and lists to RLP
  • Decoding - Decode RLP to data structures