OCP-0002: Crown-Weighted Governance

Abstract

Crowns carry inherent governance rights. Every crown minted under the Open Crown Standard represents a verified, soulbound stake in the ecosystem: proof of token ownership, on-chain activity, and ongoing stewardship. This OCP formalizes the principle that every crown inherits a right to the throne: crown health determines voting eligibility. Active crowns (health ≥ 40) have full governance weight; inactive crowns do not.

Crown health (heartbeat score, 0-100) determines voting eligibility via a binary threshold. No separate governance token is introduced. This eliminates speculation, securities risk, and custody liability while ensuring that governance power flows to active participants rather than passive speculators.

This proposal introduces four governance primitives:

1. Weighted voting. Active crowns (health ≥ 40) have equal governance weight across four decision categories with escalating quorum and approval thresholds.
2. Crown holder veto. A reactive mechanism allowing crown holders to overturn decisions after passage, preventing governance capture without creating gridlock.
3. Opinion polls. Non-binding but formally acknowledged inquiries that can escalate to binding proposals when participation thresholds are met.
4. Decision calendar. A quarterly governance rhythm that replaces ad-hoc proposal chaos with predictable, transparent scheduling.

Sovereignty transfers from founders to crown holders as the ecosystem matures. This OCP fills the "Community Class" slot defined in the operating agreement (Article III, Section 3.2(c)) and maps directly onto the existing progressive decentralization schedule (Article IX). It is compatible with the existing multisig execution model established by OCP-0001.

Motivation

Why Governance Matters Now

The OpenCrown operating agreement declares explicit intent to progressively decentralize. Article IX defines phase triggers (crown count milestones that shift authority from founders to the community). But those triggers lack specificity: what happens when a milestone is reached? Which decisions transfer? What voting rules apply?

OCP-0002 answers these questions. It defines the governance mechanics that activate at each phase, the decision categories subject to crown holder vote, and the safeguards that prevent capture during the transition. Without this specification, progressive decentralization remains an aspiration rather than a mechanism.

This OCP also resolves an open question on the DAO roadmap: "Should OpenCrown have a governance token for DAO voting?" The answer is no. Crowns already ARE governance. The remainder of this section explains why.

The Governance Token Trap

The history of on-chain governance reveals a consistent pattern of failure when organizations introduce separate governance tokens:

Concentration of power with speculators. When governance tokens trade on secondary markets, voting power concentrates with those who can afford to accumulate, not those who participate in the ecosystem. The result is governance by capital, not governance by contribution. Typical participation rates across major protocols range from 5-15% of token supply, with a small number of whale wallets controlling outcomes.

Financial instrument dynamics. A governance token with economic rights (fee sharing, staking yield, or implicit value from controlling treasury allocation) behaves as a financial instrument regardless of how it is labeled. This triggers regulatory classification concerns, compliance overhead, and potential enforcement risk. These are exactly the liabilities the DAO's non-custodial position is designed to avoid.

Flash loan attacks. Transferable governance tokens are vulnerable to flash-borrowed voting power. An attacker borrows millions in governance tokens, votes on a self-serving proposal, and returns the tokens in the same transaction. The attack costs only a transaction fee.

Governance theater. When voting power can be purchased, well-funded actors create the appearance of community consensus by assembling whale blocs. Proposals pass with high approval percentages that mask the fact that three wallets controlled the outcome.

Soulbound crowns with health scores are the structural antidote to every failure mode above:

• Crowns cannot be flash-loaned or traded because they are soulbound (ERC-5192).
• Anti-squatting mechanics prevent accumulation. Escalating fees (2x at 4+ crowns, 4x at 11+) make hoarding economically irrational.
• Health scores reward active stewardship over passive holding. A crown's governance weight depends on ongoing activity (volume, holders, market presence), not just ownership.

Why NOT a Separate Token

Five specific reasons this OCP rejects a separate governance token:

1. Securities risk. A governance token with economic rights triggers classification concerns under existing securities frameworks. The DAO explicitly operates as a non-custodial protocol. Introducing a token with implicit financial value contradicts this position.

2. Custody liability. The DAO's operating agreement establishes non-custodial operations. A governance token creates custody obligations: airdrops require distribution mechanics, staking requires lock-up contracts, and token management requires infrastructure the DAO deliberately avoids.

3. Redundancy. Crowns already exist on-chain with verifiable ownership, activity scoring, and soulbound properties. Creating a second token to represent what crowns already encode is unnecessary complexity.

4. Speculation. Tradeable governance tokens attract mercenary capital whose incentive is token appreciation, not ecosystem health. Soulbound crowns attract builders who earn governance weight through activity, not purchase.

5. Complexity. One asset serving dual purpose (registry + governance) is architecturally simpler than managing two token economies with separate incentive structures, distribution schedules, and market dynamics.

The Constitutional Framing

Founders write constitutions; they do not retain permanent authority under them. The operating agreement encodes this through a graduated transition: founder authority narrows at verifiable on-chain milestones and expires entirely by December 31, 2030, regardless of whether the milestones are reached.

The transition is graduated rather than binary because governance requires a mature voter base to function. Premature decentralization (handing binding governance power to a small group) creates the appearance of legitimacy without its substance. The phase triggers are set at the scale where the structural defenses (supermajority thresholds, tenure gates, crown holder veto) have been exercised under real conditions and the cost of governance capture is prohibitive.

This is a transfer of authority from founders to demonstrated stewards: crown holders who have proven ongoing commitment through the activity that maintains their heartbeat scores.

Graduated Authority Transition

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Spec 1: Voting Weight

Health-to-Weight Threshold

Crown governance weight is determined by heartbeat health score using a binary threshold:

Why binary over graduated tiers:

• Graduated tiers punish market conditions crown holders can't control. Volume and holder count are partially exogenous — a bear market hits everyone's scores. A crown at 65 health shouldn't have half the governance power of one at 80.
• Reduced weight discourages participation. A crown holder told their vote is worth half as much is less likely to engage, not more. Governance needs maximum participation, not a hierarchy of influence.
• The decision tier system already provides rigor. Escalating quorum (20-50%), approval thresholds (50-80%), and hold duration requirements (7-90 days) filter for commitment. The voting weight formula should be simple — the decision tiers do the heavy lifting.
• Binary is maximally legible. Crown holders understand instantly: "Is my health above 40? I can vote." No ambiguity, no feeling like a second-class citizen.
• The 40 threshold is generous by design — only truly inactive or abandoned crowns lose voting eligibility. The heartbeat decay system and anti-squatting fees handle the rest.

