For years, onchain DNSSEC occupied a liminal space: a bridge from DNS to ENS (a blockchain based naming protocol), but at an economically prohibitive cost. The technology was compelling; the economics weren't. Beyond niche cool, the barriers to mainstream adoption were simply too high.

EIP-7951 arrived on December 3, 2025's Fusaka upgrade, introducing native secp256r1 signature verification at address 0x0100. At ~13k gas per P-256 verification operation (compared to ~1.3M gas in pure Solidity), it made onchain DNSSEC verification economically viable for the first time. We implemented it within weeks—here's what we built and what else now becomes possible.

Most "real-world" cryptographic systems rely on the NIST-standardized P-256 elliptic curve. It's the lynchpin for everything from TLS certificates and secure web traffic to hardware security modules, enterprise PKI, and modern authentication systems like WebAuthn.

Ethereum—somewhat bizarrely—privileged secp256k1 for nearly a decade, despite P-256 being the dominant curve across the rest of the internet. The result was an ecosystem that excelled at native signing, but struggled to interoperate directly with existing security infrastructure.

The precompile exposes a minimal interface for verifying secp256r1 (P-256) signatures directly at the EVM level. There is no helper logic, no domain-specific abstraction, and no protocol opinion baked in. Just a single call that answers one question:

"Does this signature verify against this message and public key?"

Before the precompile, verifying a P-256 signature on Ethereum meant implementing elliptic curve arithmetic in Solidity (or Yul), over a curve the EVM was never optimized for.

In practice, that meant:

• ~50k to 1.3M+ gas per verification (depending on implementation complexity)

• Large, complex contracts with non-trivial audit surfaces

• Implementations that were technically correct but economically unusable at scale

This wasn't a question of elegance or developer ergonomics. It was a hard economic ceiling. DNSSEC verification, WebAuthn validation, and traditional PKI checks all fell on the wrong side of that trade. The precompile collapses that entire cost profile.

In our Sepolia tests, onchain DNSSEC verification using the P-256 precompile consistently landed at ~13k gas per P-256 verification operation. At that level, P-256 checks move from "special case" to "default option." Not because developers suddenly like the curve more—but because the EVM finally treats it as a first-class primitive.

DNSSEC is a good stress test precisely because it's unforgiving:

• signatures are frequent,

• verification chains can be long,

• and correctness is binary — either the chain validates, or it doesn't.

With Solidity-based verification, even a single DNSSEC proof was expensive enough to discourage serious use. With the precompile, verification cost becomes proportional to how much security you want, not whether you can afford security at all.

That shift—from "can we do this?" to "which trust model do we prefer?"—is the real consequence of EIP-7951.

Once P-256 verification became economically viable onchain, the question was no longer whether onchain DNSSEC could be implemented—but how it should be implemented.

That distinction matters, because DNSSEC is not a single operation. It's a verification process that can be distributed across different execution environments, trust assumptions, and cost models. Choosing where verification happens—and what guarantees users get as a result—is ultimately an architectural decision, not a cryptographic one.

To reason about those choices, we leaned on a framework we'd developed earlier: the Universal Resolver Matrix (URM).

The URM emerged from a research forum exploring how heterogeneous naming systems—DNS, ENS, L2 namespaces, offchain registries—could interoperate without collapsing into a single trust assumption.

Rather than prescribing a "correct" architecture, the matrix maps resolver designs across a set of axes: trust anchors, verification location, update frequency, economic cost, and user experience.

That work was later supported by an ENS DAO research grant, with the explicit goal of moving from abstract design space exploration to concrete, testable implementations. DNSSEC—now unblocked by EIP-7951—became the first place to apply it in practice.

Rather than converging on a single "canonical" DNSSEC implementation, we intentionally built two resolver architectures that occupy different regions of the matrix. Both rely on the same cryptographic primitive—the EVM-native P-256 precompile—but they diverge sharply in trust model, user experience, and cost profile.

This was not an accident, nor an exploration for its own sake. It was a way to demonstrate that once verification is cheap enough, architecture becomes a choice again.

• One design optimizes for read-path performance and gasless resolution, pushing verification offchain while preserving cryptographic guarantees.

• The other optimizes for onchain permanence and minimization of trust, validating the full DNSSEC chain directly on Ethereum.

Neither is presented as "the one true DNSSEC implementation." Each makes different tradeoffs explicit—and each is appropriate for different application constraints.

