(source)

Table of Contents

RFC-0000: Spend Canceller Track
Start Date17 December 2025
DescriptionIntroduce a new OpenGov track for cancelling scheduled treasury spends with a maximum 15-day timeline
AuthorsTommi Enenkel

Summary

This RFC proposes a new OpenGov track called Spend Canceller (Track ID 22) that provides a dedicated, expedited governance pathway for cancelling scheduled treasury spends via treasury.void_spend(). The current mechanism requires using the Treasurer track, which takes approximately 36 days due to its conservative parameters designed for approving large expenditures. This proposal introduces a track with a maximum 15-day timeline, enabling the network to respond more swiftly to problematic or erroneous spend approvals while maintaining appropriate governance safeguards.

Motivation

Polkadot's treasury pallet supports time-based ("milestone-based") spends through the spend() extrinsic, which accepts an optional valid_from parameter to schedule disbursements for future block heights. This mechanism enables staged funding proposals where tranches are released incrementally. This feature is used to present "milestone-based" proposals which are paid out at specified times with the assumption that milestones will be reached by that point in time or cancelled through governance.

Currently, the simplest path to cancel a spend is by using the Treasurer track, which has a decision period of 28 days and confirmation period of 7 days with a linear support treshold curve of 50% to 0%. Under current conditions, this makes it likely that cancellations will conclude not earlier than 4 weeks after submission and can take up to 5 weeks.

This configuration is impractical to use in situations where monthly milestones are being paid out. If the governance community identifies issues with an approved spend, such as project abandonment, scope changes, bad delivery quality, abuse of funds, or incorrect parameters, cancellations might take too long to prevent the next spend.

A better solution would be to introduce a pathway for cancellations that can conclude within 15 days. This RFC proposes to introduce a new track called Spend Canceller

Stakeholders

  • DOT token holders: Will vote on referenda to spend or void spends. Want to retain value at the Treasury and only see it spent when the spend creates value.
  • Governance agents: Need to coordinate responses to non-delivering spends by preparing cancellations.
  • Governance explorer developers: Need to implement changes resulting from this RFC

Explanation

The Spend Canceller track (track ID 22) introduces a new governance origin that is authorized to call treasury.void_spend(index).

Parameters

The parameters of the track are:

ParamValueRationale
Prepare Period2 hoursCopied from Ref canceller
Decision Period14 daysTwo weeks is sufficient time to come to a positive confirmation. If the governance community is uncertain it can decide negatively and a new proposal can be submitted at a later time.
Confirm Period1 dayQuick positive decision that is counterbalanced with the curves. Gives 24 hours for NAY voters to kick the ref out of confirmation.
Min Enactment1 minCan enact immediately
Max Deciding500There can be a lot of concurrently scheduled spends in state
Decision Deposit1000 DOTgiven that Treasurer has 1000 DOT DD, this track should not have a higher one.
Approval CurveLinear 100% -> 50%reasonable
Support CurveLinear 10% -> 0%10% support is possible, and would signal sufficient stakeholder commitment to get the spend cancelled early. Linear curve is conservative, which should be acceptable given the parameters chosen as a whole.

Affected code files

  • runtimes/system-parachains/asset-hubs/asset-hub-polkadot/
    • origins.rs: We add a SpendCanceller origin.
    • tracks.rs: We add the curve constants, add the track to TRACKS_DATA and update track_for().
  • polkadot-sdk/substrate/frame/treasury/src/lib.rs: update RejectOrigin to accept our new SpendCanceller origin.

Edge Cases

Edge cases with regards to spend lifecycle management should be handled by the Treasury pallet itself. No additional edge cases are currently expected.

Drawbacks

A politically motivated agent could overabuse the track. The decision deposit parameter has been chosen to be equal to the Treasurer track decision deposit, so that the surface area for governance attacks stays equal.

Testing, Security, and Privacy

Besides adding tests for the new track to behave as expected, no additional considerations are expected.

Performance, Ergonomics, and Compatibility

Performance

No performance issues are expected.

Ergonomics

The RFC improves OpenGov ergonomics by allowing governance agents to more quickly react to misbheavior. Governance explorers and all other UIs integrating governance have to adapt their interfaces to match the new track.

Compatibility

Existing interfaces should stay fully compatible, since this RFC only improves convenience.

Prior Art and References

The parameters reference other OpenGov tracks to fit into the existing configuration.

Unresolved Questions

None.

None.