Report: Measuring the Impact of ENS’s P-256 Precompile Migration

Context

A large share of 2LDs rely on algorithm 13 (ECDSAP256SHA256) to verify the leaf signature in their DNSSEC chain of trust from the IANA root when importing names into ENS.

Before Fusaka, ENS performed that verification in EVM opcodes as elliptic-curve arithmetic: high compute, high gas. Fusaka shipped the native EIP-7951 P-256 precompile on December 3, 2025, and I proposed switching ENS to it 22 days later. Reference: ensdomains/ens-contracts PR #509.

Measurement

I ran a full historical replay study, re-executing every ENS DNS import on record against deployed mainnet bytecode using a complete 2021–2026 census with no sampling.

After the DAO activated the change on March 9, 2026, the cost of a single verification fell from 1.34M gas to 10.5K—a 99.2% reduction.

Over the realized period from March 9 to July 27, 2026, the migration saved 1.12B gas across all eligible DNS imports—equal to 82.3% of what those imports would otherwise have cost, measured on transaction receipts.

Live dashboard: → ENS P-256 Migration: Realized Impact | Dune

What the study found

  • PR #509 described the reduction as ~200K → ~3.5K gas per verification, and the DAO executable carried those figures. The actual measured saving is 1.33M gas. The public record understates the impact by 6.8×.
  • A DNS import used to take up more than one-seventh of an entire 30M-gas block. After the migration, it dropped to about 3% of a block, increasing theoretical capacity from roughly 7 imports per block to about 39.
  • 98.1% of 2026 imports use algorithm 13, but doma.xyz accounts for 60.6% of that window and Cloudflare 17.8%. At the registry level, algorithm-13 adoption across gTLDs is 11.5%, which suggests the reachable namespace is much larger than the population importing today.

Full study, citation layer, and live dashboards → https://13.emilemarcelagustin.eth.link

Verify it yourself

The harness and data are public, and the headline comparison reproduces on your own machine in about a minute using your own archive RPC:

git clone https://github.com/estmcmxci/algo13-study.git
cd algo13-study && cp .env.example .env && export $(grep -v ^# .env | xargs)
forge install foundry-rs/forge-std --no-git

# ~10 seconds — the population
node research/scripts/c3-names.mjs
# -> total claims: 2145

# ~1 minute — the headline gas comparison
forge test --match-path "test/Unified.t.sol" --fork-url $MAINNET_RPC_URL -vv
# -> p256_old_current 1340706
# -> p256_new 10493
2 Likes

Update: bringing sth from my research to the forefront:

  • The study replayed all 2,283 DNS import attempts on record, from 2021–2026.
  • 156 transactions reverted on-chain; about a 1:15 failure ratio.
  • After P-256 activation, 315 imports occurred during the measured period.

Anomaly → At a 1:15 failure rate, ~22 of those 315 imports should have reverted, but none did.

An ensjs bug might explain it:

  • Failures appear on-chain only if a tx is submitted.
  • If proof fetching fails locally, the would-be failure leaves no on-chain trace.
  • Since Q4 2025, the library may have filtered out devs using stock tooling.
  • The paths able to import were the patched official app and hardened custom pipelines—potentially selecting for operators less likely to fail.

The zero failure rate I picked up in the research could mean failures moved off-chain, beyond the census’s view.

I spotted this PR identifying the bug; it’s still open. Would recommend a maintainer give it a quick lookie look: fix(dnssec): bump dnsprovejs to 0.5.4, fixing silent failure of DNSSEC proof fetch by zoneguest · Pull Request #369 · ensdomains/ensjs · GitHub