Skip to main content

CLUE Governance and Management

Governance works as an open system of shared governance: the community stakes CLUE in the governance pool, puts forward ideas, votes and runs decisions directly into on-chain governance processes. The goal is for any changes to the protocol, budgets and parameters to take place transparently, without behind-the-scenes buttons and manual edits.

All logic is embedded in smart contracts and is visible on the blockchain: the treasury is opened smoothly according to a geometric unlock formula, rights and limits are set by voting, and any action leaves an on-chain event trail. This makes management predictable for participants and resistant to human error.

Top-15 active voters
Voting weight snapshot is fixed at proposal creation.
1 day + 1 day execution flow
Grace period for creator, then open execution window.
DAO Treasury geometric unlock
0.008% of remaining balance every 24h.
DAO modelGovernance rolesProposal and treasury flowDAO governance mechanicsContract wiring
DAO Staking PoolGovernance ControlsEconomic ModelDAO Treasury UnlockArbitration MechanicsGovernance/Economic Risks

DAO model​

  • Active composition: taken into account up to 15 addresses with the largest active stake (see DAO staking model); when the limit is full, you can only get into the lineup by staking no less than the weakest participant.
  • Reserve and dynamic minimum: when the limit of active places is full, entry is possible only with a stake higher than the current weakest; in parallel, a reserve list is maintained for automatic roster rotation.
  • Weight of votes and awards: stake × activity% (details in effective weight model); starting activity — 100%, range 5–100%. The weight snapshot is captured when the offer is created; only addresses from this snapshot can vote and receive fines/bonuses.
  • Activity for actions: every vote increases activity by +25 p.p. (but not higher than the maximum); marked omission of voting reduces it by -50 p.p., but not below the minimum (see activity discipline).
  • Voting duration: permissible range 7 days – 30 days (the author chooses a value within the boundaries).
    • For emergency situations, a separate whitelist of addresses is provided, which can create emergency proposals (for example, a protocol pause or a critical parameter fix) with a shortened minimum voting period 12 hours.
    • Even in emergency mode, quorum, weight snapshot, grace and executionWindow are preserved.
  • Default quorum: 50% from snapshot weight; the author can raise the threshold to 100%. Works only with a positive quorum.
  • Making a decision: Yes > No when quorum is met; tie or quorum not met = rejected.
  • Signal proposals: allowed without a target call (target = 0, calldata empty) — record the will of the DAO without on-chain action execution.
  • Finalization and execution: after the deadline the grace period begins 1 day, in which only the creator can finalize and execute the action. Next, executionWindow opens 1 day, where any address can finalize, and the action is executed automatically at the moment of finalization. After the window, anyone can call cancelProposal; if the proposal passes, penalties for non-participation and non-performance apply (see discipline model).
  • Submission mode: by default, only addresses from the whitelist can submit. By DAO voting you can choose: Whitelist only — only pre-approved addresses; DAO only — any current members with non-zero weight; All — any person with correct action. Switching modes is fixed on-chain.
  • Anti-capture guard: if one participant gains ≥ 50% of active weight, the All mode is automatically narrowed to whitelist-only for new proposals (aligned with anti-concentration safeguards).
  • Stake withdrawal: unlock request — 30 days, minimum output delay — 30 days (see governance pool locks).
  • Fee flow without referral: 25% assembled fee (0.75% from the transaction at the base rate 3%) is sent to the DAO and distributed among active participants in proportion to their effective weight (see fee flow and economic split).
  • Paid usernames as additional DAO revenue: paid user aliases (the cost of one username is 10 000 CLUE) generate additional income for DAO Treasury and enhance the value of membership.
  • What DAO regulates: DAO has complete control over the protocol: from changing parameters and turning services on/off to replacing contracts through voting and timelocking (see governance controls). DAO Treasury budgets and spending are also approved and reconfigured by community votes.

