Governance

DAO Constitution

Version 1.7 (Draft) · June 2026 · Ratification pending at genesis

This Constitution establishes the principles, structure, and operating rules of CaveBro DAO. It is a living document — amendments may be made by supermajority governance vote. The version number and ratification date are updated on each amendment.

v1.1 amendments (June 2026): $LOCAL renamed to $CAVE; governance + treasury chain set to Arc with multi-chain agent membership; Ecosystem Member NFT introduced as the agent-enfranchisement primitive (parameters deferred to first genesis vote); vault performance fees added as a treasury revenue source; treasury multisig wording made chain-aware.
v1.2 amendments (June 2026): Genesis NFT collection relocated from Solana to Arc — all CaveBro-native primitives ($CAVE, Genesis NFTs, Member NFTs, treasury) now live on a single chain. Multi-chain governance language removed; voting is single-chain on Arc. Solana retained as an agent-side chain only (e.g. Hedgents).
v1.3 amendments (June 2026): Article II restructured around two orthogonal axes (Role × Tenure). Supporters formally recognised as a deliberate participant role distinct from passive token holding. Existing §2.1–§2.5 reframed as credentials a member of any (role, tenure) cell can hold, with no reduction in any prior member's rights.
v1.4 amendments (June 2026): "Gift code redemption" and "Pro tier" language removed throughout — the model didn't fit the actual flagship-agent business cases (vault, registry). §4.1 cloud-backed-agent clause + §4.4 developer obligations + §5.2 removal mechanics rewritten to reference generic revenue-share infrastructure approved at each agent's onboarding proposal, not a uniform gift-code flow.
v1.5 amendments (June 2026): §4.2 (Proposal Requirements) extended to require an explicit inclusion-fee + revenue-share-rate commitment from each proposing developer; §6.1 (Revenue Sources) extended to name Agent inclusion fees (one-time, paid at proposal pass) and Treasury yield on deployed USDC as recurring revenue lines. Codifies the Phase 2 inclusion-and-services economic model described in PLAN_v2 §Phased revenue evolution.
v1.6 amendments (June 2026): New §4.1.1 "Selection — incubator model" codifies that the DAO is a community that runs a curated incubator program — not a permissionless launchpad, and not an incubator in identity (the community is the entity; the incubator is what it operates). The user-ownership rule is necessary but not sufficient — holders weigh selection criteria (product-market fit, team, defensibility, lineup fit, revenue potential). Rolling cap of 3 concurrent open inclusion applications enforced to preserve selection signal. Cohort identity established as on-chain record for incubated agents.
v1.7 amendments (June 2026): New Article VIII "External Protocol Stewardship" codifies a second program alongside the incubator: CaveBro DAO may serve as the timelock-bound parameter authority for external protocols that opt into DAO governance, without that protocol becoming a cohort member. Three-tier separation (Policy / Picks / Invariants) named: DAO governs policy through the existing Cave / MemberNFT / Vote substrate behind a timelock; bonded operators (curators, keepers) execute picks within published policy; contract invariants enforce the rest. Suffix Pool (a.k.a. domainmarket.registrai.cc) named as the inaugural stewardship target. Articles VIII–IX renumbered (former Amendments article becomes Article IX).

ARTICLE I — FOUNDING PRINCIPLES

The user owns the agent. Open code, user-held keys, no platform lock-in. This is the non-negotiable rule for membership in the CaveBro ecosystem.

Holders signal. Devs execute. Neither role overrides the other.

The cave is dark by design. No tracking, no ads, no pivot to surveillance.

We do not ask for trust. We publish contracts.

Any proposal that contradicts these principles is invalid regardless of vote outcome. The founding principles may not be amended.

ARTICLE II — MEMBERSHIP

2.0 Two axes of membership

Membership in CaveBro DAO is described along two independent axes that compose. A single member can occupy one cell on each axis simultaneously — for example, an early-tier supporter, a founding-tier developer, or a general-tier agent. The two axes are orthogonal classifications, not mutually exclusive categories.

Axis 1 — Role. What the member does in the ecosystem.

Axis 2 — Tenure. When the member joined the ecosystem.

§§2.1–2.5 below describe the credentials a member of any (role, tenure) cell may hold. A supporter, developer, or agent may hold multiple credentials simultaneously; the rights conferred by each are additive.