In URM terms, these implementations occupy different cells of the same matrix.

Both implementations share the same cryptographic primitive: the EIP-7951 P-256 precompile at address 0x0100. The P256SHA256Algorithm contract (used by both) accepts 68-byte DNSKEY RDATA (4-byte header + 64-byte public key), extracts the P-256 coordinates via assembly, and calls the precompile with a 160-byte input (32-byte hash + 32-byte r + 32-byte s + 32-byte x + 32-byte y).

DNSSECResolver.sol Implements EIP-3668 (CCIP-Read), reverting with OffchainLookup to trigger gateway-based proof fetching.

The trust model follows a pinned KSK (Key Signing Key, flags=257) as the trust anchor—verifying the domain's DNSKEY and the target RRset (e.g., TXT) without parent-zone DS verification. The gateway (`server.mjs`) fetches DNSSEC material offchain and returns ABI-encoded proof bundles for onchain verification.

DNSSECOracle.sol is an ENS-style oracle contract that validates the full DS (Delegation Signer) chain from IANA root trust anchors.

The trust model follows the complete chain validation (Root → TLD → Domain), matching ENS's DNSSEC oracle approach. It stores verified DNS records onchain via verifyRRSet(), supporting both Algorithm 8 (RSA/SHA-256 via the modexp precompile) and Algorithm 13 (P-256 via EIP-7951).

The divergence is architectural: Option A pushes verification offchain via CCIP-Read while preserving cryptographic verifiability under a pinned trust anchor; Option B validates the full trust chain onchain for permanent storage. Both use the same precompile—the difference is in trust boundaries and data flow.

Both implementations presented here are correct. Both are secure within their stated assumptions. The difference lies in where trust is anchored, where computation happens, and what guarantees are prioritized.

The table below summarizes the tradeoffs explicitly.

Choose Option A if:

• you want gasless, low-latency resolution,

• you are comfortable with a scoped trust anchor (pinned KSK),

• and you prefer flexibility over permanence.

This model is well suited for frontends, authentication flows, and applications where resolution happens frequently and records may change.

Choose Option B if:

• you want maximal trust minimization,

• you need records to persist independently of any offchain service,

• and you are willing to pay a one-time cost for stronger guarantees.

This mirrors ENS's existing DNSSEC import model and is appropriate for long-lived bindings and high-assurance use cases.

DNSSEC is not unique in its reliance on P-256. It's just unusually explicit about trust chains. Once the EVM can verify secp256r1 signatures cheaply, an entire class of "real-world" cryptographic systems becomes addressable on Ethereum—most notably WebAuthn.

Like DNSSEC, WebAuthn sits at the intersection of strong cryptography, legacy infrastructure, and real users. And like DNSSEC, it is less a single operation than a verification workflow.

At a cryptographic level, the overlap is straightforward:

• WebAuthn authenticators commonly use P-256 keys,

• signatures are verified over structured challenge data,

• and correctness is binary—either the signature verifies, or it doesn't.

What varies, again, is not the primitive but the architecture.

Using the Universal Resolver Matrix as a guide, WebAuthn implementations naturally decompose along the same axes we explored with DNSSEC:

• where verification occurs (onchain vs offchain),

• what trust anchors are assumed (device attestation, RP policy, platform roots),

• who pays for verification,

• and whether results are ephemeral (authentication events) or persistent (registered credentials).

In other words, the same question reappears:

"Which trust model do we prefer?"

A read-path WebAuthn design might verify signatures offchain and surface proofs to Ethereum only when needed—for example, to authorize a transaction or gate access—prioritizing UX and latency. A write-path design might register and verify credentials onchain, trading higher upfront cost for stronger guarantees and replay resistance.

The important point is not that one approach is correct, but that both become viable once P-256 verification is cheap enough.

This is exactly the pattern the URM was designed to elucidate: not to prescribe implementations, but to make architectural tradeoffs explicit before code is written. DNSSEC was the first place to apply it end-to-end. WebAuthn is the next.

We've published an initial WebAuthn specification that applies the same matrix-driven reasoning to authentication flows, and we plan to build concrete implementations along the same lines—multiple architectures, shared primitives, explicit trust boundaries.

DNSSEC demonstrated that EIP-7951 crossed an economic threshold. WebAuthn will test whether Ethereum can now serve as a verification layer for human authentication as well.

