Clarity Working Group — passing the baton from Setzeus

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

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.

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)

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.

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.

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.

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

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

Same calendar event and link.

Hugo (stx-labs) opens with Epoch 4 / Clarity 6 in Clarinet. The new Bitcoin built-ins are mature now: read and verify Bitcoin state directly on-chain — tx output extraction, Merkle proof verification — testable end-to-end on Clarinet 3.19. Live demo, with the BTC staking SIP / Epoch 4.0 vote as context.

Then open office hours — bring anything Clarity. Office-hours-style questions always welcome, so come by even if you’re just curious.

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

Sessions + every deck → Jing Swap, Swap big from Bitcoin to USDC on Stacks.

Minutes from today’s Clarity Working Group are below. Thanks to everyone who joined — especially Hugo for the deep-dive demo — and welcome to the new faces. See you in two weeks. Happy Clarity coding! :high_voltage:


CWG Session Recap — Clarity 6 / Epoch 4

Clarity 6 features (Hugo C, stx-labs)

SIP-44 lands a batch of language updates centered on Bitcoin staking and contract ergonomics:

  • New SECP256K1 cryptographic functions for verifying Bitcoin transactions on-chain.
  • A variadic concat that flattens many items in one call — better brevity, lower cost, and easier on the AST depth limit. The linter now flags nested concats you can collapse.
  • New stacking/pox postconditions (more below).
  • Underscore-prefixed variables to mark intentionally-unused vars for the linter — though Brice flagged this one may slip due to epoch-gating complexity.

with-staking vs with-pox postconditions (Brice Dobry)

The two operate at different layers. with-staking lets a contract specify amounts for staking actions; with-pox covers unstaking and registration updates (no arguments). At the transaction level, postconditions act as a security wrapper that confirms staking actions actually completed once the full tx executes. The split gives you granular control at the contract layer and a safety check at the tx layer.

Clarinet (testing the new features now)

  • Change your contract epoch + Clarity version in Clarinet settings to simulate the new environment today.
  • Recommended on simnet for now; Devnet deployment is expected this week but currently resets.
  • VS Code heads-up: an accidental publish of a very high version (15.16) is blocking auto-updates, and the marketplace won’t let it be deleted yet. Workaround → manually install a 3.x version to get the latest features. VS Codium and other forks are unaffected.
  • LSP integration gives inline linting/error feedback in your editor; CLI clarinet format / clarinet check run the same checks in your workflow.

Rendezvous 1.0.1 (Radu Bahmata)

Fixes a bug that blocked running contracts requiring sBTC suite tokens (missing trait reference), now aligned with the latest Clarinet SDK. Great for hardening contracts before deploy — pairs well with AI to fuzz many code variants. Report any remaining issues to Radu.

Open discussion: nonce management

Current nonce retrieval ignores in-flight/mempool transactions, so broadcasting many txs quickly forces manual nonce tracking. A real pain point for backends supporting multiple builders or smart-wallet-as-a-service. Open question on where the fix belongs — Stacks.js, the Rust SDK, or the API layer. Hugo invited contributions/sponsorship to tackle it.

Community

Welcome to Emmanuel List and Jesus, who joined after the recent outreach. Want to present a demo or topic next session? DM Rapha.


Next session: in two weeks. Same time, same link.
Sessions + every deck → Jing Swap, Swap big from Bitcoin to USDC on Stacks.

:date: Reminder: Clarity Working Group — Tomorrow, Tuesday July 7 · 9:00–9:30 AM ET

Same calendar event, same link.

On deck:

:red_circle: Live demo by LabSTX (@labstxorg) — ~10–15 min
An AI-native platform for building Bitcoin and Stacks applications: developer tools, smart contract development, workflows, and deployments. Come see what AI-assisted Clarity development looks like end to end.

:speech_balloon: Open office hours — bring anything Clarity. Questions always welcome; come by even if you’re just curious.

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


