Public Goods RFP Proposal: P256 precompile support in the EVM

I understand. In that case, we can refer to the milestones that have been included in the draft RFP.

The major milestones include:

a. Month 1: Standards and Specifications

  • Define the standards and specifications for the secp256r1 precompile.
  • Document the requirements and expected behavior of the implementation.

b. Months 2-3: Code Development

  • Implement the secp256r1 precompile functionality within the EVM codebase.
  • Thoroughly test the code to ensure correctness and reliability.
  • Iteratively refine and improve the implementation based on feedback and testing.

c. Months 4-6: PRs and Community Engagement

  • Create PRs for major Ethereum clients, proposing the inclusion of the secp256r1 precompile.
  • Engage with the Ethereum community, present the proposal, and gather feedback.
  • Advocate for the inclusion of the secp256r1 precompile in the next hard-fork at All Core Devs and other relevant meetings.

*funds may be paid out in tranches, according to when milestones are met.

Seems like they have already met the first milestone, given that their EIP has been merged with the EIP Repo. I would surmise that they are well on their way to accomplishing the second milestone. Are there any updates to share @ulerdogan?

I’m requesting that the Public Goods stewards review the draft RFP and provide feedback — they should suggest a maximum budget for the RFP since they have access to the Working Group bursar. If they find it meets their standards, then they should adopt the RFP officially, according to the RFP Process outlined therein.

1 Like

Thanks, great document and milestones! Let me explain our current status:

I have opened a new PR to move the EIP to the Review status as we think that the content is clear and it should be discussed in a wider ecosystem. I am planning to reach out to some client developers, other projects that use the r1 curve, researchers interested in the subject, and more to hear more feedback before taking the EIP to the ACD calls. I will keep the EIP in the Review status until a few weeks after the ETH CC event because I believe that I can reach more reviewers at the event.

In this stage, we have assigned tasks in our team to implement the EIP for different clients such as Erigon, Reth, Nethermind, and Ethereum.js. While we are working on these implementations, we will be collecting some reviews.

I think the milestones are great, but I believe that we will reach the “c” goals earlier than 4-6 months.

@estmcmxci Thank you for putting the draft together. Are you available to introduce it on the next PG call on July 11th, 12pm EST?

@ulerdogan Do you have other feedback on these milestones, does this look reasonable? @estmcmxci It might be helpful to have someone technical (not subject to applying for the RFP) help craft these.

1 Like

I think the draft is quite fine. It might be good to clarify in the RFP which client implementations will be included. Also, if it’s appropriate for the RFP structure, it would be nice to add some emphasis on how ENSDAO will support the EIP in review and community engagement. These can enhance the reviews to reach a better “Final” version and spread the EIP to convince the community that the improvement is valuable and should be included with a hard fork. I believe that showing ENSDAO’s contribution is a big step to attract attention and support.


1 Like

Yes, I’ll make sure to to attend the call.

Thanks for this feedback; it is valuable and we should consider how to incorporate it into the RFP.

1 Like


I want to share my current updates and request reviews.

The PR to move the EIP has merged!

Now, we are looking for reviewers who are interested in giving feedback and share comments in the FEM post. Also, inviting @nick.eth as you shared that this improvement is useful for the EVM and opened this discussion. Your review and comments are valuable for us and appreciated.

Lastly, I would love to hear any updates if there are from your call today @estmcmxci.


@ulerdogan There was some confusion around the call time. We’re going to hold it on Thursday this week.

I’ve tagged both of you in the agenda posted!

1 Like

Thanks! I’ve published an article that explains the RFP Process, the PG working group’s role in stewarding an EIP implementation, and the importance of adding a P256 precompile to the EVM. Public Goods: P256 Precompile Support — marcus

1 Like

Hey, I’ve just read your article. It perfectly explains the process and needs. Thanks!

Also, I am sorry, I couldn’t catch the PG Call. I had a flight that was delayed a bit.


Hello! Thank you. To be frank, it was quite a challenge for me to write this as I don’t have a background in computer science or mathematics for that matter. I’m quite enthusiastic about the subject, however, and it felt fulfilling to break down this process in a way that could make sense to the average bear.

