Skip to content

EIP-7951 — secp256r1 Precompile

Status: Runnable locally (stdio v0.1, self-hosted). Public MCP not launched yet — use the website exploration today.

What became possible

Why add a secp256r1 precompile? EIP-7951 exposes P-256 (the curve behind Apple/Android passkeys and WebAuthn) at address 0x100. Contracts can verify device-native signatures on-chain.

The MCP server runs caller-supplied bytecode that CALLs the precompile with five 32-byte fields: message hash, r, s, public key x, public key y. A valid signature returns 0x01 (32 bytes). Invalid payloads fail or return empty data — your agent can explore both.

What you can ask your agent

Connect the MCP server, then try prompts like:

  • “Verify this P-256 signature payload on Osaka — does the precompile return 0x01?”
  • “I'm exploring passkeys on Ethereum — run a valid and an invalid secp256r1 example and explain the difference.”
  • “What gas does EIP-7951 verification cost for this WebAuthn-shaped input?”
  • “Help me understand how the 0x100 precompile encodes its input — then run my test vector.”

These are inspiration prompts — curiosity, understanding, or builder checks.

What the server does

StepActionPurpose
1Discover supportConfirm 7951 catalog entry; read input layout
2Run bytecodeExecute CALL bytecode on osaka

Fork caveat

The secp256r1 precompile is available on Osaka (mainnet). There is no meaningful “precompile missing” gas compare — focus on valid vs invalid return data, not fork deltas.

Twins and spec

Link
Website exploration (interactive textbook)EIP-7951 on feelyourprotocol.org
Canonical specEIP-7951
Coverage indexCoverage

Changelog

EIP-7951 MCP Catalogue Changelog
  1. v0.12026-08-31Initial catalogue page — P-256 verification on 0x100, twin link.

Use = end-user reference. Internals = architecture and operations. Each section carries its own micro-changelog.