## Brief History and Current Situation of RIP-7212

In the next ACDE, there will be final decision to include EIP/RIP-7212 in Pectra. I want to share the history and current situation of the proposal with possible debates, then present my final recommendation.

**What:**

- "Proposal to add precompiled contract that performs signature verifications in the “secp256r1” elliptic curve."
- It is a significant contribution to key management in account abstraction by enabling the use of native signers of mobile devices in smart contracts, already used by many wallets like *Clave, Safe, Coinbase Smart Wallet, and Soul Wallet*.
- *ENS* is willing to use this precompile for onchain DNSSEC on L1 for web2 domains.
- Additionally, various use-cases like remote attestations, private/encrypted mempools with TEEs (for example SGX), emphasized by teams such as *Scroll, Taiko, Flashbots, and Puffer Finance*, require verification by this elliptic curve.

**History:**

- A year ago, the proposal was first introduced as an EIP and then collected a lot of feedback and demand during the Draft and Review phases. It was also discussed in a previous ACDE.
- Then, with the newly started RollCall's in December, the EIP was migrated to an RIP as the first one, with the demand to integrate it before L1 from various L2 blockchains.
- The specification of the proposal was finalized in various RollCalls, with contributions from EIP-7587, which reserves an address range for the RIP precompiles (`0x100` for this precompile).

**Now:**

- RIP-7212 has been implemented by various rollups and some other blockchains: ZKsync Era, OP Mainnet and OP Stack chains, Polygon, Kakarot ZKEVM. Also, it’s in the development progress for Arbitrum and Scroll.
- There are client implementations, which are also used by rollups, for Geth, Erigon, Besu, Reth. Meanwhile, Nethermind team has shared that it’s on active development now.

**Debates and My Rationale:**

- Return Data:
- The current final spec of RIP-7212 defines the return data as 1 in 32 bytes for successful verifications and does not return data for other cases.
- The rationale for this choice is to keep the data *identical* to the return values of `ecrecover` (recovered address or no data). I agree that returning 0 for unsuccessful verifications could be an option, but I don’t see any significant contribution of this alternative version in L1.
- EIP/RIP Confusion and Precompile Address:
- I respect that you may not want to maintain this compatibility as this is a feature that L1 will implement for the first time, but preserving the same specs and address in L1 and rollups would be great for the ecosystem. However, if a specification change is decided here, it may be more appropriate for the precompile to be at a different address with a new EIP.
- Verification vs Recovery:
- The official specs of `secp256r1` only define “verification,” and all of this curve’s ecosystem follows verification in their practices. Therefore, recovery will not be coherent with the broader ecosystem and will not be useful for the EVM (recovery does not reach the public address like `ecrecover`).
- Complexity:
- I agree that Pectra is currently quite comprehensive, and there are concerns about adding a new proposal. However, I think that a relatively simple addition, which has been implemented on behalf of all clients and has already started to be used in rollups, might be feasible.

**Final:**

- Currently, the EIP and RIP are duplicate. I recommend following up this discussion by EIPIP and remove the proposal from “EIPs” repository.
- https://github.com/ethcatherders/EIPIP/issues/345
- I don’t see any requirement to change the specs. I recommend including the RIP-7212 in the Pectra.
- https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md