Governance Roles​

  • Author of the proposal: generates CIP with metadata and precise action; submission is available in the selected DAO mode (whitelist, dao only, or all), which is enabled by voting and logged as on-chain governance action.
  • Delegates: accept voting powers from DAO stakers, publish the position in advance.
  • Voters: stake or delegate CLUE to participate in voting; weight — according to the snapshot at the time of creation.
  • Finalizers/executors: after the grace period, any address can finalize the proposal within the executionWindow; there is no separate execution step — the action is performed during finalization.
  • Whitelist / emergency submitter: addresses from the whitelist can create emergency proposals with a shortened minimum voting period; they do not receive voting rights beyond the stake.

Treasury management and proposal/voting process​

In CLUE — Governance this is not a “voting page”, but on-chain procedure, which turns community decisions into executable actions in smart contracts. Participants stake CLUE → create a proposal → vote → record the result → perform an action → move funds from the treasury if necessary.

Basic route: new proposal → vote (within vote duration) → grace (finalization only creator) → executionWindow (finalization by any address) → after window cancelProposal.

Important: there are no hidden controls in CLUE and the project does not depend on the creators, who can change the rules or withdraw the treasury at the touch of a button. Any change in parameters, addresses or accesses goes through the same public path in the blockchain (see protocol/interface separation).

Full cycle: from idea to spending the treasury​

  • Preparation. The participant stakes CLUE in the DAO Pool (see governance staking flow); when a proposal is created, the registry records the weights of the current active DAO members and stores them in voting slots.

  • Important: the snapshot is recorded only for the active set (top-N); addresses outside this set do not vote on the proposal (see snapshot discipline).

  • Practical meaning: the composition of voters and their “weight” is fixed at the time of start, so that the balance of power cannot be changed after the fact.

  • Creating a proposal. The author submits a request with a reference to the description (CID), specifies the address of the contract to be called, and the data for this call. The voting duration is selected within acceptable limits: from the minimum allowed to the maximum allowed; if the author does not specify anything, the default period is applied. The submission mode (whitelisted addresses only / DAO stakers only / everyone) determines who can create submissions.

    • Target must be a contract if there is calldata; signal proposals are allowed (target = 0 and calldata is empty) without on-chain execution of an action.
    • From this point on, a public proposal ID and description appear and can be checked in the explorer. The logs also record a hash of the transmitted action data so the community can verify that exactly what was put to discussion is being executed (see event/data flow model).

  • Cancel proposal. Before finalization, the author (or owner of the manager) can cancel the proposal to eliminate erroneous or outdated actions.

  • Voting. The weight is distributed between “Yes” and “No” according to the pre-recorded snapshot. Each vote is published with a link to the rationale; those who vote receive an increase in their activity score, and exceeding the available weight is not allowed.

    • You can vote in parts, rather than “all or nothing.” Each vote is recorded in the log: who voted, how and with what amount of weight, as well as how much weight has already been used.

  • Finalization. After the deadline, the creator can finalize the proposal in the grace period; after grace, anyone can finalize within the executionWindow. Quorum is calculated by snapshot, the outcome is recorded by votes. Finalization immediately executes the action (if target is specified) and records the execution status.

    • If the proposal passes, penalties for non-participation are automatically applied upon finalization (see non-participation discipline).
    • After finalization, you cannot “re-vote”: either the decision is executed at the time of finalization, or the window will be missed and a new proposal will be required.

  • ExecutionWindow. During executionWindow, any address can finalize the proposal if the creator has not done so during grace. The action is performed within finalization; if execution is not initiated by the creator (after grace), a penalty for non-execution is applied to the creator.

  • Cancel after window. After executionWindow has expired, anyone can call cancelProposal. If the proposal passes the votes, fines for non-participation and for non-compliance on the part of the creator are automatically applied.

  • Discipline of participation. Penalties for non-participation are applied automatically when finalizing a previous proposal (outcome Yes) and when canceling after the window. This reduces the effective weight of passive holders and keeps the DAO composition active (see governance anti-passive model).

  • Movement of treasury funds. After a successful decision, the owner of the treasury makes a withdrawal to the agreed address and amount within the unlocked limit; the unlocking itself occurs automatically according to the geometric treasury formula and does not require manual intervention.

    • The treasury is being revealed gradually: only tokens in the “can be withdrawn” status are available. An attempt to take more is rejected, and the output is recorded in the logs.

  • DAO fee share. When fees without a referral or other payments come into the treasury, the registry immediately divides them among active participants according to current weights and records the distribution in the logs (see referral/DAO split branch and fee-flow implementation).

    • The distribution is transparent: the event shows the token, amount, number of recipients and total weight.
    • Accruals go into pending status, and participants collect them via on-chain claim.

