Clarity Working Group — passing the baton from Setzeus

Rapha23 · May 13, 2026, 12:14am

Hey all,

@setzeus has passed me the calendar event for the Clarity Working Group, shared the slides, and will share the operating rules shortly. Huge thanks to him — his deck’s last slide lists 35 sessions over the past two years, from his first on May 14, 2024 to today’s, his last before handing off. The community owes him a lot for keeping that rhythm going.

I’m keeping the same slot Setzeus has been running: every 2 weeks on Tuesdays, 9:00–9:30 AM ET. Next session: Tuesday, May 26.

A few things I want to be clear about from day one:

I’m not the owner of the Clarity WG. Everyone in this community is as much an owner of it as I am. I’m simply trusted with the calendar event — showing up reliably, and coordinating/vetting guests.

What this means in practice:

Clarity devs are warmly invited to collab. If you want to present, demo something you’re building, or open a topic for discussion, please reach out.
Office-hours sessions are fine too. If nobody has prepared anything for a given slot, that’s okay — conversations happen, questions get asked, no pressure.
I’ll usually share one or two things from the Clarity code I’m currently working on. But please don’t expect deep dives into topics like Lamport signatures, at least not when I’m starting out. I’m here to learn alongside everyone, not lecture from above.

Thank you for the opportunity. I’ll take it seriously, and honestly I see this as much an opportunity for me to learn from all of you as it is to coordinate the space.

If you have a topic in mind, or want to be slotted in for the May 26 session (or any after), drop a reply here or DM me.

— Rapha

Rapha23 · May 26, 2026, 2:11am

This Tuesday, May 26, the Clarity Working Group meets at 9:00–9:30 AM ET — same calendar event and link @setzeus has been running. It’s a packed 30 minutes with three short topics, and Clarity devs are warmly invited to join, ask questions, and jump into the discussion.

@ECBSJ opens with Bitcoin Staking on L1 — why the staking commitment is locked with a P2WSH script rather than P2SH or P2TR, and the mechanics and UX tradeoffs behind that choice from the Bitcoin Staking whitepaper.

@BowTiedRadone follows with Rendezvous (RV) fuzzing, walking through how version 1.0 does property-based, invariant testing of Clarity contracts, along with the roadmap — a joint announcement with Clarinet is in the works.

If there’s time, I’ll close with Vini.btc’s cross-chain attack on a BTC↔STX swap contract and a second bug that RV fuzzing caught in JingSwap — two hacks avoided before they ever created any havock.

Come by even if you’re just curious — office-hours-style conversation is always welcome. And if you’d like a slot in a future session, or want to demo something you’re building in Clarity, reply here or DM me.

— Rapha

Slides: Jing Swap, Swap big from Bitcoin to USDC on Stacks.

Rapha23 · May 26, 2026, 1:50pm

Thank you everyone. Stellar pres by @ECBSJ and @BowTiedRadone

Also great share by @setzeus . Please find fireflies notes below!

Script Choice Justification: P2WSH offers compatibility, simplicity, and deterministic address creation for Bitcoin staking over complex Taproot.
Hardware Wallet Impact: Taproot’s complex reclaim paths challenge wallet integration; P2WSH avoids exposing sensitive keys.
Rendezvous v1.0 Enhancements: New tool features flexible testing, auto-saves failures, and enforces property-based tests for mainnet safety.
Bitcoin Script Advances: Research on OP_CTV focuses on secure covenants and automated Bitcoin vaults to enhance custody security.
Collaborative Culture: Team values input on Bitcoin staking details and expresses ongoing enthusiasm for knowledge sharing and learning sessions.

Notes

Bitcoin Staking Script Design and Technical Choices

The team clarified why Bitcoin staking on Stacks uses Pay to Witness Script Hash (P2WSH) instead of Pay to Taproot, balancing compatibility and technical constraints.

P2WSH chosen for Bitcoin staking due to compatibility and simplicity (01:02)
- P2WSH uses native Segwit v0, widely supported by wallets and institutions.
- It allows deterministic creation of addresses from one script commitment, easing user reasoning.
- Pay to Taproot offers script privacy and multiple spending paths but adds complexity.
- Pay to Taproot’s complex script tweaking cannot currently be validated in Clarity smart contracts, which lack 256-bit math support.
Hardware wallet constraints influenced the script choice (09:14)
- Ledger and other wallets have difficulty supporting Taproot reclaim paths as required for Bitcoin staking.
- Stacks Labs avoided requiring users to expose sensitive keys needed for Taproot on Ledger.
- Bitcoin staking’s use of Clarity to confirm locking scripts further limits Taproot use due to math and validation gaps.
Legacy Pay to Script Hash (P2SH) was rejected for inefficiency (05:44)
- P2SH is less efficient in size and fees compared to P2WSH.
- Lock times on Pay to Public Key Hash (P2PKH) lack support for script embedding, limiting flexibility.
Differences highlighted between SBTC bridge and Stacks Bitcoin staking approaches (06:42)
- SBTC uses Pay to Taproot with hidden reclaim and sweep paths, visible only when spent.
- P2WSH scripts expose all conditional paths on spending, making them transparent on-chain.
- This transparency tradeoff is accepted for better wallet support and clarity integration.

