A good proposal asks the right authority for one clear decision.

Proposal templates are useful only after the decision has been routed correctly. Before copying a template, ask:

What authority am I actually requesting, and who legitimately holds it?

Use Moloch for shared treasury capital, membership, $vKKN, Loot, and binding DAO-rule actions. Use Guild and domain review for contribution quality and specialized work. Use farm operators for routine agricultural execution. Use Framework and affected reviewers for shared methodology. Use MRV / evidence review for claims. A proposal can connect those scopes, but it should not collapse them into one vote.

Route the decision first

Identify the correct authority, required reviews, current timing, and whether a binding Moloch vote is actually needed.

Understand authority boundaries

Review the separation between capital, contribution, farm operations, methodology, evidence, and technical execution.

Inspect live DAO state

Verify current membership, proposal parameters, voting state, and execution conditions before a binding Moloch action.

Draft and discuss

Use the current Kokonut collaboration surface for visible drafting and review.

A template is not authorization. Completing a document does not create treasury rights, token rights, farm authority, scientific validity, legal authority, Guild Points, or payment. Those depend on the applicable review and approval process.

Choose the right template

Farm Funding

Request shared treasury capital for a new farm, defined infrastructure milestone, or material farm-development phase.

Guild Bounty

Request treasury funding for bounded contributor work with explicit acceptance criteria and a qualified reviewer.

Framework / Methodology Change

Propose a change to schemas, MRV methods, development phases, shared data structures, or other interoperable Framework primitives.

Partnership / External Commitment

Authorize a defined external commitment involving treasury, brand, data, access, contractual obligations, or material network resources.

Moloch Membership / Token Action

Request membership, $vKKN issuance, Loot recognition, or another explicitly Moloch-scoped token action.

Governance Amendment

Change a binding DAO governance rule, parameter, right, role, or process rather than a general Framework method.

If the decision mainly asks for…	Use	Primary authority
Shared capital for a farm	Farm Funding	Moloch for treasury; operators for field execution
Shared capital for scoped contributor work	Guild Bounty	Moloch for funding; domain reviewer for acceptance
Shared schema / methodology change	Framework / Methodology Change	Framework + affected reviewers; Moloch only if required
External commitment	Partnership / External Commitment	Depends on commitment; Moloch for DAO capital/authority
Membership, $vKKN, or Loot	Moloch Membership / Token Action	Moloch
Binding DAO rule / parameter change	Governance Amendment	Moloch when the rule is Moloch-scoped

Existing prefixes such as KDP, KBP, KFP, and KPP are documentation conventions already used in this repository. They are not smart-contract types. Use a working title during drafting and follow the current proposal-register process for any final identifier.

Proposal flow at a glance

Stage	What happens	Authority / owner
1. Route	Identify the decision class and authority requested	Author + affected reviewers
2. Draft	Complete the relevant template	Author / proposal team
3. Review	Domain, financial, operational, evidence, legal, or technical review as needed	Qualified reviewers
4. Revise	Resolve material questions and narrow scope	Author / proposal team
5. Activate	An authorized actor moves a binding proposal into the live process	Current governance rules
6. Vote when required	Moloch decides Moloch-scoped actions	Eligible $vKKN holders
7. Grace / retention when applicable	Current Moloch protections run before execution	Live DAO rules
8. Execute	Transaction and/or operational work begins	Authorized executors
9. Evidence / acceptance	Deliverables and outcomes are documented and reviewed	Named reviewers
10. Closeout	Variance, unresolved issues, and next actions are published	Proposal team / governance record

Current documentation uses a minimum 5-day draft baseline and 5-day Moloch voting baseline for applicable proposals. These are current governance parameters, not permanent rules. Verify live state before acting.

The common proposal base

The current Kokonut templates use the same ten-field base structure. That structure improves comparability, but it should be supplemented with authority, risk, dependencies, evidence, change-control, and closeout where the proposal type requires them.

Base field	What it should answer
A. Proposal Name	What decision are we discussing?
B. Proposal Author(s)	Who prepared the request and can answer questions?
C. Proposal Team	Who executes, reviews, accepts, or reports?
D. Draft Start Date	When did visible review begin?
E. Proposal Description	What exactly is being requested?
F. Mission Alignment	Why does this belong in Kokonut?
G. Brand Usage	Does the decision create public representation or brand obligations?
H. Financial Implications	What capital, cost, revenue assumption, liability, or token effect exists?
I. Success Metrics	What evidence will show delivery and, separately, any later outcomes?
J. Next Steps	Who does what after authorization?