Multi-Crown Weighting

A wallet holding multiple crowns has total governance weight equal to the sum of individual crown weights:

wallet_weight = sum(weight(crown_i) for each crown_i in wallet)

Anti-squatting fees already disincentivize mass accumulation:

• Crowns 1-3: Standard claim fee
• Crowns 4-10: 2x claim fee
• Crowns 11+: 4x claim fee

Each crown MUST independently maintain its own health. A wallet with 5 crowns where 3 are active (≥40) and 2 are critical (<40) has weight 3.0 (3 × 1.0 + 2 × 0.0), not 5.0.

Snapshot-at-Proposal-Time

Governance weight is calculated at the block when a proposal is created. This prevents gaming during the voting period — crown holders cannot rush to improve health scores after seeing a proposal they want to influence. The snapshot block number is recorded in the proposal metadata and is publicly verifiable.

View Function Specification

Conformant implementations MUST expose view functions that return crown governance weight. The current-block accessor is sufficient for off-chain tooling; the historical-block accessor is REQUIRED before the on-chain VoteAggregator deploys at Phase 3.

// EVM
interface IGovernanceWeight {
    /// @notice Governance weight for a crown at the current block.
    /// @return weight 0 if crown is below health threshold or does not exist;
    ///                1e18 if the crown meets the eligibility threshold (binary v1).
    function getGovernanceWeight(uint256 crownId) external view returns (uint256 weight);

    /// @notice Governance weight for a crown at a historical block.
    /// @dev Required by the Phase 3 VoteAggregator for proposal-snapshot weighting.
    function getGovernanceWeightAt(uint256 crownId, uint256 blockNumber)
        external view returns (uint256 weight);

    /// @notice Aggregated governance weight across all crowns owned by `owner`.
    function getGovernanceWeightOfOwner(address owner)
        external view returns (uint256 totalWeight);
}

// Solana
pub fn get_governance_weight(crown_id: u64) -> Result<u64> {
    // 0 if crown.health < 40 or crown does not exist;
    // 1_000_000 (scaled) if the crown meets the eligibility threshold.
}

pub fn get_governance_weight_of_owner(owner: Pubkey) -> Result<u64> {
    // Sum of governance weights across all crowns owned by `owner`.
}

The weight return value uses 1e18 (EVM) or 1_000_000 (SVM) scaling so the interface remains forward-compatible with a future graduated weight scheme without an ABI break. The v1 binary model returns only 0 or full weight.

Implementations MAY add getGovernanceWeight as a non-breaking view in advance of Phase 3 to avoid a coordinated registry upgrade later. This is RECOMMENDED before mainnet.

Spec 2: Decision Categories

Decisions are classified into four tiers with escalating requirements, plus a multisig-only category for operational matters. Quorum thresholds are anchored to active governance weight (the total weight of crowns at or above the health eligibility threshold), not lifetime crown supply. Decayed and inactive crowns drop out of the denominator.

These thresholds are deliberately calibrated against observed participation rates at established protocol DAOs (Compound, Aave, Uniswap, Arbitrum). Unicameral protocol DAOs that set base quorum above 10% systematically fail to clear votes; the result is governance theater where the founder/multisig retains de facto authority through inaction. OpenCrown's protection against capture comes from the layered defenses — soulbound mechanics, heartbeat-gated weight, per-cluster caps, founder veto with public override, time-locks — not from quorum heights no DAO actually reaches.

Tier 1 — Protocol Parameters (Crown Holder Vote)

Decisions affecting protocol configuration that do not involve economic flows:

• Heartbeat weight adjustments (the 50/30/20 split between timestamp, volume, holders)
• Anti-squatting fee thresholds and multipliers
• Grace period durations
• Heartbeat decay parameters

Tier 2 — Economic Decisions (Crown Holder Vote + Multisig Execution)

Decisions affecting fee structures, revenue flows, or treasury allocation:

• Deal facilitation fee cap adjustments
• Revenue allocation between protocol treasury and operations
• Operator fee structure changes
• Treasury subsidy ceiling adjustments (see Spec 10)
• Grant allocations above threshold

Tier 3 — Governance Changes (Supermajority)

Decisions that modify the governance system itself:

• Amending governance OCPs (including this one), except those reserved to Tier 4
• Multisig composition changes (adding/removing signers)
• Voting weight formula modifications
• Phase trigger threshold adjustments

Tier 4 — Constitutional / Existential (Dual-Key)

Decisions with irreversible or fundamental impact require both crown holder approval and multisig consent. Neither party may pass a Tier 4 change unilaterally. The dual-key structure replaces the founder veto on Tier 4 with a symmetric requirement.

Decisions in this tier include:

• Protocol dissolution
• Fundamental standard changes (rewriting core specification)
• Cross-chain migration
• Merger with or absorption into another protocol
• Sunsetting or extending Phase 5
• Removal of the founder veto step-down at 500 crowns (Spec 2a)

Multisig-Only (Not Subject to Crown Vote)

Certain operational decisions remain under multisig authority and are not subject to crown holder vote:

• Emergency security patches — REQUIRES retroactive ratification by crown holders within 30 days
• Routine operations under $500 — Day-to-day expenses below materiality threshold
• Operator management — Day-to-day OpCo operations per OCP-0001 protocol/operator separation
• Smart contract deployments — Until Phase 4, when deployment authority transfers to governance

Spec 2a: Founder Veto Scope and Step-Down

The founder veto is a defined, scoped, time-bounded mechanism — not an open-ended block on DAO actions. Its scope narrows mechanically at on-chain milestones and sunsets entirely no later than Phase 5 or December 31, 2030 (whichever comes first).

Veto Scope by Phase

The T+24-month time anchor on Phase 3 is the protocol's commitment to crown holders that the "founder-led" period has a hard ceiling regardless of crown growth. If 10,000 crowns is reached earlier, Phase 3 activates earlier; otherwise the calendar guarantees activation by T+24mo. This anchors the bootstrap period and prevents indefinite founder authority through low crown adoption.

The 500-crown step-down at Phase 2.5 is the protocol's commitment that even before binding votes activate, the founder voluntarily narrows the veto scope as the ecosystem demonstrates adoption — a credibility signal rather than a vote-gated transition.

Public Justification Log

Every exercise of the founder veto MUST be accompanied by a written justification published to IPFS within 7 days of the veto. The justification MUST include:

• The proposal vetoed (ID and full text reference)
• The specific veto category invoked (from the scope list applicable at the current phase)
• The protocol risk the veto is intended to prevent
• The intended path forward (revised proposal expected, no action expected, etc.)