Rendezvous v1.0 Release and Testing Enhancements

Rendezvous v1.0 launched as a production-ready fuzzing tool with improved workflow, AI friendliness, and developer usability.

Rendezvous v1.0 integrates simnet environment annotation and config files for flexible testing (15:00)
- Tests no longer inject into contract source but compile separately for simnet and mainnet.
- Config files replace complex CLI flags, enabling multiple testing scenarios (e.g., nightly runs, regression).
- Real mainnet accounts can be included in simnet testing through config-based principal specification.
Failures during testing are now automatically saved to disk for regression testing (18:57)
- Captured failures store seed, dial path, hooks, run counts, and timestamps.
- Developers can rerun regression tests to catch known bugs efficiently.
- This automation reduces manual bug tracking and improves test reliability.
Breaking change enforces property-based tests and context functions as private (20:30)
- Prevents accidental inclusion of test functions in mainnet contracts.
- Adds a safety guard reflecting real-world deployment risks.
- Users upgrading to v1.0 must modify their tests accordingly to avoid failures.
Plans to make Rendezvous AI-friendly aim to lower technical barriers (22:50)
- Future versions will support AI agents to assist writing invariants and properties.
- The goal is to help operators find bugs without deep testing knowledge.
- Possible plugin-based AI integration will maintain platform neutrality and ease of use.

Insights on Bitcoin Script Advancement and Covenants

The discussion covered ongoing research into Bitcoin script opcodes, especially OP_CTV, and their potential impact on script security and vault design.

Jesus Najera is actively researching Bitcoin script upgrades including Covenants (28:36)
- Focus on OP_CTV as a simple, secure covenant opcode proposed since 2020.
- OP_CTV checks that a spent transaction matches a pre-committed transaction exactly.
- Covenants enable defining strict spending rules, useful for vaults or multi-party controls.
OP_CTV’s potential for secure, automated Bitcoin vaults was highlighted (34:20)
- It allows locking funds to only move along predefined transaction paths.
- Example use case: a family vault restricting spending only to trusted addresses.
- This reduces risk even if keys are compromised, improving Bitcoin custody security.
Current testing environments for OP_CTV include Mutiny Net and Bitcoin Inquisition (33:41)
- Mutiny Net integrates some covenant flavors for experimentation.
- Bitcoin Inquisition is an experimental client supporting new opcodes for testing.
- These networks provide practical grounds to tinker with upcoming script features.
OP_CTV is considered the simplest and safest covenant flavor with strong community review (32:41)
- More complex covenant proposals face stronger opposition due to increased risk.
- OP_CTV’s long standing and simplicity boost its likelihood of adoption.
- Jesus plans to publish an article detailing covenant design and benefits soon.

Strategic and Operational Perspectives

The team expressed openness to collaboration, shared operational updates, and reflected on the value of recent contributions.

Eric Choy encouraged further input from Stacks Labs on Bitcoin staking technical details (13:25)
- He invited official team members to fill gaps or clarify script design decisions.
- This fosters transparency and collective understanding of the staking mechanism.
Rapha Sierra shared positive user experience with SBTC bridge reclaim functionality (14:12)
- The reclaim process worked smoothly, reinforcing confidence in the protocol.
- This practical insight validates some of the technical choices discussed.
Rendezvous bug detection credited for uncovering edge case coding errors (23:10)
- Rapha’s use of AI-driven fuzzing found a bug in his own code related to data overriding.
- This showcases the tool’s effectiveness in improving contract robustness.
Team expressed enthusiasm for continued learning and future presentations (35:56)
- Rapha thanked presenters and expressed interest in further sessions.
- Jesus Najera offered to discuss Bitcoin script research anytime.
- The positive tone suggests ongoing collaboration and knowledge sharing ahead.

Action items

Radu Bahmata

Provide Rapha RSierra with information about the second bug identified in Rendezvous for PR submission (27:21)

Rapha RSierra

Verify details of the second bug in Rendezvous and submit a PR if applicable (27:43)

Participants at Stacks Labs

Share further technical details about Bitcoin staking design and script implementations to fill knowledge gaps within the group (13:25)

Jesus Najera

Prepare and publish an article explaining Covenants and related opcodes such as OP_CTV (32:41)

Anyone interested

