Treasury Guardianship

[GabrielJ]

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.

Advantages of Milestone-Based Payouts

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

1. A preimage is created with multiple payouts scheduled at specific future blocks.
2. If the community approves the proposal via OpenGov, the payments are scheduled in the Treasury pallet.
3. 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.

1. Bob, a Treasury Guardian, tracks Project X and notices the team is behind on their milestone.
2. Bob contacts the team via Polkassembly, Subsquare, or another platform to understand the delay.
3. 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.
4. The referendum is submitted to OpenGov for voting.
5. If approved, the transactions are executed as proposed.

Benefits to the Polkadot Ecosystem

1. More Eyes on the Treasury: Incentivizes a decentralized network of Treasury Guardians to participate in governance and ensure efficient resource use.
2. Fewer Referenda: Milestone-based proposals bundle multiple payouts into a single referendum, reducing the number of proposals processed by OpenGov.
3. Encourages Active Communication: The 2% penalty for delayed milestones motivates proposers to provide regular updates to avoid delays.
4. Scalable Milestone-Based Payments: Enables milestone-based payments at scale by leveraging a decentralized workforce to monitor proposals.
5. 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%.

Next Steps

To test Treasury Guardian, we plan to do the following on Kusama:

1. Create a referendum with a scheduled payout of 1 KSM in the future.
2. Use the tool to propose a delay referendum for this payout.
3. If successful, propose a cancel referendum to further test the tool.

We invite the community to support these referenda to ensure thorough testing.

Try Our Tool

Explore Treasury Guardian at: https://www.treasury-guardian.app/

Please give us your feedback!

And give us a follow on X for latest updates: https://x.com/TreasuryEff

---

Help us protect the Polkadot Treasury and incentivize efficient project delivery!

[junglanml]

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?

[GabrielJ]

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.

[wabkebab]

@GabrielJ

• 1. Propose actions (e.g., delaying or canceling spends) to protect the Treasury if milestones are not met.
  2. Earn a financial reward for successful interventions.

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.

[voliva]

That’s interesting!

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.

[GabrielJ]

Perfect! Thanks so much for that input.

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.

[GabrielJ]

We are moving along our Roadmap nicely.

After giving the website a complete revamp, we have successfully demoed a spend delay via our tool:

https://kusama.subsquare.io/referenda/580

[anaelleltd]

Hello Gabriel,

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.

Thanks!

[GabrielJ]

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.

We are interested in pushing milestone-based scheduled payout referenda as a whole though as we see them highly beneficial to treasury efficiency.

We currently have the following discussion post up on Polkadot to gauge interest: Polkassembly - Milestone-Based Payouts at Scale: Treasury Guardian Tool for Efficient Polkadot Treasury Spending #3337

[GabrielJ]

The delay demo for the treasury guardian was a success with https://kusama.subsquare.io/referenda/597 executing successfully!!!