For years, onchain DNSSEC occupied a liminal space: a bridge from DNS to ENS (a blockchain based naming protocol), but at an economically prohibitive cost. The technology was compelling; the economics weren't. Beyond niche cool, the barriers to mainstream adoption were simply too high.

EIP-7951 arrived on December 3, 2025's Fusaka upgrade, introducing native secp256r1 signature verification at address 0x0100. At ~13k gas per P-256 verification operation (compared to ~1.3M gas in pure Solidity), it made onchain DNSSEC verification economically viable for the first time. We implemented it within weeks—here's what we built and what else now becomes possible.

Most "real-world" cryptographic systems rely on the NIST-standardized P-256 elliptic curve. It's the lynchpin for everything from TLS certificates and secure web traffic to hardware security modules, enterprise PKI, and modern authentication systems like WebAuthn.

Ethereum—somewhat bizarrely—privileged secp256k1 for nearly a decade, despite P-256 being the dominant curve across the rest of the internet. The result was an ecosystem that excelled at native signing, but struggled to interoperate directly with existing security infrastructure.

The precompile exposes a minimal interface for verifying secp256r1 (P-256) signatures directly at the EVM level. There is no helper logic, no domain-specific abstraction, and no protocol opinion baked in. Just a single call that answers one question:

"Does this signature verify against this message and public key?"

Before the precompile, verifying a P-256 signature on Ethereum meant implementing elliptic curve arithmetic in Solidity (or Yul), over a curve the EVM was never optimized for.

In practice, that meant:

• ~50k to 1.3M+ gas per verification (depending on implementation complexity)

• Large, complex contracts with non-trivial audit surfaces

• Implementations that were technically correct but economically unusable at scale

This wasn't a question of elegance or developer ergonomics. It was a hard economic ceiling. DNSSEC verification, WebAuthn validation, and traditional PKI checks all fell on the wrong side of that trade. The precompile collapses that entire cost profile.

In our Sepolia tests, onchain DNSSEC verification using the P-256 precompile consistently landed at ~13k gas per P-256 verification operation. At that level, P-256 checks move from "special case" to "default option." Not because developers suddenly like the curve more—but because the EVM finally treats it as a first-class primitive.

DNSSEC is a good stress test precisely because it's unforgiving:

• signatures are frequent,

• verification chains can be long,

• and correctness is binary — either the chain validates, or it doesn't.

With Solidity-based verification, even a single DNSSEC proof was expensive enough to discourage serious use. With the precompile, verification cost becomes proportional to how much security you want, not whether you can afford security at all.

That shift—from "can we do this?" to "which trust model do we prefer?"—is the real consequence of EIP-7951.

Once P-256 verification became economically viable onchain, the question was no longer whether onchain DNSSEC could be implemented—but how it should be implemented.

That distinction matters, because DNSSEC is not a single operation. It's a verification process that can be distributed across different execution environments, trust assumptions, and cost models. Choosing where verification happens—and what guarantees users get as a result—is ultimately an architectural decision, not a cryptographic one.

To reason about those choices, we leaned on a framework we'd developed earlier: the Universal Resolver Matrix (URM).

The URM emerged from a research forum exploring how heterogeneous naming systems—DNS, ENS, L2 namespaces, offchain registries—could interoperate without collapsing into a single trust assumption.

Rather than prescribing a "correct" architecture, the matrix maps resolver designs across a set of axes: trust anchors, verification location, update frequency, economic cost, and user experience.

That work was later supported by an ENS DAO research grant, with the explicit goal of moving from abstract design space exploration to concrete, testable implementations. DNSSEC—now unblocked by EIP-7951—became the first place to apply it in practice.

Rather than converging on a single "canonical" DNSSEC implementation, we intentionally built two resolver architectures that occupy different regions of the matrix. Both rely on the same cryptographic primitive—the EVM-native P-256 precompile—but they diverge sharply in trust model, user experience, and cost profile.

This was not an accident, nor an exploration for its own sake. It was a way to demonstrate that once verification is cheap enough, architecture becomes a choice again.

• One design optimizes for read-path performance and gasless resolution, pushing verification offchain while preserving cryptographic guarantees.

• The other optimizes for onchain permanence and minimization of trust, validating the full DNSSEC chain directly on Ethereum.

Neither is presented as "the one true DNSSEC implementation." Each makes different tradeoffs explicit—and each is appropriate for different application constraints.