Sessions + every deck → Jing Swap · Swap big from Bitcoin to USDC on Stacks.

Clarity Working Group — Session Minutes

Date: Tuesday, July 7, 2026 Host: Rapha (rapha.btc) Attendees: Rapha, Brice Dobry, Hugo C, Radu Bahmata, Oyewale Prudence (LabSTX), Ayomi (newcomer)

Agenda: LabSTX demo, followed by open office hours.


1. LabSTX Demo — Oyewale Prudence

LabSTX is a browser-based smart contract IDE for Stacks developers, allowing them to write Clarity contracts without installing a local environment. Inspired by Remix IDE on Ethereum. @LabSTX

Features demoed:

  • Project templates — Projects can be imported via templates, including Hiro templates fetched dynamically from the Hiro templates GitHub repository and spun up directly in the IDE.

  • LSP support — The language server detects warnings/errors just like a local environment (demoed on a semi-fungible token template).

  • Contract interaction tool — A mini interaction tool similar to the one in the Stacks Explorer.

  • Test runner (experimental) — With a test directory present, tests can be run with one click; contracts are deployed and executed in simnet.

  • AI assistant — Currently running on a low-budget model; acknowledged as a work in progress.

  • Terminal — Projects sync to an online server where commands (e.g., clarinet check) run server-side, with logs streamed back to the frontend. Supports interactive terminal sessions. Limitation: devnet is not yet supported (requires Docker); implementation is in progress.

Presenter background:

  • ~2 years working with Clarity; building the IDE since September of last year.

  • Inspiration came from Remix IDE — the ability for JavaScript/TypeScript developers to start writing Solidity in the browser without local setup friction.

Planned features:

  • Interactive playgrounds with guided learning for developers new to Clarity smart contracts.

  • Improved AI implementation for debugging, deployments, and code generation (plans to integrate Claude and Gemini).

  • Bring-your-own-API-key support via settings.

  • Git/GitHub integration — connect a repository to the IDE, make commits and pull requests.

  • A minimal package to stream local projects to the web IDE and sync changes back.

2. Group Feedback & Discussion

Hugo C:

  • Serious projects eventually require local tooling (Git, Docker — industry standards). Asked about plans for Git/versioning integration.

  • Suggested bring-your-own-key support, since developers use different LLM harnesses (Claude, Gemini, Codex, locally hosted agents).

  • Emphasized avoiding user lock-in: developers need assurance they own their code and can exit at any point — GitHub integration is key to trust. @hugo-stacks

Radu Bahmata:

  • Main friction point of a browser IDE: maintaining the backend and vetting all installed packages (Docker, Rust compilation, etc.). Solving this would put the project ahead of the curve.

  • Seconded bring-your-own-key as a differentiator.

  • Noted a unique browser benefit: working on contracts from mobile, especially with Xverse and Leather mobile apps supporting wallet connections. @BowTiedRadone

Brice Dobry:

  • Hiro experimented with a web IDE and had trouble generating interest.

  • Web IDEs are valuable for quickly inspecting and testing another project without pulling it locally; most developers eventually want to work locally on their own projects.

  • Key challenge: identifying the target audience and which features matter to that segment vs. features that matter to local-development users.

  • Complimented the strong foundation and quality of the work. @brice

Rapha:

  • Sees a target segment in “vibe coders” who don’t know Clarity but build via tools like Lovable and Replit — those services have GitHub attached, reinforcing the case for GitHub integration and an exit path.

  • Shared his own workflow: building in a sandbox with AI, SSH access, linked to GitHub. Noted ~10–15 vibe coders from his Pillar Wallets (smart-wallets-as-a-service) iteration who could experiment with simple contracts (e.g., audit trails on Stacks via smart wallets).

  • Suggested a code-discovery angle for experienced developers and recommended connecting with @friedger , who runs sourceofclarity.com indexing deployed Stacks code.

  • Advice: talk to users across segments to identify what they desperately need and iterate faster.

