DAO Codex

Constitutional rules of the Colabonate community governance system

Version 1.0.0-draft
Phase 4

The DAO Codex defines the constitutional rules of the Colabonate community governance system. It is not a legal document and is not directly enforceable in state courts. It applies within the technical system and is enforced through Nostr Events and Lightning Escrow.

Tickets with an optional DAO binding (daoId + codexHash fields) are subject to this Codex's dispute resolution and sanction procedures.

Colabonate Foundation (Stiftung)Protocol development, IP/trademark holder, protocol spec steward
Colabonate DAOCommunity governance via this Codex, token-weighted and reputation-weighted voting
Colabonate GmbHCommercial services entity, premium features, governed by separate terms

Three voting models are available. The DAO selects the applicable model per proposal type.

1P1V (One Person One Vote) — Phase 4+Humanode Biomapper verification — Identity Level 3. 1 vote per verified human. Prevents multiple accounts, bot networks, sock puppets.
Token-Weighted — Phase 4+COLA Token staked via Kind 30025 event. 1 governance unit per 1 staked COLA. RRC-20 governance token on RSK (Bitcoin sidechain). Staking enables 5% APY yield.
Reputation-Weighted — Phase 5+COL-Points (off-chain). Score-based multiplier (DAO sets formula).

Normal DecisionToken-weighted or Reputation · Quorum 10% · Majority >50% · 7 days
Codex Amendment1P1V (if available) or Token-weighted · Quorum 20% · 2/3 majority · 21 days
Treasury SpendingToken-weighted · Quorum 15% · Majority >50% · 14 days
Sanction / Ban1P1V required · Quorum 10% · 2/3 majority · 7 days
Protocol UpgradeToken-weighted + 1P1V confirmation · Quorum 25% · 2/3 majority · 21 days
New DAO Creation (Foundation Recognition)Token-weighted · Quorum 10% · Majority >50% · 7 days

Quorum is measured as a percentage of active pubkeys (at least 1 COMPLETED ticket in the last 90 days).

  1. Proposer publishes a Governance Proposal (Nostr Kind 30022, sub_type: proposal) — Title, description, options, deadline, voting model
  2. 14-day public comment period before voting opens (Codex amendments only)
  3. Voting period opens — participants publish Kind 30022 vote events
  4. Quorum and majority checked at deadline by protocol tallying logic
  5. Result published as a final Kind 30022 event (immutable, signed by DAO operator pubkey)

  • Voting rights can be delegated to another pubkey
  • Delegation is revocable at any time
  • Valid for 90 days, then automatically expired
  • Delegation is published as a public Nostr Event (auditable)
  • COLA delegation: delegatee casts vote with combined stake weight
  • 1P1V delegation: not permitted — each HID-verified human must vote directly

  • Requirement: 2/3 majority + 21-day voting period (Codex amendment type)
  • Proposal must be published 14 days before voting opens
  • Change history is traceable through immutable Nostr events
  • The codexHash field in all active tickets references the Codex version at ticket creation — amendments do not retroactively affect in-flight tickets

1
Level 1 — Self-Resolution (7 days) · Phase 1+

Cooling-off, direct negotiation between parties.

2
Level 2 — Community Mediator (14 days) · Phase 3+

Reputation-selected neutral mediator assists agreement.

3
Level 3 — DAO Court (24–48h) · Phase 4+

Arbitrator panel, binding verdict. DAO Court verdicts are published as Kind 30019 events with escrow_action tag, triggering Lightning escrow settlement.

Level 1 — WarningPublic Nostr Event. First violation, minor breach.
Level 2 — Temporary Restriction (30 days)No ticket creation. Repeat or serious violation.
Level 3 — Permanent BanRequires DAO Governance Vote (Sanction type). Fraud, abuse, serious harm.

Since identity = Lightning wallet pubkey, a banned user could create a new wallet. Sanctions are therefore effective primarily through reputation loss (COL-Points forfeiture, public Nostr sanction event visible to all counterparties).

  • Private keys never leave the client device
  • No custody — Colabonate holds no Bitcoin at any layer
  • All governance decisions are Nostr-signed and immutable on relay
  • Open source — protocol spec is CC BY 4.0; reference implementation is open source

  • Primary currency: Bitcoin, denominated in satoshis (sats)
  • All marketplace payments, escrow, mediator fees, and arbitrator fees are in sats via Lightning Network
  • The COLA Token is a governance and utility token — it is not a payment currency
  • No altcoin integration; RSK (for COLA) is a Bitcoin sidechain with 1:1 BTC peg (RBTC)

SymbolCOLA
NetworkRSK (Bitcoin sidechain)
Max Supply100,000,000 COLA
UseGovernance voting weight, staking yield
Payment UseNot permitted — all payments in sats

Platform Fee0% — Phase 1–3
Mediator Fee1% of escrow (in sats) — Phase 4+
Arbitrator Fee2% of escrow (split) — Phase 4+
Protocol RoyaltyVariable (sat-denominated) — Phase 5+

  • Optional multi-sig Lightning treasury for each Community DAO
  • Funding: voluntary contributions, protocol royalties (Phase 5), DAO grants
  • Spending: requires Governance Vote (Treasury type)
  • Foundation DAO Treasury: 25M COLA allocation (vested)

  • Pseudonymous identity allowed (pubkey = identity, no real name required at Level 0–1)
  • Identity levels 0–3 unlock progressive features — no KYC required at any level
  • Level 3 (Humanode) is required for 1P1V voting and high-value DAO interactions

  • Built through: completed tickets (COMPLETED status), mutual reviews (Kind 30024)
  • Non-transferable: Soulbound via signed Nostr Events bound to pubkey
  • Publicly visible: reputation score is computable from public Nostr events
  • Can be lost: losing a dispute, sanctions, abandoning tickets

  • No geographic restriction
  • A Lightning-compatible wallet is the only technical prerequisite
  • No KYC at base level (Level 0 = LNURL-Auth pubkey only)
  • Platform UI will be multilingual — Phase 3+

  • Community members can create their own DAOs governed by a custom Codex
  • Based on the Foundation Codex as a template
  • Independent governance from the Foundation DAO
  • Minimum requirements: 5 founding members, HID Level 2, COLA stake

This appendix documents the operational state of the Foundation DAO. The M2 upgrade (ADR-126) lifted the Council from single-admin bootstrap to a multi-member quorum body.

M2 Quorum Types:

SINGLEAny single verdict resolves (backward-compatible with M0)
MAJORITY>50% of active arbitrators required
THRESHOLDExactly N verdicts required

Upgrade Path:

  1. M2 (implemented): Admin invites arbitrators → quorum activates → audit trail public
  2. Phase 3: Humanode HID integration → 1P1V enforcement → Level 2 mediator pool starts
  3. Phase 4: COLA token staking → token-weighted votes → arbitrator compensation → SPLIT outcome
← Foundation DAO·Role Onboarding →