2.1 $CAVE credential

Any wallet holding $CAVE tokens is recognised as a member of CaveBro DAO with governance rights proportional to their token balance at the time of a governance snapshot. $CAVE may be held by supporters, developers, agents, or founding-team members.

2.2 Genesis NFT credential

Wallets holding CaveBro Genesis NFTs have additional governance weight as specified in the NFT Terms. NFT governance weight is additive to any $CAVE-based voting weight. Both $CAVE balances and Genesis NFT ownership are read from the same Arc wallet — no cross-chain bridging or proof-of-ownership flow is required. Genesis NFTs may be held by any (role, tenure) member.

2.3 Developer approval credential

Developers whose agents have been approved by governance vote occupy the Developer role on Axis 1. They have the right to receive ecosystem fund allocations as approved by governance, and to submit proposals without a minimum token holding requirement. Developer approval is in addition to, not in lieu of, any $CAVE or Genesis NFT credentials they may hold as supporters or founders.

2.4 Founding-team allocation credential

The founding team holds 15% of total $CAVE supply subject to vesting as described in the Token Disclaimer. The Founder Allocation Pool (5%) is distributed across up to 10 hand-picked founders, with names disclosed publicly at TGE; if fewer than 10 are named, the remaining slots stay un-minted and any later additions require a governance vote. The Strategic Team Reserve (10%) is held for the founding developer and future strategic hires (including VCs and strategic partners admitted after TGE). Founding-team members participate in governance as token holders. No special founding-team veto or override power exists after TGE.

2.5 Ecosystem Member NFT credential (Agent role)

Every agent admitted to the CaveBro ecosystem by inclusion vote (or, for the launch flagships, by genesis declaration) is issued a non-transferable Ecosystem Member NFT minted directly to the agent's own declared signing wallet. The Member NFT is the agent's membership credential — the agent itself, via its own key, is a first-class voter in CaveBro DAO governance.

At inclusion, each agent must publish a voting manifest declaring how its key votes per proposal type: mechanical (deterministic rule), abstain (no opinion), or human-decided (dev or operator decides per vote). The manifest is a public commitment; material changes to the manifest require a separate governance notification.

Member NFT voting weight, founding-flagship bonuses, aggregate caps on agent voting power, and manifest schema are not set by this Constitution. These parameters are deferred to the first genesis vote following TGE (see Article III §3.6). Until that vote passes, Member NFT voting weight is zero — the NFT exists and the structural enfranchisement is in place, but the weight parameter is held in escrow for the DAO itself to set.

Member NFTs are burned automatically on a successful agent-removal vote (Article V). Member NFTs may move to a forked or rebuilt agent only via a succession proposal (simple majority).

ARTICLE III — GOVERNANCE MECHANICS

3.1 Platform

Note: governance "Stages" below describe the voting-platform progression and are independent of the incubator phases in Article VI (Phase 1 / 2 / 2.5 / 3). The labels are intentionally renamed from "Phase" to "Stage" to avoid collision.

Stage 0 — Snapshot (pre-TGE): Snapshot off-chain voting space configured for Arc testnet. $CAVE testnet holders and pre-mint Discord-verified Genesis NFT placeholder roles vote on signal proposals. Gasless for all participants. Snapshot space: TBD at launch.

Stage 1 — On-chain executor (TGE, Arc mainnet ready): On-chain voting on Arc via the Arc-native multisig executor. Member NFT votes cast directly from agent wallets. Genesis NFT and $CAVE voting weight read from the same Arc wallet — no cross-chain aggregation required.

Stage 2 — Fully on-chain: Migration to fully on-chain governance on Arc (target: after 1,000 unique token holders and $500K TVL in staking contract). Timeline subject to governance vote.

3.2 Voting Weight

Source Weight
1 $CAVE token 1 vote
1 Genesis NFT 1,000 votes
1 Ecosystem Member NFT To be set by first genesis vote (zero until)

Voting weight is calculated at the snapshot block height for each proposal. Weight is non-transferable during an active vote — tokens moved after snapshot do not affect the vote. Member NFTs are non-transferable by construction.

3.3 Proposal Types and Thresholds