The emergency path (if enabled) is limited to whitelisted addresses and uses the same basic principles: snapshot, verified quorum, grace and executionWindow. In emergency mode, a shortened minimum voting period is allowed, but quorum, snapshot, finalization rules and automatic fines are not dispensed with (compare with appeal/auto-resolve emergency branches).

How it works with contracts (explained step by step)​

Briefly linking steps to specific contracts and events.

  • DAORegistry (createProposal / vote / finalize / cancelProposal): when submitting, captures a snapshot of the weights of top participants at the limit activeMembersLimit, validates target/code/calldata and allows signal proposals when target = 0 (see governance execution lane).

    • Submission modes (Whitelist/DaoOnly/All) are applied on-chain; when one participant dominates (≥ 50% effectiveWeight) in the mode All submission is limited to whitelist.
    • For whitelisted addresses, an emergency minimum voting duration is allowed (via emergencyMinVoteDuration), without quorum bypass and snapshot.
    • Finalization: only the creator is available during the grace period; after grace — to any address within the executionWindow. Finalization immediately tries to execute the action (if target is specified) and records the execution status (success/reverted).
    • Penalties for non-participation are applied automatically when a proposal passes; if finalization is not performed by the creator after grace, the creator receives a penalty for non-execution. After executionWindow has expired, anyone can call cancelProposal; if outcome = Yes, penalties are applied automatically (see DAO participation discipline).

  • DAOManager: stores the DAO configuration: voting duration boundaries, defaultVotingPeriod, defaultQuorumBps, resolveGracePeriod, executionWindow, separate emergency minimum for whitelist, active participant limit and reserve (activeMembersLimit, extraReserveStakers), activity steps and their range, as well as unstake/withdrawal parameters. All changes are available only to the owner (DAO via timelock) and are enacted through on-chain decisions (see governance parameter control).

  • DAOPool: management role staking. Stores stake, counts effectiveWeight = stake × activity%, a snapshot of this weight is included in the proposal. When the limit is full, a dynamic minimum applies: in order to enter the active roster, a new participant must exceed the weakest; a backup queue is supported. The unstake goes through a request and a queue, with delays specified by the DAO. Active voters receive an increase in activity by calling rewardActivity, passes are recorded automatically when finalizing/cancelling past proposals (see DAO staking lifecycle).

    • Practical result: those who vote systematically increase their activity% and their effective weight; passive holders lose weight and share of rewards.

  • DAORewardsDistributor → DAORegistry: fee share without referral and other income comes to the distributor, who forwards them to the registry. He calls distributeDaoRewards and divides the amount in proportion to the current weights of active stakers from the top-N snapshot (activeMembersLimit). Accruals are recorded as pending and are collected by participants via claimDaoReward. All counters are written to ClueAccounts and logged by the event DaoRewardsDistributed with the fields token/amount/number of recipients/total weight (see economic fee model and fee data flow).

  • DAOTreasury — a separate safe of the CLUE token with a mathematical “drop” (details in DAO Treasury tokenomics section).

    • Every 24 hours automatically released 0.008% remaining balance.
    • Constant RELEASE_RATE_BPS = 8 in the contract.
    • ≈ 2.9% per year according to the formula:
1−(1−0.00008)3651 - (1 - 0.00008)^{365}

