EIP-2537: teaching the EVM the consensus layer's own signatures
Ethereum's validators sign with BLS12-381 — a curve chosen for aggregatable signatures and strong security. But the EVM only knew the older, weaker bn128 curve, so a contract couldn't verify a beacon-chain signature at all. EIP-2537 adds native BLS12-381 precompiles, letting contracts check the consensus layer's own signatures — the missing piece for trust-minimized bridges.
- precompiles (EIP-196/197)
- the beacon chain & BLS signatures
Prague / Electra, May 2025. Byzantium’s bn128 precompiles taught the EVM enough curve math to verify zk-SNARKs. But there’s a curve the EVM conspicuously didn’t understand: the one Ethereum’s own consensus layer signs with. Every validator attestation, every sync-committee signature, is a BLS12-381 signature — and a contract had no way to verify one, because the EVM only knew the older, weaker bn128 curve. That gap meant the EVM couldn’t check its own chain’s consensus. EIP-2537 closes it. Let’s derive it.
The problem: the EVM knew bn128, not BLS12-381
Ethereum’s consensus uses BLS12-381 An elliptic curve pairing offering ~128-bit security and, crucially, signature aggregation — many validators' signatures combine into one. It's the curve the beacon chain signs with; the EVM had no native support for it until EIP-2537. because its signatures aggregate (a whole committee’s signatures fold into one) and it’s strong enough for consensus-grade security. The EVM, meanwhile, only had precompiles for bn128 — a curve that’s fine for many zk applications but weaker (its effective security had eroded below the comfort zone) and, more to the point, the wrong curve. So a contract simply had no way to verify a BLS12-381 signature, and implementing the curve’s math in bytecode is infeasible for exactly the reason any pairing is — it would cost more gas than a block holds.
→ Step 2: give the EVM the right curve, natively.
EIP-2537: native BLS12-381 precompiles
The fix follows the bn128 template exactly, one curve over: EIP-2537 adds a family of precompiles for BLS12-381 — point addition and scalar multiplication on both groups (G1 and G2), the pairing check, and map-to-curve A precompile that deterministically hashes an arbitrary input to a point on the curve — the 'hash-to-curve' step needed to turn a message into something a BLS signature scheme can sign and verify. for hashing messages onto the curve — each run natively and priced at its real, low cost. With these, a contract can perform the operations that a BLS signature verification requires, so it can check a BLS12-381 signature in a single cheap call, on the same curve the consensus layer uses.
→ Step 3: verify Ethereum’s own consensus, from a contract.
The payoff: bridges, aggregation, and one shared curve
Once a contract can verify a BLS12-381 signature, it can verify the beacon chain’s own signatures — most powerfully, a sync committee Altair's 512-validator group that signs each block with an aggregate BLS signature. With BLS12-381 precompiles, a contract (on Ethereum or another chain) can verify that signature directly. signature. That’s the missing piece for a truly trust-minimized bridge A bridge where the destination chain verifies the source chain's consensus signatures directly, rather than trusting a multisig of relayers. On-chain BLS12-381 verification lets a contract check that Ethereum's sync committee signed a state, making Ethereum-to-anywhere bridges trust-minimized. : another chain (or an L2) can run a contract that checks Ethereum’s sync-committee signature and thereby confirm Ethereum’s state cryptographically, not on the say-so of a relayer multisig. It also enables efficient on-chain aggregate-signature schemes for staking, DAOs, and rollups. And at last, the EVM and the consensus layer share a curve.