A veto exercised without a published justification within the 7-day window MUST be treated as withdrawn. The underlying proposal proceeds to time-lock and execution as if no veto had been exercised.

The Coordinator contract MUST maintain an immutable on-chain log of veto events linked to their IPFS justifications. Failure to maintain the log SHALL constitute a Tier 3 governance violation subject to override.

Spec 3: Crown Holder Veto

The veto mechanism is reactive — crown holders can overturn decisions after passage, not block them before consideration. This design prevents governance gridlock while preserving the community's ability to check power.

Veto Process

1. Initiation. Any crown holder with voting eligibility (health >= 40) MAY initiate a veto petition against a passed proposal during its time-lock period.

2. Petition threshold. The petition MUST gather signatures representing 20% of total governance weight within 7 days. Signatures are crown-weighted — each active crown's signature counts as 1.0.

3. Veto vote. If the petition threshold is met, a 14-day veto vote begins. All eligible crown holders may participate.

4. Veto passage. The veto succeeds if >50% of participating governance weight votes to overturn the original decision.

5. Cooling period. Vetoed decisions MUST NOT be re-proposed for 60 days. This prevents proposal spam and allows time for discussion and revision.

6. Attempt limit. A maximum of two veto attempts are allowed per proposal. If the second veto attempt fails, the original decision stands and is final.

7. Exemptions. Emergency security decisions executed under multisig-only authority are exempt from veto (but still require retroactive ratification).

Relationship to Founder Authority

The founder veto (operating agreement Section 5.2) and crown holder veto coexist during early phases and transition as milestones are reached. See the Constitutional Framing table and Spec 2a for the full schedule. The founder veto narrows mechanically at the 500-crown step-down (Phase 2.5) and is overridable by crown holder vote starting at Phase 3 (Spec 3a). The crown holder veto in this section operates on passed proposals; the founder veto override in Spec 3a operates on vetoed proposals. Both mechanisms remain available throughout their phase ranges.

Spec 3a: Founder Veto Override

The founder veto MUST be overridable by sustained crown holder vote. This makes the veto a friction layer with a clearable bar, not an absolute block. Override is available beginning at Phase 3 (when binding votes activate); during Phases 1-2.5 the veto is final because no binding voting infrastructure exists.

Override Process

1. Initiation. Any crown holder with voting eligibility (health ≥ 40 and tenure ≥ 7 days) MAY initiate an override petition within 30 days of the founder veto being exercised and the public justification being published.

2. Petition threshold. The petition MUST gather signatures from crown holders representing the override quorum for the original tier within 14 days:

   • Tier 1-2 vetoes: 10% of active governance weight
   • Tier 3 vetoes: 18% of active governance weight

3. Override vote. If the petition threshold is met, a 14-day override vote begins. The original proposal text AND the founder's published justification (per Spec 2a) MUST be presented together to voters.

4. Override passage. The override succeeds if participating governance weight meets BOTH the override quorum AND the override approval threshold:

   • Tier 1-2 vetoes: 10% quorum AND >60% approval
   • Tier 3 vetoes: 18% quorum AND >66% approval

5. Effect. A successful override executes the original proposal, bypassing the veto. The proposal enters its tier's standard time-lock and then executes.

6. Tier 4 exception. Tier 4 (Constitutional / Existential) decisions are not subject to override. They require dual-key approval by design (Spec 2).

7. Multiple veto exemption. A founder veto re-applied to a substantively-identical proposal within 12 months of a successful override SHALL be treated as null and void. This prevents serial vetoing of community-ratified decisions.

Spec 4: Opinion Polls (Binding Inquiry)

Opinion polls provide a formal channel for crown holders to signal preferences and initiate dialogue on topics not yet ready for formal proposals.

DAO Response Requirements

• Acknowledgment threshold. Multisig signers MUST formally acknowledge any poll that reaches 30% participation of total governance weight. Acknowledgment means a public written response addressing the poll's subject matter — not necessarily agreement.

• Escalation threshold. Any poll that achieves both 50%+ participation AND 66%+ support automatically qualifies as a formal Tier 1 proposal. The poll creator (or any crown holder with voting eligibility) may submit the formal proposal without additional prerequisites.

Spec 5: Decision Calendar

Quarterly Governance Rhythm

Governance follows a quarterly cycle to replace ad-hoc proposal chaos with predictable, transparent scheduling:

Emergency proposals MAY bypass the calendar using existing multisig-only authority, subject to retroactive ratification requirements.

Mandatory Annual Reviews

The following items MUST appear on the decision calendar at least once per year:

1. Deal facilitation fee cap — Starting at 5%, reviewed annually for adjustment
2. Heartbeat weight review — Current 50/30/20 split (timestamp/volume/holders) evaluated against ecosystem data
3. Multisig composition review — Signer additions, removals, or threshold changes
4. Operator fee structure review — Operator fee caps and incentive alignment
5. Treasury allocation review — Protocol treasury balance, spending, and reserve targets

The decision calendar is published as an IPFS document linked from the protocol coordinator contract. Any operator may display and distribute it.

Spec 6: Concrete Example — Deal Fee Review

To illustrate how these mechanisms work together, here is a complete walkthrough of an annual deal facilitation fee review:

1. Calendar publication. The Q4 decision calendar includes "Annual Deal Facilitation Fee Review" as a scheduled item.

2. Sentiment poll. During Month 1, a crown holder with voting eligibility submits an opinion poll: "Should the deal facilitation fee change?" with four options: keep at 5%, reduce to 3%, reduce to 4%, increase to 6%.

3. Poll results. After 7 days, the poll closes with 12% participation of active governance weight. Of that participating weight, 60% prefers reducing to 3% with a $300 cap.

4. Formal proposal. During Month 2, a formal Tier 2 proposal is submitted: "Reduce deal facilitation fee from 5% to 3% with a $300 maximum cap per deal."

5. Vote. During Month 3 voting period, the proposal achieves 11% participation of active governance weight (clearing the 8% Tier 2 quorum) with 62% approval (clearing the >60% Tier 2 threshold). The proposal passes.

6. Time-lock. A 14-day time-lock begins (Tier 2 requirement).

7. No veto. No veto petition is filed during the time-lock period.

8. Execution. The multisig executes the on-chain configuration change, updating the maxDealFacilitationFeeBps parameter from 500 to 300.

Spec 7: Phase Integration

Crown governance rights activate progressively, aligned with the operating agreement Article IX decentralization schedule and the graduated founder authority model:

