Treasury proposal flow is live: bounty posting, payouts, and next phases

[ramimbo]

PR #458 is merged and deployed. This changes the normal maintainer/admin path for MergeWork treasury actions.

What changed

Normal app-path treasury actions now go through public treasury proposals before they mutate the ledger:

• create_bounty: reserves MRWK for a GitHub bounty issue.
• pay_bounty: pays an accepted manual claim from an existing bounty reserve.
• close_bounty: closes a bounty and releases unused reserve.

Each proposal has a canonical payload, a payload hash, a public status, and an execution time. Execution is delayed by 24 hours. When a proposal executes, the resulting ledger entry/proof becomes the canonical public record.

The proposal API is public for reads:

• GET /api/v1/treasury/proposals
• GET /api/v1/treasury/proposals/{id}

Proposal creation and execution remain admin-token operations. Challenge submission requires GitHub login and at least one previously accepted MRWK award.

What this means for bounty issues

The old shortcut was: create a GitHub issue, reserve it immediately, add mrwk:bounty, and comment Reserved on MergeWork.

The new flow is:

1. Create the GitHub issue.
2. Create a public create_bounty proposal.
3. Wait 24 hours.
4. Execute the proposal if it is still valid and unblocked.
5. Only after execution, add mrwk:bounty and comment Reserved on MergeWork with the public bounty URL.

A GitHub issue is not live as an MRWK bounty until step 5. Contributors should not treat proposed issues as claimable MRWK bounty work until the reserve execution is visible.

What this means for manual payouts

Manual review, smoke-check, docs, and verification claims now follow:

1. Maintainer accepts the work.
2. Maintainer creates a public pay_bounty proposal.
3. Wait 24 hours.
4. Execute the proposal if it is still valid and unblocked.
5. Mark the work paid only after the proof exists.

A pending proposal is not a payment. Public updates should say queued as proposal <id> during the delay and should use proof links after execution.

Accepted-label PR webhook payouts are unchanged when their guards pass. The proposal flow mainly affects normal admin bounty creation, manual payout, and close/release actions.

Challenge behavior

Earned contributors can submit proposal challenges. Machine-checkable challenges can block a pending proposal when the current ledger/app state proves the issue, for example duplicate bounty, closed bounty, already-paid submission, insufficient reserve, or reserve-cap breach. Subjective notes are recorded publicly but do not block by themselves.

This creates a public objection window without pretending that app-level governance can stop direct production server or database access by an operator. The goal is transparency and rule-checkable normal operation.

Current examples

Two initial proposals are queued:

• Proposal Server acceptance smoke #1 closes the now-finished MRWK bounty: detailed governance MVP PR review, part 4 #569 / bounty 80 governance-review round. It can execute after 2026-05-29 20:26:24 UTC.
• Proposal MRWK bounty: star MergeWork and verify the wallet claim flow #2 reserves proposed bounty Proposed MRWK bounty: 75 MRWK - post-deploy treasury proposal verification #597 for post-deploy treasury proposal verification. It can execute after 2026-05-29 20:27:20 UTC.

#597 is not active yet and intentionally does not have mrwk:bounty or Reserved on MergeWork.

Phase plan

Phase 1 is now live: MergeWork has the governance surface from PR #458: proposal table/API, delay enforcement, reserve caps, proposal execution, and public challenge logs.

Phase 2 is experimental testnet work: a beta EVM testnet repo/package with snapshot export, Merkle root building, Base Sepolia claim contract experiments, timelocked root updates, and no liquidity. Early outputs should be labeled testnet, experimental, and proposal_validation: partial.

Phase 3 is proposal-aware canonical snapshots: exported balances should be derived from valid ledger history under proposal rules. This is where invalid or bypassed history starts being rejected by the canonical snapshot process rather than merely documented after the fact.

Boundaries

MRWK remains the native MergeWork ledger coin. MergeWork does not currently operate a bridge, exchange, off-ramp, public external-value path, or fixed 1:1 external-value relationship. Future work may explore public snapshots, bridge design, and onchain claim experiments, but those are not live systems and should not be described as liquidity, cash-out, or price support.

Immediate next steps

• Execute proposal Server acceptance smoke #1 after the delay if unblocked, then close MRWK bounty: detailed governance MVP PR review, part 4 #569 and release unused reserve.
• Execute proposal MRWK bounty: star MergeWork and verify the wallet claim flow #2 after the delay if unblocked, then add mrwk:bounty and Reserved on MergeWork to Proposed MRWK bounty: 75 MRWK - post-deploy treasury proposal verification #597.
• Use Proposed MRWK bounty: 75 MRWK - post-deploy treasury proposal verification #597 to verify the live proposal flow, improve docs and admin wording, and catch post-deploy bugs.
• Keep public updates proof-backed: pending proposals are pending; executed proofs are paid.