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 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 MRWK bounty: 75 MRWK - post-deploy treasury proposal verification #597.
• Use 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.

[ramimbo]

Phase plan update: I think the right next step is to start Phase 2A as read-only ledger snapshot infrastructure.

The immediate target is deliberately narrow: deterministic MRWK ledger snapshots with integer microunit balances, ledger height/hash anchors, supply-conservation checks, hash-chain verification, and proposal_validation: partial until fuller proposal-aware replay exists.

This supports future public snapshots, Merkle-proof work, testnet-only claim experiments, and possible federation reconciliation review. It is not a live bridge, exchange, off-ramp, liquidity path, custody path, relayer path, or external-value system.

I opened the first Phase 2A implementation proposal here:

• MRWK bounty: 700 MRWK - Phase 2A read-only ledger snapshot exporter #764: Phase 2A read-only ledger snapshot exporter
• Treasury proposal: https://api.mrwk.online/api/v1/treasury/proposals/113

#764 is not claimable yet. It becomes claimable only if the treasury proposal executes and the issue is finalized with the public bounty row, mrwk:bounty, and the claims-open reserve comment.

Federation discussion in #571 remains separate. It is a useful possible future direction, but the MergeWork-side foundation should be snapshots, proofs, and reconciliation before any custody or value movement is considered.

[ramimbo]

Working roadmap after Phase 2A:

Phase 2A is the current first step: a read-only ledger snapshot foundation with deterministic account balances, integer microunits, ledger sequence/hash anchors, conservation checks, hash-chain verification, and proposal_validation: partial.

After that, the likely direction is:

• Phase 2B: Merkle proofs
  Make snapshot balances independently provable with deterministic leaves, root generation, proof generation, and proof verification.

• Phase 2C: Base Sepolia claim experiment
  Use the snapshot/Merkle foundation for a clearly experimental testnet claim flow. The goal is to test the mechanics and UX before making stronger claims about future public paths.

• Phase 2D: Federation reconciliation draft
  Keep Federation proposal: 1:1 RTC ↔ MRWK bridge #571 moving in parallel by drafting a neutral MergeWork-side reconciliation schema that can compare committed MRWK ledger state with external read-only reconciliation data.

• Phase 2E: Pilot readiness criteria
  Before any future pilot is considered, define public readiness gates: fixed-supply accounting, zero-drift committed counters, pause/refund/failure handling, custody limits, relayer responsibility, reviewed public wording, and clear operator boundaries.

The common thread is to make MRWK ledger state more provable and reviewable step by step: snapshots first, proofs next, testnet experiments after that, and federation review only from a stronger accounting base.

[ramimbo]

Phase 2B plan update: the next proposed step is a narrow read-only Merkle proof bounty for Phase 2A ledger snapshots.

I opened the proposed bounty issue here:

• MRWK bounty: 450 MRWK - Phase 2B snapshot Merkle proofs #1027: Phase 2B snapshot Merkle proofs
• Treasury proposal: https://api.mrwk.online/api/v1/treasury/proposals/214

This is not claimable yet. It becomes claimable only if the treasury proposal executes and the GitHub issue is finalized with the public bounty row, mrwk:bounty, and the claims-open reserve comment.

Scope is intentionally limited to deterministic Merkle root generation, account proof generation, proof verification, ledger-anchor binding, generated_at/source metadata independence, and tamper tests.

Out of scope: public API/UI, Base Sepolia, onchain claims, bridge, exchange, off-ramp, liquidity, custody, relayer, federation execution, and external-value claims.