Time anchor on Phase 3: the T+24-month anchor is the protocol's commitment that the bootstrap period has a hard end date. If crown adoption is slower than projected, binding votes still activate by calendar. This guarantees the "founder ratifies without binding vote" period does not extend indefinitely.

Absolute backstop: The operating agreement's December 31, 2030 deadline applies as a hard ceiling on Phase 5. If 1,000,000 active crowns is not reached by that date, Phase 5 activates regardless. No individual retains permanent authority under any scenario.

Community Class Allocation

Crown governance weight maps to the Community Class allocation defined in the operating agreement (Article III, Section 3.2(c)):

your_dao_voting_power = (your_crown_weight / total_crown_weight) * community_class_percentage

Where community_class_percentage is the governance allocation assigned to the Community Class at the current phase. This percentage increases as phases progress, reflecting the transfer of sovereignty from founders to crown holders.

Spec 8: Eligibility Requirements

Beyond health-based weight, the following eligibility requirements apply:

Protocol-level heartbeat only. On-chain governance weight MUST use only the protocol-level heartbeat score (the 50/30/20 weighted composite of timestamp, volume, and holders). Operator-level boosts (social engagement scores, UI-specific metrics) MUST be excluded from governance calculations. This ensures governance weight is determined by verifiable on-chain activity, not operator-specific metrics that could be gamed or manipulated.

Spec 9: Initial Fee Schedule

The following fee parameters are set at protocol launch based on financial sustainability projections. All parameters are Tier 2 Economic Decisions (30% quorum, 60% approval, 14-day timelock) and are subject to crown holder governance from day one.

Crown Transaction Fee Split

All protocol-level transaction fees are split between the DAO treasury and the facilitating operator:

This split MUST apply uniformly to all crown transaction types:

Anti-squatting fee multipliers (2x at 4+ crowns, 4x at 11+ crowns) MUST apply to the full fee before the split. Both DAO and operator portions scale proportionally.

Deal Fees

Deal fees use an additive model with a hard cap:

The registry MUST revert any deal transaction where protocolDealFeeBps + operatorFacilitationFeeBps > maxTotalDealFeeBps.

Claim/Reclaim Facilitation

Operators MUST monetize claims through their 80% share of the flat fee, subscriptions, API access, and premium features — not through additional markup above the end-user price.

Operator Registry

An on-chain operator registry gates the fee split. Claim and reclaim transactions MUST revert if the facilitating operator address is not registered and active. This prevents fee-split spoofing where users pass their own address to claim crowns at an 80% discount.

The operator registry is designed to be permissionless with on-chain guardrails — no DAO vote is required to register or operate. The chain enforces the rules; the market determines which operators succeed. This aligns with OCP-0001's guarantee of permissionless operation and the protocol's broader principle that verification is cryptographic, not political.

Operator Lifecycle

Operators progress through four on-chain states:

PROVISIONAL → ACTIVE → (SUSPENDED) → EXITED
     │                      │
     │   on-chain only      │  on-chain only
     │   no human judgment  │  no human judgment
     └──────────────────────┘

Registration (Permissionless)

Any address MAY register as an operator by calling registerOperator() with the following requirements:

1. Registration fee. The registrant MUST pay a non-refundable operatorRegistrationFee (initial value: ~$150 equivalent in native token (10× baseClaimFee)). This fee is transferred immediately to the DAO treasury (protocolTreasury) and is never returned, regardless of operator outcome. The registration fee is a sunk cost that deters drive-by spam registrations — it ensures any registrant has skin in the game before the provisional period even begins.

2. Stake bond. The registrant MUST deposit a stake of minOperatorStake (initial value: equivalent of 50 crown claim fees at current baseClaimFee). The stake is held by the registry contract for the duration of the operator's registration. The stake is separate from the registration fee and is refundable upon clean exit.

3. Fee address. The registrant MUST provide a non-zero feeAddress where operator fee shares will be routed. This MAY be the same as the registrant address or a separate treasury address (e.g., a multisig or smart contract wallet).

4. Metadata CID. The registrant MUST provide an IPFS CID pointing to a JSON document containing:

   • name (string, REQUIRED): Human-readable operator name
   • domain (string, REQUIRED): Primary web domain
   • description (string, OPTIONAL): Brief description of the operator's focus
   • contact (string, OPTIONAL): Contact URI for dispute resolution

5. Uniqueness. Each address MAY register at most one operator. An address that has exited MAY re-register after the cooldown period (the registration fee MUST be paid again on re-registration).

The registry MUST assign a sequential operatorId (uint256) and set the operator's status to PROVISIONAL. No admin approval, DAO vote, or human judgment is required at registration.

// msg.value MUST equal operatorRegistrationFee + minOperatorStake
function registerOperator(
    address feeAddress,
    string calldata metadataCID
) external payable returns (uint256 operatorId);

Provisional Period (Probationary)

New operators enter a PROVISIONAL state that provides consumer protection without requiring human gatekeeping:

During the provisional period:

1. Fee escrow. The operator's 80% fee share from each facilitated transaction is held in escrow within the registry contract for provisionalEscrowPeriod (14 days) before release. If the operator is slashed or exits during the escrow period, escrowed fees are returned to the DAO treasury — not to the end user, as the crown claim itself remains valid regardless of operator status.

2. Crown facilitation. Provisional operators MAY facilitate crown claims, token creation, reclaims, and deals. The end-user experience is identical to an active operator. Users SHOULD be informed of the operator's provisional status by the operator's own UI (not enforced on-chain).

3. Graduation. An operator automatically graduates to ACTIVE when ALL of the following conditions are met:

   • provisionalPeriod has elapsed (90 days since registration)
   • Operator has facilitated ≥ minCrownsToGraduate (25) crown transactions
   • Facilitated crowns are held by ≥ minUniqueCrownHolders (10) distinct wallet addresses
   • Operator has not been suspended during the provisional period
   • Operator's stake remains fully bonded

   Graduation is triggered by anyone calling graduateOperator(operatorId) — the contract verifies all conditions on-chain. No admin action required.

4. Failure to graduate. If an operator does not meet graduation criteria after provisionalPeriod, it remains PROVISIONAL indefinitely until conditions are met or the operator voluntarily exits. The provisional period is a minimum, not a deadline. There is no penalty for slow graduation — only for violations.

Active Operation

Active operators receive direct fee routing (no escrow delay):

• 80% of facilitated crown transaction fees route immediately to feeAddress
• 20% routes to protocolTreasury
• Fee routing is automatic and on-chain — no claims, no manual distribution
• Active operators MAY update their feeAddress and metadataCID at any time