3. Office Hours

Rendezvous fuzz testing win (Rapha):

  • Using Rendezvous (RV) fuzz testing alongside Clarinet, Rapha found an edge case in an order-book-style contract for MiamiCoin: a uint at/near its maximum value entered as an offer would have broken the mechanism — no one could have taken the offer as quoted, though no funds would have been stranded in the contract.

  • Takeaway: strong endorsement of fuzz testing (and AI-assisted auditing) for hardening code before mainnet deployment.

  • Radu proposed adding it to the Rendezvous “trophy case” in the README — Rapha to open a PR (or share context for Radu to open one).

AI model discussion:

  • Rapha: long-time Claude user; moved from Opus to Fable. Fable consumes roughly 25–50% more tokens (per measurements from a peer at AIBTC) but is noticeably smoother — “coding at a level that is almost human.” Sees this accelerating the vibe-coder-to-developer path.

  • Radu: finds Fable’s guardrails restrictive for security-related use cases (e.g., property-based testing), falling back to Opus 4.8 — acknowledged the rationale (bug-finding capabilities could be exploited) but finds it frustrating. Codex feels productive/fast but lacks OAuth token support, blocking automated CI usage outside business plans. Interested in trying GLM, though it’s less smooth than mainstream options.

  • Rapha: next step is testing local models and privacy tools (e.g., Venice); concerned his current workflow “leaks a lot.”

  • Radu: local models are the long-term direction, but hardware costs (~$15k for decent performance) remain a barrier; usage pricing may rise.

4. Newcomer Onboarding & Resources

  • Newcomers directed to the official Stacks Discord: the pick-interest channel grants access to builder/developer channels where the group is active — no need to DM.

  • Rapha mentioned Stacks Endowment/Foundation programs — Foundry for Builders is evolving into a new program with grants and other resources.

5. Closing

  • Next CWG session in two weeks. Anyone interested in presenting a demo or Clarity-focused topic should DM Rapha.

  • Thanks to LabSTX for the presentation and to the tool builders present.

  • “Stay positive, keep building — we need more builders.”

:hammer_and_wrench: Clarity Working Group — Office Hours Today, Tuesday July 21 · 9:00–9:30 AM ET Same calendar event, same link.

No formal deck this time — it’s open office hours. Come hang with the Clarity community and bring whatever you’re working on, stuck on, or curious about. Newcomers very welcome: you don’t need a question prepared to show up.

If we’re lucky, maybe a pox-5 peek from Brice. No promises, and no pressure on him — if it’s not ready, it’s not ready.

If the room is quiet, a few things I’m happy to open up:

:one: Stacks 4.0 & pox-5 — what actually changes for a signer. New bond/signer model, no more delegate-stx, and what that means if you’re running (or planning to run) a signer.

:two: Jing RFQ is live on mainnet. Two-phase RFQ swaps with market makers hedging on CEXs. Happy to walk through the contract design — native oracle, price band, the fix-price vs fulfill split — and show a swap end to end.

:three: Bitcoin CLO as pristine collateral. More thought experiment than product: what it would take to structure Bitcoin-backed credit on Stacks, and which primitives are missing today.

Pick whichever you want — or ignore all three and bring your own topic. That’s the better outcome.

:alarm_clock: See you at 9 ET sharp. We keep it to 30 minutes.

:speech_balloon: Want to present a demo or a Clarity topic at a future session? DM me.

:hammer_and_wrench: Clarity Working Group — Session Minutes Tuesday, July 21, 2026 · 9:00–9:30 AM ET

Summer edition — small room, no deck, open format. Attendees included Rapha, Brice Dobry, Hugo, and Radu. Short and dense anyway. Here’s what was covered:

:one: pox-5 transition — the timeline that matters

