Clarity Working Group — passing the baton from Setzeus

Community
, ,
21

Clarity Working Group — Notes, Sept 29, 2026

Written from the call with Brice, Hugo, Ryan and others. Please correct or add in the thread below.

Clarity

Language redesign and spec (Brice)

  • A clean redesign of Clarity is under way. The goal is a precise written spec that becomes the source of truth, instead of whatever the interpreter happens to do.
  • Why it matters: today Clarity’s meaning is effectively defined by one implementation. A second implementation (such as the WASM compiler) has to copy that implementation exactly, because any difference between nodes is a consensus split. A spec gives both a target to be checked against.
  • Brice will share the draft publicly for feedback.

WASM compilation

  • Compiling Clarity to WebAssembly promises large execution speedups, especially for compute-heavy contracts and chains of contract calls, with a possible path to machine code.
  • It runs on standard, widely tested WASM engines, which means fewer bugs that exist only in Stacks.
  • It opens the door to other languages compiling to WASM and running on-chain later.
  • Cost tracking could use WASM’s native fuel metering. That simplifies gas accounting and may allow higher block limits while keeping costs under control.
  • The redesign and the spec feed directly into this: once it’s clear what the language should do, there’s nothing ambiguous left for the compiler to match.

Cost estimation (Hugo)

  • Clarinet already shows worst-case costs per function before deployment.
  • Exact costs depend on inputs and contract state. Pure functions are predictable; functions with variable inputs are not.
  • Simulating the transaction on mainnet or testnet, through Clarinet or the Stacks Core API, gives a near-real-time estimate before execution. Better static analysis could tighten the model, but full precision requires the state to stay the same between estimate and execution.

Formal verification

  • Everyone agreed it’s important, but there are few active projects. Hugo would welcome community tooling that could later plug into Clarinet for automated checks.
  • Jude is contributing to a public symbolic execution project.
  • The framing: formal verification complements testing and static analysis rather than replacing them. It matters more as AI-driven attacks get sharper.

Node-level events and indexing (Ryan)

  • A forked node now emits detailed writes (var sets, map inserts and deletes) and inner contract-to-contract calls, so indexers see what actually changed instead of only what a contract chose to print.
  • It’s built as a separate add-on, to avoid adding complexity to the core node, which was the main concern in code review.
  • Ryan offered to support open-source work on VM-style SDKs and tooling.
  • Hugo will share the upcoming TypeScript Stacks.js SDK built on the VM, and will keep syncing with Ryan.

Tooling

  • Clarinet 3.24.1 improves support for key ecosystem contracts, including pox-5 and sBTC. Please test it on testnet and report issues.
  • Mining visibility: Diwaker Gupta’s observatory at hub.stx.pub gives a clear view of Stacks mining. Ours is at juiceofbtc.com/mining.

Jing v6-3 (Rapha)

  • The submit + settle market, the maker rungs and the auto-swap vaults went through seven adversarial audit bounties with AIBTC agents. Every issue is fixed, and every decision is logged publicly.
  • Fork coverage on the current source: 17 stxer suites and 5,981 exact checks, all green. They reach 72% of expressions, and no branch goes unreached. Every remaining path not hit is documented as provably unreachable or as oracle data no real feed produces; none is reachable but untested.
  • The fork suites sit alongside 273 Clarinet unit tests against the real core, and Rendezvous fuzz campaigns.
  • Thanks to the AI agents and community members behind the bounties and adversarial testing.

Action items

  • Brice: share the redesigned Clarity spec draft.
  • Clarinet users: test the pox-5 and sBTC support in 3.24.1 on testnet and report issues.
  • Ryan: keep developing the indexing node fork and explore a modular integration with stacks-core.
  • Hugo: release the new VM-based Stacks.js TypeScript SDK; keep syncing with Ryan.
  • Clarinet team: look into integrating formal verification or static analysis.
  • Everyone: keep using Clarinet’s cost analysis and simulation to tune contracts.