• © Goverland Inc. 2026
  • v1.0.8
  • Privacy Policy
  • Terms of Use
RomeDAORomeDAOby0xDb8c3Fa2b53A40651492efc71f9861AB42759E850xDb8c…9E85

Final Rome Redemption Wind‑Down, Multichain Waiver, and Residual Treasury Distribution

Voting ended 20 days agoSucceeded

Summary

This proposal gives the Rome redemption multisig (the “Trustees”) a final mandate to:

  1. Close the existing Moonriver redemption contract (“Redemption1”) after clear notice.
  2. Define the remaining treasury in that contract as a residual pool (“Zombie Assets”).
  3. Distribute all Zombie Assets strictly pro rata among Redemption1 participants who sign a final waiver, with:
    • no distributions to anyone who does not sign the waiver; and
    • no meaningful Zombie Assets left stranded at the end of the process.

The technical implementation will be designed and reviewed after this vote. Any implementation is acceptable if it achieves those outcomes and follows the constraints and budget below


Motivation

  • RIP‑028 authorized a wind‑down of the Rome treasury via Redemption1 on Moonriver.
  • Years later, the redemption contract still holds a significant pool of assets, including anyDAI, and many ROME holders never interacted.
  • Rome is effectively in a zombie state, but the residual treasury and unresolved Multichain position keep the trust open and keep fiduciary risk on the signers.

Doing nothing leaves value idle and the Trustees exposed. Forcing the signers to formally enter the Multichain liquidation is also undesirable. The outcome we want:

  • Every Redemption1 participant who steps forward and signs a waiver gets a pro‑rata share of all remaining assets.
  • No meaningful assets remain in the trust when this is done.
  • The Trustees get a clear beneficiary‑approved mandate and broad releases.

Voting power and quorum

Who can vote

For this proposal, Voting Power per address is:

Voting Power = current eligible ROME/sROME balance at the Snapshot block
+ total ROME previously redeemed by that address via Redemption1

A custom Snapshot weighting has been configured so that:

  • current ROME/SROME holders, and
  • addresses that redeemed via Redemption1

can both vote in proportion to their economic stake in the redemption trust (no double‑counting).

Turnout / quorum

Rome historically referenced a 25% quorum target for Snapshot, (a product of RIP-28 vote), but this was never encoded on‑chain, and it is not realistic for a dormant project.

For this proposal:

  • Turnout below 25% of historic supply does not automatically invalidate the vote.
  • The Trustees are authorized to treat the proposal as approved, and to act on it, if there is a clear supermajority (for example ≥ 80% of Voting Power cast) voting FOR, even if overall turnout is below 25%.

The relevant signal is the will of the remaining engaged beneficiaries.


Resolution / specification (outcome level)

If this proposal passes, the Trustees are authorized and directed to implement the following outcomes.

1. Governance mandate and Redemption1 cut‑off

  1. Announce, via official Rome channels, a clear 60 day final deadline for using Redemption1 and that the Redemption2 window will be 30 days after.
  2. After that deadline:
    • Redemption1 is treated as closed.
    • Any ROME that was still unredeemed is treated as having had a fair opportunity and is excluded from the final pool going forward.

2. Define the residual pool (“Zombie Assets”)

  1. After Redemption1 closes, identify all assets remaining in the redemption contract, including:
    • liquid tokens,
    • anyDAI,
    • any reserves reasonably needed for execution costs.
  2. Treat this set of assets as the Zombie Assets to be distributed under this proposal.

3. Waiver‑gated, pro‑rata redistribution

Implement a final distribution process in which:

  1. Eligible participants are all addresses that redeemed under Redemption1 (“Redemption1 participants”).
  2. Participation is conditional on waiver:
    • Each participating address must sign/record a clear waiver and release in favor of the Trustees as a hard precondition to receiving value.
  3. Pro‑rata sharing:
    • Every participant that signs the waiver receives a strictly pro‑rata share of the Zombie Assets, based on the amount of ROME they redeemed in Redemption1 relative to total ROME redeemed.

