RLP Encoding

Overview

RLP Encoding serializes two basic kinds of values: byte strings and lists containing other RLP values. Short values use compact prefixes, while longer values include an encoded length. Recursion allows transactions, accounts, and other structured objects to be represented as one deterministic byte sequence.

RLP does not define application data types. It does not inherently know that a byte string is an address, integer, signature, or text. The surrounding Ethereum specification defines field order and interpretation. Positive integers use minimal big-endian byte representation, and noncanonical forms with unnecessary leading zeros can be invalid.

Legacy Ethereum transactions are commonly described as RLP-encoded field lists, while typed transactions prepend a transaction type and encode a defined payload. Execution-layer account values and trie nodes also use RLP in specific contexts. Other Ethereum layers use different encodings such as SSZ.

Correct serialization is security-critical. A single byte difference changes the hash that is signed or used as an identifier. Developers should use maintained libraries, compare against official test vectors, and never construct RLP by concatenating hexadecimal strings manually.

RLP is one specialized form of Binary Encoding. APIs may expose the final bytes as Hexadecimal, but the hex display should not be confused with the underlying serialization. Debugging requires decoding each layer in the right order: text representation, transaction type, RLP structure, and protocol fields.

Decoders must apply input limits before recursively allocating memory or traversing deeply nested lists. Canonical encoding protects consensus consistency, while defensive parsing protects the application from malformed or resource-exhausting input received through APIs, files, or peer messages.