Cryptographic verification precompiles expose native implementations for primitives that would be expensive, awkward, or unavailable in ordinary EVM bytecode. They are verification surfaces: contracts pass structured inputs and receive success, failure, or decoded output according to the relevant ABI.

​
Surfaces

SurfaceAddressUse it for
P256 / secp256r10x0000000000000000000000000000000000000100Raw-call P-256 verification for enterprise and passkey-style signatures.
Ed255190x0000000000000000000000000000000000000500Ed25519 signature verification.
Schnorr0x0000000000000000000000000000000000000703Schnorr verification over secp256k1-style ecosystems.
Schnorrkel0x0000000000000000000000000000000000000704Schnorrkel / sr25519-style verification.
ECVRF0x0000000000000000000000000000000000000708Publicly verifiable randomness.
FROST0x0000000000000000000000000000000000000709Threshold-signature share verification flows.
PQMLDSA0x0000000000000000000000000000000000000712ML-DSA post-quantum signature verification.
PQSLHDSA0x0000000000000000000000000000000000000713SLH-DSA post-quantum signature verification.

​
When to use

  • Use these precompiles when a protocol must verify signatures or proofs from ecosystems that are not covered by standard Ethereum precompiles.
  • Prefer native precompile verification over pure Solidity implementations for gas-heavy cryptographic operations.
  • For P256, use a raw low-level call because the ABI reference documents no Solidity ABI for that address.

​
Safety notes

ConcernGuidance
Input encodingFollow the exact ABI or raw-call input shape from the canonical reference.
Failure behaviorVerification failures may return false, empty bytes, or revert depending on the interface.
Domain separationContracts remain responsible for message framing, replay protection, and domain separation.
Upgrade boundaryTreat address, ABI, revert, and gas schedule changes as compatibility-sensitive.