EIP-3541: reserving a byte for the future
How do you leave room to add a whole new contract format later, when every possible first byte of code is already a valid opcode? You can't — unless you make one byte off-limits, on purpose. EIP-3541 forbids deploying new code that starts with 0xEF, turning that byte into reserved space that later upgrades (EOF, and EIP-7702's delegation designator) build on.
- contract code & opcodes
- contract deployment
London, August 2021. Alongside the fee market and the refund fix, London shipped a change that does nothing on its own — it just makes a certain deployment fail. That sounds pointless until you see what it’s for. Ethereum wanted to leave itself room to introduce an entirely new contract code format in a future fork — structured, versioned, validated up front — rather than today’s take-it-as-it-comes blob of bytecode. But adding a new format needs a way to tell it apart from the old one, and that turns out to be surprisingly hard. EIP-3541 is the small, forward-looking move that makes it possible. Let’s derive it.
The problem: every byte is already an opcode
A contract’s code is just a sequence of bytes, and the EVM reads them as opcodes One-byte EVM instructions. The contract's code is a raw byte string interpreted an opcode at a time — 0x60 is PUSH1, 0x01 is ADD, and so on. There's no header or type tag; the first byte is simply the first instruction. . To introduce a new format, you’d want a magic prefix — a first byte that says “don’t read me as plain bytecode; I’m the new thing.” The trouble is that every byte value from 0x00 to 0xff already means something as an opcode (or is a defined-invalid instruction), so there’s no value you can claim as a marker without it already being legal code. A new format has no way to announce itself.
→ Step 2: make a byte off-limits, deliberately.
EIP-3541: reject new code that starts with 0xEF
The fix is a rule, not a mechanism: from London onward, any attempt to deploy new contract code whose first byte is 0xEF fails — the creation reverts and no contract is made. That single prohibition turns 0xEF into reserved prefix A byte value the protocol forbids new contract code from starting with, so future upgrades can safely assign it a special meaning. EIP-3541 reserved 0xEF this way. — a byte guaranteed to never begin ordinary bytecode, and therefore free for a future format to claim. (0xEF was picked because it was an undefined opcode and evokes “EVM Format”; the tiny handful of already-deployed contracts starting with 0xEF are grandfathered in, since the rule only blocks new deployments.)
→ Step 3: cash in the reservation.
The payoff: a magic prefix for new formats
With 0xEF guaranteed free, a future fork can safely declare “code beginning 0xEF… isn’t legacy bytecode — interpret it specially,” with zero risk of misreading a real contract. Two things build directly on this. The EOF EVM Object Format — a structured, versioned contract container (header, code/data sections, validated at deploy time) that begins with the magic bytes 0xEF00. It relies on 3541 having reserved 0xEF. uses the prefix 0xEF00 for its versioned container. And — the connection that closes a loop in this book — EIP-7702’s delegation designator is 0xef0100 ‖ address: when 7702 sets an EOA’s code to that value, it’s using the reserved 0xEF prefix precisely so the value can’t be mistaken for ordinary bytecode.