Brice walked through the pox-4 → pox-5 handoff, centered on Epoch 4 activation targeting July 29 (~block 959,006):

  • Block 960,230 — pox-4 stakes auto-unlock at epoch activation, but rewards keep accruing through the end of cycle 140 as if still locked

  • Block 962,050 — prepare phase for cycle 141 begins. This is the deadline to re-lock into pox-5

  • Cycle 141 — first pox-5 cycle: STX-only staking, no BTC bonds. You can specify up to 96 cycles but unstake at each cycle end

  • Cycle 142 — BTC bonds go live, with a 6-month lockup commitment

:warning: TL;DR for stackers: you unlock automatically, you don’t miss cycle 140 rewards, but you must re-lock into pox-5 during cycle 140’s reward phase — before the prepare phase starts.

:two: Infra & upgrades

  • Signers and nodes must upgrade before the hard fork. Signer 4.0.1 adoption is already strong (visible on slotwatch.dev). Rapha confirmed a smooth upgrade on his signer.

  • API nodes require a full resync from genesis or archive — epoch 4 adds new event fields, so this is a fresh sync, not a patch. Plan accordingly if you run infra apps depend on.

:three: Second layer & indexing

Rapha is self-hosting Ryan’s second-layer library on a Stacks node — think Chainhooks v2: parsed contract events pushed to a backend, simplifying indexing workflows. Ryan will be invited to present it at a future session.

:four: Ecosystem updates

  • Jing RFQ large swap facility is live — two-phase RFQ swaps with market makers hedging on CEXs

  • Rapha shared exploratory research on Bitcoin-collateralized fixed-rate lending models as a comparison point to variable-rate DeFi lending — thought experiment stage, no product decisions

:white_check_mark: Action items

  • Brice — clearer docs + community comms on the pox-5 transition and staking process

  • Rapha — follow up with Ryan re: presenting the second-layer library

  • Everyone running infra — upgrade signers/nodes before block 960,230; re-lock into pox-5 before cycle 141’s prepare phase at 962,050.

Next session: same time, same link. Want to demo or present a Clarity topic? DM me.

Stacks 4.0 epoch start (bitcoin block 960230) is 1223 blocks away.

https://slotwatch.dev/signers

:hammer_and_wrench: Clarity Working Group — Next Session

:date: Tuesday, August 4 · 9:00–9:30 AM ET Same calendar event, same link.

This time we have a presenter in slot 1 — and he told me “put me in coach, I’m ready to play.” So we’re putting him in.

:one: Second Layer — indexing without the pain (Ryan Waits)

Ryan will present his second-layer library: think Chainhooks v2. Parsed contract events pushed straight to your backend, simplifying indexing workflows for Stacks apps.

I’ve been self-hosting it on a Stacks node for the past few weeks, and it now powers most of the event indexing behind my apps — swaps, liquidity events, NFT marketplace activity. If you run infra or maintain an indexer, this one is for you.

Ever fought with chainhooks, missed events, or reorgs? Bring your questions.

:two: Open floor — whatever time is left goes to office hours. Bring what you’re working on, stuck on, or curious about. Newcomers welcome, no question required.

:alarm_clock: See you at 9 ET sharp. We keep it to 30 minutes.

:speech_balloon: Want to present a demo or a Clarity topic at a future session? DM me.

Please find attached minutes from session 6. Thank you and happy Tuesday everyone!

Clarity Working Group — August 4, 2026

TL;DR

  • Wallet security — two-factor signing (wallet key + passkey) with configurable cooldowns blocks fast unauthorized withdrawals; recovery path handles long inactivity.

  • pox-5 post conditions — staking moves tokens, pox-5 updates unlock params. Avoid unsafe post conditions.

  • Signer manager — batch reward distribution cuts gas, stays non-custodial, makes fee policy explicit.

  • sBTC bridge — BTC rewards bridged to sBTC. ~1% fees today from bridging UTXOs individually; optimization in progress.

  • Edge cases — Xverse contract drops the withdrawal ID; fallback accounting in the signer manager recovers locked sBTC from failed withdrawals.

  • Epoch 4 — activated smoothly. Clarity WASM work resumed.


