Cryptographic Verification - c8ntinuum Docs

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

Surface	Address	Use it for
P256 / secp256r1	`0x0000000000000000000000000000000000000100`	Raw-call P-256 verification for enterprise and passkey-style signatures.
Ed25519	`0x0000000000000000000000000000000000000500`	Ed25519 signature verification.
Schnorr	`0x0000000000000000000000000000000000000703`	Schnorr verification over secp256k1-style ecosystems.
Schnorrkel	`0x0000000000000000000000000000000000000704`	Schnorrkel / sr25519-style verification.
ECVRF	`0x0000000000000000000000000000000000000708`	Publicly verifiable randomness.
FROST	`0x0000000000000000000000000000000000000709`	Threshold-signature share verification flows.
PQMLDSA	`0x0000000000000000000000000000000000000712`	ML-DSA post-quantum signature verification.
PQSLHDSA	`0x0000000000000000000000000000000000000713`	SLH-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

Concern	Guidance
Input encoding	Follow the exact ABI or raw-call input shape from the canonical reference.
Failure behavior	Verification failures may return `false`, empty bytes, or revert depending on the interface.
Domain separation	Contracts remain responsible for message framing, replay protection, and domain separation.
Upgrade boundary	Treat address, ABI, revert, and gas schedule changes as compatibility-sensitive.