In plain terms:

“Only Redemption1 participants who sign the waiver receive anything, and they all share everything pro rata.”

4. No residual assets left

At the end of the process:

  1. There must be no meaningful Zombie Assets left in the contract or under the Trustees’ control for the benefit of Rome.
  2. Any residual after a 30 day claim period (for example, because not all waiver‑eligible addresses claimed promptly) must be pushed out pro rata to the same set of waiver‑signing Redemption1 participants.

The trust should end with everything distributed to waiver‑signers, not with a tail of stranded assets.

5. Multichain/anyDAI waiver

This proposal explicitly authorizes:

  1. The community to elect not to pursue any formal recovery action in the Multichain liquidation for the contract’s anyToken holdings.
  2. The Trustees to decline to file a Proof of Debt or similar claim for those positions.
  3. The waiver text used in the final distribution to include:
    • beneficiary consent to this decision, and
    • a release of any claims against the Trustees for not pursuing Multichain or related litigation.

This converts the Multichain “duty to enforce” problem into a consensual waiver backed by a distribution of all other value.

6. Implementation budget, dev selection, and timing

  1. Dev work timing

    • No implementation work or payment is expected before this proposal passes.
    • Actual coding and review happen after the vote passes.
  2. Dev selection framework

    • The Trustees select implementer(s) they are comfortable with.
    • Code must receive at least one independent review (peer review or light audit).
  3. Budget

    • Up to USD 20,000 equivalent from the Zombie Assets pool is authorized as an administrative cost to cover:
      • development,
      • independent review,
      • necessary gas/execution costs,
    • with recipients and amounts disclosed at the end of the process.
    • There are no special economics or side‑deals for any group; aside from these documented costs, all value flows to waiver‑signing Redemption1 participants, pro rata.

Suggested technical implementation (non‑binding)

The following is guidance only. The Trustees and their chosen devs may adjust the exact architecture, as long as the outcomes and constraints above are met.

One simple pattern:

  1. Accounting token (“pROME”)

    • Deploy a minimal token or ledger that assigns 1 unit per ROME redeemed under Redemption1 to each participating address.
    • Total supply = total ROME redeemed by the Redemption1 cut‑off.
  2. Claim contract (“Redemption2”)

    • A contract that:
      • burns user's pROME tokens upon interaction;
      • enforces acceptance of a waiver (e.g. via an on‑chain flag or signed message) before permitting any claim;
      • lets each waiver‑signing address claim its pro‑rata share of each asset in the Zombie Assets pool during a defined window.
  3. Final push distribution

    • After a 30 day claim window:
      • calculate how much of the pROME/ledger supply actually signed the waiver;
      • treat any remaining value as a leftover pool;
      • execute a one‑time batched payout that pushes all leftovers to the same set of waiver‑signing addresses, pro rata.

If an alternative implementation (for example, off‑chain signed messages plus direct multisig payout scripts) delivers the same economic result:

  • only waiver‑signers receive value,
  • everything is shared strictly pro rata,
  • no meaningful assets remain at the end,

then it is within the mandate of this proposal.


Effect of a FOR / AGAINST vote

  • FOR

    • Approves the final wind‑down framework described above.
    • Authorizes the Trustees to:
      • close Redemption1 after notice,
      • define and distribute the Zombie Assets as described,
      • treat a strong supermajority approval as sufficient even below historic 25% turnout,
      • waive Multichain/anyDAI claims,
      • pay reasonable implementation costs (up to USD 20,000 equivalent) from the pool.
  • AGAINST

    • Rejects this framework and leaves the current stalled status quo in place until another plan is adopted.

Off-Chain Vote

For
339.97K ROME100%
Against
0 ROME0%
Download mobile app to vote

Timeline

Feb 23, 2026Proposal created
Feb 23, 2026Proposal vote started
Mar 02, 2026Proposal vote ended
Mar 02, 2026Proposal updated