Hey guys, we just launched an initiative to supercharge the NIST Elliptic Curve seeds bounty. The aim is essentially to find the pre-image for the P256 seed c49d360886e704936a6678e1139d26b7819f7e90 given the major hint in the original bug bounty announcement:
The people who are involved are:
A major shoutout to @merkleplant who has been the driver behind this initiative! Would appreciate spreading this initiative & any donations are ofc welcome 
I would like to disagree with this disagreement, and add my 2 cents in support of adding this precompiled contract.
Right now, Ethereum’s “Web3” ecosystem has many vulnerabilities. In practice, people trust the website they are on (such as app . uniswap . com) to produce “safe” transactions. Very few people even check what contract is being interacted with, or what method is being called, or what parameters are being passed, they just simply press “OK” because they trust the website (and PKI ecosystem for HTTPS and DNSSEC). But the webserver can easily be hacked, or the DNS can be pointed to a different server, stealing funds from anyone who uses, say, the Uniswap web interface (which is what most people use to access Uniswap) and the same goes for any DEX.
Similarly, people sign into websites by signing various payloads, and even EIP712 doesn’t really help if the payload is complex.
But the biggest issue is in practice people don’t actually remember their 12 word phrase. They take a screenshot of it, or write it down somewhere their friends can find it. I encourage everyone I know to duplicate the phrase 3 times, cut it with scizzors into a grid of 12 pieces, and hide it in different places… most people don’t do that, however.
The fact that most Ethereum wallets allow exporting private keys is a major security flaw for the Ethereum ecosystem. This is how people get phished, whether for their private key or security phrase. Even a few developers fall for fixation attacks, by using a website to generate a vanity address, or something like that.
By contrast, having a precompiled contract will give all Ethereum users the option to authenticate using a device of their choice, from a growing number of authenticator systems. Face it, most of the world’s authentication / signature systems in public use – including secure enclaves, and even webauthn and web subtle crypto – use the r1 curve not the k1 curve. And the governments and industry are unlikely to join Bitcoin / Ethereum, it’s been over a decade and they don’t care. If anything, they are doing what they can to marginalize the ecosystem.
So, if you consider the trade-offs between a possible backdoor in manufacturer keys or even SECP256R1 curve itself, against most people taking screenshots of their phrases and syncing it into the (unencrypted) iCloud, or being able to export their private keys, I think it’s a net security gain for the ecosystem to make it cheap to verify these signatures.
And frankly, it’s a HUGE net gain for their adoption – no one wants to remember 12 words, when they can use passkeys or whatever.
But even more to the point – the open web standards and web crypto support sec256R1 for non-extractable keys. By contrast, web3.js and ethers.js or any other JS library that Web3 would use are forced to keep the keys accessible to Javascript! Compared to the potential security downsides of allowing SECP256r this is absolutely terrible from a security point of view.
Maybe the guys behind app . uniswap . com and etherscan.io have a tight lid on security, who knows. But Ethereum and Web3 have enabled a long tail of websites to incorporate it, just like PHP script kiddies and tags back in the day. Any one of those websites can be hacked, or the Javascript switched out. In fact, even MetaMask wallet and other wallet browser extensions can and do swap their code out anytime! And app-based wallets can ship an update via the App Store, and no one would be the wiser. I don’t think Apple would catch it.
I wonder what @vbuterin would say is more of a threat, Apple / Google backdooring their secure enclaves or Consensys / publishers of Metamask and Binance / publishers of Trustwallet backdooring their next version, or Apple / Google backdooring the app store versions (no one checks reproducible builds). Seems obvious to me that the latter includes the former (Apple/Google) plus a long tail of wallet makers. Moving to SECP256R1 would reduce the attack surface tremendously while also making EVM go mainstream in a big way.
If you want the EVM ecosystem (Ethereum/BNB/MATIC) ecosystem to stop having a reputation for scams and rugpulls, we need to have professional developers move to factory patterns rather than “devs in a Telegram chat” who clone a SAFEMOON contract and rugpull you. Most smart contracts should just be produced by factories, with custom parameters. (Compare the trust people place in Uniswap Liquidity Pools for example vs a random SAFEMOON clone that was deployed manually to the blockchain.)
But besides the factory pattern, we have to get rid of the terrible practices of 12 word phrases just to create a wallet, the ability to export private keys, etc. etc. And if we start to support cheap verifications of SECP256R1 signatures on the blockchain, then people can have a direct relationship with contracts on the blockchain, and in addition trust only their Operating System and Browser vendors (which is their trusted computing base anyway) instead of a myriad websites and extensions all serving their own Javascript and able to switch it out anytime.
Disclaimer: I’ve spent $1 million and 5 years to build such an open source ecosystem, which you can see here… but we are not the only ones:
I should add that unless we make it cheap and easy for smart contracts to verify SECP256R1 signatures, even a simple XSS exploit on a site (including third party analytics, let’s say), can steal the keys, phone home and later use them to sign any payload.
As a web developer for over a decade I definitely can say that having sandboxed iframes with postMessage, and subresource integrity, mitigates most of the XSS attacks inside those iframes. So if you as a web developer place such an iframe on your webpage, with SRI, then any code that loads inside it (cached or not) can be trusted, as long as some third parties have vetted that SRI hash. That is currently the only way to ensure reliable security on the open web. But if the top-level website colludes with the iframe then users who trust both domains will be open to having their keys stolen. In the case of browser extensions, just consider them the same as that iframe … they just come from the Google Chrome Store, e. g. Metamask.
Couldn’t agree more.
Hi Magicians,
They were inconsistencies in the Benches of EIP7212 implementations, so here is the onchain address for the FCL version of EIP7212:
0xE9399D1183a5cf9E14B120875A616b6E2bcB840a, available on Polygon (Mainnet), and the following testnets: Sepolia, Optimism, Base and Linea.
It has the same API’s as Daimo and Vyper, and you will find a script to easily push additional transactions on chain here:
(script uses the --ledger version, use PRIVATEKEY=<> instead if u don’t have one for testing)
For daimo, on chain results indicate a 355K average cost, FCL a 227K average cost.
The version with precomputations shall be easier to use with this script, the cost is around 100K because we are using the 'extcodecopy" version to provide a blockexplorer code verification. (Optimal codecopy, unverified is close to 80K in a tx).
As discussed in the RollCall#0 and RollCall#1, the final decision is that it would be more beneficial and quick to continue the proposal as a RIP. Thus, willing rollups will be allowed to complete their implementation around the standardization created with RIP.
In this regard, a copy of the EIP with RIP naming has been merged into the RIP repo in the Last Call. 
The RIP specification will be finalized by determining the address space where the precompiles will be implemented. Also, the proposal will be changed due to the RIP repo requirements. Would love to hear your last comments and feedback during the Last Call.
Following the RIP merge, the address range for the RIP precompiles has been set to 0x100+ (ACDE#177 as reference) and as the first precompile as RIP, P256VERIFY will have 0x100 address (indicates 0x00...00100).
Last Call deadline is 2 weeks from now, until the 4th of January. Then, the proposal will be moved to the Final status and be ready for any implementations by rollups.
Wow. Two months after I wrote this, the Ledger wallet JS got hacked in the exact way that this would have prevented
As a web developer for over a decade I definitely can say that having sandboxed iframes with postMessage, and subresource integrity, mitigates most of the XSS attacks inside those iframes. So if you as a web developer place such an iframe on your webpage, with SRI, then any code that loads inside it (cached or not) can be trusted, as long as some third parties have vetted that SRI hash. That is currently the only way to ensure reliable security on the open web.
@ulerdogan what about layer 1 blockchains like Ethereum Mainnet, Polygon, Binance Smart Chain, etc. ? This is only for rollups and Layer2s?
It’s dependent on the governance mechanisms for every L1 or L2 chain.
Hello everyone! I’d like to express massive support for this EIP!
Wanted to share that some months back I also wrote an implementation of a P256 verifier in Huff Language. I implemented it from Daimo’s implementation and made some optimisations to it to bring down its costs to the range of 228k - 250k gas. This implementation has the same interface as Daimo’s too and passes all their tests too. It is currently deployed on Ethereum’s and Base’s Goerli and Sepolia testnets at 0x00000083Ea3aBb243c4acfDB095DB5aD5A606fc5.
For anyone interested, you can check out the code and tests here:
The PR which applies the last changes and announces Last Call deadline has been merged. The new Last Call deadline is January 10.
There is a push towards multi-proofs in rollups, SGX in particular is a prime candidate:
Having this precompile would solve a big gas cost headache and enable SGX verification without relying on Intel chain of trust.
I wasn’t aware of this use case that EIP-7212 could enable and yes, it is obvious that multi prover rollups could use this precompile. Thanks for the contribution!
As of this PR, RIP-7212 has reached to the Final status and became the first finalized RIP. Now, it’s guaranteed that there will be no changes in the specs and the proposal is ready to be implemented by any chain.
Please check my reference implementation for go-ethereum:
RIP-7212 is live on Polygon Testnet.
You can try it yourself:
Hi everyone,
I was wondering if there are any implementation tricks that can programmatically check if RIP-7212 is live within a specific L2. I believe some longer-term ideas were discussed in the RollCall #2.3 meeting that would address this (e.g. progressive precompiles, or a precompile that itself returns information about which precompiles are active on a chain). However, I believe RIP-7212 will be live before some of these.
The best solution I can think of is to hardcode a call to the precompile with a signature that’s already known to be correct, and then the precompile is live iff bytes32(1) is returned. Does this seem like the best implementation that’s currently possible? Preferably it’d be possible to tell if the precompile is live regardless if a signature is valid or not. However, I believe a call to the RIP-7212 precompile with an invalid signature will return no data, which is equivalent to calling an address with no code/precompile, so it’s difficult to distinguish whether the precompile exists or not in this case.
Hello Riley! Yes, there is no progress on the onchain registry idea. Also, I agree with you that it looks like the most ideal way to understand if precompile exists.
I understand RIP-7212 is not yet live on the Ethereum Mainnet? Do we expect this to happen soon? Or is there any rough estimate as to when it will be?
As an RIP, the proposal has not been planned for the Ethereum mainnet yet. It can be considered in the future.
