RFC-159: Spend Canceller Track

OpenGov is heavily leaning into milestone-based funding through scheduled spends.

The idea here is that future milestones can be cancelled if the proposer is not delivering up to expectation. However, the track to cancel such a scheduled spend is Treasurer, which takes up to 36 days to execute. This is too long if milestones are spread out on a monthly basis.

This RFC proposes a new OpenGov track called Spend Canceller that provides a dedicated, expedited governance pathway for cancelling scheduled treasury spends via treasury.void_spend(). This track has a maximum 15-day timeline, enabling the network to respond more swiftly to problematic spend approvals.

This thread is intended to gather feedback and relevant discussion around the issue. I will integrate tangible feedback into the RFC and post updates here if the RFC significantly develops.

7 Likes

Thanks for bringing this to discussion. I have identified this issue as well with the current setup requiring Treasurer track for voiding payouts and proposed a slightly different approach here Allow for treasury.voidSpend on the respective track where the payout is approved · Issue #1026 · polkadot-fellows/runtimes · GitHub But honestly, any solution that lets us act swiftly will be good.

6 Likes

Thanks for bringing this up.

Your solution as well as @radha ‘s only allow for binary decisions: cancel or don’t cancel.

I could foresee many cases of milestone delivery delays. In those situations a payout cancelation might be an overkill since the proposers then would have to go through OpenGov again for a new funding request. This could potentially delay the project further and bring about great uncertainty for the team. At the same time, letting the payout proceed as scheduled exposes the treasury to significant risks which we would not want either.

The Treasury Guardian has logic that allows payouts to be delayed by doing the following: canceling the currently scheduled payout and then in the same referendum creating a new scheduled payout X days later. See an example here: https://polkadot.subsquare.io/referenda/1817

In case this separate track does not have treasury.spend permissions, the above delay solution would not longer work. As I mentioned on the Github post referenced above however, perhaps the introduction of a separate delay_spend call might be the best solution for maintaining the ability to delay spends.

Perhaps a separate track for void_spend and delay_spend (to be created) calls? A separate track for payout scheduling matters seems more sensible to me than the proposed solution by @radha since it keeps OpenGov more organized.

2 Likes

There is a push in OpenGov to encourage projects to use referenda that include several milestone-based scheduled payouts as opposed to a full up-front payment.

Example: https://polkadot.subsquare.io/referenda/1794

When these referenda get executed, the payouts will get scheduled on-chain to be then automatically paid out at the specified dates.

The only way to cancel these payouts is via OpenGov. You currently need to create a referendum on the Treasurer track with a void_spend(spend_id) call to cancel a scheduled payout. Since a cancelation of a payout has to go via the Treasurer Track the whole process to cancel an upcoming payout currently takes 36 days.

Here improvements to the current scheduled payout cancelation process are being discussed. Specifically to reduce the time required to cancel a payout by having a separate track for scheduled payout cancelations and give this track a shorter voting period amongst other things.

These are pretty good ideas. Maybe a change_spend() that can delay and potentially lower the amount of the spend.

We could either update the existing proposal or submit an additional one. At the moment I would tend to treat this as a separate idea.

It would be helpful to understand from a core developer how feasible changing a spend is after it has been approved.

1 Like