I’m working on implementing a non-custodial wallet using WebAuthn (passkeys/biometric authentication). However, I’ve hit a fundamental compatibility issue:
Current Problem:
WebAuthn uses P-256 (secp256r1) for signatures
Clarity only supports secp256k1 verification
This forces complex workarounds that reduce security
Current Workarounds:
Store an encrypted secp256k1 key in browser storage
Use WebAuthn to decrypt it
Sign with secp256k1
Verify with secp256k1-verify
This adds unnecessary complexity and attack surfaces compared to using WebAuthn’s secure enclave directly.
Proposed Solution:
Add P-256 signature verification to Clarity, enabling:
WebAuthn key stays in secure enclave
Public key stored in contract
Direct signing from secure enclave
Contract verifies P-256 signature
Questions:
Is adding P-256 verification to Clarity feasible?
If yes, could someone point me to relevant code (like the secp256k1 implementation) that I could learn from to potentially contribute this feature?
What would be the process for proposing/implementing such an addition?
This would enable truly secure, non-custodial wallets using native device security without compromising the security model with additional key storage.
Let me add that important use case to the post:
Real World Impact & Mass Adoption:
The ability to use WebAuthn natively would enable a powerful user experience for mainstream adoption:
User buys sBTC/asset with credit card
Assets are sent to a smart contract wallet
User can access/control their assets using just their device’s biometrics (Face ID/Touch ID)
No seed phrases to manage
No complex key management
Security backed by device hardware
This creates a familiar authentication flow that mainstream users already trust (similar to Apple Pay or banking apps), while maintaining the non-custodial nature of crypto. It bridges the UX gap between traditional finance and web3 without compromising on decentralization.
This could be a significant step toward making Stacks more accessible to mainstream users who are comfortable with biometric authentication but hesitant about seed phrase management.
The deep technical bits are beyond me, but I love the proposal’s goal of making Stacks more real-world-friendly. I wonder if @marvin.id has thought about this given his work on Ryder and could offer some comments here
Thank you @cuevasm - completely agree it would be great to get @marvin.id’s insights given his experience with Ryder!
To clarify - Nicolas Bacca’s project smoo.th on Ethereum L2s is actually implementing direct passkey integration without workarounds, as those chains support the native secure enclave signatures. While there are some edge case vulnerabilities (particularly during device synchronization as shown in his talk: https://www.youtube.com/watch?v=TEjNSr8jjUI), the massive UX improvement makes it a worthwhile tradeoff for onboarding when risks are properly disclosed.
From Faktory’s perspective, even the current workaround implementation (though less secure due to potential browser key interception) could serve as a valuable experiment for limited-value use cases - like sending gift cards to friends.
The key question remains whether building native Clarity support for the passkey algorithm is feasible, and @marvin.id’s perspective on this would be incredibly valuable.
We’re working with passkey in the manner you mention here at Boom. Keep in mind that passkeys are device dependent, so you still would want/need a back-end ID that users can use across devices for the same account.
From this perspective, the current Stacks wallet is actually useful.
At Ryder, we use a custom secure element and we decided to base our device security mechanisms on secp256k1 instead of secp256r1 (or other) for that exact reason.
Passkeys-compatible Stacks transforms our existing devices into potential hot wallets, and I’m curious if other Stacks builders will notice this potential.
TLDR: If adding WebAuthn support doesn’t slow Clarity 4 (and it is safe) by more than ~2 months, and doesn’t create risk for existing Stacks’ DeFi platforms then
→ We should have it.
It aligns with Stacks Roadmap’s onboarding strategy well.
As a non-technical founder focused on making onboarding easier for non-native crypto users (while avoiding custodial models), this feels like an obvious step forward. Passkeys/WebAuthn could provide the kind of familiar, secure experience that mainstream users already trust, while keeping things non-custodial.
If supported natively in Clarity, I’d expect broad adoption across apps. More importantly, it could be one of the most impactful improvements for making Stacks approachable to people and builders outside the ecosystem—safe, simple onboarding that lowers one of the biggest barriers to entry. I’m really hoping this makes it into Clarity 4.
Currently the SIP is going through CABs review & approval.
Once CABs approved, Clarify 4 SIP (SIP-033) will go up for ecosystem wide voting, as it is a consensus breaking change.
We had @raphasierra.id.block and @brice on last Friday’s SIP call talking about the recent addition of "secp256r1” in SIP-031 Clarity 4 Upgrade, specifically to give more context to this feature.
TLDR: native Clarity 4 support to add foundation building blocks to allow app/wallet builders to create more secure onboarding feature.
SIP approval update: Technical CAB has reviewed SIP-031 including secp256r1 support and given it thumb up, therefore we are proceeding to public vote around 15th October.
You can watch the replay via this link: 
SIP approval update: Technical CAB has reviewed SIP-031 including secp256r1 support and given it thumb up, therefore we are proceeding to public vote around 15th October.
You can contribute by jumping into the Github PR reviewing the SIP too: 