Reach out to Jesus Najera for detailed discussions on Bitcoin Script research and Covenants (37:02)

Rapha23 · May 27, 2026, 2:55pm

Clarity Working Group — Tuesday, June 9: New Bitcoin functions in Clarity 6 + secondlayer

This Tuesday, June 9, the Clarity Working Group meets at 9:00–9:30 AM ET — same calendar event and link @setzeus has been running. Two topics this round, and as always Clarity devs are warmly invited to join, ask questions, and jump into the discussion.

@brice opens with the new Bitcoin functions coming in Clarity 6 — the new built-ins that let Clarity contracts read and verify Bitcoin state directly, what they unlock, and how they change what’s possible on-chain.

Ryan Waits follows with secondlayer (secondlayer.tools) — the agent-native data plane for Stacks. The chain emits events; apps and agents need them in any shape. Ryan will walk through how its Streams firehose serves every Stacks event as an immutable, cursor-paginated, reorg-aware log — so you can build indexers and higher-level APIs without ever running a node — plus Index, Subgraphs, Subscriptions, and the curated Foundation Datasets layered on top.

Come by even if you’re just curious — office-hours-style conversation is always welcome. And if you’d like a slot in a future session, or want to demo something you’re building in Clarity, reply here or DM me.

Rapha23 · June 9, 2026, 2:06am

Reminder: Clarity Working Group — tomorrow, Tuesday June 9, 9:00–9:30 AM ET

Same calendar event and link.

@brice opens with the new Bitcoin functions in Clarity 6 — read + verify Bitcoin state directly on-chain. Ryan Waits follows with secondlayer, the agent-native data plane for Stacks.

Come by even if you’re just curious — office-hours-style questions always welcome.

See you at 9 ET sharp; we’ll keep it to 30 minutes.

Rapha23 · June 9, 2026, 3:04am

Small shuffle for tomorrow (Tue June 9, 9:00–9:30 AM ET):

Ryan Waits had the day mixed up (Wed, not Tue), so secondlayer moves to a future CWG. @brice still opens with the new Bitcoin functions in Clarity 6.

In Ryan’s slot, I will walk through clarity-webauthn — signing Stacks txs on-chain with a passkey (Face ID) — and maybe live-demo it: https://www.jingswap.com/cwg2/webauthn

Office-hours questions welcome as always.

Rapha23 · June 9, 2026, 2:24pm

Please find attached fireflies ai notes from today’s session. Thank you everyone and catch you again in 2 weeks!

ClarityWG — Meeting Notes

Date: Jun 9, 2026, 9:00 AM Attendees: Rapha RSierra, Brice Dobry, Friedger Müffke, Hugo C, Radu, Setzeus, … Language: English (Global)

Highlights

BTC TX output extraction (Rust) — extracts a single output by index from a serialized Bitcoin tx, returning script, amount, and txid; no witness data. Merged into the PoX WF integration branch.
Merkle proof verification (built-in) — validates tx inclusion in a block; guarded against the CVE-2012-2459 duplicate-leaf vuln. Critical for confirming BTC staking txs.
Passkey auth for smart wallets — WebAuthn signature verification in Clarity with no backend DB; domain verification for phishing resistance; gasless Face ID signing demoed on an sBTC-funded wallet.
Ledger ↔ passkey integration — derive a Ledger-compatible seed phrase from a passkey; powers on-chain Nostr content rewards via sBTC.
Clarinet 3.19 — imminent; ships all new built-ins except variadic concat (pending PR). SIP to be voted alongside the BTC staking SIP, targeting Epoch 4.0.

Bitcoin transaction processing

TX output extraction in Rust (00:00) — A function extracts a single output from a serialized BTC tx by output index, returning script, amount, and txid without witness data. Direct calls to the Bitcoin library (per Brice) keep accuracy and cost in check versus a Clarity implementation. Witness txids are excluded for now; inclusion is under discussion. Merged into the PoX WF integration branch.

Merkle proof verification built-in (04:18) — Validates that a BTC tx is included in a block using leaf hash, Merkle root, tx index, total tx count, and sibling hashes. Includes safeguards against duplicated leaf hashes in odd-numbered Merkle trees (CVE-2012-2459). Allows up to 24 sibling hashes — beyond Bitcoin block constraints — for robust verification.

Remaining work (08:19) — Finalize the variadic concat built-in to consolidate multiple concatenations into one, cutting cost and improving performance. Pending PR merge; targeted for Clarinet 3.19. The SIP carrying these built-ins is expected to be voted concurrently with the BTC staking vote, launching alongside Epoch 4.0. An sBTC testnet is live and expected fully operational by week’s end for end-to-end testing.

