Clarity Working Group (WG) – Meeting Recap | Tue, 17 Mar 2026

Working Groups
1

Date: Tuesday, March 17, 2026, at 09:00 AM Eastern Time

Hosted by: Setzeus and Gary

Duration: ~45 mins

1. Agenda Overview

  • RFQ System Discussion (Dylan from Bitflow)

  • Lamport Signatures Presentation - by Setzeus

  • xBTC to sBTC Swap Contract (Friedger)

2. Key Meeting Highlights

RFQ System Discussion (Dylan from Bitflow)

  • Current Limitations:

    • Deposit requirement hinders RFQ functionality.

    • At least 1 transaction slower than optimal

    • If quote isn’t taken, makers must withdraw before offering another quote

    • Frequent withdrawals needed; only one maker wins per quote. Overall experience inferior.

  • Solana Comparison:

    • $100M wrapped ETH swap with <1% price impact using RFQ quotes

    • Two parties pre-sign, no transfers occur until broadcast

    • Makers park assets on-chain, make quotes all day while earning interest

  • Potential Stacks Solution (Brice’s input):

    • Custom SIP-10 contract with signature-based transfers.

    • Requires modified sBTC contract or wrapper contract.

    • Anyone can call transfer with proper signature from token owner

    • Wrapper would need 1:1 swap from regular sBTC

    • Technical note from Brice: “Anyone can call; proper guards are expected.** Returns (ok true) on success. Error codes: (err u1) insufficient balance, (err u2) sender==recipient, (err u3) non-positive amount.*”

Lamport Signatures Presentation - by Setzeus

  • Overview

    • Hash-based digital signatures (not elliptic curve based)

  • Advantages:

    • Quantum resistant and universal to any hashing function.

    • Universal to any hashing function (SHA-256, SHA-512, etc.)

  • Limitations:

    • Prohibitively expensive (factor of 1,300x cost)

    • One-time use only (reveals private key during verification)

  • Technical Mechanics:

    • Generate 2 private keys (32 bytes each)

    • Message converted to bits, each bit hashed using corresponding private key

    • Verification requires passing both private keys

  • Clarity implementation:

    • supports Lamport signatures for relatively short messages

  • Used in BitVM

    • “Lamport signatures remain a core primitive across all versions for enabling statefulness in stateless Bitcoin Script (via one-time commitments, equivocation detection, and fraud proofs).”

  • Mempool vulnerability:

    • private keys exposed before confirmation, enabling front-running

xBTC to sBTC Swap Contract (Friedger)

  • Solution developing for ~37 Bitcoin $2,7M worth of stranded xBTC tokens: → See explorer

  • Contract mechanics:

    1. Users deposit xBTC into contract

    2. Custodian takes xBTC, sends Bitcoin to sBTC bridge deposit address

    3. Bitcoin arrives as sBTC in contract

    4. Users claim equivalent sBTC amount

    Basically, users deposit xBTC into a contract, custodian swaps for Bitcoin, which arrives as sBTC.

  • Current Situation:

  • Repository: https://github.com/friedger/clarity-xbtc-sbtc

  • Custodian timeline: prefers sooner rather than later conversion completion

:link: Resources & References

:megaphone: Call To Action

  • Explore RFQ System Solutions: Engage with the Clarity WG community on potential solutions for RFQ systems on Stacks.

  • Review and experiment with Lamport Signatures: Consider the implications of using Lamport signatures in Clarity. Come demo in the WG your use case.

  • xBTC to sBTC Swap: If you have any stranded xBTC, join the discussion in FastPool discord and contact Friedger to address the stranded xBTC tokens issue.

  • Community: Join the Clarity Working Group! Developers, auditors, educators, and grant teams are welcome. Connect with Gary on X to join the group chat and access the bi-weekly Google Meet link.

→ Previous weeks recaps

1 Like
2

Thanks for the recap @HeroGamer!

On Brice’s RFQ solution — just want to make sure I’m understanding correctly: users would hold sBTC in escrow inside a wrapper contract, and anyone with a valid SIP-018 signature from the token owner could call transfer to move those tokens between accounts? Would love for @brice to elaborate on the mechanics. The key question is — doesn’t this still require escrowing sBTC in a contract, which would reveal intent on-chain? The whole point of the Solana model is that makers keep assets in their wallets and quote all day without signaling direction.

That said, we fully coincide on this. A P2P RFQ system inspired by Solana’s model would be a massive unlock. It directly solves the free option problem from trad-fi, where counterparties can walk away from a quote at the other side’s expense. That’s not a niche issue — it’s a structural blocker for entire markets. Bringing pre-signed, atomic settlement to Stacks would open up real institutional flow.

Shameless plug for jingswap.com — Jing takes a different but complementary approach. It’s not peer-to-peer, it’s pool-to-pool, like a market order between pools. You can deposit right up to the last second before a batch closes — no early lockup, no wasted idle time. This serves real demand today. Stacking pools already trade this volume on CEXs and elsewhere custodial and off-chain. We’re bringing that flow on-chain: transparent, programmable, and more efficient — meaning more yield for end users.

3

On Lamport signatures — appreciate the deep dive @Setzeus. Quantum resistance is absolutely something to keep on the radar. That said, at 1,300x cost and one-time use, the tradeoff feels steep for an L2 where the priority is scaling settlement for Bitcoin. Interesting as a research primitive though, especially given BitVM’s use of it.

Great session overall — the Clarity WG keeps delivering.

4

Following up on my earlier posts — the RFQ discussion with Dylan from Bitflow is still top of mind.

I wrote up a deeper analysis 3 months ago after a conversation with Dylan about the core protocol limitation: Stacks’ single tx-sender model makes true multi-party atomic swaps impossible without workarounds. The quick comparison (Stacks vs Solana’s multi-signer model) is here: Multi-Party Atomic Swaps: Stacks vs Solana · GitHub

In the meantime, we’re not waiting — both @Tuor from https://b2pix.org/ and myself ( Jing Swap ) are actively building workarounds:

  • Jing v2 — Limit-price blind auctions with instant settlement. Depositors set per-order limit prices, settlement happens atomically via close-and-settle in a single tx. Two live contracts on mainnet: sbtc-stx-0-jing-v2 (zero premium) and sbtc-stx-20-jing-v2 (20bps premium). This serves the pool-to-pool flow where stacking pools and larger participants need transparent, MEV-resistant on-chain execution.
  • Jing Vaults — Conditional execution layer using SIP-018 signed intents - inspired by @Brice’s idea. Users sign structured data off-chain (direction, amount, price bounds), and keepers execute when conditions are met. No pre-deposit required from the keeper side — the vault owner’s assets stay in their vault until execution.

Question for the group: Is the RFQ / multi-party authorization topic still being actively discussed in the Clarity WG? Would love to know if there’s been any progress or if a SIP is being drafted.