Clarity-webauthn: Passkey Verification Library for Clarity 5 [Follow-up]

Apps Identity
1

Hey Stacks fam :waving_hand:

Back in February I posted about Adding WebAuthn (P-256) Support to Clarity for Native Passkey Integration. Big thanks to everyone who engaged — @cuevasm, @dant, @marvin.id, @HeroGamer, @PeaceLoveMusic.btc — and especially to the core engineers @Brice, @jude, and @aaron who helped clarify the path forward.

The good news: Clarity 5 will fix the secp256r1-verify double-hash bug (PR #6763), which means native passkey verification (Face ID, Touch ID, Windows Hello) finally becomes possible on Stacks.

No more intermediaries. No more $0.10/signature fees. True self-custody with keys that never leave your device’s secure enclave.

Since then I’ve been building PillarBTC, forking Clarity Smart Wallet by @friedger and team, with passkey auth using Turnkey as an intermediary. It works, but $0.10/signature adds up fast — testing alone cost 55 signatures.

I’ve submitted a proposal to the Foundation to build an open-source Clarity library that handles WebAuthn signature reconstruction, so any developer can add passkey auth when Clarity 5 ships.

Full proposal: Proposal: clarity-webauthn - Passkey Verification Library for Clarity 5 · GitHub

Draft repo: GitHub - Rapha-btc/clarity-webauthn: A complete toolkit enabling Stacks smart contracts to verify passkey signatures directly on-chain—no intermediaries, no custody, no per-signature fees.

Would love feedback on the approach. And if you’d find this useful for your project, a +1 helps show there’s demand! :folded_hands:

— Rapha (@RaphaStacks)

3 Likes
2

love the initiative on this. better onboarding, better L2 UX.

But in your proposed SDK, you should give guidance on exactly who/what will be signing the actual Stacks contract call tx payload. For example in the actual contractCall, sure we could pass in the user’s webauthn creds to be verified during the Clarity code execution, but it’d be nice to explain who/what will be signing that actual contract call payload to the Stacks network. Some relayer service?

Perhaps Bitflow can provide some guidance on how they’ve built their relayer service behind those Keeper contracts.

1 Like
3

Hey Rapha, I replied to your email but just posting here for completeness - definitely best to make sure folks at Stacks Labs and/or Stacks Endowment see this as these the homes for grants, core development, etc. post SIP-031. :slight_smile:

1 Like
4

Agree Eric, we discussed this and you’re right to flag it. The relayer question is critical.

One path: an x402 endpoint. Rather than having users trust the app layer directly—which introduces MEV concerns and alignment questions—a facilitator with reputation could relay these transactions via x402.

Bonus: they could sponsor fees too, removing another onboarding friction point.

BitFlow’s Keeper architecture is probably the closest reference implementation. Would be great to get their input on how they’ve structured the relayer side.

I’ll add a dedicated section to the SDK docs covering relayer patterns and tradeoffs (self-relay vs. sponsored vs. x402 facilitator).

5

Thanks for the reply and the pointer — much appreciated Mitchell! I’ll make sure to route this through the right channels post SIP-031. Stacks Labs and Stacks Endowment noted.

6

Would love to have this for the Dataing Data Marketplace, Tony is keen on implementing it alongside the other x402 stuff. I’ll let the gigabrains sort out the details but count me down for seconding the proposal overall :folded_hands:

1 Like
7

Thanks @peptoshi! Great to hear you and Tony want this for Dataing. x402 + passkey auth is a natural fit — micropayments without wallet pop-ups or seed phrases.

Happy to sync with Tony on what the integration would look like once the library ships. The goal is to make it drop-in simple: pass the WebAuthn signature, verify on-chain, done.

Appreciate the +1