Clarity Working Group (WG) – Meeting Recap | Tue, 6 Jan 2026

Working Groups
1

Date: January 6, 2026 at 9:00am ET

Hosted by: Setzeus, Gary Riger

Duration: ~60 mins

Participants: Setzeus, Gary, BowtiedRadone, Hugo, Victor, Rv404, Brice, HeroG

1. Agenda Overview

  • Clarity V4 Check-in

  • CoFund Multisig Wallet Demo

  • X402 Payment Protocol Education

  • AI agents and deterministic crypto systems

2. Key Meeting Highlights

Clarity V4 Check-in

  • Current Status: No significant projects on the call have been built with Clarity V4 yet. Participants are still exploring new features, showing interest but limited hands-on experience. The group discussed the potential of Clarity V4 and encouraged more experimentation and development.

  • Rapha currently building around WebAuthn secp256r1

CoFund Multisig Wallet Demo (Setzeus)

  • Overview: Setzeus demonstrated an SMB wallet for businesses with multisig cross-chain functionality. The wallet features a dashboard for cash flow, asset distribution, and DeFi interactions, looking at Compound on Ethereum.

  • Technical Implementation:

    • State Contract: Stores all client data across helper contracts on the Stacks blockchain.

    • Wrapper Contracts: Use buffer bytes instructions for DeFi interactions, allowing for flexible and generic function calls.

    • Vault Contracts: Have two main functions: execute transaction (for DeFi wrapper calls)and execute transfer (for policy-based transfers) - Signature verification folds through a list of signers and signatures to ensure each signer is unique and each signature is valid

    • Signature Verification: Utilizes a fold through a list of signers and signatures to ensure each signer is unique and valid.

  • Security Considerations: A bug was identified on Solidity side where the same signer could submit multiple times to reach a threshold due to an unconsumed Auth ID, allowing transaction replay.

  • Current Status: Processing a couple of hundred thousand monthly through client vaults, indicating active use and growth.

  • Setzeus proposed to set up a signature workshop so that everyone here can see how you write a sign how you write a message how you verify it. Also to touch on secp256r1-verify.

X402 Payment Protocol Education (Gary)

  • Overview: Gary discussed the use of the HTTP 402 “Payment Required” status code for crypto payments, developed by Coinbase and implemented on Stacks for STX/sBTC. This enables instant automatic payments over HTTP without accounts or sessions.

  • Use Cases: The protocol supports API service payments, AI agents, paywalls for digital content, microservices, and microtransactions.

  • Payment Flow Process:

    1. Request access to API/content.

    2. Receive a 402 response with payment instructions.

    3. App reads cost, token, and recipient details.

    4. Prepare payment with amount, recipient, and unique ID.

    5. Wallet signs payment intent (no money moved yet).

    6. Facilitator verifies signature, amount, and recipient match.

    7. Facilitator broadcasts transaction to blockchain.

    8. Receive payment proof/receipt token.

    9. Retry API call with proof of payment.

    10. Access granted to requested content/service.

  • x402 on Stacks Implementation Status: Tony built the foundation, and Jason’s AI BTC Working Group is developing “full suite” of infrastructure on x402 for Stacks, including a reputation system for facilitator trust. An NPM package and dashboard are available, with cross-chain support in X402 v2 released by Coinbase in December.

AI agents and deterministic crypto systems

  • Setzeus raised concern that AI behavior is stochastic and unpredictable, whereas blockchains and smart contracts are strictly deterministic, and questioned how these can safely interact

  • Group clarified that the non-determinism is in how the AI chooses actions, not in how transactions are executed on-chain; the chain remains deterministic and only executes valid, rule-constrained transactions

  • Treat blockchains as deterministic “money and state” rails and AI as an off-chain “agent” that uses those rails as a tool

    • Give the AI access to a wallet (or sub-wallet) with explicit limits (balance caps, policies, multisig requirements)

    • The AI can decide which APIs or x402 endpoints to call or where to source data/content from, but the spending and permissions are constrained by on-chain policies

    • Examples discussed: an AI “employee” that can go fetch data or spend within a budget (e.g., “go get me $100” or “fetch 100 dog pictures”) using crypto rails as the native payment layer

  • Takeaway: safely combining AI + crypto means not making the chain stochastic, but letting AI make choices within a deterministic, policy-guarded on-chain environment

  • Further clarification with AI BTC Working Group.

Action Items / Next Steps

Topic Owner Next Step
Signature Verification Workshop Setzeus Scheduled for next WG session - January 20th

:link: Resources

:open_book: Call-To-Action

  • Developers: Explore and build with Clarity V4 features and participate in the upcoming signature verification workshop to enhance security practices.

  • 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.

  • Join “Signature Workshop” on Tuesday 20th January: Add to Calendar

→ Previous weeks recaps

1 Like
3

Great recap @HeroGamer - this was a solid read as I had to skip the session.

Kudos to @setzeus on the CoFund demo - I’ve had the chance to see it and it’s very polished work. On the auth ID bug you mentioned (same signer submitting multiple times to reach threshold due to unconsumed auth ID) - could you share a code snippet showing how this was handled?

This relates to @friedger 's smart wallet that we forked at pillarbtc.com - in our implementation we map signatures once consumed and assert-out on any signature that’s already been mapped, which should prevent that replay vector. Would be good to compare approaches.

@Setzeus - also curious about your thoughts on the contract-caller composability issue. I wrote up some thoughts here: Composability vs. Security: Rethinking contract-caller Restrictions in Stacks DeFi. TL;DR: strict contract-caller gating forces duplicated code across every integration rather than allowing shared extension contracts. Wondering if you’ve hit this friction with CoFund and how you’re thinking about it.

On the AI + deterministic systems discussion - worth noting there’s already working infrastructure here. The AIBTC working group contracts plus Friedger’s smart wallet (which Pillar forked) implement exactly this pattern: a “guardian” role that can only act within parameters enforced by the Clarity contract itself. The AI agent has autonomy in what actions to take, but the on-chain policy constrains how much it can spend or what operations are permitted. Similar concept to Bitflow’s keepers. The chain stays deterministic - you’re just giving an off-chain agent bounded access to those deterministic rails.

Looking forward to the signature workshop on the 20th.

1 Like