Wallet security and recovery

Two-factor signing + cooldowns (00:06) Requiring both wallet signing (Leather/Xverse) and a passkey adds a 2FA layer. Cooldowns are configurable and delay withdrawals above a set threshold — e.g. two weeks, giving you time to react if a key is compromised. If suspicious activity shows up, you can transfer wallet ownership and cut the attacker out.

Recovery for inactive wallets (01:21) Friedger Müffke originally built the recovery mechanism; Rapha is testing it now. Owners can regain control after a year of inactivity, which mitigates key loss.

Slow on-chain operations by design (02:36) Rapha: chain operations shouldn’t be as instant as a bank account, because you can’t revert them. Slower is the point — it buys detection and response time.

pox-5 contract and staking mechanics

Staking vs. pox-5 post conditions (04:33) Brice Dobry: staking post conditions carry amounts for token movement; pox-5 post conditions cover parameter changes — unlock time, signer manager updates. Rapha confirmed pox-5 changes don’t move assets immediately, they update unlocking params and trigger unlock events after the cycle completes.

Correct usage (07:04, 08:48)

  • Locking sBTC → standard FT post conditions, since tokens actually transfer into the pox-5 contract.

  • Unstaking → no immediate token movement. The pox-5 post condition must pass for unstake, bond registration, and early exit.

Unsafe post conditions (13:25) Brice advised against broad use of “unsafe” post conditions even though pox-5 is a trusted contract — the risk is accidental vulnerabilities.

Hard forks and STX unlocking (15:06) Unlocking behavior at fork time is controlled by stacks-core, not contract code. pox contracts deactivate, new ones activate, and all STX unlocks per the core team’s decision.

Signer manager and yield distribution

Batch reward distribution (09:55) Rapha built a manager that accounts for rewards at the manager contract and distributes to many stackers at once, cutting gas. Signers stay non-custodial and transparent.

FastPool’s signer manager guide (11:56) Cited as a good resource for standardizing signer policies — shows how different managers operate and enforce fee policy (max fee caps, OG user exemptions).

Non-custodial as the actual user benefit (31:15) Users want hands-free, trustless claiming with a clear fee policy. The design avoids custodial control and lets users pick a manager on fee transparency.

Tranches and reward cycles (26:28, 30:57) pox-5 uses two tranches per cycle; if no call is made, it falls through to the next tranche. Stacker Labs plans to automate the reward calculation call so payouts don’t depend on user action.

Cost vs. usability (34:55) Experimentation continues on batch claims and contract calls. Brice noted stacks-core caching already removes redundant work, but changing the cost model needs a consensus upgrade.

sBTC bridge and BTC reward distribution

How it works (28:38, 29:23) BTC rewards are bridged and converted to sBTC through a Taproot address into the pox-5 contract. Anyone can call calculate-rewards on pox-5 to distribute sBTC among signers, twice per cycle.

Fees today (33:29) ~1%, because the bridge currently bridges multiple UTXOs individually. Dan from the core team has worked on optimizing this — worth getting him into a future session.

PlanBetter’s approach (23:10, 23:43) Pays out BTC every two cycles and takes 100% fees, then redistributes to pool operators. Bypasses contract-controlled distribution — relies on off-chain conversion and operator trust.

Minimum claim amounts (25:08) Some signer manager contracts set a contract-level minimum. Rewards below it fail and roll into future cycles, avoiding small-claim inefficiency.

Contract variants and edge cases

Xverse contract drops the withdrawal request ID (18:29, 22:16) Friedger: this discourages BTC reward claims without fully preventing them — rewards are still received. Brice: the withdrawal ID is needed to reclaim a failed withdrawal, but it can be pulled from events or debugger tools.

