Secp256r1 Precompile Scheduled for Inclusion in Fusaka Upgrade

🌱 ENS Ecosystem Ecosystem Discussion
1

Update: EIP-7951 (formerly EIP-7212), which introduces a precompile for secp256r1 curve, has been included in the upcoming Fusaka upgrade, tentative June 23, 2025. You can track its inclusion here.

This opens a fascinating design space for ENS. If this implementation lands on L1, no fundamental cryptographic blockers will remain for the following:

  • WebAuthn + ENS login: Authenticate into WebAuthn-supported apps (email, banking, dapps) using ENS name—e.g. sign in as yourname.eth using Face ID or a YubiKey.
  • Onchain DNSSEC + ENS integration: Secure, verifiable domains backed by DNSSEC can be linked to ENS, enabling cross-chain and Web2 ↔ Web3 identity resolution.
  • Enterprise ENS subnames: Issue alice.company.eth tied to a P256-secured device for passwordless access to internal tools, gated dapps, or multi-role DAOs.
  • IoT authentication with ENS: Use ENS to manage and verify identities of constrained devices (sensors, drones, routers) that rely on P256-based crypto stacks.
  • Gov/NGO identity systems: Map national or organizational IDs to ENS in a way that respects existing infrastructure while unlocking composability across Ethereum.
  • Unified identity layer: Reduce cognitive overhead from managing fragmented accounts—anchor all online presence to a single, sovereign ENS identity, verified across Web2 and Web3.

—

Special note to @ulerdogan and co., I express remorse for having called this initiative a red herring. Your conviction is inspiring, and I’ve learned not to underestimate the long arc of infrastructure work.

For a primer on what the secp256r1 precompile unlocks for Ethereum and ENS identity flows, check out Enabling Unified Identity Frameworks with P256 on Ethereum — m

12 Likes
2

Thanks for updating the forum and all! Your and ENSDAO’s support over the last 2 years has been invaluable.

2 Likes
3

+1 for r1 & CLZ in Fusaka :rocket:

I was playing around https://porto.sh/ dev preview from ithaca.xyz team, it’s using solady implementation.

There are few things that ENS should warn or at least mention for future devs implementing passkeys.

  1. eth.limo /.link gateways:
    a) eth.limo isn’t listed on PSL, there’s possible phishing risk as passkeys check PSL for rpID. I’ve already ping’d @ethlimo.eth team about this.
    b) Any eth.limo/link based passkeys must include well-known domain supporting both .limo & .link

@ethlimo.eth could turn this bug into feature by acting as passkey provider like Porto :stuck_out_tongue_winking_eye:, but I guess that’s way out of scope for gateway provider.

  1. Ruggable : if domain.eth.limo goes down there’s no “easy” way to exit anything locked under that passkey “soulbound” to specific domain. It’s already happening on privy+domain based key setup.

  2. finallly, we shouldn’t give up secp256k1 support in passkeys. Brave is pushing for it and there’s still hope for future. why stop at r1, wen Ed25519? :pray:

1 Like