Skip to main content
Address: 0x0000000000000000000000000000000000001011 This precompile implements RIP-7212, which defines a precompiled contract to verify signatures on the secp256r1 or P-256 elliptic curve.

Overview

The P256 precompile verifies signatures on the secp256r1 curve efficiently. Many modern security systems use this curve, including:
  • Apple’s Secure Enclave
  • WebAuthn and FIDO2
  • Android Keychain
  • Various hardware security modules (HSMs)
  • Passkeys
This precompile uses much less gas than a Solidity implementation of P-256 verification.

Interface

Implementation library

This is a complete implementation of the P256 library, a convenient wrapper around the precompile:

Basic usage

Using the P256 library

Direct precompile usage

For more control, you can call the precompile directly:

Signature format

Signature verification requires these components:
  • digest: 32 bytes of the signed data hash
  • signature: Contains the r and s components of the signature
  • publicKey: Contains the x and y coordinates of the public key
The precompile expects these components encoded in this format:
  • First 32 bytes: message hash
  • Next 32 bytes: r component of the signature
  • Next 32 bytes: s component of the signature
  • Next 32 bytes: x coordinate of the public key
  • Next 32 bytes: y coordinate of the public key
Total length: 160 bytes

Gas costs

Each verification costs a fixed 3,450 gas, the same as the RIP-7212 P256VERIFY precompile. This cost is much lower than the cost of P-256 verification in Solidity. Like every Sei precompile, the call also pays a charge for its calldata. For details, see Gas for precompile calls. The precompile charges for the calldata first. Then it charges the 3,450 gas, and then it checks the signature. If the call cannot pay the calldata charge, it reverts. If the call cannot pay the 3,450 gas, it fails with an out-of-gas error and does not revert.

Real-world use cases

WebAuthn/passkeys authentication

Apple Secure Enclave integration

Multi-signature with hardware keys

Security considerations

Always validate public keys and signature components before verification. This prevents invalid curve point attacks.

Public key validation

Signature malleability

P256 signatures can be malleable. If your application requires unique signatures, implement more checks:

JavaScript integration

Preparing input data

Error handling

The P256 precompile returns no data on failure. Because verify is declared to return bytes, a high-level Solidity interface call reverts when it tries to decode the empty return data. Always use a low-level staticcall, as the examples above do. Invalid signatures then resolve to false instead of reverting. Common failure cases include:
  1. Invalid input length: The input must be exactly 160 bytes.
  2. Invalid public key: The point is not on the P256 curve.
  3. Invalid signature: The r or s values are out of the valid range.
  4. Verification failure: The signature does not match the message and public key.

Testing

Unit tests

Performance considerations

  • Gas efficiency: A verification costs a fixed 3,450 gas, plus the calldata charge
  • Batch operations: Consider batching multiple verifications in a single transaction
  • Caching: Cache public keys on-chain to reduce calldata for repeated verifications
  • Hardware integration: Particularly efficient for applications that use hardware-backed keys
View the complete P256 precompile ABI in sei-chain v6.7.1, or browse the implementation source.