In URM terms, these implementations occupy different cells of the same matrix.

Both implementations share the same cryptographic primitive: the EIP-7951 P-256 precompile at address 0x0100. The P256SHA256Algorithm contract (used by both) accepts 68-byte DNSKEY RDATA (4-byte header + 64-byte public key), extracts the P-256 coordinates via assembly, and calls the precompile with a 160-byte input (32-byte hash + 32-byte r + 32-byte s + 32-byte x + 32-byte y).

DNSSECResolver.sol Implements EIP-3668 (CCIP-Read), reverting with OffchainLookup to trigger gateway-based proof fetching.

The trust model follows a pinned KSK (Key Signing Key, flags=257) as the trust anchor—verifying the domain's DNSKEY and the target RRset (e.g., TXT) without parent-zone DS verification. The gateway (`server.mjs`) fetches DNSSEC material offchain and returns ABI-encoded proof bundles for onchain verification.

DNSSECOracle.sol is an ENS-style oracle contract that validates the full DS (Delegation Signer) chain from IANA root trust anchors.

The trust model follows the complete chain validation (Root → TLD → Domain), matching ENS's DNSSEC oracle approach. It stores verified DNS records onchain via verifyRRSet(), supporting both Algorithm 8 (RSA/SHA-256 via the modexp precompile) and Algorithm 13 (P-256 via EIP-7951).

The divergence is architectural: Option A pushes verification offchain via CCIP-Read while preserving cryptographic verifiability under a pinned trust anchor; Option B validates the full trust chain onchain for permanent storage. Both use the same precompile—the difference is in trust boundaries and data flow.

Both implementations presented here are correct. Both are secure within their stated assumptions. The difference lies in where trust is anchored, where computation happens, and what guarantees are prioritized.

The table below summarizes the tradeoffs explicitly.

Choose Option A if:

• you want gasless, low-latency resolution,

• you are comfortable with a scoped trust anchor (pinned KSK),

• and you prefer flexibility over permanence.

This model is well suited for frontends, authentication flows, and applications where resolution happens frequently and records may change.

Choose Option B if:

• you want maximal trust minimization,

• you need records to persist independently of any offchain service,

• and you are willing to pay a one-time cost for stronger guarantees.

This mirrors ENS's existing DNSSEC import model and is appropriate for long-lived bindings and high-assurance use cases.

DNSSEC is not unique in its reliance on P-256. It's just unusually explicit about trust chains. Once the EVM can verify secp256r1 signatures cheaply, an entire class of "real-world" cryptographic systems becomes addressable on Ethereum—most notably WebAuthn.

Like DNSSEC, WebAuthn sits at the intersection of strong cryptography, legacy infrastructure, and real users. And like DNSSEC, it is less a single operation than a verification workflow.

At a cryptographic level, the overlap is straightforward:

• WebAuthn authenticators commonly use P-256 keys,

• signatures are verified over structured challenge data,

• and correctness is binary—either the signature verifies, or it doesn't.

What varies, again, is not the primitive but the architecture.

Using the Universal Resolver Matrix as a guide, WebAuthn implementations naturally decompose along the same axes we explored with DNSSEC:

• where verification occurs (onchain vs offchain),

• what trust anchors are assumed (device attestation, RP policy, platform roots),

• who pays for verification,

• and whether results are ephemeral (authentication events) or persistent (registered credentials).

In other words, the same question reappears:

"Which trust model do we prefer?"

A read-path WebAuthn design might verify signatures offchain and surface proofs to Ethereum only when needed—for example, to authorize a transaction or gate access—prioritizing UX and latency. A write-path design might register and verify credentials onchain, trading higher upfront cost for stronger guarantees and replay resistance.

The important point is not that one approach is correct, but that both become viable once P-256 verification is cheap enough.

This is exactly the pattern the URM was designed to elucidate: not to prescribe implementations, but to make architectural tradeoffs explicit before code is written. DNSSEC was the first place to apply it end-to-end. WebAuthn is the next.

We've published an initial WebAuthn specification that applies the same matrix-driven reasoning to authentication flows, and we plan to build concrete implementations along the same lines—multiple architectures, shared primitives, explicit trust boundaries.

DNSSEC demonstrated that EIP-7951 crossed an economic threshold. WebAuthn will test whether Ethereum can now serve as a verification layer for human authentication as well.