DAO Governance Mechanics​

The mechanics of DAO governance are designed so that influence is calculated by stake and activity, the DAO remains “alive” and protected from passive holders, proposal submission modes can be flexibly chosen, and incentives encourage participation (see governance staking model).

Our goal is to combine two things: security (treasury and parameters are protected by procedure and limits) and controllability (the community can actually change the protocol without waiting for a command). That is why the mechanics include both “carrots” (rewards for active participants) and “fuses” (quorum, execution windows, treasury restrictions, fines for non-participation).

Influence: what weight is made of​

In CLUE, not only the size of the stake is important, but also participation in the life of the DAO. Therefore, the effective weight is used (same model as DAO stake weighting):

effectiveWeight = stake × activity%

This means that two participants with the same stake can have different real weights if one votes consistently and the other systematically ignores proposals.

  • Stake — actual staked CLUE in DAOPool.
  • Activity% — coefficient in range 5–100%, changing with participation/non-participation.
  • Active composition (top-N) — key voting/distribution operations use limited most-significant participant set via activeMembersLimit (see rotation logic).

Proposal submission: who can initiate changes​

The protocol provides submission modes so that the DAO can choose the level of openness at different stages of development:

  • Whitelist — proposals can only create pre-authorized addresses (for example, for "emergency" or for an early stage).
  • DaoOnly — DAO members (stakers with voting rights) can create proposals.
  • All — a proposal can create any address if it is valid according to the rules (target/call).

The mode is not an “admin setting”, but an on-chain parameter that is updated by the DAO procedure (see ProposalSubmitModeUpdated and DaoWhitelistUpdated events in DAORegistry) and aligns with protocol-first governance execution.

Participation discipline: why skipping votes is unprofitable​

Governance breaks down when large stakers don't participate (or only participate when they need to). Therefore, CLUE provides transparent discipline mechanics:

  • Plus for participation. When voting, rewardActivity is called in DAOPool, increasing activity%.
  • Minus for non-participation. Fines are calculated automatically when a previous offer is finalized (outcome Yes) or when canceled after the window; there is no longer a separate call penalizeNonVoters.
  • Effect. Over time, the passive participant loses effectiveWeight, and therefore the influence and share of the DAO income distributions (see DAO discipline impact).

Capture protection and emergency modes​

  • Top-N + reserve: voting is carried out only by active participants (top-N), the reserve ensures rotation and reduces concentration (see DAO rotation mechanics).
  • Dynamic entry minimum: with a full limit of active places, the new staker should surpass the weakest one, which reduces the risk of “smearing” influence with small addresses.
  • Dominance guard: at ≥ 50% effectiveWeight in one participant, submission mode All is limited to whitelist (aligned with anti-whale safeguards).
  • Timelock execution: there is a grace period before execution, which gives time for the community to react.
  • Penalty for non-compliance: if the creator did not finalize the proposal to the end of grace and another address completed it (or the proposal was canceled after the window), the creator receives an automatic activity penalty.
  • Emergency feed: whitelisted addresses can run proposals with a shortened minimum voting period, but without quorum bypass or snapshot.
  • Unbonding/withdraw delay: exit from a stake is not instantaneous and is performed with delays, which reduces the risks of sudden exit after voting (see staking lock models).

Treasury safety: why one vote cannot instantly drain funds​

The treasury DAOTreasury is protected not only by the voting procedure, but also mathematical limit on output speed (see DAO Treasury release model). Even if the DAO decides to “withdraw a large amount”, the contract will not physically allow you to withdraw more than what has already been unlocked according to the formula. This eliminates the “one vote → instant treasury drain” scenario.

Unlocking works like this geometric stream: every 24 hours automatically released 0.008% remaining balance (rather than a fixed percentage of total). Therefore, the rate of release decreases over time: at the beginning, more is released in absolute terms, then less and less.

Any output goes through a limit check:

withdraw(to, amount) compares amount against availableToWithdraw().

