Hi Magicians
The post is about EIP7212 which proposes adding a new precompiled contract to the EVM that allows signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, r  s components of the signature, and x  y coordinates of the public key.
EIP Page (the PR):
What are the use cases of the “secp256r1” elliptic curve?
 The secp256k1 elliptic curve, which is the only cryptographic primitive to prove ownership in Ethereum, does not offer flexibility in onboarding new users via new solutions. Adding this new elliptical curve will allow biometric and hardware authorization solutions to be easily executed onchain.
 Many hardware and software solutions use this elliptic curve as signing algorithms, such as TLS, DNSSEC, Apple’s Secure Enclave, Passkeys, Android Keystore, and Yubikey, which can be used in the EVM.
Why is this precompile recommended, and how do we believe the user/developer experience will be improved?
 The addition of this precompiled contract improves efficiency and gas affordability in the EVM. With the improvement, the gas costs are reduced alongside the computational load decreases, and the block gas limit is maximized to enhance the transaction throughput and overall network performance.
 Supporting an elliptic curve with a precompiled contract provides a uniform and standardized way of operations. So that potential confusion and errors that occur from different implementations can be avoided. The curve operations can be made in reliable implementations in terms of security with precompiled contracts.
 Enabling this precompiled contract improves the developer experience by allowing effortless integration of the curve signatures and building applications on top of it to provide interoperability with different solutions using the curve, resulting in more userfriendly products.
Possible integration ideas of the precompiled contract:

The EIP4337 account abstraction wallets can use these elliptic curve signatures to sign the user operation data with mobile device secure elements and then validate them in the smart contracts.

@arachnid suggested in the ENSDAO that the precompiled contract allows lots of opportunities with DNSSEC for the projects by adding a new cryptographic primitive.
“One of the major barriers to onchain DNSSEC, along with many other potential projects such as web authentication integration, email verification, and other tasks that rely on verifying ‘real world’ crypto proofs, is the EVM’s limited support for cryptographic primitives.”
Questions:
 The recovery of the signatures in the “secp256r1” curve by EVMMAX (the EIP is mentioned in a post by @jwasinger).
 The EIP presents a public key verification process different than the “ECRECOVER” precompiled contracts public address recovery process. A similar recovery method can be implemented after the discussion, but the design choice of the verification is explained in the “Rationale” part of the EIP. Is it efficient to try each possible v component for the signatures offchain and give them to the precompiled contract as parameters?
The proposal has been discussed in the ACDE#168 call, the summary shared by Tim Beiko.
Reference implementation on goethereum:
References:
 https://neuromancer.sk/std/secg/secp256r1
 "secp256r1"  For 256Bit ECC Keys
 SECP256R1 Support  Hyperledger Besu  Hyperledger Foundation
 A “secp256r1” package has already been included in the Besu Native library which is used by Besu client.