> ## Documentation Index > Fetch the complete documentation index at: https://kokonut.network/llms.txt > Use this file to discover all available pages before exploring further. # DAO Proposal Templates > Copy-ready Kokonut proposal templates for farm funding, Guild bounties, Framework changes, partnerships, Moloch membership/token actions, and governance amendments — with authority, evidence, execution, and closeout built in. # 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. Identify the correct authority, required reviews, current timing, and whether a binding Moloch vote is actually needed. Review the separation between capital, contribution, farm operations, methodology, evidence, and technical execution. Verify current membership, proposal parameters, voting state, and execution conditions before a binding Moloch action. 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 Request shared treasury capital for a new farm, defined infrastructure milestone, or material farm-development phase. Request treasury funding for bounded contributor work with explicit acceptance criteria and a qualified reviewer. Propose a change to schemas, MRV methods, development phases, shared data structures, or other interoperable Framework primitives. Authorize a defined external commitment involving treasury, brand, data, access, contractual obligations, or material network resources. Request membership, \$vKKN issuance, Loot recognition, or another explicitly Moloch-scoped token action. 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: * [ ] The decision is routed to the correct authority. * [ ] The requested authority is written explicitly. * [ ] Local farm authority is preserved where relevant. * [ ] Domain reviewers have reviewed the parts within their competence. * [ ] Forecasts are labeled as forecasts. * [ ] Impact claims are backed by evidence or clearly framed as intended outcomes. * [ ] Budget assets, amounts, recipients, milestones, and evidence are specific. * [ ] Conflicts of interest are disclosed. * [ ] Dependencies and risks are visible. * [ ] Acceptance criteria are testable. * [ ] Material-change rules are defined. * [ ] Execution owners are named. * [ ] Closeout evidence is defined. * [ ] Current Moloch parameters are verified if a binding DAO action is required. 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. ```markdown theme={null} # [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. ```markdown theme={null} # [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. ```markdown theme={null} # [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. ```markdown theme={null} # [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. ```markdown theme={null} # [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. ```markdown theme={null} # [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 A proposal can fund research or authorize publication, but it cannot make an unsupported ecological, financial, or scientific claim true. Farm funding can authorize capital and milestones without transferring routine agronomic authority to token holders. Guild Points, thresholds, standing, and elections should not be promised as automatic bounty outputs. Crop revenue, impact, adoption, and partnership value assumptions should remain visibly modeled until actuals exist. Shared schema, MRV, API, and Framework changes should explain migration and affected systems. Every material authorization needs execution ownership, evidence, acceptance, variance handling, and closeout. *** ## Before you copy a template Confirm whether the authority belongs to Moloch, a Guild/domain process, farm operators, Framework stewardship, evidence review, or more than one scope. Ask for only the authority required for this decision. Link budgets, contribution records, farm data, specifications, agreements, live DAO state, and assumptions before asking reviewers to infer them. Make expertise, acceptance, transaction execution, and operational delivery distinguishable. Decide what can change inside the approved scope and what requires renewed authorization. State what evidence will allow the proposal to move from authorized to accepted and closed. *** ## Continue through The Kokonut DAO Route decisions correctly, review the current process, and distinguish authorization from execution and closeout. Review membership, \$vKKN, Loot, treasury governance, rage-quit, live contracts, and current-state verification. Understand contribution records, domain review, developing Guild Points, stewardship, and the path from work to formal proposals. See which authority owns capital, contribution, farm operations, methodology, evidence, and technical execution. Start with useful work before creating governance overhead when no formal authority is needed. 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.** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.