On-Chain Violation Detection and Suspension

The protocol detects violations automatically without human judgment. Suspension is triggered by on-chain provable conditions only:

The registry MUST NOT suspend operators for reasons that require human judgment (UI quality, uptime, reputation, subjective "harm"). The protocol constrains what operators can do (OCP-0001); it does not judge how well they do it. The market handles that.

Suspension mechanics:

1. The contract sets operator status to SUSPENDED and pauses fee routing.
2. All facilitated transactions during suspension route 100% to treasury.
3. Cure period: The operator has curePeriod (30 days) to remedy the violation:
   • Stake shortfall → deposit additional stake
   • Inactivity → facilitate at least 1 crown transaction (proves liveness)
   • Self-dealing → no cure available (slash finalizes after cure period)
4. If cured within the cure period, the operator returns to previous status (PROVISIONAL or ACTIVE).
5. If not cured, the slash finalizes and the operator enters EXITED status.

Slashing

Slashing is the on-chain penalty for proven violations. Slash amounts are fixed and proportional to prevent excessive punishment:

Emergency admin slashing is the only mechanism that involves human judgment. It is reserved for situations where on-chain detection is insufficient (e.g., an operator whose contracts are exploited and actively draining user funds through a vulnerability in their off-chain systems). Emergency slashes MUST be ratified retroactively by a Tier 2 crown holder vote (30% quorum, 60% approval, 14-day timelock) within 30 days. If ratification fails, the slashed amount MUST be returned to the operator.

Remaining stake after slashing is returned to the operator upon exit.

Voluntary Exit

An operator MAY exit at any time by calling deregisterOperator(operatorId):

1. Status changes to EXITING (a sub-state of EXITED)
2. Fee routing pauses immediately
3. Cooldown period of exitCooldownPeriod (30 days) begins
4. Any escrowed fees (from provisional period) continue their escrow countdown and are released normally if no violations occurred
5. After cooldown, the operator (or anyone) calls withdrawStake(operatorId) to return the remaining stake
6. Status changes to EXITED (terminal)

The cooldown prevents stake-and-run scenarios where an operator registers, facilitates a few claims, and immediately exits with the fee share before any violations can be detected.

Why Not Fully Permissionless (No Provisional Period)

The 80% fee share is a significant economic incentive. Without the provisional period, the following attack is trivially profitable:

1. Register as operator with minimum stake
2. Build a thin frontend that passes your operatorId on crown claims
3. Run paid ads or bots to drive claims through your frontend
4. Collect 80% of fees immediately
5. Provide zero value (no profiles, no tools, no support)
6. Exit and withdraw stake

The non-refundable registration fee ($150) + provisional period's escrow + graduation requirements make this attack unprofitable: the attacker must burn $100 upfront, wait 90 days, and service 25 real users (10 distinct wallets) before receiving any fee share. The sunk cost and real-user requirement eliminate the economic incentive for drive-by registration.

Why Not DAO-Gated (Vote Required)

Requiring a DAO vote to register operators contradicts OCP-0001's permissionless guarantee and creates the exact gatekeeping dynamic the protocol is designed to eliminate. A DAO vote introduces:

• Subjectivity. "Is this operator good enough?" is a political question, not a protocol question.
• Delay. Quarterly governance calendar means up to 3 months before an operator can launch.
• Incumbency bias. Existing operators have incentive to vote against new competitors.
• Centralization. A small set of crown holders (early phase) could block all new operators.

The on-chain requirements (stake, provisional period, graduation criteria, automated suspension) provide equivalent consumer protection without any of these failure modes. The protocol verifies; it does not judge.

Operator Registry Parameters

All operator registry parameters are classified as Tier 1 Protocol Parameters (20% quorum, 50% approval, 7-day timelock):

No Admin Gate on Registration

Operator registration is permissionless from day one. There is no admin-only launch phase. The registration fee ($150 non-refundable), stake bond (50× base claim fee), 90-day provisional period, graduation requirements (25 crowns facilitated, 10 unique holders), and on-chain violation detection provide sufficient gatekeeping without requiring human judgment or admin approval at any stage. Nobody registers as an operator when there are 12 crowns in existence — the economics don't support it. When the ecosystem is large enough that operating makes economic sense, the door is already open.

Namespace Allocation (Separate Concern)

Operator registration and namespace allocation are distinct processes. Registration grants the right to facilitate crown transactions and receive fee shares. Namespace allocation grants an exclusive naming prefix (e.g., .og, .mint).

Namespace allocation is a scarce resource allocation and MUST require a Tier 1 crown holder vote (20% quorum, 50% approval, 7-day timelock). An operator MAY operate without a namespace — namespaces are optional for fee routing and crown facilitation. Namespace governance is specified separately in the resolution layer (future OCP or OCP-0001 amendment).

EVM Implementation

enum OperatorStatus { PROVISIONAL, ACTIVE, SUSPENDED, EXITED }

struct Operator {
    address feeAddress;
    uint256 stakeAmount;
    uint256 registeredAt;
    uint256 graduatedAt;        // 0 if not yet graduated
    uint256 lastActivityAt;
    uint256 crownsFacilitated;
    uint256 uniqueHolderCount;  // tracked via bitmap or mapping
    string metadataCID;
    OperatorStatus status;
}

mapping(uint256 => Operator) public operators;      // operatorId => Operator
mapping(address => uint256) public operatorByAddress; // registrant => operatorId
uint256 public nextOperatorId;
uint256 public operatorRegistrationFee;              // non-refundable (~$100)
uint256 public minOperatorStake;                     // refundable (50 × baseClaimFee)

// Escrowed fees for provisional operators
mapping(uint256 => EscrowEntry[]) public operatorEscrow; // operatorId => entries

struct EscrowEntry {
    uint256 amount;
    uint256 releaseAt;
}

Solana Implementation

#[account]
pub struct OperatorRecord {
    pub operator_id: u64,
    pub registrant: Pubkey,
    pub fee_address: Pubkey,
    pub stake_amount: u64,
    pub registration_fee_paid: u64, // non-refundable (~$100), sent to DAO treasury
    pub registered_at: i64,
    pub graduated_at: i64,         // 0 if not yet graduated
    pub last_activity_at: i64,
    pub crowns_facilitated: u32,
    pub unique_holder_count: u16,
    pub status: OperatorStatus,    // enum: Provisional, Active, Suspended, Exited
    pub metadata_cid: String,      // IPFS CID (max 64 chars)
    pub bump: u8,
}
// PDA seeds: ["operator", operator_pubkey]

