Kokonut Guilds coordinate useful work without requiring capital first.
The Guild system is Kokonut’s contribution path. It exists because useful work, domain expertise, and capital contribution are different forms of participation. A developer should not need to tribute stablecoins before fixing infrastructure. An agronomist should not need $vKKN before reviewing a farm method. A researcher should not need treasury voting power before improving an MRV claim. A community coordinator should not need capital membership before helping a farm or partner relationship move forward.Guilds make contribution legible: what was done, who did it, what evidence supports it, which domain should review it, and when the work needs to move into Moloch governance.
Start contributing
Begin with a bounded, reviewable contribution in agriculture, research, MRV, software, governance, finance, documentation, or partnerships.
Join the community
Meet contributors, discuss a task, and find the domain where your skills can be useful.
Understand capital governance
See when Guild work needs treasury authorization, Loot recognition, or another formal Moloch action.
Understand the full architecture
See how Guilds fit alongside Moloch, farm operators, the Framework, MRV, and technical execution.
Guild coordination is active. Guild Points are still developing. Contribution records, domain review, working groups, and proposal preparation can happen today. Point thresholds, formal standing rules, voting weight, elections, and on-chain reputation should not be treated as fully mature or automatic.
What Guilds are responsible for
Guilds are domain coordination groups. They can help:- identify useful work;
- define acceptance criteria;
- review contributions;
- maintain domain knowledge;
- coordinate working groups;
- prepare bounty scopes;
- recommend standards;
- draft or improve proposals;
- surface risks and dependencies;
- recommend significant contributors for broader recognition.
- the DAO treasury;
- $vKKN issuance;
- Loot issuance;
- local farm operations;
- scientific truth outside appropriate review;
- every Framework change;
- every technical deployment.
Guilds influence work through expertise and contribution, not because they sit above farm operators, the Framework, MRV reviewers, or the Moloch DAO.
Six current Guild domains
These domains are coordination surfaces.
They are not exclusive professions.
A single contribution can involve more than one Guild.
The current contribution lifecycle
The most durable part of the Guild model is not a point number. It is the contribution record and review process.1. Do useful work
Examples include:- code;
- documentation;
- MRV analysis;
- field records;
- financial models;
- governance reviews;
- research;
- partnership coordination;
- design;
- community operations.
2. Create a contribution record
A useful record should identify:3. Review the work
The relevant reviewers determine whether the contribution meets the expected standard. Review can consider:- factual accuracy;
- technical quality;
- evidence;
- compatibility;
- scope;
- local context;
- impact on other systems;
- whether the work actually satisfies the task.
4. Build contribution history
Accepted work can become part of a contributor’s visible record. That history is more durable than any single reputation score.5. Route formal actions when needed
If the work requires:- DAO treasury capital;
- Loot recognition;
- DAO-level governance changes;
- formal token actions;
- another Moloch-scoped commitment;
Guild Points — designed reputation, still developing
Guild Points are intended to represent non-transferable contribution reputation within a domain. The current design principle is:Reputation should come from reviewed work, not from buying a token.That principle is established. The exact implementation is still maturing.
Current design intent
Guild Points are intended to be:- contribution-based;
- non-transferable;
- domain-specific;
- tied to reviewable work;
- separate from $vKKN;
- separate from Loot;
- usable as one input into contribution standing.
Still developing
The following should not be treated as fixed live rules unless a current Guild process explicitly defines them:- point values per contribution;
- minimum thresholds;
- active-member thresholds;
- voting weight;
- expiration or activity windows;
- cross-Guild portability;
- steward-election mechanics;
- on-chain representation;
- automatic eligibility rules.
Contribution standing should be evidence-first
The old Guild documentation describes four tiers: Contributor → Member → Steward → Emeritus That remains a useful target operating model, but the specific thresholds and rights are not mature enough to present as universal live rules.The important principle is progressive responsibility based on demonstrated contribution. The exact role mechanics should be published and reviewable before they are used to allocate formal authority.
Stewardship is a function, not a title alone
A Steward should be understood as a contributor trusted to help coordinate a domain. Possible stewardship responsibilities include:- maintaining an active work queue;
- defining review criteria;
- helping new contributors find bounded tasks;
- reviewing contributions;
- identifying cross-Guild dependencies;
- documenting decisions;
- helping mature work become a proposal;
- surfacing conflicts or risks;
- making sure completed work is recorded.
- unilateral treasury authority;
- permanent office;
- automatic Moloch voting power;
- authority over local farm operations;
- authority to self-award Loot;
- authority to declare scientific claims verified without the relevant review.
- selection method;
- term;
- review/removal method;
- conflicts of interest;
- decision scope;
- escalation path.
Technology Guild
Domain: software, data, contracts, automation, and developer infrastructure. Useful work can include:- smart-contract tooling;
- DAO interfaces;
- Farm Registry and API work;
- MRV pipelines;
- dashboards;
- schema validators;
- Kokonut Intelligence integrations;
- agent workflows;
- tests;
- technical documentation.
Review boundary
Technology review can determine whether software is technically sound. It does not automatically determine:- whether an ecological methodology is valid;
- whether treasury funds should be spent;
- whether a farm operator should adopt a workflow;
- whether a shared schema change is acceptable without affected-domain review.
Impact Guild
Domain: MRV, ecology, evidence, sustainability, and impact interpretation. Useful work can include:- MRV methodology;
- field-evidence review;
- remote-sensing analysis;
- biodiversity records;
- soil evidence;
- SDG mapping;
- EBF interpretation;
- CRISP risk review;
- impact-report preparation.
Review boundary
Impact review can assess whether evidence supports a claim. It does not automatically:- certify a regulated environmental credit;
- approve treasury spending;
- control farm operations;
- convert an EAS attestation into scientific truth.
Communications Guild
Domain: documentation, education, onboarding, and public communication. Useful work can include:- documentation;
- ecosystem updates;
- contributor onboarding;
- educational assets;
- proposal explainers;
- grant narratives;
- public progress summaries;
- visual communication.
Review boundary
Communications should improve clarity without turning:- forecasts into actuals;
- project intent into achieved impact;
- developing systems into live systems;
- marketing language into unsupported evidence claims.
Governance Guild
Domain: decision process, proposal quality, roles, and accountability. Useful work can include:- proposal review;
- governance documentation;
- process diagrams;
- amendments;
- onboarding;
- decision records;
- facilitation;
- role definitions;
- cross-Guild coordination.
Review boundary
Governance contributors can improve the process. They do not automatically:- decide treasury outcomes outside the formal Moloch process;
- override domain experts;
- command farm operators;
- create Moloch voting rights.
Finance Guild
Domain: financial analysis, budgets, treasury reporting, and farm economics. Useful work can include:- budget models;
- forecast review;
- scenario analysis;
- treasury reporting;
- grant finance;
- farm economics;
- public-goods allocation modeling;
- financial diligence.
Review boundary
Finance analysis can improve a funding decision. It does not turn a forecast into realized revenue or grant authority to move DAO funds without the applicable approval. The current Adelphi documentation also contains an unresolved 10% vs. 40/40/20 public-goods allocation inconsistency, which is an example of the kind of cross-document financial issue that should be reconciled before being used as a binding model. Review the Adelphi forecast model →Community & Partnerships Guild
Domain: relationships, onboarding, local coordination, and ecosystem partnerships. Useful work can include:- farmer onboarding;
- partner research;
- local events;
- institutional relationships;
- ReFi collaborations;
- MOU preparation;
- coordination notes;
- new-farm pipeline research.
Review boundary
Relationship-building does not automatically authorize:- a binding legal agreement;
- DAO treasury spending;
- commitments on behalf of a farm operator;
- claims about a partner that have not been verified.
How Guild work connects to Moloch
Guilds and Moloch solve different coordination problems.Routing model
Guilds can recommend and prepare. Moloch authorizes Moloch-scoped actions.
From contribution to Loot
Guild Points, contribution history, and Loot are different concepts.Contribution history
The evidence that useful work happened.Guild Points
A developing reputation mechanism intended to summarize reviewed contribution within a Guild.Loot
A live, non-voting token primitive under the current Moloch model that can be awarded through a DAO proposal. A contribution-to-Loot path can look like:1. Complete meaningful work
Produce a durable contribution with clear evidence and acceptance criteria.
2. Get domain review
Relevant reviewers determine whether the contribution is accepted.
3. Build a contribution record
Preserve the contribution, evidence, reviewer, and outcome in a reusable record.
4. Consider DAO-level recognition
If the contribution creates significant durable value, the Guild or other participants can recommend broader recognition.
5. Submit a Loot proposal
Loot issuance enters the normal Moloch proposal process.
6. Moloch decides
Eligible $vKKN holders decide whether the proposed Loot award is approved.
Loot should not be described as an automatic promotion from Guild Points. The contribution record supports the case; the Moloch proposal is the authorization mechanism.
Bounties and paid work
A Guild can help define a bounty by specifying:- problem;
- deliverable;
- owner;
- acceptance criteria;
- reviewer;
- dependencies;
- budget;
- timeline;
- evidence required for completion.
Cross-Guild work
Many useful contributions cross domains. Examples:
The goal is not to create committee overhead.
The goal is to avoid one Guild approving work outside its competence.
Relationship to farm operators
Guilds can support farms. They do not replace farm operators. A Guild may:- research a crop method;
- build a dashboard;
- review a budget;
- improve MRV;
- prepare a funding proposal;
- document a process;
- coordinate a partner.
- change the crop plan;
- direct labor;
- change irrigation timing;
- commit a farm to a partner agreement;
- publish sensitive farm information;
- override local operating judgment.
Expertise should travel through the network. Operational authority should remain close to the farm.
Relationship to the Framework and MRV
Some work belongs partly in a Guild and partly in a shared methodological process.Framework changes
A Technology, Impact, Governance, or other Guild may propose improvements to:- schemas;
- development phases;
- evidence requirements;
- shared terminology;
- reporting logic.
MRV review
Impact and Technology contributors can help with:- evidence structure;
- validation;
- remote sensing;
- data tooling;
- attestation workflows.
What is live and what is still developing
Transparency about maturity protects contributors from being promised rights or rewards that are not yet operational.
What the Guild model is not
Not pay-to-participate
Capital is not required to begin contributing.
Not automatic reputation
Work should be reviewed before it becomes recognized contribution history or reputation.
Not automatic Loot
Significant work can support a Loot proposal; it does not self-mint a DAO token.
Not shadow treasury governance
Guilds can recommend budgets, but Moloch authorizes DAO treasury actions.
Not remote farm management
Domain expertise can support operators without replacing their real-world authority.
Not expertise by title
A role or point balance should not substitute for evidence, competence, or appropriate review.
How to start contributing
1. Choose a useful problem
Start with a bounded issue, documentation gap, research question, MRV need, technical task, governance improvement, financial review, or partnership task.
2. Identify the review domain
Decide which Guild or combination of Guilds is best positioned to review the work.
3. Define evidence before doing the work
Know what artifact will demonstrate completion: PR, report, dataset, model, field record, design, proposal, or coordination outcome.
4. Submit something reviewable
Make the contribution easy for another person to inspect.
5. Record the outcome
Preserve what was accepted, who reviewed it, and what should happen next.
6. Route formal actions only when needed
Move into Moloch governance when treasury, token, or formal DAO authority is actually required.
Continue through The Kokonut DAO
DAO Architecture
See the boundaries between Moloch, Guilds, farm operators, Framework stewardship, evidence review, and technical execution.
Kokonut Moloch DAO
Understand the capital-governance system that authorizes treasury spending, $vKKN, Loot, and other DAO-level actions.
Governance Framework
Follow the proposal process from drafting and review through sponsorship, voting, grace, execution, and reporting.
Proposal Templates
Use structured templates when Guild work needs funding, recognition, Framework changes, or partnership authorization.
Open Collaboration
Start contributing without capital and choose a bounded, reviewable first contribution.
Build with Kokonut
Explore technical tasks, current contracts, data primitives, MRV schemas, and developer contribution paths.
The Guild model is strongest when reputation follows evidence, responsibility follows demonstrated contribution, and formal authority is only granted where the process for granting it is explicit.