Failed sBTC withdrawals (20:53, 21:30) Failed withdrawals can lock funds. Rapha and Friedger confirmed fallback accounting in the signer manager contract allows reclaiming the locked sBTC.

97 cycles in test (16:11, 16:44) Incrementing staking cycles beyond 96 was observed in the test environment. Brice to check whether that’s valid or a test artifact.

Epoch 4 and Clarity WASM

Epoch 4 activated smoothly (02:55) Brice led the activation. Next real test is the prepare phase for the upcoming cycle, ~7 days out.

Clarity WASM resumed (03:49) Brice is rejoining the Clarity team to push the implementation toward completion and broader use.

General confidence in the transition (17:01, 42:02) Rapha is looking to deploy the new wallet security features in production.


Action items

Brice Dobry

  • Verify the limit on staking cycle increments beyond 96 in pox-5, and follow up on the test environment inconsistency.

  • Confirm withdrawal ID handling in pox contracts; coordinate with Ken (or the relevant lead) on the Xverse contract changes affecting BTC reward support.

  • Consider inviting Dan from the core team to cover sBTC bridge mechanics and reward bridging optimization.

Friedger Müffke + Brice Dobry

  • Monitor performance impact of batch contract calls; consider hard fork timing for contract call cost changes.

Rapha

  • Continue testing and deploying user staking safes with the new recovery and cooldown features.

Where can you stake your STX? https://signer-guide.fastpool.org/

As discussed, please find below minutes from session 7. Thank you everyone for joining. Wishing you a happy Tuesday everyone. @brice @hugo-stacks @friedger @setzeus

Clarity Working Group — Session 7

Date: August 18, 2026 · 9:00 AM ET Attendees: Rapha (host), Brice Dobry, Hugo Caillard, Friedger Müffke, Jesus Najera (SetZeus) Format: Open office, no fixed agenda


TL;DR

  • Clarity has no autonomous execution — every action needs an externally initiated transaction. Keeper + flag is the working pattern.

  • Bitcoin bonds deployment is friction-heavy: address translation across networks, whitelisted contract names, no clean sBTC→user allocation.

  • Node reliability work in progress: tighter signer timeouts, faster recovery, new setup tooling. Network health 98.2% with 24 signers.

  • Coldcard incident moved multisig from nice-to-have to need-to-have. CoFund out of stealth.

  • Two known Clarinet/Clarity gaps confirmed: pox-5 simnet locking, and contract constants breaking read-only contract-call?.


1. Clarity execution & triggering

Confirmed: Clarity contracts require external triggers. No action happens on chain without a signed transaction, and the initiator pays the fee.

  • Write the function so anyone can call it, then run a keeper service that watches conditions and fires the call (e.g. every block, or on a specific event).

  • Arkadiko and others have run this pattern in production.

  • Recommended design: contract holds a flag; the keeper triggers, but the contract enforces whether the action is permitted as a function of that flag. Monitoring stays off-chain, state changes stay on-chain and verifiable.

Use case discussed: a treasury deposits liquidity into the Jing maker model seeking better execution than an instant AMM fill. If the book doesn’t absorb it, a keeper recalls the liquidity and crosses it through the Bitflow AMM on the depositor’s behalf.

2. Bitcoin bonds & sBTC bridging

Deployment friction (Friedger): contracts written in simnet must be renamed and re-addressed for testnet and mainnet — testnet requires whitelisted bond contract names, and sBTC addresses differ. Currently handled with a separate testnet Clarinet.toml plus a script that rewrites addresses in the contracts.

Hugo: Clarinet already maps the mainnet sBTC address to its testnet counterpart in the deployment plan, so manual replacement shouldn’t be necessary — but the testnet address changed after the reset and needs updating. Mapping should be extended to all boot/known contracts, not just sBTC.

sBTC allocation problem: when bridged sBTC arrives directly in a pool contract, there is no on-chain binding between the depositing Bitcoin address and the recipient Stacks address.