Cross-Chain Fee Parity

All fee parameters defined above MUST be implemented identically on every supported chain, including Solana. Chain-specific implementation details differ (e.g., lamports vs wei, PDAs vs mappings), but the economic parameters — protocolFeeBps, protocolDealFeeBps, maxTotalDealFeeBps, maxDealFacilitationFeeBps — MUST have identical values.

Solana-specific notes:

• Fees are denominated in lamports (1 SOL = 1,000,000,000 lamports)
• The base claim fee ($15) and reclaim fee ($25) are set in lamports at deployment and updated by admin as SOL/USD fluctuates
• Operator registry uses PDA accounts (OperatorRecord with seeds ["operator", operator_pubkey]) instead of a Solidity mapping
• Fee split transfers use system_program::transfer CPI calls rather than Solidity's call{value:}
• If no operator is provided in a claim/reclaim transaction, 100% MUST go to treasury (backwards compatible)

Fee parameter sync requirement: When governance updates any fee parameter via Tier 2 vote, the change MUST be applied to all chain implementations within the same decision's timelock window. A fee change that is live on one chain but not yet applied to another creates an arbitrage window and MUST be treated as a protocol incident.

Governance of Fee Parameters

All fee parameters listed above are classified as Tier 2 Economic Decisions:

• 30% quorum of total governance weight

• 60% approval of participating weight

• 14-day time-lock after passage

The mandatory annual reviews (Spec 5) include all fee parameters. Crown holders set fee policy — they do not approve individual operator applications.

These defaults are set pre-launch based on financial sustainability projections. The protocol starts with sensible defaults; the community governs all changes.

Spec 10: DAO Treasury Policy (Bootstrap Subsidy)

During the first 24 months post-mainnet launch ("Bootstrap Period"), the DAO MAY allocate a portion of the protocol treasury to subsidize protocol-level public-goods infrastructure operated by the reference operator. The subsidy is bounded, line-itemed, time-anchored, and subject to public quarterly reporting. After the Bootstrap Period sunsets, all protocol infrastructure funding MUST go through an open RFP/grant process.

Eligible Expenditures

Treasury subsidy during the Bootstrap Period MAY fund only line items that constitute public-goods infrastructure benefiting any current or future operator equally:

• Multi-chain RPC infrastructure
• Indexer operations
• Smart contract security audits and ongoing security review
• SDK and developer documentation maintenance
• Multi-chain expansion infrastructure
• Contingency for the categories above

Treasury subsidy MUST NOT fund:

• Operator-specific user interfaces or frontends
• Operator marketing, growth campaigns, or paid acquisition
• Operator subscription billing infrastructure
• Operator-specific customer support staff
• Any line item that does not benefit other potential operators equally

Bootstrap Period Budget

Ops scaling factor: approximately $1,500-3,000 per 10,000 additional active crowns per year, reflecting indexed-event growth, RPC call volume, and storage costs across supported chains.

Ceiling Adjustments

The Hard Ceiling MAY be adjusted only via a Tier 2 Economic Decision (8% quorum, >60% approval, 14-day timelock). The founder/multisig MAY spend within the Working Budget without additional authorization, and MAY spend up to the Hard Ceiling for variance within budgeted categories provided the variance is disclosed in the next quarterly transparency report. Spending above the Hard Ceiling without a Tier 2 vote SHALL constitute a Tier 3 governance violation subject to override.

Public Quarterly Reporting

The reference operator MUST publish a quarterly transparency report within 30 days of the end of each calendar quarter, signed by the reference operator's treasury signer(s). Each report MUST contain:

• Spent / Working Budget / Hard Ceiling, by line item
• Reason for any variance above the Working Budget
• Total treasury balance, treasury inflows, and outflows for the quarter
• Cumulative spend against the 24-month total
• Sunset countdown (months remaining in the Bootstrap Period)
• External grant funding received and how it has reduced treasury allocations (per the Grant Compatibility clause below)

Reports MUST be published to IPFS and linked from the Coordinator contract's transparency log. Failure to publish within the 30-day window SHALL trigger an automatic pause on new subsidy disbursements until the report is published.

Sunset

The Bootstrap Period MUST end on the date T+24 months post-mainnet launch. After sunset:

• The DAO treasury MUST NOT route further subsidies to any single operator
• Protocol-level infrastructure funding MUST proceed via open RFP/grant processes (any registered operator MAY apply)
• The reference operator funds its own infrastructure from its 80% fee share or external sources

The Bootstrap Period MAY be terminated earlier via a Tier 2 vote. It MAY be extended only via a Tier 3 vote with public justification — extension is not a routine option.

Grant Compatibility

The Bootstrap Period categories are deliberately structured to align with public-goods grant funding programs (Ethereum Foundation, Optimism RetroPGF, Arbitrum Grants, Gitcoin, others). The reference operator SHOULD pursue external grant funding for any Bootstrap Period line item.

If external grants fully or partially cover Bootstrap Period expenditures, treasury allocations to the subsidy SHALL be reduced proportionally. The intent is for the DAO treasury 20% protocol take to accumulate as long-term runway during the Bootstrap Period, with grants covering the public-goods work. This is the protocol's preferred Bootstrap path: external public-goods funding for public-goods work; treasury 20% take preserved as protocol endowment.

Operator-Specific Capital (Out of Scope)

Operator-specific capital needs — Chain Daddy's product surface, marketing, hiring, sales motion, operator-managed services — are explicitly outside the Bootstrap Period subsidy scope and MUST be funded by the operator's own 80% fee share, subscription revenue, or external investment. The protocol/operator wall (OCP-0001) prohibits treasury allocations for operator-specific work regardless of operator status (reference or third-party).

Rationale

Why Binary Weight Beats Graduated Tiers or Separate Token

Graduated tiers (mapping health ranges to fractional weights like 0.5 or 0.1) create a participation hierarchy that discourages engagement. A crown holder told their vote is worth half as much is less likely to participate, not more — and governance needs maximum participation.

Market conditions are partially exogenous. Volume and holder count reflect broader market dynamics, not just a crown holder's stewardship. Punishing crown holders with reduced governance power for conditions they cannot control is counterproductive.

The decision tier system (escalating quorum from 20-50%, approval thresholds from 50-80%, and hold duration requirements from 7-90 days) already provides sufficient governance rigor. These mechanisms filter for commitment and prevent capture — the voting weight formula should be simple. The decision tiers do the heavy lifting.

