​

Kokonut is not governed by one DAO.

Kokonut uses different coordination systems for different kinds of responsibility. The Moloch DAO governs capital and treasury-level decisions. Guilds coordinate useful work and domain expertise. Farm operators remain responsible for day-to-day agricultural execution. The Kokonut Framework provides shared methods and data structures. MRV, the Kokonut Hub, and Kokonut Intelligence make claims easier to inspect. Contracts and automation execute or support authorized workflows without becoming independent governance authorities.

The design principle is simple: give each responsibility the narrowest authority it needs, then connect the layers through evidence, proposals, shared standards, and review.

---

​

Six scopes of responsibility

The architecture is easier to understand as six scopes of authority, not a top-down chain of command. This architecture is designed around interoperability without sovereignty by one layer.

---

​

Who decides what

A governance system becomes fragile when authority is ambiguous. This matrix defines the intended boundaries.

---

​

How to route a decision

---

​

The architecture as a coordination loop

The important flow is not “token holders command the network.” It is: capital can authorize resources → contributors and operators execute work → evidence records what happened → evidence improves the next decision.

---

​

1. Capital governance — Kokonut Moloch DAO

The Kokonut Moloch DAO is the live capital-governance system. The current documentation describes it as deployed on Gnosis Chain and responsible for:

• stablecoin-based membership proposals;
• treasury allocation;
• proposal voting and execution;
• $vKKN issuance through approved membership proposals;
• Loot recognition through approved proposals;
• rage-quit protections under the applicable Moloch rules;
• governance-parameter changes.

​

Current token roles

The current Kokonut model also relates $vKKN issuance to coconut trees. That relationship belongs to the Moloch/token model; it should not be interpreted as meaning the token controls the underlying farm, tree, land title, or agricultural decisions.

---

​

2. Contribution coordination — Kokonut Guilds

The Kokonut Guilds provide the contribution path. They exist because useful work and capital contribution are different forms of participation. The current Guild domains are:

• Technology;
• Impact;
• Communications;
• Governance;
• Finance;
• Community & Partnerships.

A contributor can begin with useful work such as:

• code;
• documentation;
• MRV review;
• farm research;
• financial modeling;
• governance work;
• partnerships;
• field or community coordination.

​

Contribution lifecycle

Significant contributions can become eligible for Loot recognition, but Loot awards still require the applicable Moloch DAO proposal and approval process.

---

​

3. Farm operations — local authority stays close to the land

Farm operations are not a DAO subcommittee. They are real-world agricultural responsibilities. At a Kokonut farm, local operators can be responsible for decisions such as:

• what and when to plant;
• irrigation timing;
• crop rotation and succession;
• soil and nutrient management;
• pest and disease response;
• harvesting;
• labor coordination;
• maintenance;
• local supplier and buyer relationships;
• adaptation to weather and field conditions.

A treasury proposal can approve capital for irrigation. It should not tell an operator when to irrigate. A Framework can define a harvest-record structure. It should not decide which crop is locally appropriate.

Shared governance should increase local operating capacity, not convert agricultural judgment into token voting.

---

​

4. Shared methodology — Kokonut Framework

The Kokonut Framework is the interoperability layer. It provides reusable structures such as:

• the Common Data Schema;
• development phases;
• regenerative principles;
• MRV expectations;
• value-accounting methods;
• impact-reporting logic;
• shared terminology and documentation.

The Framework helps multiple farms use compatible records without requiring identical implementation.

​

Framework authority is narrow

The Framework can define:

• what a baseline record should contain;
• what evidence a claim should provide;
• how a development phase is documented;
• how shared schemas remain compatible.

It should not define:

• every farm’s crop mix;
• local ownership;
• local labor arrangements;
• day-to-day agronomy;
• local cultural priorities.

---

​

5. Evidence — MRV, Hub, and Kokonut Intelligence

Evidence is a coordination layer, not a governance constituency. The MRV methodology separates: observation → structured record → review → publication → optional attestation → interpretation Kokonut Intelligence provides the active data and analytical infrastructure around those records. The Kokonut Hub provides a public surface for published project and farm information. Evidence can inform:

• funding review;
• farm operations;
• forecast updates;
• Guild work;
• grant reporting;
• governance decisions;
• Framework improvements.

Evidence does not become true because the DAO voted for it. And an on-chain attestation does not become scientifically correct simply because it is timestamped.

---

​

6. Technical execution — authorized systems, not autonomous rulers

Contracts, SAFEs, APIs, and agent workflows are execution infrastructure. Their job is to make authorized processes more reliable.

​

Gnosis Chain

Current Kokonut documentation uses Gnosis Chain for:

• Moloch governance;
• membership;
• treasury execution;
• $vKKN and Loot;
• proposal-related contract logic.

​

Celo

Current Kokonut Intelligence documentation uses Celo for:

• EAS farm-data attestations;
• MRV evidence references;
• harvest and impact records;
• other evidence-oriented schemas.

Governance capital and farm evidence are connected, but they are not the same system and they do not need to live on the same chain.

​

AI agents

AI-agent workflows are a developing support layer for tasks such as:

• MRV draft preparation;
• data-quality checks;
• forecast-vs-actual analysis;
• proposal formatting;
• evidence packaging;
• recurring reporting.

Agents should not independently:

• approve treasury spending;
• certify scientific claims;
• replace farm operators;
• grant themselves governance authority;
• silently change shared schemas.

---

​

Two participation paths — plus local operating roles

The original architecture page described two entry paths. Those remain useful, but the broader ecosystem has more than two forms of participation. This is plural participation, not one ladder where every participant eventually becomes the same kind of governor.

---

​

What requires Moloch approval — and what usually does not

​

Typically Moloch-level

• treasury spending;
• membership;
• $vKKN issuance;
• Loot awards;
• DAO governance changes;
• network-level funded commitments;
• funded Guild bounties when treasury capital is required.

​

Typically outside direct Moloch control

• routine farm operations;
• scientific or methodological review;
• ordinary documentation edits;
• Guild-internal work that does not require treasury authority;
• data-quality review;
• agronomic decisions;
• routine software development within an already approved scope.

A decision can move into Moloch when it requires shared capital or changes DAO-level rules. That does not mean Moloch becomes the subject-matter authority over the entire underlying domain.

---

​

Why this separation matters

---

​

What this architecture is not

---

​

What is live and what is still evolving

Transparency about maturity is part of the governance model. A developing mechanism should not be described as if it already carries the same authority as a live contract or operating farm.

---

​

Use the right page for the right question

---

​

Continue through The Kokonut DAO

Kokonut’s governance architecture is strongest when no layer has to pretend it is qualified to govern everything.