If you try to withdraw more than what is available, the transaction will be rejected.

So the DAO manages direction and appointment funds (to whom/where/why), but cannot speed up the “release” from the treasury beyond the given formula.

DAO Governance Diagram​

Stake → Snapshot → Proposal → Voting → Execution → Treasury Withdraw

Governance execution path
Stake CLUE in DAO PoolAcquire effective weight for proposals and distributions.
→
Submit proposalCreate an on-chain action or signal proposal.
→
Vote For / AgainstSnapshot weight determines the outcome and participation discipline.
→
Execute proposalFinalization runs the approved on-chain action during the execution window.
→
Release DAO Treasury CLUEWithdraw only the amount unlocked by the treasury formula.

Technical contract wiring​

Technical contract wiring: how modules are connected and which component is responsible for each function. All key contracts in the CLUE ecosystem are managed through the DAO governance loop (owner routing in practice is configured through DAORegistry/DAOExecutor and, if necessary, timelock at deployment), so any changes, limits, and withdrawals go through DAO decisions (see system-level governance wiring).

DAORegistry - proposals, voting, execution​

  • Creation: createProposal(metadataCid, target, actionCalldata, votingPeriod, quorumBps) checks the validity of the action (target/code/calldata), duration boundaries and correct quorum. The weight snapshot is captured by top-N, and the parameters resolveGracePeriod and executionWindow are copied from DAOManager. Logs ProposalCreated (including actionCalldataHash, compare with data flow logging).
  • Voting: vote(id, choice, weight, voteMetadataCid) works only for addresses with snapshot weight; limits the total weight used and logs ProposalVoted.
  • Finalization and execution: finalize(id) is only available after votingDeadline and before executionDeadline = votingDeadline + grace + executionWindow.
    • During the grace period, only the creator can complete it; after grace — any.
    • Finalization counts the quorum, sets the outcome, and automatically applies penalties for non-participation if the proposal passes.
    • If outcome = Yes and target is given, the call is executed immediately; the result is recorded in ProposalActionExecutionResult, and executionStatus takes the value success/reverted.
    • If the execution was not performed by the creator after grace, the creator receives a penalty for non-execution.
  • Cancel: cancelProposal(id) is available to the creator/owner until executionWindow expires. After the window, any address can cancel. If outcome = Yes, penalties for non-participation and an additional creator penalty for non-compliance are automatically applied.
  • Submission mode and whitelist: setProposalSubmitMode, setDaoWhitelist (available to the manager owner) log ProposalSubmitModeUpdated and DaoWhitelistUpdated.

DAOTreasury - limited treasury​

  • Condition: totalWithdrawn takes into account the total amount withdrawn from the treasury. The base budget is fixed upon initialization: fixedBudget = balance + totalWithdrawn at the time initializeBudget(); then _totalBudget() returns exactly fixedBudget.
  • Unlock: unlockedAmount() simulates a geometric “drop” with a step of 1 day (RELEASE_INTERVAL) and a rate RELEASE_RATE_BPS (same profile as DAO Treasury tokenomics).
  • Available for output: availableToWithdraw() = unlocked − totalWithdrawn.
  • Withdrawal: withdraw(to, amount) is accessible only to the owner and checks the limit; logs TreasuryWithdrawal(to, amount, totalWithdrawn).
  • Preview: previewReleasedAt(timestamp) shows unlocked/withdrawable for a given time.

DAOPool / DAOManager / ClueAccounts — weight, activity, accounting​

  • DAOManager sets boundaries and defaults (duration, quorum, execution window, limit of active participants, etc.).
  • DAOPool maintains the stake and computes effectiveWeight, and also implements rewardActivity/penalizeActivity (see DAO pool mechanics).
  • ClueAccounts stores counters/accounting (proposal creation, votes, fines, execution, etc.), which makes the behavior of participants measurable and verifiable (compare with protocol accounting/data flows).

For full context around governance and management, use these canonical sections across docs/protocol: