Milestone-Based Payouts at Scale: A Tool for Efficient Treasury Spending
The majority of projects funded by the Polkadot Treasury still request full upfront payments. However, some projects have transitioned to milestone-based staged payouts, as seen in Referenda #1425, #1439, and #1497.
Milestone-based payments offer clear benefits for the Polkadot Treasury:
Reduced Risk: Payments are tied to milestone delivery, minimizing financial risk to the Treasury.
Guaranteed Payouts: Projects receive funds automatically upon meeting promised milestones.
How Milestone-Based Payouts Work
A preimage is created with multiple payouts scheduled at specific future blocks.
If the community approves the proposal via OpenGov, the payments are scheduled in the Treasury pallet.
Without intervention, these payments are executed automatically at their designated blocks.
The Problem
No tooling currently exists to:
Track scheduled payouts.
Take action to protect the Treasury if milestones are delayed or not met.
The Solution: Treasury Guardian Tool
Our tool, Treasury Guardian, enables anyone to:
Track upcoming Treasury spends.
Propose actions (e.g., delaying or canceling spends) to protect the Treasury if milestones are not met.
Earn a financial reward for successful interventions.
How It Works: Example Scenario
Project X has a scheduled payout in one month for a milestone due today.
Bob, a Treasury Guardian, tracks Project X and notices the team is behind on their milestone.
Bob contacts the team via Polkassembly, Subsquare, or another platform to understand the delay.
The team confirms a two-week delay. Bob uses our tool to create a âDelay Spend Referendumâ with the following transactions (automatically created):
Cancel the currently scheduled payout.
Schedule a new payout in 1 month and 2 weeks, reduced by 2%.
Send the 2% reduction to Bob as a reward if the referendum passes.
The referendum is submitted to OpenGov for voting.
If approved, the transactions are executed as proposed.
Benefits to the Polkadot Ecosystem
More Eyes on the Treasury: Incentivizes a decentralized network of Treasury Guardians to participate in governance and ensure efficient resource use.
Fewer Referenda: Milestone-based proposals bundle multiple payouts into a single referendum, reducing the number of proposals processed by OpenGov.
Encourages Active Communication: The 2% penalty for delayed milestones motivates proposers to provide regular updates to avoid delays.
Scalable Milestone-Based Payments: Enables milestone-based payments at scale by leveraging a decentralized workforce to monitor proposals.
No Disadvantages for Proposers: Projects that meet milestones receive automatic payouts, ensuring financial stability for teams.
Aligned Incentives
Delayed Payouts: If a payout is delayed, the Treasury Guardian receives 2% of the scheduled amount, deducted from the delayed payout (no extra cost to the Treasury).
Canceled Payouts: If a project is abandoned and the payout is canceled, the Treasury Guardian receives 5% of the saved amount, with the Treasury retaining 95%.
Interesting work. The current model seems somewhat set-and-forget. As well as more eyes on the Treasury, this brings more eyes to the value being delivered. Fosters relationship between the team and the âclientâ. Itâs an area of interest to me, as (like most of tech) we seem to be a long way from most of the models in say Ten Agile Contracts Infographic | Saat Network GmbH , let alone the uncertainty-aligned ones.
Is it the case that if a delay (or cancel) proposal is rejected, the payout proceeds as scheduled?
I can see this opening interesting conversations about milestones. Some projects have easily measured milestones like âoffer a PBA-X cohortâ. Would that be coupled with a target of enrolments for that cohort? Does communicating constitute meeting a milestone, even when other delivery has strayed from what was predicted? How does this work with software projects which are inherently unpredictable and may evolve considerably during delivery?
Could a cynical Bob make delay or cancel proposals (esp for projects that passed narrowly) even when teams assert that they are meeting milestones, arguing he deserves 2% for holding the team to account?
Yes, if a delay/cancel proposal is rejected no changes are made to the payout schedule and payout proceeds as scheduled.
Time will tell what the community considers as meeting a milestone. Our goal is not to dictate anything here and rather provide the tooling to facilitate that discussion.
A cynical Bob (or anyone) can create any proposal they want including delay or cancel proposals for any previously approved referenda. It is up to the community to decide on these as they are presented for voting. Bob will only receive the 2% if his delay proposal passes governance. Projects are incentivised to convince the community of maintaining the originally scheduled payments. Token holders are the judges over who has the stronger case.
Rather than reinventing the wheel and being overly complicate, this tool makes use of the existing OpenGov infrastructure which already has deterrents to malicious behavior and also is continuously approved upon.
I would suggest that instead of openGov randoms, when a proposal is submited to openGov there are independent designated âcurators/judges/approversâ to evaluate the delivery.
If the team deliver they approve the payment.
If the team doesnât deliver, they pause the payment, until team does it correctly.
In terms of wording, I would refrain to use the word âdelayâ as it implies that is going to happen at some point.
Is the source available somewhere? (no pressure if not)
A couple of points I noticed when playing around:
I could be wrong, but I think the tx to cancel a payout void_spend (both to re-schedule or cancel) requires a Reject origin, which is for tracks with root - I see the current track for that referendum is BigSpender, which I donât think would make it.
With this we also need to be careful, since it might take some time until a void_spend refereundum gets enough support to get approved and enacted.
Also, your tool always creates a pre-image of the calls to be executed, when itâs not always needed. Preimages are only needed if the calldata exceeds 128 byes. e.g. for Treasury.void_spend itâs most probably not needed, and this way users wonât have to pay the deposit.
I saw that you are using PAPI. If it helps, some of these things are resolved in the referenda-sdk. You can also look at the polkadot bounties dApp we built around many sdks related to governance.
Currently the delay/cancel referenda get created on the track that the original referendum was created on (to ensure amounts requested are satisfied by the track). That is of course playing it safe. I will look into the track point you mentioned.
Yes, milestone payouts should be scheduled 1 month after milestone delivery to give OpenGov time to intervene if need be. One of the next things on my ToDo is to make this clearer in the UI (that action has to be taken a month before payout is scheduled).
I also intend to roll out educational content for the community to see if we are interested in establishing this norm: delivery being 1 month before scheduled payout. If suitable it could be integrated into the existing proposal creation UIs.
Excellent point on the preimage. I will look into whether a better solution can be implemented here. The referendum always has several batched calls in it (void_spend, new spend(s), spend(s) to proposer). Certainly a nice to have as it reduces the barrier for users if no preimage deposit is required.
I will look into the referenda-sdk and the bounties dApp for inspiration .
I cannot thank you enough for this input! Thank you Victor.
I am wondering whether your team has something else planned in the pipeline to facilitate the on-chain submission of milestone-based proposals?
It seems to me that the main blocker to popularising this functionality is the absence of a proper UI. All I found for reference is this guide from the Polkadot Wiki which is using Polkadot-JS. At a time when the majority of people/teams have moved to more mainstream wallets (to simplify their operations and avoid being overwhelmed with technical complexities), such guide clearly doesnât work for the average user.
We would need an accessible and usable UI for all, before we can see more people use the milestone-based option when submitting proposals? Looking at Polkassemblyâs and Subsquareâs most recent proposals, it appears that this area for development isnât accounted for. So, there is room for a team to come in and take this challenge on.
Hey Anaelle,
It is currently possible both on Polkassembly and Subsquare to do scheduled payouts. Although the PA UI seems much more intuitive for this atm.
.