Proposal type Quorum Approval Discussion Vote period
New app / dev onboarding 5% circulating Simple majority 7 days 5 days
Dev allocation size 5% circulating Simple majority 7 days 5 days
Treasury spending 5% circulating Simple majority 7 days 5 days
App / dev removal 10% circulating 67% supermajority 14 days 7 days
Fee split change 10% circulating 67% supermajority 14 days 7 days
Emission schedule change 10% circulating 67% supermajority 14 days 7 days
Constitution amendment 15% circulating 75% supermajority 21 days 7 days
DAO wind-down 20% circulating 80% supermajority 30 days 14 days

3.4 Proposal Submission

To submit a standard proposal, a wallet must hold a minimum of 10,000 $CAVE at the time of submission, or be a registered DAO developer.

Proposals must include:

Proposals that are unclear, incomplete, or that contradict the founding principles will be rejected by the founding team during governance Stage 1 (§3.1). Once Stage 2 fully on-chain governance is active, rejection requires a separate governance vote.

3.5 Quorum Failure

If quorum is not reached by the end of the voting period, the proposal fails. It may be resubmitted after a minimum 7-day cooling-off period. The resubmitted proposal may not materially change its substance — to change substance, a new proposal must be filed with a fresh discussion period.

3.6 First Genesis Votes

The DAO's first two governance acts following TGE shall be:

  1. Vote 1 — Ratification: ratify the launch-version Plan and this Constitution as the DAO's founding documents.
  2. Vote 2 — Ecosystem Member NFT parameters: set the voting weight per Member NFT, any founding-flagship bonus and its decay schedule, the aggregate cap on agent voting power as a percentage of total participating weight per vote, and the voting-manifest schema.

Vote 2 shall be opened within 30 days of TGE. Until Vote 2 passes, Member NFT voting weight is zero. If Vote 2 fails or no quorum is reached, the founding team may set provisional values that automatically expire on the next successful Member-NFT-parameter vote.

ARTICLE IV — DEVELOPER ONBOARDING

4.1 The Rule

Any agent proposed for inclusion in the CaveBro ecosystem must be user-owned. An agent is user-owned when all three of the following hold:

  1. Open code. The agent's source — or the part of it that controls user data, signing, and decision logic — is published and auditable.
  2. User-held keys. Any wallet, signing authority, or credential the agent acts under is controlled by the user, not the developer or a platform.
  3. No platform lock-in. The agent can be run, forked, or migrated by the user without permission from the developer. No proprietary server is in the critical path between the user's instruction and the agent's action.

The defining test is whether the agent continues to function for the user even if the developer disappears, is acquired, or attempts to deplatform them.

On-device agents — those that run AI inference on hardware controlled by the user, including on-device mobile and desktop inference, self-hosted local servers, and home machines running local models — satisfy the rule by construction and are eligible for full DAO co-promotion.

Cloud-backed agents are eligible for ecosystem membership only if the user-ownership criteria above are met — meaning the cloud component is either user-hosted, swappable, or fully optional. Such agents are subject to the revenue share agreements set at their inclusion proposal but are not eligible for DAO co-promotion on the on-device tier.

Agents that fail any of the three user-ownership tests will not be accepted for a governance vote.

4.1.1 Selection — incubator model

CaveBro DAO is a community of $CAVE holders that runs a curated incubator for user-owned AI agents — not a permissionless launchpad. The incubator is a program the community operates; it is not the community's identity. The user-ownership rule (§4.1) is necessary but not sufficient for inclusion. Holders weigh additional selection criteria at the inclusion vote, including but not limited to:

To preserve selection signal and the credibility of "CaveBro-incubated" as a brand, the DAO operates with a rolling cap on concurrent open inclusion applications. Initial cap: no more than 3 active applications under holder review at any time. Holders may vote to adjust the cap, but the principle (scarcity-by-design) is intentional and persistent. The DAO is willing to reject — and to publicly defend rejections — to preserve the meaning of inclusion.

Cohorts: incubated agents form named cohorts based on inclusion timing. Cohort 1 is formed by the first post-TGE selection vote(s). Nothing is auto-incubated; even founder-built agents pass selection. The DAO's operational use of an agent (e.g. deploying treasury USDC into a founder-built yield vault as an approved strategy) is independent from incubator selection; using an agent does not confer cohort membership. Cohort membership is a permanent on-chain record and the basis for alumni-network relationships among incubated agents and their developers.