Add these controls to every material proposal

Control	Requirement
Authority requested	State exactly what the approving body is being asked to authorize
Out of scope	State what the approval does not authorize
Dependencies	List reviews, signatures, permits, schemas, partners, or operators needed
Conflicts of interest	Disclose authors/reviewers/payees with material financial or operational interests
Evidence	Link the records that support assumptions and later completion
Material-change rule	Define what can change operationally and what requires re-approval
Closeout	Define the acceptance record, final report, variance, and unresolved follow-up

A proposal should be auditable before approval and closeable after execution.

Universal readiness checklist

Before moving toward binding authorization, confirm:

If reviewers cannot tell what is being authorized, who executes it, how completion is proven, and what would require re-approval, the proposal is not ready.

Farm Funding Proposal

Use this template when Kokonut shared capital is requested for a specific farm milestone. Examples:

new farm onboarding;
irrigation;
land preparation;
nursery or biofactory;
poultry infrastructure;
tools or equipment;
a defined production-phase budget.

A farm-funding vote authorizes capital under stated conditions. It does not transfer land title, replace local operators, prove forecast revenue, or grant token holders routine farm-management authority.

# [WORKING PROPOSAL TITLE]
# Example: KDP-[TBD] · [Farm] — [Defined funding milestone]

## A. Proposal Name
[Working title. Final identifier follows the current proposal-register process.]

## B. Proposal Author(s)
- Name / alias:
- Wallet:
- Relationship to farm:
- Contact:

## C. Proposal Team

| Role | Person / organization | Responsibility | Conflict disclosed? |
| --- | --- | --- | --- |
| Local farm operator | [Name] | Field execution / operator approval | [Yes/No + details] |
| Budget owner | [Name] | Procurement / financial reporting | [Yes/No] |
| Impact / MRV reviewer | [Name] | Evidence-plan review | [Yes/No] |
| Technical reviewer | [If needed] | Data / infrastructure / integration | [Yes/No] |
| Acceptance reviewer | [Name] | Milestone acceptance | [Yes/No] |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Authority requested
The Kokonut Moloch DAO is being asked to:
- authorize up to [AMOUNT + ASSET] from the DAO treasury;
- send funds to [recipient / Safe / payment path];
- release funds according to the milestone conditions below.

This proposal does **not** authorize:
- transfer of land title;
- routine crop / irrigation / labor decisions;
- publication of unsupported impact claims;
- spending outside the approved budget/change-control rules.

### Farm identity

| Field | Value |
| --- | --- |
| Farm / project | [Name] |
| Location | [City / Province / Country] |
| Coordinates | [If appropriate to publish] |
| Land / operating right | [Owned / leased / agreement / other + evidence link] |
| Local operator(s) | [Name / entity] |
| Framework phase | [Phase] |
| Existing Hub / record | [Link or "not yet created"] |
| Relevant legal / permit dependency | [If any] |

### Problem / need
[Describe the specific farm constraint. Separate documented condition from broader community or impact intent.]

### Funded scope
[Describe physical / operational deliverables precisely.]

### Out of scope
[List what this funding round will not pay for or authorize.]

### Budget

| Line item | Amount + asset | Recipient / vendor | Basis | Evidence |
| --- | ---: | --- | --- | --- |
| [Item] | [Amount] | [Recipient] | [Quote / estimate / contract] | [Link] |
| **Total** | **[Total]** |  |  |  |

### Disbursement milestones

| Milestone | Amount + asset | Release condition | Required evidence | Acceptance reviewer |
| --- | ---: | --- | --- | --- |
| Kickoff | [Amount] | [Condition] | [Evidence] | [Reviewer] |
| Milestone 2 | [Amount] | [Condition] | [Evidence] | [Reviewer] |
| Final | [Amount] | [Condition] | [Evidence] | [Reviewer] |

### Production / economic model
[Link the farm forecast. Summarize assumptions without presenting projected yield/revenue as actual.]