Open questions (09:30) — Brice requested feedback on parsing complexity / cost to prioritize the next iteration, especially around parsing tx inputs/outputs more comprehensively and verifying Stacks txs via Merkle proofs. Stacks tx verification use cases remain unclear (verifying success beyond inclusion is the sticking point). Feedback directed to the Stacks Core repo.

Passkey auth & smart wallet integration

Signature verification in Clarity (24:00, Rapha) — Contracts verify WebAuthn passkey signatures with no backend DB by reconstructing a double-SHA256 hash of authenticator data and client data JSON from the front end. Two modes: user presence (tap) and user verification (biometric), defaulting to user-verified. Domain verification within the contract prevents phishing; the factory fund restricts approved domains to two.

Live demo (30:44) — On an sBTC-funded smart wallet, users sign with Face ID and transact (including small token swaps) without managing seed phrases. Wallets deploy freely, onboard via passkeys, and support admin-wallet addition for recovery/upgrades.

Expansion considerations (29:23, 36:00) — Plans to widen domain whitelisting so wallets work across environments and contracts; contracts need to cover all interactions on whitelisted domains. Brice noted strong adoption potential from the improved UX.

Ledger integration & Nostr derivation (Friedger)

Passkey → seed phrase extraction (36:28) — Derives a Ledger-compatible seed phrase from a passkey via a partial random function of the passkey protocol, removing the need to manage seed phrases. Demo app (passnokkel.netlify.app) shows passkey sign-in with automatic Nostr account derivation and auth.

On-chain content rewards via sBTC (38:12) — Upvote/zap Nostr posts using sBTC, authenticated solely by passkeys. Upvotes emit approval messages (incrementing emoji counts); zaps are on-chain payments directly rewarding creators.

Security (39:41) — Passkey sync risks across Google/Apple discussed; iPhone hardware attestation mitigates some concerns. Users can export seed phrases for recovery / cross-device use. Open-source for auditability.

Alignment (41:10) — Passkey-derived seed phrases can serve as admin keys or recovery options for smart wallets, simplifying multi-wallet management.

Clarinet release & SIP timeline

Clarinet 3.19 is imminent, including all built-ins except variadic concat (pending PR). (21:34)
The SIP bundling these built-ins will be voted alongside the BTC staking SIP, timed to Epoch 4.0 activation.
Testnet w/ sBTC is live, expected fully functional by end of week; early users already exercising the new built-ins in the staking contract. (22:28)
Vote expected within ~1 month, moving the feature set into production quickly given demand.
Testing (Hugo C, 9:13) — testable on Clarinet 3.19.0; 3.18.0 only shipped two of the functions, 3.19.0 has all of them except variadic concat. → stx-labs/clarinet · discussion #2406

Cost / workflow optimizations

Variadic concat (08:19) — Replaces nested concatenations with one variadic function, cutting exponential cost growth. PR ready to merge.
Buffer manipulation (20:16) — Slicing/concatenating buffers is expensive; targeted built-ins could help. Rapha’s and Friedger’s use cases show real demand.
Rust for complex logic (00:00) — Direct calls to optimized Bitcoin libraries cut on-chain overhead and open the door to delegating costly crypto ops to Rust.
Monitoring (22:28) — Active testnet use + community engagement to catch bottlenecks before mainnet.

Action items

Brice Dobry

Complete the final PR for variadic concat and coordinate its release in Clarinet 3.19. (00:21)
Gather community feedback on BTC built-in features, esp. tx input parsing and witness data support. (00:10)
Support the BTC staking SIP vote (incl. new built-ins), targeting Epoch 4.0. (00:21)

Rapha RSierra

Share the existing BTC tx parsing library in the Stacks Core repo for review/collaboration. (00:17)
Open issues with detailed feedback on practical use cases / challenges with BTC tx built-ins. (00:10)
Continue smart wallet dev & demos, including expanded domain support for multi-contract use. (00:29)
Collaborate with Friedger and Brice on Nostr + passkey smart wallet integration. (00:42)

Friedger Müffke

Share source + demo app for passkey → seed phrase extraction (Ledger integration). (00:37)
Continue on-chain sBTC micro-payments and content reward zaps via passkey auth. (00:38)
Help build smart wallet admin recovery + cross-platform passkey capabilities. (00:42)

References & contracts

Rapha’s deployed contracts

SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.clarity-5-webauthn-v3 — WebAuthn passkey signature verification
SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.bitcoin-helper-wtx-v1 — Bitcoin (witness) tx helper / parsing
SPV9K21TBFAK4KNRJXF5DFP8N7W46G4V9RCJDC22.bitcoin-swap-to-stx — Bitcoin swap to STX

Links

Clarinet 3.19.0 discussion: Clarity 6 Preview · stx-labs/clarinet · Discussion #2406 · GitHub
Ledger/Nostr passkey demo: https://passnokkel.netlify.app/