The goal: Delay the spend of 1 KSM scheduled to Bill on 25/3/26 (Spend #6: https://kusama.subsquare.io/treasury/spends/6) by 50 days .

The treasury guardian tool prepared a referendum to do the following:

1. Cancel original scheduled spend (Spend #6)
2. Create a new scheduled spend at 98% of original value (50 days after original scheduled spend: 14/5/26. Spend #7: https://kusama.subsquare.io/treasury/spends/7)
3. Pay out 2% of original value immediately to treasury guardian that created the delay referendum (Spend #8: https://kusama.subsquare.io/treasury/spends/8)

With the treasury guardian we now have a tool that incentivises treasury oversight. This paves the way for milestone-based scheduled payout referenda at scale.

1. Governance approves referenda that encompass several scheduled payouts based on milestones.
2. An army of treasury guardians is incentivised to keep an eye on the projects as milestones become due.
3. Treasury guardians create delay/cancel referenda with our tool and earn part of the funds they delay/cancel should their referenda be successful.

We will also be demoing how treasury spends can be canceled with our tool soon.

[HopeClary]

I would like to bring some color and my experience to your attempt at a working model. I really like this concept, as I had also mentioned this onchain, however there are a few hurtles to get over.

• Attracting people
• Scarcity mindset/worry

As this current model reads, as a Product person planning I think “ WOW, what if X,Y or Z happens?'“ where would I pull funds from? How would my team be paid if a life hiccup occurs???

I would like to suggest a 20% drawer up front with 1st initial payout. If a team gets delayed because we’re creating things they or society has never done before, we require financial room to keep people paying rent, or mortgages & food. When you work for the man you get a secured base salary and this is the number one reason people work in big corp. If we want to become an alternative to that and keep and retain talent, we must think differently, for not only the treasury, but for the people we’re sponsoring to do work. We must get out of scarcity and lack mindset for people we do not know personally. We must provide runway for teams to succeed and learn valuable life lessons along the way.

[GabrielJ]

Currently voters have turned very conservative and projects are having a harder time getting their proposals approved.

This project is more about reducing the risk to the treasury by having a clawback mechanism should things not work out. With this clawback mechanism in place the goal is to reduce the risk to the treasury and thus give voters peace of mind to approve more funding for the right projects.

The up-front amounts acceptable to token holders are to be seen. It seems sensible to me to provide certain up-front guarantees to projects as a cushion but I cannot comment on the general consensus.

[GabrielJ]

As per feedback on our Treasury Proposal, community members brought up the issue of the delay and cancel reward percentages of 2% and 5% respectively leading to very large payouts to Guardians when intervening on large referenda (we have some proposals with request amounts in the millions). When potential rewards drastically outweigh the effort involved in milestone verification and intervention, very large rewards could potentially lead to negative effects for the treasury and OpenGov.

As one voter put it eloquently:

“I can easily see this degrade into nitpicking milestones and shit flinging from anonymous accounts.”

To ensure that interests are properly aligned between Guardians and the Treasury without introducing negative side effects, we are proposing introducing maximum reward caps for both delay and cancel referenda. What cap amounts (in USD) does the community feel to be appropriate for delay and cancel rewards?

Example: 1k USD cap for delay, 3k USD cap for cancel

The reward curve would look something like this:

Sample payout amounts with their respective rewards:

[HopeClary]

Thank you, I understand the need, hopefully with POP reputation will play a role in my feedback here.

[Mork]

Big fan of this project.

One question about the cryptoeconomics, though ..

What’s to stop a proposal’s beneficiary from delaying and then collecting the delay payout?

[GabrielJ]

Time will tell how OpenGov will react to this. Perhaps token holders will consider this to be a case of effective self-reporting and be okay to reward the transparency with that small guardian reward. To note the guardian reward gets reduced from the future scheduled payout so the team would not gain $$$ by doing this if they deliver on the milestone in the end. If they end up not delivering on the milestone, they would gain the guardian reward.

Perhaps however token holders will think that it is not right for a project to collect a guardian reward themselves and prefer to approve a delay proposal from a known treasury guardian instead of the project. Note that multiple referenda can be created to delay the same payout. First one to be executed by OpenGov is the only one that will execute successfully. Any others will fail to execute.

Something we could include in our UI is a checkbox that a guardian can click to not include a guardian reward. That way teams could use the tool as effective self-reporting of their delays without this introduced caveat you mention. The delayed amount would then not be reduced and no guardian payout transaction would be included in the delay referendum.

I suggest we observe how the current tool is used first and then make any required changes along the way.

[dandan]

1. Where is the money?

Inflation.
That’s the only source. No fees, no real users, no coretime revenue, no external cashflow.
DAP and Treasury Guardianship are just two new ways to redistribute newly minted DOT.
Nothing enters the system from outside.

2. Demand is the problem, not distribution

Blockspace demand is near zero.
Daily active users <60k. Coretime sales <20%. TVL <$500M.
No allocation formula and no guardian can create paying users.
Fixing how we split inflation while demand stays dead is pointless.

3. Wrong priority, wrong timing

Polkadot doesn’t need another internal mechanism in 2025.
We need real adoption, real applications, real revenue.
Until someone is willing to pay actual money for our blockspace, every inflation-funded “reform” is just rearranging deck chairs on the Titanic.

[GabrielJ]

Treasury Guardian ensures that any funding for future projects (that includes projects looking to drive real adoption & revenue) yields actual results.

[dandan]

This basic work should be done by Parity, not by the community patching their broken system.
If OpenGov cannot ensure on‑chain verifiability, these off-chain review processes are a waste of resources.

[Mork]

Demand is the problem, not distribution

Demand is the primary problem. Flawed distribution is the major problem after demand.

Wrong priority

So all of OpenGov should only work on only one thing at a time?

Where is the money?

Well a significant proportion of the money that we did have is now with grifters.
The project is trying to avoid that circumstance happening again if we ever do get a second chance for Polkadot to take off.

wrong timing

And here’s the crux.
Yes, it would have been nice if OpenGov had have been released with protection mechanisms built in (though those would still need be iterated on). But it wasn’t.
So let’s imagine Polkadot does get a Hail Mary, it’s Spring 2027, the treasury recovers and we are once again in the state we were in early 2023 - flush with cash, best tech, bright future ahead of us. But we still don’t have any mechanism to prevent grifters taking the funds from their treasury proposals and disappearing / overcharging / generally being crap after they’ve got their hand on the money.
What happens then?
Just let it happen a second time?
Or, given that your point was ‘timing’, do you suggest that we wait until then, for the upswing of a bull market, when everybody is proposing shiny sexy projects, when devs are getting offers from all over without having to go through the waking nightmare that is OpenGov … we wait until then to even start working on the mechanism to fix the problem which happened 4 years ago in 2023 but, now in 2027, the evidence is not yet in to know if it’s happening again?

This basic work should be done by Parity, not by the community patching their broken system.

Sure it could have been done before OpenGov was released but, given that it wasn’t, then if that is what you believe, then you and I have very different views of the meaning of ‘decentralisation’ (or different views of its importance).

Iterating processes using a game-theoretical method that can be bolted on offchain, and still give the same game-theoretical soundness as the on onchain alternative, the same soundness as if the original blockchain architects built the add-on instead … that is exactly how a decentralised technical system should evolve.
(There is another blockchain that evolves its software primarily through permissionlessly developed bolt-ons. You may have heard of it. And in fact, the ability for infrastructural innovations to be developed permissionlessly is a major driver of demand for its usage. -both by teams in the course of actually innovating said innovation, but even more so by users and investors who are confident that innovation will never be choked up by some bottleneck in the appointed innovation team, as it so often has been in the Polkadot eco.)

If OpenGov cannot ensure on‑chain verifiability [presumably of proposers’ compliance with milestones?]

Not even going to respond to this point - I honestly can’t imagine how ‘on-chain verifiability’ can be applied to things which happen offchain IRL, let alone things as subjective as proposal milestones.