| Stream | Key assumption | Forecast period | Forecast gross revenue | Evidence class |
| --- | --- | --- | ---: | --- |
| [Crop / product] | [Yield / loss / price] | [Period] | [Amount] | Forecast |

### Public-goods / revenue allocation
[If an approved economic arrangement exists, cite it. If only a planning assumption exists, label it as an assumption. Do not invent or universalize a percentage.]

### MRV / evidence plan

| Claim / milestone | Record required | Reviewer | Publication / evidence pointer |
| --- | --- | --- | --- |
| [Infrastructure installed] | [Receipt / photo / field record] | [Reviewer] | [Hub / file / record] |
| [Planting] | [Planting record] | [Reviewer] | [Pointer] |
| [Harvest] | [Harvest actual] | [Reviewer] | [Pointer] |

### Risks / dependencies
- Weather / agronomic:
- Procurement:
- Market:
- Regulatory:
- Data / MRV:
- Operator capacity:
- Other:

### Material-change rule
[Any change above [threshold / category] in budget, recipient, funded scope, operator commitment, or material obligation requires [published variance / amendment / new proposal].]

## F. Mission Alignment
[Explain the connection to Kokonut's mission and Framework without treating alignment as achieved impact.]

## G. Brand Usage
[Where Kokonut name / marks may be used, by whom, and any approval dependency.]

## H. Financial Implications
- Total DAO treasury request:
- Asset:
- Recipient(s):
- Ongoing cost:
- Expected farm revenue: [Forecast / None]
- Any expected return to DAO: [Only if explicitly documented]
- Any public-goods allocation: [Approved arrangement / planning assumption / none]

## I. Success Metrics

### Delivery metrics
- [ ] [Physical milestone]
- [ ] [Record / reporting milestone]
- [ ] [Procurement / installation milestone]

### Outcome metrics
[Separate later farm outcomes from funded-deliverable acceptance.]

| Metric | Baseline | Target / hypothesis | Reporting period | Evidence |
| --- | --- | --- | --- | --- |
| [Metric] | [Baseline] | [Target] | [Period] | [Source] |

## J. Next Steps

| Action | Owner | Timing / deadline |
| --- | --- | --- |
| Complete domain review | [Reviewer] | [Date] |
| Activate binding proposal if ready | [Authorized actor] | [Date] |
| Execute approved payment | [Executor / system] | [After authorization] |
| Deliver milestone | [Operator / vendor] | [Date] |
| Publish evidence | [Owner] | [Date] |
| Closeout / variance report | [Owner] | [Date] |

For farm proposals, operator acknowledgment should be explicit. Treasury governance can approve funding, but it should not silently commit a locally operated farm to a plan the operator has not accepted.

Guild Bounty Proposal

Use this template for bounded contributor work that needs DAO treasury funding. The Guild / domain layer should define and review the work. Moloch authorizes shared capital when required. Guild Points are developing and should not be promised automatically.

# [WORKING PROPOSAL TITLE]
# Example: KBP-[TBD] · Technology — [Defined deliverable]

## A. Proposal Name
[Working title.]

## B. Proposal Author(s)
- Name / alias:
- Wallet:
- Contribution domain:
- Contact:

## C. Proposal Team

| Role | Person | Responsibility |
| --- | --- | --- |
| Domain coordinator | [Name] | Scope / routing |
| Contributor | [Name or TBD] | Delivery |
| Qualified reviewer | [Name] | Acceptance |
| Budget owner | [Name] | Payment / accounting |
| Additional affected reviewer | [If needed] | Cross-domain review |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Authority requested
Authorize [AMOUNT + ASSET] of DAO treasury funding for the bounded work below.

This proposal does **not** automatically:
- mint Guild Points;
- award Loot;
- grant \$vKKN;
- create employment;
- give the Guild authority outside the defined scope.

### Problem / context
[Why is this work useful now?]

### Deliverables

| # | Deliverable | Format | Acceptance criteria | Reviewer |
| --- | --- | --- | --- | --- |
| 1 | [Deliverable] | [Code / report / design / research] | [Testable criteria] | [Reviewer] |
| 2 | [Deliverable] | [Format] | [Criteria] | [Reviewer] |

### Evidence of completion
[PR, commit, dataset, report, deployment, meeting record, design file, analysis, etc.]

### Out of scope
[Explicit exclusions.]

### Dependencies
[Systems, data, farms, partner input, schemas, other contributors.]

### Review / revision process
- Submission method:
- Reviewer:
- Included revision rounds or remediation path:
- Acceptance record:

### Material-change rule
[Define what scope/budget/timeline changes require updated approval.]

## F. Mission Alignment
[Connect to a defined Guild / farm / Framework / governance need.]

## G. Brand Usage
[Public / internal / official docs / partner-facing.]

## H. Financial Implications

| Milestone | Amount + asset | Payment condition | Payment executor |
| --- | ---: | --- | --- |
| [Milestone] | [Amount] | [Acceptance condition] | [DAO / Safe / approved executor] |
| **Total** | **[Total]** |  |  |

### Conflicts of interest
[Disclose if author, coordinator, reviewer, and payee overlap.]

## I. Success Metrics

### Acceptance
- [ ] Deliverables meet criteria
- [ ] Documentation / handoff complete
- [ ] Reviewer records acceptance

### Later utility
[Optional: adoption, usage, reliability, or effect. Keep separate from acceptance.]

## J. Next Steps

| Action | Owner | Deadline |
| --- | --- | --- |
| Domain review | [Reviewer] | [Date] |
| Activate treasury proposal if needed | [Authorized actor] | [Date] |
| Execute work | [Contributor] | [Date] |
| Acceptance review | [Reviewer] | [Date] |
| Final payment | [Approved executor] | [After acceptance] |
| Contribution record updated | [Owner] | [Date] |
| Guild Points / Loot consideration | [If applicable] | Separate process — not automatic |

A bounty dispute should use the escalation path defined in the proposal or current Guild/governance process. This template does not assume that every dispute automatically becomes a Governance Guild ruling or DAO vote.

Framework and Methodology Change Proposal

Use this template for changes to:

Common Data Schema;
MRV payloads / methods;
development phases;
shared evidence rules;
impact methodology;
shared API / interoperability requirements;
Framework documentation that changes normative behavior.

A Framework change may need domain approval without a Moloch vote. If it also needs treasury funding or changes binding DAO rules, route those parts separately or explicitly.

# [WORKING PROPOSAL TITLE]
# Example: KFP-[TBD] · Framework — [Component]: [Change]

## A. Proposal Name
[Working title.]

## B. Proposal Author(s)
- Name / alias:
- Domain:
- Contact:
- Related issue / discussion:

## C. Proposal Team

| Role | Person | Responsibility |
| --- | --- | --- |
| Change author | [Name] | Specification |
| Technical reviewer | [Name] | Compatibility / implementation |
| Methodology reviewer | [Name] | Evidence / Framework review |
| Affected operator reviewer | [If applicable] | Operational impact |
| Documentation owner | [Name] | Migration / docs |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Authority requested
[Examples:
- approve a shared Framework method;
- approve a schema version;
- authorize treasury funding for implementation;
- approve a Moloch governance parameter — if so, consider the Governance Amendment template.]

### Current state
[Link and quote only the relevant current rule / schema.]

### Proposed change
[Exact new language / field / process.]

### Change type
- [ ] Additive
- [ ] Modification
- [ ] Deprecation
- [ ] Removal
- [ ] Breaking change

### Systems / actors affected

| Surface | Affected? | Impact |
| --- | --- | --- |
| Existing farm records | [Yes/No] | [Impact] |
| Common Data Schema | [Yes/No] | [Impact] |
| MRV payload / lifecycle | [Yes/No] | [Impact] |
| Kokonut Hub | [Yes/No] | [Impact] |
| Kokonut Intelligence | [Yes/No] | [Impact] |
| EAS schema / attestations | [Yes/No] | [Impact] |
| Farm operators | [Yes/No] | [Impact] |
| Partner integrations | [Yes/No] | [Impact] |

### Compatibility
- Backward compatible: [Yes / No / Partial]
- Existing data migration required:
- Dual-read / dual-write required:
- Versioning plan:
- Rollback plan:

### Migration plan

| Stage | Action | Owner | Exit condition |
| --- | --- | --- | --- |
| Notice | [Action] | [Owner] | [Condition] |
| Test | [Action] | [Owner] | [Condition] |
| Migration | [Action] | [Owner] | [Condition] |
| Cutover | [Action] | [Owner] | [Condition] |

### Evidence / rationale
[Issue, bug, data-quality analysis, farm need, research, compatibility requirement.]

### Out of scope
[What this change does not modify.]

## F. Mission Alignment
[Why the change improves interoperability, evidence quality, usability, or farm support.]

## G. Brand Usage
[Docs/API/public-reference changes.]

## H. Financial Implications
- DAO treasury required: [Yes/No]
- If yes: [budget + milestones]
- New recurring infrastructure cost:
- Migration support cost:
- External dependency / vendor lock-in risk:

## I. Success Metrics
- [ ] Specification accepted by affected reviewers
- [ ] Tests pass
- [ ] Migration / compatibility checks pass
- [ ] Documentation updated
- [ ] Existing records remain readable or explicit migration completes
- [ ] No unresolved critical compatibility issue

## J. Next Steps

| Action | Owner | Deadline |
| --- | --- | --- |
| Affected-domain review | [Reviewer] | [Date] |
| Technical compatibility review | [Reviewer] | [Date] |
| Treasury proposal if funding required | [Authorized actor] | [If needed] |
| Implement | [Owner] | [Date] |
| Migrate / validate | [Owner] | [Date] |
| Publish change record | [Owner] | [Date] |

For non-trivial shared schema, MRV, contract-interface, or data-model changes, the repository’s builder guidance already recommends opening an issue first and documenting compatibility implications.

Partnership and External Commitment Proposal

Use this template when Kokonut is being asked to make a material external commitment. Examples can include:

DAO treasury co-funding;
binding data-sharing obligations;
privileged access;
formal brand rights;
integration commitments;
grant obligations;
signed agreements;
long-lived resource commitments.

Not every relationship needs a DAO proposal. A conversation, informal collaboration, or ordinary contributor relationship should not be turned into governance solely because another organization is involved.

# [WORKING PROPOSAL TITLE]
# Example: KPP-[TBD] · Partnership — [Partner]: [Defined commitment]

## A. Proposal Name
[Working title.]

## B. Proposal Author(s)
- Name / alias:
- Relationship to partner:
- Contact:
- Conflict disclosure:

## C. Proposal Team

| Role | Person | Responsibility |
| --- | --- | --- |
| Relationship owner | [Name] | Coordination |
| Finance reviewer | [If needed] | Financial terms |
| Technical / data reviewer | [If needed] | Integration / data |
| Legal reviewer | [If needed] | Agreement / jurisdiction |
| Brand / communications reviewer | [If needed] | Public representation |
| Execution owner | [Name] | Delivery |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Authority requested
[Exactly what Kokonut / Moloch is being asked to commit.]

### Partner
| Field | Value |
| --- | --- |
| Legal / public name | [Name] |
| Entity / project type | [Type] |
| Jurisdiction if relevant | [Jurisdiction] |
| Website | [URL] |
| Wallet / chain if relevant | [Details] |
| Relationship owner | [Name] |

### Commitment scope

**Kokonut commits to:**
- [Commitment]

**Partner commits to:**
- [Commitment]

### What is explicitly not authorized
[Brand, data, treasury, farm commitments, exclusivity, sublicensing, etc. that remain out of scope.]

### Term / review
- Start:
- End / review point:
- Renewal method:
- Termination / suspension rights:
- Survival obligations:

### Data / privacy
- Data shared:
- Public / private:
- Retention:
- Access:
- Security / selective-disclosure requirement:

### Brand / public representation
[Exact permitted use by both parties.]

### Legal / regulatory dependencies
[Agreement, MOU, grant, data-processing agreement, farm/operator consent, regulatory review, etc.]

### Risks
- Counterparty:
- Financial:
- Data:
- Brand:
- Technical:
- Farm / local-operator:
- Regulatory:

### Material-change rule
[What change to term, money, data, exclusivity, brand, obligations, or partner scope requires re-approval.]

## F. Mission Alignment
[Why this commitment belongs in Kokonut.]

## G. Brand Usage
[Exact permissions and approval path.]

## H. Financial Implications

| Flow | Amount / asset | From | To | Condition |
| --- | ---: | --- | --- | --- |
| [Payment / grant / in-kind] | [Amount] | [Party] | [Party] | [Condition] |

- Ongoing cost:
- Revenue share if any:
- In-kind value:
- Liability / indemnity if any:

## I. Success Metrics

### Delivery
- [ ] Kokonut commitments delivered
- [ ] Partner commitments delivered
- [ ] Required agreement / record completed
- [ ] Technical / data milestones accepted

### Outcome
[Separate later relationship outcomes from contractual delivery.]

## J. Next Steps

| Action | Owner | Deadline |
| --- | --- | --- |
| Partner reviews terms | [Owner] | [Date] |
| Required domain / legal reviews | [Reviewer] | [Date] |
| Moloch vote if required | [Authorized actor] | [Date] |
| Sign / execute agreement if applicable | [Authorized signatory] | [Date] |
| Deliver commitments | [Owners] | [Date] |
| Review / closeout | [Owner] | [Date] |

The previous template used a universal “more than 90 days” trigger and a generic 14/30-day termination rule. The repository does not establish those as universal governance rules, so this revision requires the actual term and termination mechanism to be stated proposal by proposal.

Moloch Membership and Token Action Proposal

Use this template when the requested authority is explicitly within Moloch:

membership onboarding;
stablecoin tribute;
$vKKN issuance;
Loot recognition;
another defined DAO token action.

Do not hard-code a token price, tribute ratio, or holder percentage from static docs. Verify the current DAO state and proposal terms.

# [WORKING PROPOSAL TITLE]
# Example: Membership — [Applicant] / Loot Recognition — [Contributor]

## A. Proposal Name
[Working title.]

## B. Proposal Author(s)
- Name / alias:
- Wallet:
- Applicant / recipient relationship:
- Contact:
- Conflict disclosure:

## C. Proposal Team
| Role | Person | Responsibility |
| --- | --- | --- |
| Applicant / recipient | [Name + wallet] | Subject of action |
| Proposal author | [Name] | Draft |
| Evidence reviewer | [If Loot] | Contribution evidence |
| Activation contact | [Current authorized actor] | Binding proposal activation |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Action requested
- [ ] Membership onboarding
- [ ] \$vKKN issuance
- [ ] Loot issuance
- [ ] Other Moloch-scoped token action: [describe]

### Exact requested action
- Recipient wallet:
- Stablecoin tribute if applicable:
- Requested \$vKKN if applicable:
- Requested Loot if applicable:
- Any linked treasury action:
- Current-state reference / DAO link:

### Basis

**For membership:**
[Why membership and requested voting power are being proposed. Include current terms rather than relying on an old static ratio.]

**For Loot:**
[Describe the durable contribution being recognized and link its contribution record / evidence.]

### Rights created
[State the actual current documented rights of the token/action.]

### Rights not created
This proposal does not automatically create:
- land title;
- farm-management authority;
- employment;
- Guild standing;
- scientific-review authority;
- guaranteed financial return.

### Live-state checks
- Current \$vKKN supply:
- Current recipient balance:
- Current governance parameters:
- Current treasury / eligible assets if relevant:
- Source / date checked:

## F. Mission Alignment
[Why the membership / recognition supports Kokonut.]

## G. Brand Usage
[If relevant.]

## H. Financial Implications
- Tribute:
- Treasury inflow/outflow:
- Token supply change:
- Potential dilution / governance concentration effect:
- Rage-quit / treasury implications if relevant:

## I. Success Metrics
For this proposal type, success is primarily **correct execution of the authorized action**, not a promised social/economic outcome.

- [ ] Correct recipient
- [ ] Correct tribute / token amount
- [ ] Correct proposal state
- [ ] Correct transaction execution
- [ ] Governance record updated

## J. Next Steps

| Action | Owner | Deadline |
| --- | --- | --- |
| Verify live DAO state | [Owner] | Before activation |
| Activate proposal | [Authorized actor] | [Date] |
| Moloch vote / grace | [DAO] | Under live rules |
| Execute if eligible | [System / authorized executor] | [Date] |
| Verify token / treasury state | [Reviewer] | After execution |
| Publish record | [Owner] | [Date] |

Loot recognition can be supported by Guild contribution evidence, but Loot is still authorized through Moloch. Guild Points do not automatically convert into Loot.

Governance Amendment Proposal

Use this template for a binding governance rule or parameter. Examples:

Moloch governance parameters;
proposal rights;
voting / activation rules;
treasury authorization rules;
retention / quorum settings;
formal amendments to this Governance Framework where the change is intended to be binding.

Do not use this template merely because a documentation page changed.

# [WORKING PROPOSAL TITLE]
# Example: Governance Amendment — [Rule / Parameter]

## A. Proposal Name
[Working title.]

## B. Proposal Author(s)
- Name / alias:
- Wallet:
- Contact:

## C. Proposal Team

| Role | Person | Responsibility |
| --- | --- | --- |
| Amendment author | [Name] | Draft |
| Governance reviewer | [Name] | Process / rights review |
| Technical reviewer | [If contract parameter] | Execution implications |
| Affected-domain reviewer | [If needed] | Impact on other scopes |

## D. Draft Start Date
[YYYY-MM-DD]

## E. Proposal Description

### Authority requested
[Exact binding governance action.]

### Current rule
[Quote / link current rule or current live parameter.]

### Proposed rule
[Exact replacement language / parameter.]

### Reason
[Problem being addressed.]

### Rights / responsibilities affected

| Actor | Current right / duty | Proposed change |
| --- | --- | --- |
| [Actor] | [Current] | [New] |

### Technical execution
- Contract / module affected:
- Transaction required:
- Migration / transition:
- Effective time:
- Rollback / emergency consideration:

### Risks
- Governance concentration:
- Treasury:
- Member rights:
- Operational:
- Technical:
- Unintended interactions:

### Material-change rule
[Any change to the amendment text or parameter after review requires renewed review / proposal.]

## F. Mission Alignment
[Why the governance change improves accountability, safety, participation, or clarity.]

## G. Brand Usage
[Usually none; state if external communication is needed.]

## H. Financial Implications
- Treasury effect:
- Token / voting-power effect:
- Implementation cost:
- Ongoing cost:

## I. Success Metrics
- [ ] Exact approved rule / parameter is implemented
- [ ] Effective date / block is recorded
- [ ] Documentation is updated
- [ ] Affected participants are notified
- [ ] No unresolved mismatch between docs and live state

## J. Next Steps

| Action | Owner | Deadline |
| --- | --- | --- |
| Governance review | [Reviewer] | [Date] |
| Technical review if needed | [Reviewer] | [Date] |
| Verify live parameter before vote | [Owner] | [Date] |
| Activate Moloch proposal | [Authorized actor] | [Date] |
| Execute if approved | [System / executor] | [Date] |
| Verify on-chain state | [Reviewer] | [Date] |
| Update docs | [Owner] | [Date] |

What happens after approval

Approval is the beginning of accountable execution.

Proposal type	Authorization	Execution	Acceptance / closeout
Farm Funding	Treasury budget / milestones	Payments + farm work by authorized operators/vendors	Milestone evidence, variance, farm records
Guild Bounty	Treasury budget	Contributor work + approved payments	Domain acceptance + contribution record
Framework Change	Method / schema approval and/or funding	Implementation + migration	Compatibility checks + published change record
Partnership	Defined external commitment	Signatures, payments, integrations, obligations	Delivery review + term/renewal decision
Membership / Token	Moloch token action	Contract / DAO execution	Token / treasury state verification
Governance Amendment	Binding governance change	Parameter / rule implementation	Live-state verification + docs alignment

Closeout record

Every material proposal should eventually answer:

What was authorized?
What actually executed?
What was delivered?
What changed from the approved plan?
Which evidence supports completion?
What remains unresolved?
Did any forecast differ materially from actuals?
Is another proposal or operational action required?

Do not mark a proposal “complete” merely because an on-chain transaction succeeded. Transaction execution and real-world delivery are different statuses.

Material changes after approval

Minor implementation details can remain within the approved scope. Material changes should be disclosed and evaluated against the original authority. Examples that may require an amendment or new proposal:

material budget increase;
new payment recipient;
materially different deliverable;
change to token amount;
new legal obligation;
new exclusivity;
different farm operator / land arrangement;
breaking schema change not reviewed originally;
change to success / acceptance criteria that makes completion easier to claim;
substantially different use of treasury capital.

An approved proposal is an authorization envelope, not a blank check.

Proposal status vocabulary

Use precise statuses.

Status	Meaning
Draft	Being prepared; not authorized
Reviewed	Required reviews are substantially complete
Active / Voting	In the current binding decision process
Passed / Authorized	Approval exists, subject to applicable grace / execution conditions
Executed on-chain	Authorized transaction completed
In delivery	Operational work is still underway
Accepted	Defined deliverables passed acceptance
Closed	Evidence, variance, and follow-up are recorded
Withdrawn	Author stopped the proposal before authorization
Rejected	Required authorization was not granted

This vocabulary makes governance records easier to compare with farm and contribution records.

What proposal templates should never do

Do not vote a fact into existence

A proposal can fund research or authorize publication, but it cannot make an unsupported ecological, financial, or scientific claim true.

Do not override local operators

Farm funding can authorize capital and milestones without transferring routine agronomic authority to token holders.

Do not promise developing reputation

Guild Points, thresholds, standing, and elections should not be promised as automatic bounty outputs.

Do not hide forecasts inside targets

Crop revenue, impact, adoption, and partnership value assumptions should remain visibly modeled until actuals exist.

Do not skip compatibility

Shared schema, MRV, API, and Framework changes should explain migration and affected systems.

Do not stop at the vote

Every material authorization needs execution ownership, evidence, acceptance, variance handling, and closeout.

Before you copy a template

1. Route the decision

Confirm whether the authority belongs to Moloch, a Guild/domain process, farm operators, Framework stewardship, evidence review, or more than one scope.

2. Choose the narrowest template

Ask for only the authority required for this decision.

3. Gather evidence first

Link budgets, contribution records, farm data, specifications, agreements, live DAO state, and assumptions before asking reviewers to infer them.

4. Name reviewers and executors

Make expertise, acceptance, transaction execution, and operational delivery distinguishable.

5. Define change-control

Decide what can change inside the approved scope and what requires renewed authorization.

6. Define closeout

State what evidence will allow the proposal to move from authorized to accepted and closed.

Continue through The Kokonut DAO

Governance Framework

Route decisions correctly, review the current process, and distinguish authorization from execution and closeout.

Kokonut Moloch DAO

Review membership, $vKKN, Loot, treasury governance, rage-quit, live contracts, and current-state verification.

Kokonut Guilds

Understand contribution records, domain review, developing Guild Points, stewardship, and the path from work to formal proposals.

DAO Architecture

See which authority owns capital, contribution, farm operations, methodology, evidence, and technical execution.

Open Collaboration

Start with useful work before creating governance overhead when no formal authority is needed.

DAOHaus

Verify live proposals, membership, voting state, and current Moloch parameters before binding action.

A proposal is strongest when it asks for the narrowest legitimate authority, gives reviewers enough evidence to evaluate it, and defines exactly how authorization becomes accountable delivery.

​A good proposal asks the right authority for one clear decision.

Route the decision first

Understand authority boundaries

Inspect live DAO state

Draft and discuss

​Choose the right template

Farm Funding

Guild Bounty

Framework / Methodology Change

Partnership / External Commitment

Moloch Membership / Token Action

Governance Amendment

​Proposal flow at a glance

​The common proposal base

​Add these controls to every material proposal

​Universal readiness checklist

​Farm Funding Proposal

​Guild Bounty Proposal

​Framework and Methodology Change Proposal

​Partnership and External Commitment Proposal

​Moloch Membership and Token Action Proposal

​Governance Amendment Proposal

​What happens after approval

​Closeout record

​Material changes after approval

​Proposal status vocabulary

​What proposal templates should never do

Do not vote a fact into existence

Do not override local operators

Do not promise developing reputation

Do not hide forecasts inside targets

Do not skip compatibility

Do not stop at the vote

​Before you copy a template

​Continue through The Kokonut DAO

Governance Framework

Kokonut Moloch DAO

Kokonut Guilds

DAO Architecture

Open Collaboration

DAOHaus

A good proposal asks the right authority for one clear decision.

Choose the right template

Proposal flow at a glance

The common proposal base

Add these controls to every material proposal

Universal readiness checklist

Farm Funding Proposal

Guild Bounty Proposal

Framework and Methodology Change Proposal

Partnership and External Commitment Proposal

Moloch Membership and Token Action Proposal

Governance Amendment Proposal

What happens after approval

Closeout record

Material changes after approval

Proposal status vocabulary

What proposal templates should never do

Before you copy a template

Continue through The Kokonut DAO