EIP-7212: Precompiled for secp256r1 Curve Support

OP produced an example implementation for OP hackathon project: Opclave | ETHGlobal


Claiming this will help users manage their private keys better by entrenching them in a proprietary SoC solution (Apple Secure Enclave) is ridiculous. We trust in math, not Chinese supply chain vendors. Claiming that “backdooring” is not viable misses the point: we are not claiming that all chips are backdoored, only that certain chips be intercepted en route to end user by TAG/TAU and flashed with backdoor. It is hard to verify hardware, its easier to verify software.

Here is an approach that uses existing authentication schemes to provide user key management, check their github for examples. https://mfkdf.com/

Precompiles should be ossified, they were always a “temporary” solution, that was 8 years ago.



Strongly in support of this - secp256r1 is by far the most widely used curve, and enabling it to be efficiently verified in the EVM will enable countless integrations with existing infrastructure that are currently impractical.

Those suggesting alternate curves or raising issues with the derivation of the secp256r1 parameters are missing the point; the idea here is not to pick the ideal curve, it’s to add functionality that permits integrating with external and legacy applications efficiently.

I would suggest that an ‘ecrecover’ type implementation is more versatile, though; it’s easy to convert ecrecover into a signature verification operation, but impossible to do the inverse.


In strong support of this proposal.

Generally speaking, hard reproducible evidence has to exist for the claims of NSA influencing NIST to weaken the secp256r1.

Otherwise it’s unproductive for the conversation.

Alexander has been constantly requesting and implementing support for secp256k1 for the bitcoin community in Apple’s Swift crypto library for the past 4 years: New API Proposal: Add SECG curves, especially `secp256k1` · Issue #8 · apple/swift-crypto · GitHub

It’s evident from the conversation that they consider secp256k1 to be limited to cryptocurrency and not for “wide usecases” and have been delaying and denying support.

Considering this proposal, the wallet UX for regular Mobile users using Android/iOS/Android-derivate OSes can drastically improve.

This also includes keychain devices which already support the curve or hardware devices which can be built using secure element (SE) that support secp256r1.

So it isn’t just Mobile Devices, but beyond that, large no. of IoT devices can come integrated with SE and utilise this precompile to unlock new/existing use-cases.


I see no reason to support secp256r1 instead of x25519 / ed25519. r1 is US gov standard. The world is bigger than US.


  • is present in TLS 1.3, HPKE, SSH, PGP, Signal
  • is faster and more secure than p256
  • is much simpler, can be implemented without EC arithmetics

That’s a false dichotomy; this proposal doesn’t argue anywhere that secp256r1 support should supercede 25519 support. I suspect most people here would also support a 25519 precompile.


I personally think secp256r1 has a lot of usage, having a precompile will be beneficial. And I also agree with the counter argument that there is cost to implement and adopt such precompile.

It seems a pattern that whenever a precompile is proposed, there will be a lot of debate about whether there is likely to be a lot of usage. The chicken-and-egg nature is that without deploying the precompile, we can’t calculate the adoption, and without the adoption, it’s hard to argue for making it a precompile.

Good news, we are propose to have a “progressive path towards precompiles”, where author proposes a precompile, but instead of requiring it to be deployed as precompile first, they deploy a precompile candidate which is a traditional smart contract (with higher gas cost per operation, though), and see if there is usage. Once the usage is validated, the data can be used to (1) justify the need for such precompile, and (2) serve as call pattern to help client implementor tune performance

See more Progressive precompiles via CREATE2 shadowing


In terms of usecase and “will it get used”, this EIP is essentially for onboarding the next millions of users. There’s no way to onboard normies at the moment as you need to use MetaMask or another wallet to use DeFi, NFTs etc. With this EIP we can convert web2 users in scale.


Would like to express support for this EIP. Echo the opinion that this should not be a debate on the security of the curve. Providing a precompile for the curve enables integration with mass distributed hardware where users are already trusting the curve. We should provide an option for those users to extend that trust to smart contracts which elect to use this curve for validation.

To me it feels pretty straight forward. The most widely adopted curve should have a precompile. Its not forcing anyone to use it but provides critical functionality for those who want it.


+1 Echoing support for this EIP. Game changer in terms of onboarding.


EVM can’t include every curve. Including even one additional curve drastically increases system complexity. Choices need to be made, carefully.

Implementing a new curve:

  1. Requires secure cryptography for all execution-layer clients
    a. There needs to be implementations in go, .net, java, rust
    b. Someone will need to audit them
    c. Low-level impl is not the same as high-level, probably platform-specific assembly code would be required
  2. Clients will need to support the new code for many years, going forward
    a. Why not pick something better right now? That’s ed25519.
  3. The PR advances usage of p256. We should decrease its usage. p256:
    a. Relies on PRNG security for nonce reuse, which has been breached continuously. See playstation root key extraction.
    b. Is usually slower than ed25519
    c. Is harder to implement in const-time than ed25519. Renes-Costello-Batina 2015 helps, but it’s really slow. See https://minerva.crocs.fi.muni.cz

