throw-away k1 → smart-wallet → passkey

Nowadays passkey is everywhere. Web3 wants to stay in the loop, so why not enjoy the already existing hardware enclave in everyones hand to sign contracts as well. Despite its intimate possibility, in practice it is not feasible, not cost efficient.

Sad fact 1, please skip the jargon as will be explained in simple term later:

Passkeys normally create keys on the P-256 (secp256r1) curve, keep the private half locked inside hardware enclaves, and give browsers no direct way to export it. Ethereum EOAs, however, are hard-wired to the secp256k1 curve and rely on the inexpensive ECRECOVER pre-compile for signature checks.

Directly using passkeys for EOAs would require:

• Modifying Ethereum’s consensus layer (e.g., via EIP-7212), which could take years.

• Sacrificing cross-chain compatibility, as most EVM chains use k1

bottom line is passkey [r1] is expensive compare to current EOA key [k1]. Then to mitigate the situation, make r1 as cheap and universal as k1, RIP-7212 comes into play to get passkey convenience (biometric auth) without sacrificing Ethereum compatibility.

Sad fact 2: RIP-7212 needs a custom verification logic, not doable without smart contractable wallets, another way to think of AA.

To conquer these sad facts, ie. expensive and current incompatibility, people opted a two step approach as explained in this survey, sorry if Japanese but well explained and deserved to be cited. These solutions are basically:

These are good looking remedies but the root cause, a fundamentally better solution is to go after a single step approach that is intrinsically better, ie. 1. easier 2. more intuitive 3. closer to the use case 4. no need to waste (dispose). However:

A deterministic “passkey → k1” mapping although sounds tidy, but current WebAuthn and device-enclave rules give you no stable, exportable seed to drive that math. The only practical way to enjoy passkey UX and universal EVM compatibility today is the two-step approach: bootstrap with a disposable secp256k1 key, install smart-wallet code with EIP-7702, and let that code verify the passkey either through the cheap RIP-7212 precompile or an off-chain aggregator. Until browser vendors expose a standard, deterministic, origin-agnostic key-derivation API inside passkeys, this mapping shortcut is neither safer nor cheaper.

https://widget.0xecho.com?color-theme=light&desc=&has-h-padding=true&has-v-padding=true&modules=comment%2Clike%2Ctip&receiver=0x7870C5496c10463ee4470AC68244015E822Ad017&target_uri=https%3A%2F%2Fmirror.xyz%2F0x7870C5496c10463ee4470AC68244015E822Ad017%2FDOxJx0KzeqyNDgY7VvwNLFdwItmDDleOd-Jw3hw3Qf8&height=800&display=iframe