Binary is maximally legible and fair. Every active crown holder has equal voice. "Is my health above 40? I can vote." No ambiguity, no hierarchy, no second-class citizens. The 40 threshold is generous by design — only truly inactive or abandoned crowns lose their voice.

A separate governance token remains rejected for all the same reasons argued in the Motivation section: securities risk, custody liability, speculation, redundancy, and complexity. Binary crown-weighted governance achieves the same goal (distributing power to active participants) without any of these costs.

Why Graduated Authority with a T+24-Month Time Anchor

Small thresholds create governance theater. At 100 crowns, a "community vote" is a dozen participants — that is a group chat, not governance. At 1,000 crowns, a well-funded actor can plausibly acquire enough governance weight to influence outcomes; the anti-squatting fees are a deterrent, not a wall. The 10,000-crown threshold is set at the scale where the structural defenses — supermajority thresholds, tenure gates, soulbound mechanics, crown holder veto and override — have been exercised under real conditions and where the cost of governance capture is prohibitive.

The T+24-month time anchor on Phase 3 is the protocol's commitment to crown holders that the founder-ratification period does not extend indefinitely. If crown adoption is slower than projected, binding votes activate by calendar regardless. The anchor balances two failure modes: premature decentralization at a 100-crown holder base creates illegitimate "community" outcomes; indefinite founder ratification beyond the bootstrap window undermines protocol credibility. The two-year window is calibrated against typical protocol launch cycles (Compound Bravo at ~T+12mo, Arbitrum at ~T+6mo from token launch, Optimism at ~T+8mo) — OpenCrown's longer window reflects the deliberate decision to not issue a governance token at launch, accepting that crown-weighted governance scales more slowly than token-weighted.

The 500-crown step-down (Phase 2.5) demonstrates good faith before binding votes exist: even with the founder still ratifying OCPs, the veto scope narrows by adoption signal. This is a credibility commitment validated by the public justification log, not a vote-gated transition.

The December 31, 2030 backstop is deliberately aggressive relative to the crown count milestones. It is more likely that 2030 arrives before 1,000,000 crowns than the reverse. This is intentional: the milestones define when the system has proven itself, the date guarantees that no individual retains authority indefinitely regardless of protocol growth.

Why Reactive Veto Prevents Gridlock

Proactive blocking mechanisms (where any stakeholder can prevent a proposal from reaching a vote) create governance gridlock. A small minority can stall the entire system indefinitely. The reactive veto model — overturn after passage — ensures that governance moves forward by default while preserving the community's ability to reject harmful decisions.

The 20% petition threshold, 50% overturn requirement, and 60-day cooling period are calibrated to make vetoes meaningful but not routine. Vetoes should be exceptional events, not standard procedure.

Why a Quarterly Decision Calendar

Ad-hoc proposal submission creates several problems: voter fatigue from continuous voting, low participation from unpredictable timing, and proposal spam from low-cost submission. A quarterly rhythm concentrates governance energy, allows thorough discussion before voting, and creates predictable windows for participation.

The mandatory annual reviews ensure that critical protocol parameters do not ossify through inertia. Even if no crown holder proposes a fee change, the annual review forces the question onto the calendar.

Why Non-Binding Polls With Escalation

Referendums on everything lead to voter fatigue and low-quality decisions. Non-binding polls allow the community to signal preferences without the overhead of formal governance. The escalation mechanism (50%+ participation AND 66%+ support auto-qualifies as Tier 1 proposal) ensures that strong community sentiment cannot be ignored, while the non-binding default keeps routine signaling lightweight.

Why 20/80 Crown Fee Split

The 20/80 split is the minimum rate that makes the DAO self-sustaining without external funding. At projected Y1 volume, 20% of crown fees generates approximately $10,800 against $2,100 in operating costs. Lower rates (5-10%) create existential dependency on operator goodwill or external grants.

The rate is still dramatically more generous to operators than traditional domain infrastructure: traditional domain registries retain 57-86% of registration fees, leaving registrars with 14-43%. OpenCrown retains 20%, and operators keep 100% of their subscription, API, and premium feature revenue — revenue streams the protocol never touches. The effective DAO rate on an operator's full revenue stack is under 13% in Y1 and declines every year as subscription revenue grows.

The 2% protocol deal tax provides a secondary DAO revenue stream tied to deal activity rather than just crown registrations, ensuring the DAO benefits from ecosystem liquidity without relying solely on new crown claims.

Operating Agreement Integration

This OCP fills existing legal framework rather than replacing it:

• Article III, Section 3.2(c) defines the Community Class — this OCP specifies how Community Class voting power is calculated and exercised.
• Article IX defines the progressive decentralization schedule — this OCP specifies what governance rights activate at each phase trigger.
• Section 5.2 defines the founder veto sunset — this OCP specifies the graduated authority transition (full veto → Tier 3-4 veto → emergency brake → convening authority) and the crown holder veto that ultimately succeeds it. The operating agreement's December 31, 2030 hard backstop is preserved as an absolute ceiling on founder authority regardless of crown count milestones.
• Section 5.1 authorizes algorithmic governance — this OCP provides the algorithm.

Why No Delegation in v1

Vote delegation (allowing one crown holder to vote on behalf of another) is deliberately excluded from this initial specification. Delegation creates secondary governance markets — delegates compete for delegated voting power, which reintroduces the same concentration dynamics that governance tokens create. Delegation may be appropriate in Phase 5 when the ecosystem is large enough that direct participation is impractical, but it is premature at this stage. This OCP recommends revisiting delegation as a future OCP after Phase 4 activation.

Backwards Compatibility

This OCP introduces no backwards incompatibilities:

• No changes to existing crowns. Crown NFTs, heartbeat formula, soulbound behavior, and claim/reclaim mechanics are unchanged.
• No changes to heartbeat scoring. The existing 50/30/20 weighted composite (timestamp, volume, holders) is used as-is. Governance weight is a read-only derivation.
• Compatible with existing multisig. Crown votes produce decisions; the multisig executes them on-chain. This extends the existing model rather than replacing it.
• Compatible with existing on-chain roles. The GOVERNOR_ROLE is already defined in the registry contract. Governance weight calculation requires only a new view function, not contract modification.
• No new on-chain state. Crown weight is a simple threshold check against existing heartbeat scores — getGovernanceWeight(crownId) is a pure view function that reads existing storage.
• Fee split is a new parameter. protocolFeeBps and related state variables are additive to the registry contract. The fee split mechanism does not modify existing claim/reclaim interfaces — it adds internal distribution logic.
• Operator registry is additive. On EVM, registeredOperators is a new mapping. On Solana, OperatorRecord is a new PDA account type. Both require operators to be registered before facilitating claims. Existing claim/reclaim transactions that do not specify an operator continue to work (100% to treasury).