There is EIP-665 for ed25519. We should support it instead.


Apologies if this is a dumb question but is there a bounty system we can bid up to get this approved? I’m willing to put a few thousand in for incentive.

This EIP is the room temperature superconductor moment for EVM, it’s likely the sole impediment to the next billion users.

I have this thread as my start page on my browser and read everyone’s bull post comment out loud. Let’s get it boiiii


There are a couple of thoughts and feedback I would like to share on this proposal:

  • I generally support EVM changes that can help onboard the next millions of users. However, I neither trust Apple nor Android, nor any big corporation that may use secp256r1 as curve. We should work on solutions, which make us more independent than dependent on potential supply chain attacks.
  • The original Yellow Paper states: these are so-called ‘precompiled’ contracts, meant as a preliminary piece of architecture that may later become native extensions. But we don’t yet know if this new instruction is something that will have traction and be a future-proof feature that will eventually be added as opcode. To figure this out, I suggest using the L2 EVM versions (and not the mainnet EVM version, but e.g. Optimism and Arbitrum) to test the need for this new instruction and, if proven to be important enough, eventually add it as opcode to the EVM mainnet version. IMO, generally, we should not add more precompiles to the mainnet EVM; if it is important enough, it should be an opcode. Period.
  • If secp256r1 support is added, soon many wallets will support it. But we eventually don’t know whether there really exists a backdoor or not. You can call it paranoid, but I’m rather 100% safe than sorry ultimately.
  • The secp256r1 implementation is not consistent with the current ecrecover implementation that returns the recovered 20-byte address instead. I can already see implementation bugs here. I strongly recommend aligning the behaviour with ecrecover. I do follow the arguments laid out in the rationale section, but ultimately what matters is the execution part, and we should keep consistency in how ECDSA precompile methods return values IMHO.
  • The secp256r1 elliptic curve is not quantum-resistence and thus ultimately not future proof (only time will tell when however).
  • The current implementation doesn’t support Schnorr signatures - is there a way, we can support not only ECDSA but also Schnorr signatures?

Note that Schnorr signature standard (BIP340) has only been defined for secp256k1, not for any other curve. It’s also unclear which other curves are using them at all.


Right, thanks for pointing this out - we might want to consider proposing a standard for secp256r1 in that case, as I consider Schnorr signatures an important future-proof algorithm.


r1 seems to be decreasing in popularity though, may not be worth it. Most new protocols are using x + ed 25519, which became a part of FIPS standard now.

A generic schnorr standard for weierstraß curves would be ok

It seems there are other option to achieve the same goal as well. Does anyone know JoyID? Their team have done some hard crypto work and achieved the same results without adding precompiled contract or modifying Ethereum itself. I have been testing it for a few weeks

AFAIK They works on Nervos which has a precompiled for P256 curve.

While I’m very excited of the possibilities r1 may introduce, I oppose adding support on L1 for the following reasons:

The chances of r1 having a backdoor, while as small as they may be, should be taken serious. Ethereum has a responsibility towards its users that should not be waived via arguing r1 is not a protocol level supported curve while being introduced with the goal of increasing onboarding.

I think we should utilize the L2 landscape as playground. Different L2s may set their priorities wrt to security vs onboarding differently. Securing increasing value via r1 increases the incentive to utilize the backdoor for everyone knowing about it. Once r1 secured high value over a long timeframe on (multiple) L2(s), it will be easier to gather support for an L1 support.

In case of a backdoor, the decision whether to remove the support is also highly political, among the obvious of breaking backwards compatibility. When exactly do we deem crypto insecure? Starting at <100 bit (like the still supported alt_bn256 curve), <80?

The inconsistency of the precompile wrt to ecrecover may also lead to many more bugs and more complex code. Furthermore, the proposed precompile does not allow verifying an elliptic curve multiplication like ecrecover (see vitalik’s post). This also makes verifying Schnorr signatures impossible (see this post).

The chances of r1 having a backdoor, while as small as they may be, should be taken serious. Ethereum has a responsibility towards its users that should not be waived via arguing r1 is not a protocol level supported curve while being introduced with the goal of increasing onboarding.

There are billions of devices with hardware P256 support and 0 public attacks demonstrating that P256 is broken, 14 years after Bitcoin chose k1 because of this concern. I fully expect, and welcome, a viable P256 attack to end this silly debate, however, I imagine it will happen roughly the same time k1 is broken due to quantum computing (at which point there will also be a massively political discussion to remove k1 support).

It should also be reinforced that this is for an optional precompile, not a mandated curve change for EOAs.

Several people seem to be arguing that this proposal breaks ecrecover; I agree on this point. This seems like it would need to be solved as Ethereum moves from 1 to n curves regardless (e.g. when we add ed25519). I’m curious to hear from @ulerdogan on this point. I suspect core devs have a proposal on how to resolve (via novel op codes?)


Currently, we are exploring turning to recovery to present a similar interface and provide backward compatibility with the k1 curve applications. Why do you think it breaks ecrecover? If just because of the change in interface, why does it have to follow the same interface?