Current workaround: user builds the BTC transaction → announces the salted hash of the txid → reveals it so no one else can claim → broadcasts → waits for the bridge → anyone can then confirm the sweep, and the balance is allocated to the first announcer. Functional, but poor UX.

Cleaner path discussed: encode the Stacks address in OP_RETURN and have the bridge propagate that metadata into the sweep transaction. This is close to what the existing btc2sbtc flow does; a deposit through it was confirmed working the day before the call.

Governance: Friedger has placed the signer-manager operator role behind a DAO, so pool members vote on updates rather than a single operator holding the key.

Audits: AIBTC bounty program recommended — low cost, multiple agents on the same repo, and it surfaced one real issue plus a second finding that prompted a further improvement.

3. Node reliability & tooling

  • Brice is tightening signer communication timeouts and recovery paths to reduce instability from occasional timeouts.

  • Stacks Labs has a node setup tool in progress — one-stop config and validation — plus documentation improvements. Running a node yourself has been under-documented.

  • Network health at the time of the call: 98.2%, 24 signers.

4. Clarity / Clarinet issues

pox-5 locking in simnet: stack-stx returns success but the lock isn’t reflected in the STX account. Likely cause is declaring pox-5 as a requirement instead of using the already-deployed boot contract. Proposed fix: remove it from requirements. Clarinet should probably reject boot contracts as requirements outright.

Contract principals as constants: defining a contract principal as a constant breaks contract-call? resolution in read-only functions. This blocks the clean pattern of one constant swapped per network, or an is-mainnet branch assigning the value. Acknowledged as a known pain point, not yet prioritized.

5. Multisig & CoFund (SetZeus)

CoFund is out of stealth after years in development. The Coldcard incident was the forcing function — it punished self-custody specifically, and shifted multisig from nice-to-have to need-to-have. Conversations that were uphill before are now inbound.

  • Goal: make multisig usable by non-technical users, with normal consumer-app actions (DeFi, payments, swaps) available from inside the multisig.

  • Protocol covers UTXO chains and smart contract chains; the Clarity design was the original smart-contract implementation.

  • Caveat: the overcorrection risk is real. An 8-of-8 is more brittle than a 1-of-1 with no passphrase and should not be used. Balance threshold, signer count, and recoverability.

  • Current demand is mostly cold storage and vaulting.

  • Also active on BIP-110 and Bitcoin Core. Currently integrating Robinhood Chain for tokenized equities — businesses holding BTC and stables want equity exposure in the same place.

6. Oracles on Stacks

Pyth is moving to paid API keys. As of today, teams pulling Hermes VAAs from their backend need a $500/month subscription. Access was previously covered by an ecosystem-wide subsidy; that arrangement is ending, so the cost now sits with individual teams. This hits smaller teams hardest and turns a shared infrastructure line into a per-team recurring cost.

A second option may be in the works for teams — no details confirmed on the call.

DIA is a credible alternative. Hugo to share an internal builders’ document covering the DIA integration.

Editor’s note: this argues for oracle-provider resilience at the design level rather than a hard-wired feed. Because contract-call? can’t dispatch on a stored principal (see §4), the practical pattern is a trait parameter validated against a governance-controlled allowlist — the provider becomes a config change rather than a redeploy. Single-provider dependency is a cost risk and a liveness risk at once.


Action items

Owner Item
Friedger Open a Clarinet issue for multi-network deployment (address translation + contract name whitelisting across simnet/testnet/mainnet)
Hugo Share the internal builders’ doc on the DIA oracle via Discord; update the testnet sBTC address mapping in the deployment plan
Brice Follow up with the sBTC team on bridging directly into contracts with sender→recipient binding
Stacks Labs Continue node setup tooling, docs, and signer timeout/recovery work
Clarity team Address the constant-as-contract-principal limitation in read-only functions
Rapha Test pox-5 simnet locking with pox-5 removed from requirements, report back on the open issue