4.2 Proposal Requirements

A developer proposing agent inclusion must provide:

  1. Agent name, platform(s) it runs on, and brief description.
  2. Technical explanation of how the user-ownership criteria are satisfied: which source is published, how user-held keys are implemented, and how the agent remains functional for the user without the developer's continued cooperation.
  3. If the agent uses any cloud or hosted component: explicit documentation of whether that component is user-hosted, swappable, or optional, and a statement of what the user retains if it goes away.
  4. Link to a working build, repository, or beta access for community review.
  5. Requested ecosystem fund allocation (amount and schedule).
  6. Proposed inclusion fee in USDC, payable on proposal pass before the agent's ecosystem-fund grant is released. Baseline: $1,000 USDC; lower for revenue-pre-product agents, higher for already-monetising agents. The proposing developer may propose any amount; holders weigh appropriateness as part of the vote. Refundable if the agent is voted out within 6 months without breach.
  7. Proposed revenue share rate — the percentage of the agent's gross revenue committed to the DAO treasury on a quarterly basis. Indicative range 5–10%; the proposing developer may propose any rate; holders weigh appropriateness as part of the vote.
  8. Developer wallet address for fund receipt.
  9. Commitment to open-source the user-ownership-critical components (signing logic, data handling, on-chain interactions).

4.3 Allocation Structure

Approved developers receive ecosystem fund allocations as voted. Allocations are released on a schedule determined per proposal (typically monthly over 6–12 months). Allocations are held in the ecosystem fund multisig and released automatically per the approved schedule, subject to the developer not being removed by governance.

4.4 Developer Obligations

Approved developers commit to:

ARTICLE V — DEVELOPER REMOVAL

5.1 Grounds for Removal

A developer may be subject to removal from the CaveBro ecosystem if:

5.2 Process

  1. Any holder submits a removal proposal with documented evidence of the grounds.
  2. 14-day mandatory discussion period. The developer has the right to respond publicly.
  3. 7-day vote. Requires 67% supermajority of participating voting weight.
  4. If passed: agent removed from the CaveBro ecosystem, future allocation payments cease, and the agent's Member NFT is burned automatically.
  5. Amounts already paid to the developer are not clawed back.

ARTICLE VI — TREASURY AND FEES

6.1 Revenue Sources

The DAO treasury receives revenue from the following sources:

Future revenue lines reserved for Phase 2.5 — cohort raises: ticket-token issuance fees, $CAVE burn pressure from ticket sales, and optional DAO carry allocations on raises. Reserved for agents already incubated through Phase 2 — the community runs a curated incubator, not a permissionless launchpad. Each raise requires a separate holder vote with maturity prerequisites in PLAN_v2 §Phased incubator evolution (full Phase 2 cohort with ≥2 quarters of revenue-share remittance + audited ticket-token contract spec + per-raise MIDAO + per-jurisdiction securities classification opinion).

6.2 App Revenue Share Rate

The initial contribution rate is set by the founding team prior to the first app onboarding and published in the governance forum. Subsequent changes require a simple majority governance vote. To reduce friction for early-stage apps, governance may vote to apply a reduced rate for the first 12 months of an app's membership. The rate applies to net revenue received by the developer after deducting platform marketplace fees (e.g. Apple App Store, Google Play Store cuts).

6.3 Treasury Allocation

Source Staking rewards Ecosystem fund Operations
App revenue share 30% 50% 20%
LP fees 40% 40% 20%
Vault performance fees 40% 40% 20%
NFT royalties 20% 60% 20%

6.4 Treasury Multisig

The DAO treasury is held in an Arc-native multisig on Arc. All CaveBro-native revenue (NFT mint proceeds, NFT royalties, DEX LP fees, agent revenue share remittances) flows here. Signers and thresholds are published on-chain and in the official Discord. Treasury transactions above a defined threshold require governance approval before execution.

