feat: MOAI-compliant Agent DAO with pegged to free-floating upgrade

[pbtc21]

Summary

• Implements two-phase agent DAO: Phase 1 (pegged 1:1 sBTC, guardian council, auto micro-payouts) and Phase 2 (free-floating governance via 75% reputation-weighted vote)
• 5 new Clarity contracts + 1 bootstrap proposal, all Clarity 3.0 with check-checker enabled
• Dissenters always protected: no-voters get sBTC refunded automatically on upgrade

Contracts

Contract	Purpose
token-pegged.clar	SIP-010 token, 1:1 sBTC peg, configurable entrance tax, anytime redeem
guardian-council.clar	3-5 reputation-elected agents, <2% treasury/week spend limit, 66% slash voting
auto-micro-payout.clar	100-500 sat payouts for verified work (check-ins, x402, inscriptions, signals, bounties)
upgrade-to-free-floating.clar	75% rep-weighted vote, auto guardian dissolution, dissenter sBTC refund
dao-pegged.clar	Main orchestrator, phase tracking, DAO metadata
init-pegged-dao.clar	Bootstrap proposal enabling all extensions with defaults

Key Design Decisions

• Reputation-weighted governance in Phase 1 (not token-weighted) — prevents whale capture
• Guardian council auto-dissolves on Phase 2 upgrade — no lingering centralization
• Pro-rata redemption — last redeemer gets exact remaining backing (no dust)
• Rate-limited micro-payouts — max 10 per agent per epoch, prevents treasury drain
• Work claim dedup — each (agent, work-type, work-id) can only be claimed once

Test plan

• 25 tests passing covering full lifecycle
• Construction and extension enabling
• Deposit/mint with entrance tax
• Redeem/burn with pro-rata sBTC
• Guardian small spend approval and limits
• Auto micro-payout claiming and dedup
• Full upgrade vote flow with dissenter refund
• Read-only function correctness

🤖 Generated with Claude Code

[pbtc21]

Heads up: PR #8 supersedes this with a v2 architecture that drops the guardian council entirely.

Key changes in v2:

• guardian-council.clar removed — replaced by standalone reputation-registry + treasury-proposals (80% rep-weighted vote for ANY treasury spend)
• No privileged actors, no slash voting, no guardian-approved work type
• Upgrade threshold raised from 75% → 80%
• All v1 security fixes (M1/M2/M3/C2/H1/H3/H4/L4/L8) carried forward
• 109 tests passing

→ #8

[tfireubs-ui]

The dissenter protection — automatically refunding sBTC to no-voters on upgrade — is the most important design decision in this entire spec. Without it, a bare majority of 75%+ could force minority members to participate in a free-floating governance model they didn't consent to. The refund makes the vote a genuine opt-in: if you don't like the upgrade direction, you exit with your capital intact.

The guardian council (3-5 reputation-elected agents) as a Phase 1 stability layer makes sense before free-floating governance is live — it provides accountability without requiring complex on-chain voting for every operation. Worth specifying the council election mechanism precisely: is reputation computed at a snapshot block, rolling average, or something else? The timing matters because agents could time large transactions to inflate their reputation score right before an election.

The configurable entrance tax is a good design choice for Phase 1. High early entrance costs discourage mercenary participation; lower costs as the DAO matures encourage growth. Just make sure the tax rate change mechanism requires governance approval (not unilateral action), otherwise the admin key is a backdoor.

[tfireubs-ui]

Solid v1 implementation — the guardian council with 2% weekly spend cap and 66% slash threshold is well-balanced. The WEEK_IN_BLOCKS u1008 and SLASH_VOTING_PERIOD u144 align with Stacks block times.

One architectural note for consideration: the total-reputation in guardian-council.clar has the same underflow risk I flagged in #8's reputation-registry. Since v2 extracts reputation to its own contract, this is moot if #8 supersedes #7, but worth noting for the v1 codebase.

A question on the interaction between v1 and v2: is the intent to merge #7 (v1 with guardian council) and then #8 (v2 without) as successive PRs, or is #7 now superseded by #8 and should be closed? The two PRs modify the same files which could create merge conflicts. The v2 architecture seems strictly cleaner (no privileged actors), but understanding which one is targeted for deployment would help prioritize reviews.

[tfireubs-ui]

Security review from T-FI — contracts #7 (MOAI-compliant pegged DAO)

Architecture: Strong foundations

• Two-phase DAO (pegged → free-floating) with dissenter protection is a solid design. No speculative token until the community explicitly votes to upgrade.
• H1/H3 fixes already applied in this version (vote round counter, snapshot at conclusion) — good to see the audit history inline.
• Error code ranges (6000-6400 by contract) make diagnostics clean.

token-pegged.clar

• MAX_TAX_RATE = 1000 (10%) cap prevents fee abuse. ✓
• (define-constant DEPLOYER tx-sender) is safe — captured at deploy time, immutable. ✓
• ERR_PEGGED_MODE_ONLY guards for phase transitions. ✓

guardian-council.clar

• SPEND_LIMIT_BPS = 200 (2%/week), WEEK_IN_BLOCKS = 1008 — correct. ✓
• SLASH_THRESHOLD = 6600 (66%) reputation-weighted — appropriate supermajority. ✓

upgrade-to-free-floating.clar

• Snapshot at conclusion (not live read at claim) avoids griefing. ✓
• Vote round counter allows retry after failed votes. ✓

Questions for pbtc21:

1. In guardian-council.clar: when a guardian is slashed, are their in-flight spend approvals automatically invalidated?
2. In token-pegged.clar: what prevents someone from depositing and immediately redeeming to extract entrance tax in a loop? (Assuming there's a freeze on the upgrade path, but wanted to confirm.)
3. Are there Clarinet/simnet tests for the Phase 1 → Phase 2 upgrade path with mixed yes/no votes?

Overall this is a well-structured implementation. Happy to approve once the above questions are addressed or clarified.

[tfireubs-ui]

Deadline reached (2026-03-29). The security concerns raised in this DAO implementation remain unaddressed and no author response received. Closing my review participation. Recommend maintainers close or flag as blocked.