Governance starts by asking who should decide.
Kokonut’s Governance Framework is the process for moving a decision from problem → review → authorization → execution → evidence → learning. The first question is not:“How do we put this to a DAO vote?”It is:
“Which authority actually owns this decision?”A treasury allocation belongs in Moloch governance. A routine irrigation decision belongs with farm operators. An MRV claim belongs with the relevant evidence reviewers. A shared schema change belongs with Framework and affected domain reviewers. A Guild bounty may begin with contributors and only move into Moloch when shared treasury capital is required.
Understand the authority map
See how capital governance, contribution, farm operations, shared methodology, evidence, and technical execution remain separate.
Use a proposal template
Start from a structured template when the decision actually requires a formal proposal.
Inspect live DAO state
Verify current Moloch membership, proposals, parameters, and execution state before relying on static documentation.
Draft and discuss
Use the current Kokonut collaboration space for proposal drafting, review, and discussion.
Governance at a glance
Passing a proposal is not the same as completing the work. Governance authorizes. Operators, contributors, contracts, SAFEs, or other responsible actors still have to execute the approved scope correctly.
Step 1 — classify the decision before drafting a proposal
Not every decision needs the same governance path.A decision can require multiple reviews without giving one reviewer authority over every part of the decision.
Step 2 — define the problem and the authority being requested
Before a formal draft, the author should be able to answer:- What problem are we trying to solve?
- Who is affected?
- Which authority is being requested?
- Is the proposal asking for money, token issuance, policy, recognition, technical work, or coordination?
- Which parts are within Moloch scope?
- Which parts remain with farm operators, Guilds, Framework reviewers, or evidence reviewers?
- What evidence supports the need?
- What happens if the proposal is not approved?
Example
A farm-funding proposal can authorize:- a treasury budget;
- payment milestones;
- reporting obligations.
- day-to-day crop decisions;
- scientific conclusions;
- control of locally owned land;
- publication of unsupported impact claims.
Step 3 — use the right review path
A proposal should be reviewed by the people affected by its content before a binding vote.Review is not voting. A domain reviewer can say whether a proposal is technically or methodologically ready without having Moloch voting power. A Moloch voter can decide whether to authorize shared capital without becoming the domain expert.
Step 4 — draft the proposal
The current Proposal Templates use a common ten-field base structure. That is a documentation and review standard, not a claim that every community conversation is a ten-field constitutional motion.Current ten-field base
Proposal-specific templates can add stronger requirements.
For example, farm funding should include farm context and evidence; a Framework change should include compatibility and migration implications.
Step 5 — drafting and feedback
Current Kokonut documentation uses a minimum 5-day drafting window for material proposals. During that window, contributors should be able to challenge:- the problem statement;
- scope;
- budget;
- assumptions;
- evidence;
- authority boundaries;
- risks;
- success metrics;
- execution plan.
The 5-day period is the current documented baseline, not an argument for rushing complex proposals on day six. Higher-risk proposals may need more review.
Step 6 — sponsorship / activation
A draft does not become a binding Moloch vote merely because the author wants it to. The current process requires an authorized sponsorship / activation step before the binding on-chain stage. This page intentionally does not hard-code a permanent list of sponsor roles. Why? Because sponsorship permissions and operating roles can change, while the durable principle is:Someone with the current authority to activate the proposal must take responsibility for moving it into the formal voting process.Guild Stewards or domain coordinators can help mature and route proposals, but the Guild role system itself is still evolving and should not be treated as an immutable source of on-chain sponsorship rights.
Step 7 — choose the right decision venue
Binding Moloch actions
Use Moloch / DAOHaus when the proposal requires actions such as:- moving DAO treasury funds;
- onboarding a Moloch member;
- minting $vKKN;
- awarding Loot;
- changing DAO-level governance parameters;
- another binding action enforced through Moloch contracts.
Coordination and signaling
A working group, Guild, Forum, or community process can be sufficient for:- non-binding feedback;
- signaling;
- work prioritization;
- domain discussion;
- routine coordination within an already authorized scope.
Step 8 — Moloch voting, grace, and retention
For binding Moloch actions, the current documentation describes:
These values should be treated as current governance parameters, not permanent natural laws.
Verify the live DAO before acting.
Binding proposal flow
Step 9 — distinguish authorization from execution
A passed vote creates authority. It does not guarantee correct implementation. There are at least three execution layers to distinguish.
For example:
The DAO can authorize irrigation infrastructure funding.That does not mean:
The infrastructure has been purchased, installed, tested, and is operating correctly.
Step 10 — report evidence after execution
Every funded or material proposal should produce a closeout trail. Useful evidence can include:- transaction references;
- payment records;
- receipts;
- GitHub commits;
- deployed contracts;
- farm records;
- MRV evidence;
- photos;
- datasets;
- signed agreements;
- milestone reviews;
- acceptance records;
- variance explanations.
Proposal status model
A more useful governance lifecycle is: A proposal should not be considered fully successful merely because its transaction executed.Current minimum timeline
For a binding proposal that follows the current documented baseline:This is a minimum-process illustration, not a guaranteed calendar. Complex proposals can require more drafting, reviews, revisions, signatures, dependencies, or implementation time.
Proposal quality standard
A strong proposal makes both the decision and the later audit easier.Material changes after approval
Execution sometimes reveals that the approved plan cannot be followed exactly. Minor implementation details can be handled within the approved scope. Material changes should be surfaced. Examples include:- substantial budget changes;
- new recipient wallets;
- major scope changes;
- different contractual obligations;
- changes to token issuance;
- changes to farm ownership / operator commitments;
- altered success criteria;
- materially different timelines where the timing was part of the approval.
- publish the variance;
- explain why the original plan no longer works;
- identify the new risk;
- determine whether the existing authorization still covers the change;
- submit an amendment or new proposal when it does not.
Governance approval should not become a blank check for execution drift.
Rejected and withdrawn proposals
A rejected proposal is not automatically a failed idea. It means the proposal did not receive the required authorization in that form. A useful resubmission should explain:- what was rejected or contested;
- what changed;
- which evidence improved;
- whether the budget changed;
- whether the authority request narrowed;
- what reviewer feedback was addressed.
Governance protections — and their limits
Conflict of interest
Proposal authors, reviewers, recipients, and voters can have overlapping interests. A strong proposal should disclose material conflicts such as:- author is also the proposed payee;
- reviewer has a financial interest in the vendor;
- Guild coordinator is selecting their own bounty;
- partner negotiator is financially connected to the counterparty;
- farm reviewer is also responsible for the metric being evaluated.
Governance should preserve domain review
A Moloch vote can authorize capital. It should not overwrite a failed technical, scientific, legal, or farm-operating review. Examples:Impact claims
Token holders should not vote an unsupported ecological claim into being scientifically valid.
Farm operations
A budget approval does not convert token holders into the farm’s daily operating authority.
Shared schemas
A funded implementation should still preserve compatibility and affected-domain review.
Partnership obligations
DAO enthusiasm does not remove legal, operational, or counterparty diligence requirements.
AI and automation in governance
AI agents can support governance by:- drafting proposal sections;
- checking required fields;
- summarizing feedback;
- comparing budgets;
- surfacing missing evidence;
- preparing execution payloads;
- generating draft status reports.
- sponsor themselves;
- vote with autonomous political discretion;
- approve treasury spending;
- fabricate evidence;
- declare domain review complete;
- change governance rules silently.
Governance automation should reduce clerical work while preserving accountable human authorization for high-impact decisions.
Before moving a proposal to a binding vote
1. Confirm the authority
Make sure the proposal is asking Moloch to decide something Moloch actually controls.
2. Complete the relevant domain reviews
Farm, Impact, Technology, Finance, Framework, Governance, partnership, or other affected reviewers should review the proposal as appropriate.
3. Verify the evidence and budget
Link the source records, assumptions, recipients, amounts, milestones, and acceptance criteria.
4. Complete the draft window
Follow the current minimum review period and allow more time when the risk or complexity justifies it.
5. Confirm current live governance rules
Check DAOHaus and the current governance documentation for sponsorship, voting, quorum, grace, retention, and execution conditions.
6. Define execution and closeout
Name who executes, what evidence will be produced, how material changes are handled, and what closes the proposal.
Use the right page for the right governance question
Continue through The Kokonut DAO
Proposal Templates
Turn a correctly routed decision into a structured, reviewable proposal.
Kokonut Moloch DAO
Review the live capital-governance mechanics behind voting, grace, retention, rage-quit, and treasury execution.
Kokonut Guilds
Understand contribution records, domain review, developing Guild Points, stewardship, and proposal preparation.
DAO Architecture
See why governance authority is separated across capital, contribution, farms, methodology, evidence, and technical execution.
Kokonut Forum
Draft proposals, collect feedback, and make review visible before binding action.
DAOHaus
Inspect current Moloch proposals, voting, membership, and live DAO state.
Good governance is not the process of voting on everything. It is the process of making authority, evidence, authorization, execution, and accountability clear enough that the right people can make the right kind of decision.