Collaborative decision deposits: live on Kusama, open for review

Governance
1

A Kusama Wish for Change needs a 666.67 KSM decision deposit before it can go to a vote. Governance takes that deposit from one account. A proposal can have support and still time out because nobody can carry the whole amount.

We have built a contract that lets people and groups share it. The first pool is live for our Wish for Change #676. We are asking for code review and people to try the Paseo rehearsal.

This is experimental and has not had an independent review. We deployed before that review to leave time before #676 times out. A killed referendum loses the deposit, and a contract bug could also put contributions at risk.

How it works

Each pool is fixed to one referendum and its exact deposit. It has no owner, admin key or upgrade path.

People contribute from their own accounts. The payment that fills the pool tries to place the deposit in the same transaction. If placement fails, the contribution stays in the pool and anyone can retry. Contributors can withdraw while the pool remains open, before placement.

After the referendum ends, anyone can reclaim the deposit and send payouts to the contributing accounts. These are separate contract calls. No watcher is running yet, so repayment needs someone to act through the page. A contributor that refuses payment does not block the others. If funding falls short, contributors can withdraw, or anyone can close the pool after its deadline and start payouts.

Approved, rejected, cancelled and timed-out referenda allow a refund. Killed referenda do not. Network fees are additional.

Try it together on Paseo

Paseo #147 mirrors #676’s proposal byte for byte, with the same origin and enactment. Its pool needs 20,000 PAS, with a minimum payment of 500 PAS. Funding closes 2 November 2026 at 12:00 UTC.

Connect an Ethereum account in Talisman or MetaMask. If it needs test PAS, the page opens the faucet with the account filled in. Leave enough for transaction fees.

Paseo’s Wish for Change decision period is 28 days, compared with Kusama’s 14. This rehearsal cannot return funds within hours. A separate 1 PAS proof pool on Paseo #145 is expected to end around 6 November. The public-network refund is still unproved.

Earlier work and what needs review

This follows Moonbeam’s 2023 discussion, the 2024 decision deposit track proposal, and RFC 151 on crowdsourced deposits. This experiment uses Asset Hub’s EVM and XCM precompile without a governance upgrade.

Placement has worked on public Paseo. The Kusama fork suite passed 88 checks, including refunds, failed placement and a recipient refusing payment. Fork balances and some governance outcomes were injected, so those tests do not replace public-network evidence or independent review.

We would particularly welcome review of the XCM encoding, the balance checks around placement and reclaim, and the payout handling. Please open an issue in the repo or reply here.

The Kusama pool needs 666.66666666 KSM, with a 5 KSM minimum except for the final top-up. Funding closes 3 November 2026 at 12:00 UTC, ahead of #676’s estimated timeout that evening. Please try Paseo and read the code before deciding whether to contribute KSM.

Birdbrain is a Decent initiative that tests, learns and educates in public.

2

Nice to see this done without a governance upgrade. I read DecisionDepositPool.sol with your three areas in mind, and the placement check looks right to me: if the pallet takes anything but the exact deposit, _place reverts and the XCM call is undone with it.

reclaim() is meant to let the balance decide, and it covers someone calling refund_decision_deposit directly. But weighMessage(refundMessage()) is an ordinary call made before the low-level one, so if weighing ever fails (a refund call that no longer decodes after a runtime upgrade, say), reclaim() reverts even with the KSM already back in the contract, and with no admin there’s no other way to reach Returning. Doing the weigh inside a try, or as its own low-level call, leaves the balance check as the only gate, which matters while the public refund is still unproved.

KSM that arrives without contribute() is never paid out either. An EVM transfer bounces since there’s no receive function, but a plain balances transfer to the contract’s mapped account goes through, and someone sending from a Substrate wallet could do exactly that. It never enters total or contributed, so it stays in the contract for good. A permissionless sweep to an address fixed at deployment, once the pool is Returning and total is zero, would cover it.

Smaller one on payouts: an address that withdraws and pays in again is pushed onto contributors a second time. payout() skips the duplicate because its amount is zero, so no funds move wrongly, but contributorCount() overcounts on the page. A mapping that marks an address as already listed fixes it.