Formal Verification Finds Three Doc-Code Gaps in EIP-8282

Verity has completed a formal verification of the Ethereum Foundation's EIP-8282 builder staking deposit and exit contracts and found three mismatches between the proposal's documentation and its actual code. The EIP was revised after the discrepancies surfaced, according to the review's published summary.

The verification work did not rely on human eyeballing of Solidity or of prose specifications. Verity used AI-assisted Lean proofs to verify EVM bytecode directly, with Lean's kernel serving as the mechanical checker of the proof results. That distinction matters: the kernel, not the model, certifies correctness, which limits the risk of an AI-generated proof slipping through unexamined.

What did the review actually cover?

The scope of the verification was concrete and bounded. It examined three functional areas of the contracts:

• Request submission
• Queue processing
• Fee and control logic

Each area is operationally significant for ePBS, Ethereum's proposer-builder separation design. Deposit and exit requests, the ordering of those requests in a queue, and the fees and control parameters attached to them are precisely the components where a mismatch between intent and implementation can produce griefing, stuck funds or unintended access. Three documented mismatches is a small count, but any nonzero count in deposit and exit logic deserves attention; the finding is that the documentation, not just the reader, can be wrong.

What was left out?

The review was not a full-stack audit of the mechanism. It did not cover consensus-layer scheduling, and it did not cover BLS signature checks. Those exclusions are not trivial footnotes. EIP-8282 is a companion proposal to EIP-7732, which describes Ethereum's ePBS mechanism, and the consensus-layer scheduling path is where builder staking interacts with block production itself. Readers should treat this verification as a contract-level result, not an endorsement of the full ePBS pipeline.

The published material also does not quantify the severity of the three mismatches, state whether any could have been exploited, or specify which revision of the EIP incorporated the fixes. Those omissions are worth noting; a mismatch count alone does not tell a protocol team how close the code sat to a live failure mode.

Why does Lean-verified bytecode matter here?

Formal verification of EVM bytecode closes a gap that conventional audits leave open. An audit reads source code and tests behavior; a Lean proof, checked by the kernel, establishes that the deployed bytecode satisfies stated properties. For staking infrastructure that would carry real validator deposits, that stronger guarantee is the point, provided the stated properties themselves are correct. A proof is only as good as the specification it checks against, and the three documentation mismatches are a reminder that specifications drift too.

The practical consequence is already visible: the EIP text was revised to resolve the divergences. The open question is whether subsequent revisions of EIP-8282 will receive the same verification treatment before the proposal advances further through the Ethereum process.