Security Considerations

Attack Vectors and Mitigations

Governance Weight Manipulation Resistance

The combination of soulbound mechanics, multi-factor health scoring, snapshot-at-proposal-time, and tenure requirements creates multiple independent barriers to governance weight manipulation. An attacker would need to:

1. Own legitimate tokens (cannot fake ownership due to verification)
2. Maintain real market activity for those tokens over extended periods (cannot fake health)
3. Hold crowns for 7-90 days before voting (cannot time attacks)
4. Achieve this across enough crowns to meet quorum thresholds (cannot use a single crown)

The cost of this attack scales with the governance weight needed — attacking a Tier 1 decision (20% quorum) is expensive; attacking a Tier 4 decision (50% quorum, 80% approval) is prohibitively so.

Legal Considerations

• Soulbound = no expectation of profit. Crown governance weight has no transferable economic value. It cannot be sold, lent, or used as collateral. This structurally eliminates the "expectation of profit from others' efforts" element.
• Wyoming W.S. 17-31-105 authorizes DAO governance via smart contracts, providing statutory basis for algorithmic governance weight calculation.
• Operating agreement Section 5.1 explicitly supports algorithmic governance mechanisms, and this OCP operates within that authorization.

Implementation Roadmap

Voting Infrastructure

This section specifies the voting mechanics: how votes are cast, aggregated across chains, and executed. It complements the governance primitives defined above.

Voting Architecture: Coordinator-Extended

Votes are cast natively on each chain where crowns exist. Cross-chain aggregation uses the existing Coordinator contract pattern — no cross-chain messaging protocols or bridge dependencies.

Per-Chain VoteAggregator

Each supported chain deploys a VoteAggregator contract (EVM) or program (SVM) responsible for:

1. Proposal registration — Storing proposal metadata, snapshot block, decision tier, and voting window
2. Vote collection — Recording crown-weighted votes with support for recasting
3. Local tally computation — Computing per-chain vote totals
4. Cross-chain verification — Verifying the combined result via Merkle proof against the Coordinator's state root

Cross-Chain Aggregation Flow

After a voting period closes on all chains:

1. Each chain's VoteAggregator computes its local tally (for/against/abstain weights)
2. The DAO-operated Coordinator service reads tallies from all chains via standard RPC
3. The service computes the combined result and builds a Merkle tree containing each chain's tally and the aggregate
4. The Merkle root is submitted to each chain's Coordinator contract via setStateRoot()
5. Each chain's VoteAggregator reads the state root from its local Coordinator and verifies its own tally leaf
6. The full Merkle tree and individual vote records MUST be published to IPFS for independent verification

Self-verification property: Each VoteAggregator knows its own local tally. If the Coordinator service submits a root containing an incorrect tally for any chain, that chain's VoteAggregator will reject it. Since the combination is deterministic addition, any dishonesty is detectable by anyone reading all chains' on-chain tallies.

Vote Casting

Crown holders vote on-chain on the chain where their crown exists. Each vote includes:

• Proposal ID
• Support signal (0 = against, 1 = for, 2 = abstain)
• Crown token IDs being used to vote
• Timestamp

The VoteAggregator MUST verify governance weight at the proposal's snapshot block and record the vote. Vote weight equals the sum of governance weights for all specified crown token IDs owned by the voter.

Vote Recasting

Crown holders MAY change their vote at any time during the voting period by submitting a new vote for the same proposal. The VoteAggregator MUST subtract the previous vote's weight from the old tally and add the new vote's weight to the new tally. Only the most recent vote counts at the close of the voting period.

Proposal Events

VoteAggregator contracts MUST emit standardized events for operator notification integration:

• ProposalCreated — Includes proposal ID, proposer, snapshot block, voting window, decision tier
• VoteCast — Includes proposal ID, voter, support signal, weight
• VoteRecast — Includes proposal ID, voter, old support, new support, weight
• ProposalFinalized — Includes proposal ID, pass/fail, total weights, Merkle root
• ProposalExecuted — Includes proposal ID, executor

Operators SHOULD subscribe to these events and surface governance activity to crown holders using their platform. The oc-sdk provides reference implementations for event subscription and voting UI components.

Off-Chain Polls (Pre-M2)

Before VoteAggregator contracts are deployed (M1), opinion polls use EIP-712 signed messages collected by a backend service:

1. Crown holder signs a typed message indicating their poll vote
2. Backend MUST verify signature, crown ownership, and governance weight at the poll's snapshot block via archive RPC
3. Results MUST be aggregated off-chain and published to IPFS
4. Signed vote messages MUST be preserved for independent verification

This approach has zero gas cost for voters and supports free vote recasting (new signature replaces old).

Quorum Tracking

Quorum SHOULD be tracked in real-time for UX purposes (operators display progress) but MUST be evaluated formally only at the voting period close. With vote recasting, quorum counts can fluctuate — final evaluation at close is definitive.

The quorum denominator MUST be the total governance weight of all crowns meeting eligibility requirements for the proposal's decision tier at the snapshot block. Crowns below the health threshold or hold-duration requirement MUST be excluded from the denominator.

Finalization and Execution

After the voting period closes and cross-chain results are aggregated:

1. The Coordinator service MUST submit the combined Merkle root to each chain
2. Each VoteAggregator MUST verify its tally leaf and record the result
3. If quorum and approval thresholds are met, the time-lock period MUST begin
4. After the time-lock expires, anyone MAY call executeProposal() to trigger the on-chain parameter change
5. The DAO treasury MUST pay all finalization gas costs across all chains

Rate Limiting

• Polls (M1): 2 polls per crown per 30-day period, enforced by the backend service
• Proposals (M2+): Rate-limited by the VoteAggregator contract directly. A small proposal deposit (refunded if quorum is met) provides additional anti-spam

Future Decentralization (M4+)

At 10,000+ active crowns (Phase 5), the DAO may evaluate replacing the coordinator service with a decentralized oracle network or cross-chain messaging protocol. The VoteAggregator contracts and Coordinator contracts require no changes — only the entity holding GOVERNANCE_ADMIN_ROLE changes. This is a role reassignment, not an architectural rewrite.

Implementation

Draft merge requests implementing this OCP across the ecosystem:

Copyright

Copyright and related rights waived via CC0.