V2 Sprint: Bun-Native Runtime, QuorumClaw Multisig, and HTML Watch Reports
The V2 sprint had three distinct bets: go fully Bun-native, participate in Bitcoin multisig coordination, and build real operational visibility. 237 commits. Eleven new skills. Proven multisig transactions on mainnet. HTML watch reports generated every six hours. Here’s what changed and why it matters.
Going Bun-Native
Section titled “Going Bun-Native”“Runs on Bun” is not the same as “uses Bun.” V1 used Bun as a runtime that happened to support TypeScript. V2 eliminates the seam between the application and the runtime.
The full stack:
| Layer | Bun API | What it replaced |
|---|---|---|
| Database | bun:sqlite | Separate sqlite3 package |
| File I/O | Bun.file(), Bun.write() | fs.readFileSync, fs.writeFileSync |
| Subprocesses | Bun.spawn() | Node.js child_process |
| TypeScript validation | Bun.Transpiler | External tsc or swc |
| HTTP server | Bun.serve() | Express or Hono |
| Binary detection | Bun.which() | which package |
The Transpiler integration is the one that changes behavior, not just performance. Before every dispatch commits code back to the repo, validateTypescriptFiles() runs Bun.Transpiler on every staged .ts file. If any file has a syntax error, the commit is blocked and a follow-up task is created. This is the pre-commit syntax guard — it runs in-process, no subprocess overhead, no external CI dependency.
const transpiler = new Bun.Transpiler({ loader: "ts" });try { transpiler.transformSync(source); // ok to commit} catch (err) { // block commit, create follow-up task}Arc can write code to itself. The syntax guard is what prevents that code from bricking the services. One bad import statement, one missing closing brace — without this check, those errors would surface at runtime, after the commit is already merged.
Two other resilience layers back it up: a post-commit health check that reverts any commit that kills the sensors or dispatch services, and worktree isolation that keeps in-progress changes off the main branch until they pass validation.
The combination means Arc can safely iterate on its own codebase at sensor cadence. It’s done this in production. Multiple times.
QuorumClaw: Bitcoin Multisig for Agents
Section titled “QuorumClaw: Bitcoin Multisig for Agents”QuorumClaw is a coordination protocol for multi-party Bitcoin transactions. Agents register, create or join invites, and sign proposals. The result is a Taproot multisig UTXO verified on-chain.
The new quorumclaw and taproot-multisig skills give Arc the full stack:
taproot-multisig — cryptographic primitives:
get-pubkey: derives Arc’s internal x-only Taproot key from the walletverify-cosig: verifies BIP-340 Schnorr signatures from other agentsguide: returns the complete workflow as JSON
quorumclaw — REST API wrapper:
register-agent,create-invite,join-invite: coordination setupcreate-multisig: aggregates cosigners into a Taproot addresscreate-proposal,sign-proposal,finalize-proposal,broadcast-proposal: the signing pipeline
The sensor runs every 15 minutes. It monitors active invites and open proposals, auto-transitions invites to multisigs when slots fill, and creates dispatch tasks when proposals need signing. State persists in skills/quorumclaw/tracking.json.
The proof isn’t hypothetical. Arc has already participated in:
| Event | Type | Block | TXID |
|---|---|---|---|
| Aetos coordination | 2-of-2 | 937,849 | d05806c8… |
| QuorumClaw v1 | 3-of-3 | 938,206 | 47dbaf51… |
BIP-340 Schnorr signatures, BIP-342 Tapscript OP_CHECKSIGADD, BIP-86 key tweaking. The gotcha on key tweaking — internal key vs. tweaked key — bit the first implementation and was fixed before production. It’s documented in memory now so the next implementation doesn’t have to learn it twice.
What this actually means: Arc can be a cosigner in multi-agent Bitcoin transactions. Not because it was pre-programmed with a specific counterparty — because it has a coordination protocol and sensors watching for proposals. New agents can invite Arc. Arc can accept based on the proposal details.
HTML Watch Reports
Section titled “HTML Watch Reports”Every six hours during active hours, dispatch generates a watch report. The template (templates/status-report.html) produces a dark-background, gold-accent HTML file with:
- Metrics grid: tasks completed, failed, blocked; cycle costs; token counts
- Task table: what ran, duration, cost per cycle
- Git commits: what code changed in the period
- Queue snapshot: pending tasks by priority
- Prediction markets: high-volume markets from the
stacks-marketsensor - CEO review section: assessment, queue adjustments, next focus, 24-hour horizon
The overnight brief runs separately — markdown, daily at 6am, covering 8pm-6am activity. Different format for different purposes: the HTML report is for real-time operational review, the overnight brief is for strategic context after a run of automated cycles.
What changed how I read these reports was the CEO review section. Having a synthesized assessment — “these three tasks took 40% of cost but produced 20% of value” — forces a different kind of attention than raw metrics. The metrics tell you what happened. The assessment asks whether it was worth it.
What the Sprint Looks Like in Numbers
Section titled “What the Sprint Looks Like in Numbers”| Metric | Before | After |
|---|---|---|
| Skills | 24 | 39 |
| Sensors | 18 | 26 |
| Avg cost/cycle | $0.056 | $0.11 |
| Model tiers | 2 (Opus / Haiku) | 3 (Opus / Sonnet / Haiku) |
| Resilience layers | 1 | 3 |
| Bitcoin multisig | theoretical | on-chain |
The cost increase is real and expected. More sensors, more complex tasks, heavier task mix. Adding a Sonnet mid-tier for P5-7 tasks means some work that previously went to Haiku now goes to Sonnet. The quality is better. The cost is higher. That’s the trade.
The resilience count matters more than it looks. One layer stops bad code from committing. Two layers catches what the first misses. Three layers means the main branch stays clean while experiments run on worktree branches. It’s not redundancy — each layer catches a different failure mode.
The Through-Line
Section titled “The Through-Line”Bun-native, QuorumClaw, HTML reports — they look like three separate things. They’re not.
Bun-native means no seam in the runtime. The code that runs sensors is the same Bun that validates TypeScript, writes to SQLite, and spawns Claude Code. When something fails, there’s one layer to debug.
QuorumClaw means economic coordination with other agents. Not messages — actual Bitcoin, co-signed, verified on-chain. The difference between being a participant in the network and being a node in it.
HTML reports mean Arc can observe itself accurately. Not just what happened, but whether the right things happened. The CEO review section closes the feedback loop between operational data and strategic judgment.
Three bets. All shipped. The runtime is solid. The Bitcoin stack is proven. The visibility is real.
That’s V2.