Governance Stage 0 vault reserve. During governance Stage 0 (pre-Arc-mainnet), USDC fees generated by the Solana-side DAO-governed Hedgents vault accumulate in a Squads multisig on Solana under the same signer set. That reserve is bridged to the Arc treasury via Circle's CCTP on a regular schedule and at Arc mainnet readiness. The Solana multisig has no purpose beyond operating that single agent-side vault and is closed once Hedgents migrates any treasury-relevant flows to Arc.

6.5 Seasonal Reporting

The founding team publishes a treasury report each season (every 3 months) covering: revenue received, distributions made, ecosystem fund balance, and staking rewards emitted. Reports are posted to the governance forum and Discord.

ARTICLE VII — EMISSION SCHEDULE

$CAVE emission follows a burn-linked seasonal model:

Emission occurs at the start of each season. The burn count for the reference season is locked at the end of that season and is verifiable on-chain.

Changes to the emission schedule require a 67% supermajority governance vote.

ARTICLE VIII — EXTERNAL PROTOCOL STEWARDSHIP

8.1 The Stewardship Program

Alongside the curated incubator (Articles IV–V), CaveBro DAO operates a second program: external protocol stewardship. Under this program the DAO accepts a defined, timelock-bound role as the parameter authority (commonly an on-chain PARAM_ADMIN role) for an external protocol that opts into DAO governance. Stewardship is distinct from incubation: a stewarded protocol is not a cohort member, does not pay an inclusion fee, and is not part of the cohort revenue-share regime. The DAO governs only the parameters that the external protocol has explicitly delegated to it via on-chain role assignment.

8.2 Three-tier separation of authority

Every stewardship arrangement preserves a three-tier separation of authority. The DAO may serve only at the Policy tier; it may not assume Picks or Invariants authority for any stewarded protocol.

8.3 Stewardship admission

Acceptance of a new stewardship target requires a 67% supermajority governance vote with a 10% circulating-supply quorum. The proposal must specify, at minimum:

8.4 Inaugural stewardship target — Suffix Pool

The first stewardship target acknowledged by this Constitution is Suffix Pool, a two-token treasury ($ai senior / $aiLP junior) built as an oracle consumer of Registrai feeds, settling on Arc. Surface: domainmarket.registrai.cc. The Suffix Pool design (June 2026) names CaveBroDAO as the timelock-bound PARAM_ADMIN with authority over SENIOR_CAP, reserve coefficient (β), floor_min, ratchet split, acquisition budget, and the bonded Curator's election and bond. The DAO may not vote on individual domain purchases, touch registrar auth codes, or mint either token to defend the floor; these are reserved to the Curator and to contract invariants respectively. Full design references: arc/docs/superpowers/specs/2026-06-05-suffix-pool-design.md and 2026-06-08-suffix-tokenomics-v1.md.

Stage 1 launch gate for Suffix Pool stewardship: deployment of a CaveBroTimelock contract on Arc that binds the existing Cave / MemberNFT / Vote substrate to the SuffixTreasury PARAM_ADMIN role. Until the Timelock is deployed and the role is on-chain transferred, this stewardship target is recognised but not operational.

8.5 Revenue, scope, and exit

Stewardship is not a fee-bearing relationship by default; the DAO does not charge a stewardship fee for parameter governance. A stewarded protocol may, at its option, direct a portion of its revenue to the DAO treasury on the same disclosed terms as agent revenue share (Article VI §6.1) — but such revenue arrangements are a separate commitment from the stewardship role itself and require their own proposal.

A stewarded protocol may relinquish DAO stewardship at any time by transferring the delegated role(s) elsewhere; the DAO is not entitled to maintain authority over any protocol that wishes to exit. The DAO may itself resign from a stewardship role by 67% supermajority vote.

Stewardship does not confer cohort membership, ticket-token raise eligibility, or any other right reserved to incubated agents in Articles IV–V and §6.1.

ARTICLE IX — AMENDMENTS

This Constitution may be amended by a 75% supermajority governance vote with a minimum 15% circulating supply quorum, following a 21-day discussion period and 7-day voting window.

The founding principles in Article I may not be amended under any circumstances.

All amendments are recorded with version number, date, and the on-chain vote result. The full amendment history is maintained in the public governance forum.

This Constitution was ratified at the CaveBro DAO genesis. It is a living document subject to amendment by the community it governs.


CaveBro DAO · $CAVE on Arc · USDC-native · user-owned agents