Next session same time. Open to agenda items — reply here or ping in Discord.

Clarity Working Group – September 1, 2026 (async edition)

Good morning frens. I missed this morning’s session and I apologize to the group. Rather than skip the cadence, here is an async update compiled from the builders directly.

TL;DR

  • BTC bonds have their inaugural activation in a few days. This is the moment pox-5 was built for: miners commit BTC, stakers lock BTC on L1, and the protocol sells its emission for Bitcoin.
  • Teams are lining up sBTC staking products on top of it: native staking with Friedger’s Esbee DAO, and liquid staking with stBTC at StackingDAO.
  • Friedger has been working on formal verification of the Esbee DAO code using Jude’s tool.
  • On my side: USDCx bridge integration straight into passkey smart wallets, faster 2FA activation via a central registry, and hybrid execution on Jing.
  • Updates from Brice (Clarity WASM) and Hugo (Clarinet) to follow in this thread.

1. BTC bonds – inaugural activation

This is the big one. BTC bonds go live on pox-5, likely in cycle 143, with the 6-month lockup commitment we walked through in the July 21 session. Activation is days away.

Why it matters: it changes what stacking is. Miners commit BTC, stakers lock BTC on L1 and earn on sBTC, signers sign, and the yield flows on-chain through the pox-5 contract rather than through off-chain operator trust. If you run a signer or a pool, the FastPool signer manager guide remains the best reference for standardizing your policies before bonds go live.

2. sBTC staking products lining up

Two distinct approaches are shipping on top of pox-5:

  • Native staking – Esbee DAO (Friedger). Stake sBTC directly, non-custodial, with the recovery features we covered in the August 4 session (two-factor signing, cooldowns, inactivity recovery).
  • Liquid staking – stBTC (StackingDAO). An LST wrapper: stake sBTC, receive a liquid token, keep composability with the rest of DeFi.

Different trust and liquidity trade-offs. Both are healthy for the ecosystem.

3. Formal verification of Esbee DAO

From Friedger: he has been working on formal verification of the code with Jude’s tool. This goes beyond unit tests and fuzzing, proving properties of the contract rather than sampling them. For a contract that will hold staked sBTC, this is exactly the standard we want to normalize.

[Friedger is writing a fuller update. I will quote it here or link it when it lands.]

4. On my side – onramps, wallet security, and Jing execution

Three things shipped or in flight:

  • One-click onramp to a smart wallet. I integrated Stacks Labs’ USDCx bridge and combined it with an automatic USDCx to sBTC swap. The result: a user bridges USDC from Ethereum and receives sBTC directly in their passkey Clarity smart wallet on faktory.fun. No intermediate wallet, no manual swap step. First live bridges have gone through.
  • Central registry for faster 2FA activation. The passkey smart wallets now verify against a central on-chain registry, which lets users activate two-factor signing (wallet key + passkey) much faster. This builds on the security model we covered in the August 4 session: 2FA, configurable cooldowns, and recovery for inactive wallets.
  • Jing hybrid execution – walk the offers. New matching model for Jing: hybrid pricing around mid, and when a swap goes out of range it walks the standing offers at their limit prices instead of failing or slipping blindly. Makers get filled at the prices they posted; takers get best available execution across the book.

5. Clarity WASM

[Placeholder – Brice’s update on where the WASM implementation stands since he rejoined the Clarity team. Will edit in.]

6. Clarinet

[Placeholder – Hugo’s update on where his head is at with Clarinet. Will edit in.]

Next session

Tuesday, September 15, 9:00–9:30 AM ET, same calendar event, same link. If BTC bonds have activated by then, we will do a proper post-mortem of the inaugural cycle: what worked, what surprised us, what the yield actually looked like.

Want to demo or present a Clarity topic? DM me. See you on the 15th. Exciting times.