Really incredible work that you’ve done so far — excited for you and your team to continue the discussion with the greater Ethereum community as this precompile is an absolute must!

No worries, you’re more than welcome to share about EIP-7212 whenever you’re available!

Congrats Ulerdogan. This is very important work and there’s no grant big enough that won’t be worth this if we can get merged. I’d strongly support the PG group to create a grant structure: an ongoing stream (once they have verified you have the technical capability to work on it) and a few big payouts in milestones: when first client makes an implementation, when it’s scheduled for inclusion and when it’s merged.


Great to see the continued momentum on this proposal. To review, the Ethylene Studio team introduced EIP-7212 to the Ethereum community on June 22, 2023 and has since had their PR merged with Ethereum’s Github Repo. On July 27th, 2023, Public Goods Stewards + @estmcmxci met with Ethylene Studio to discuss EIP-7212, its implementation, and how the Public Goods working group may support this initiative. Per our last communication, Ethylene have built Go and Rust reference implementations of the precompile, but are in need of a Java developer for other client implementations.

On August 17, 2023, the Ethylene team presented their proposal during an ACD (All Core Devs) call. During the presentation, developers raised several questions, one of the most critical being whether to opt for a recovery or verification mechanism for the precompiled contract. While some developers advocate for verification, others suggest aligning with the ecrecover interface. This issue has emerged as a key point of discussion for the inclusion of EIP-7212 in the next EVM hard fork.

It’s worth noting that Layer 2 solutions have expressed significant interest in this feature. Specifically, ZKsync and Aztec are already in the process of implementing the p256 precompile (correct me if I am mistaken). The ACD call also endorsed a Layer 2-first approach, emphasizing that Ethylene is concentrating on implementing this precompiled contract in certain rollup solutions. Among the Layer 2 solutions currently under consideration for this implementation are ZK Sync, Fuel, Aztec, and Gnosis.

Review: P256 Precompile Support

P256 Precompile Summary

General Overview

  • Current Limitations: EVM’s limited support for cryptographic primitives.
  • Desired Integration: Enable secp256r1 elliptic curve, widely adopted outside of crypto.
  • Use Cases: Enhance ENS, enable web authentication, email verification, and more.
  • Proposal: Ethylene Studio proposed EIP-7212 on June 22, 2023.

Development and Discussion

  • Technical Process: Involves implementations in different programming languages, feedback from core developers, and proposal preparation for EVM hard fork inclusion.
  • Public Goods Discussion: On July 27th, 2023, Public Goods Stewards + estmcmxci.eth discussed EIP-7212 with Ethylene Studio.
  • Current State: Ethylene Studio has Go and Rust implementations but needs a Java developer for other client implementations.
  • Community Feedback: Ethylene Studio is requesting further comments from key figures.

Decision Making

  • Review and Approval: The proposal needs core Ethereum developer review and approval to move forward.
  • Visibility and Advocacy: Increasing visibility and advocacy is key.
  • ACD Call: On August 17, 2023, the proposal was presented; discussion included recovery vs. verification for the precompiled contract.

Other Interested Parties

  • Layer 2 Interest: L2 solutions like ZKsync and Aztec are interested.
  • L2-First Approach: Recommended during the ACD call; focus is on some rollup implementations.
  • L2s Under Consideration: ZK Sync, Fuel, Aztec, Gnosis.

Scope of Work

  • Code Development: Modify major Ethereum client codebases for secp256r1 support.
  • Pull Requests: Create PRs proposing secp256r1 precompile functionality.
  • Community Engagement: Advocate for inclusion at AllCoreDevs and engage the Ethereum community.


Preliminary Works (April - May 2023)

  • :white_check_mark: Pre-research and EIP discussions
  • :white_check_mark: Preparing the EIP draft
  • :white_check_mark: Preparing the reference implementation on the geth

Public Intros (June 2023)

  • :white_check_mark: Publishing the EIP as draft and initiating the FEM discussion
  • :white_check_mark: Opening PR for the geth implementation and getting reviews

Reviews (July 2023)

  • :white_check_mark: Moving the EIP to the Review stage
  • :white_check_mark: Starting to collect reviews

Community Involvement (August - September 2023)

  • :hourglass_flowing_sand: Reaching individuals and projects for reviews
  • :hourglass_flowing_sand: Joining client team discussions for reviews
  • :hourglass_flowing_sand: Attending ACD calls to present the EIP
  • :hourglass_flowing_sand: Building other client implementations (Reth, Ethereumjs, Nethermind, Erigon, Besu)

Integration Discussions (October 2023)

  • :crystal_ball: Moving the EIP to the Final stage
  • :crystal_ball: Sharing example smart contract codes using the EIP
  • :crystal_ball: Communicating with rollups and side chains for integrations
  • :crystal_ball: Considering proposing in the next hard fork for L1

@ulerdogan seems like there is no consensus for an ideal implementation of the precompiled contract in terms of applying verification or recovery, so, before developing client implementations (first milestone), it’s important that devs agree on a best approach. What can be done to help the Ethereum community reach a consensus in order for a first implementation in go-ethereum to be built?

This seems like a straightforward choice, surely? If you implement recovery, users can trivially use that to implement verification - but not vice-versa. Since recovery is strictly the more expressive of the two, it’s the one that makes the most sense to implement.

Awesome, however i noticed this seems to be similar to EIP7212.

Hey, yes! We are running both processes.

1 Like

If it is a question of cost effectiveness, implementing erecovery makes point multiplication over secp256k1 relatively cheap (Dubois. R - Speeding up elliptic computations for Ethereum Account Abstraction), however I am not sure if the same applies for an r1 curve implementation, although I would have to assume so based on my limited understanding of cryptography. The argument that verification method is preferred within the r1 scheme instead is questionable. For example, Besu docs indicate support for public key recovery:

“The public key recovery from the ECDSA signature is very useful in bandwidth-constrained or storage-constrained environments (such as blockchain systems), when transmission or storage of the public keys cannot be afforded.”

While Apple’s Public Developer Documentation does not explicitly state that it uses ECDSA with recovery, some members of the Ethereum Magician community also believe it’s a straightforward task to adjust the code. This would switch the authenticator’s output from the standard ECDSA to the ‘ECDSA with recovery’ version. That being said, since core developers suggested an L2 first approach, their preference may ultimately set a path dependency on which method becomes standardized as an opcode.

Note: I am not an expert cryptographer, just a passionate / involved member of this community so please do take everything I say with a grain of salt, I am still learning!


Now that RIP-7212 is live on Polygon and coming soon to other EVM compatible L2s like OP, ZkSync, and Kakarot, has this development enabled the Labs team to further explore options for integrating this technology into the ENS roadmap?

I am aware that @clowes.eth and @Premm.eth from Unruggable have been developing a proof of concept for an ENS Chain — might implementing RIP-7212 be of relevance here?

I would also love to hear from @ulerdogan about their thoughts on RIP-7212’s potential utility for ENS.

1 Like

Hi @estmcmxci ,

Thanks for the tag.
Your blog post provides valuable context. Thanks for that.

In the context of our research into ‘ENS Chain’, Arbitrum Orbit has Stylus (and its associated EVM+) which allows utilisation of advanced cryptography. This was an interesting differentiator in our mind.

The addition of the secp256r1 precompile would open the door to doing similar interesting things on other implementing L2 chains. In the context of ENS things like fingerprint registrations come to mind.

It’s definitely something we will keep an eye on.

Really appreciative of all the work you’ve done on this @ulerdogan

1 Like

Hey Clowes.eth — that’s awesome to hear! Thanks for the update. If you don’t mind my asking, why is it necessary to use advanced cryptography in an L2? The secp256r1 precompile is live, and I think it’d be worth considering in a roadmap for an ‘ENS Chain’. It would be a massive innovation (imho) if users could register their ENS using their biometric data.

I’d love to stay informed about your research; do you have a newsletter or blog page that I can sign up for? Thank you.

I am very curious about what sort of advanced cryptography is referred to here. Can you please elaborate? Thank you :pray:t2: