A Better Treasury System

[shawntabrizi]

This post will dump various ideas of mine on how we can improve the treasury system of Polkadot, both on and off chain.

As a Council member on Kusama and Polkadot since the genesis election, I have reviewed, accepted, and even denied many treasury spends, and throughout my experience, I have formed opinions on what I like, and what I think can be improved.

Why Care

I will be very brief here, but I think it is worthwhile to convince those of you reading this post why a focus on Polkadot’s treasury system is important.

Ultimately, the Polkadot treasury is the one way that the Polkadot network can reach its hand out into the real world, and make things happen. The treasury is quite a unique feature of Polkadot compared to the last generation of chains.

If we can make sure that the treasury is easy to access for the Polkadot community, it will ensure that we will be able to fund and support growth and development of our ecosystem.

Treasury Today

The Polkadot treasury can be simplified to two main parts:

• The Pot - The funds available to the treasury, funded by a portion of the fees on the network.
• Spending Logic - Ways for the treasury to transfer funds from the pot to end users.

The treasury is currently has 3 spending methods:

• Tips - Easy process to spend small amounts of treasury funds. Low overhead, relatively hard to abuse.
• Proposals - A more laborious process to spend large amounts of treasury funds immediately and to a specific account.
• Bounties - The most complex treasury process, which involves multiple actors to coordinate the spending of funds for projects which are agreed upon in advance, but the recipient of the funds may not be known at the time of creation. (this is maybe a bad summary, but yeah, you can read more about it.)

Improving Proposals (Treasury V2)

Proposals were designed to be very simple, but I think that some additional complexity can greatly improve the end to end experience of creating and approving large treasury spends.

Proposal Phases

Currently, if a team opens a proposal for a treasury spend, if accepted, all of those funds are transferred to the team immediately. This is true for small projects, but also large, multi-year projects.

I have been concerned in the past that unknown teams come to the treasury and ask for a lot of money, for a huge project, and we have no idea how to evaluate if the team will actually deliver that project. We may ask the team to reduce the size of their ask, but then a team may be worried that the treasury will not commit to continuing the project once they get started.

Ultimately the proposal system right now is not actually good for allocating funds for really large projects.

I suggest we introduce some simple phases to each treasury proposal, and have teams ask to allocate funds to each specific phase:

1. Starting Spend
2. Reoccurring Spend
3. Final Spend

For the sake of example, I will take the role of a team lead who wants to ask for 100,000 DOT to build a new mobile wallet for Polkadot, and then use this role in the sections below.

Starting Spend

When a team asks for treasury funds, usually they will need some cash up front to get started with the project. This is what the Starting Spend can be used for.

Proposals today are basically ALL starting spend. Without having done any work, I would have asked for 100,000 DOT up front, and basically it would have been very hard to get my proposal approved.

In this case, I know I only need 10,000 DOT to get started on this project, and so I only ask for that amount as my Starting spend.

The treasury has less risk at loosing funds to people that do not deliver, and the proposer can still get the up-front capital they need to begin execution of their project.

Reoccurring Spend

Building a large project may take multiple months or even years. The reoccurring spend is the amount of funds the proposer will need on some reoccurring time scale to keep the project going.

For my example, I expect the project to take around 10 months, and I expect my monthly costs to amount to 5,000 DOT.

In this case, this reoccurring spend logic will be baked into the proposal, and if approved, every month, I can pull from the treasury funds my 5,000 DOT.

In order to get my next months funds, I must also submit a proof of the work done in the last month. This proof does not need to (and cannot really) be verified on chain. Instead, the team puts the data out there, and any user in the Polkadot ecosystem can read the update, and check for themselves the work being done is high quality and worthy of the monthly payments. As you can probably guess, later down we will describe a process where the updates are NOT high quality, and the governance system of Polakdot can end a proposal early, returning any unspent funds back to the treasury.

But generally, this process should be minimal and efficient for the proposing teams. Just provide proof that you have been doing what you said you would, and you can automatically pull out the funds you need to keep building month to month.

Final Spend

Finally, at the end of the project, the development team can potentially get a reward for their hard work done. It could be that the funds requested above were just enough to keep them afloat, but we should reward good contributors to our ecosystem with a profit for their work and hard time.

In this case, I have spent a total of 60,000 DOT for the 10 months of work and the starting spend, and thus my final reward will be 40,000 DOT for a job well done.

This will be a slightly delayed payment, where the proposer can again submit evidence that their work was completed successfully, and the public is given a period of time to review that work, and verify that the initial proposal was indeed satisfied by the work done.

If no one objects to the final spend, the my imaginary team walks away with 40,000 DOT profit on a job well done.

How Phases Effect Proposals

Now lets look at other ways this proposal could have gone, when a team asks for DOT.

1. Only Ask for Starting Spend

   This is exactly how we treat proposals today, and should be backwards compatible if there are UI/UX already developed to optimize this.

2. Only Ask for Reoccurring Spend

   In this scenario, I do not ask for any starting spend or final spend reward to execute my proposal. Instead, I simply ask that over the course of 10 months, I get a 10,000 DOT payment each month for the work done.

   This might make sense for projects where the treasury is already comfortable with the delivery of a team, and does not feel the need to keep the “DOT profits” from the team until the final spend.

   This looks very similar to “child bounties” which exist today on Polkadot.

3. Only Starting Spend and Ending Spend

   This might make sense for projects which are short in their timeline, thus the overhead of doing regular updates for the reoccurring spend would rather just be moved to the final spend.

4. Only Ending Spend

   If implemented cleverly, this can look very similar to the regular bounties system which exists today for the treasury, and potentially could replace it.

5. Etc…

As you can see, based on the amount of money, the kind of proposal, the trust we have in the proposer, etc… these phases can be tuned to spend the same amount of DOT, but over a different schedule, which allows the public to audit and keep track of the work done.

Additionally, we could potentially simplify UI/UX by combining the behaviors of bounties and proposals under a single unified process.

Other Ideas for Phases

There are a million other features and nice to haves which can be added to a phase based treasury spend, and will probably need to be in the final implementation:

• Allowing post-approval adjustments of things like reoccurring spend and final spend amount.
• Giving only a fraction of the Final Spend if the final product is “okay”, but not great.
• Ways to extend the reoccurring spend time period
• Ways to pause reoccurring spend, to allow for closer public audit
• Ways to update where the spends go
• Users placing bonds against asking for funds or stopping a spend from happening
• etc…

Improving Funds

In the example above, we talked about a 10 month project, which is asking for 100,000 DOT. But practically speaking, most of us still live in a world where we need fiat to live and pay people for work.

It could be in a bull market, the 100,000 DOT over 10 months could grow a lot in USD value. However, in bear markets, it could be that your estimated monthly payments are not actually enough to keep the project going.

One way or another, I feel the treasury needs to bring some sense of a stable coin to the system.

We could:

• Have the Polkadot treasury hold and distribute a stable coin.
• Record information about the expected DOT value on chain when a proposal is proposed and passed.
• Use ideas like “gilt”.
• other ideas?

Reputation

This is more of an offchain recommendation, but I do not find that any UIs today do a good job at representing the history of users who ask for funding from the treasury.

Similarly I don’t think we do a good job at making recommendations for new applicants on the size of proposals that the treasury would be comfortable to give out on a first try.

I don’t have any specific ideas here, just rough ideas.

For example, imagine the following table:

# of Proposals Successfully Delivered	$ of Funds for Next Proposal
0	$10,000
1	$50,000
2	$100,000
3	$500,000
4	$1,000,000
…	…

I would when users as for a proposal, I should not need to hunt for their history to see if they have delivered on time, that they are asking for an amount appropriate to what they have delivered in the past, etc… It should be a part of the process that this information is presented to everyone, that users will want to build up their reputation, and that they know what is reasonable to get their proposal approved.

Follow Up + Impact

This is one of the problems that I think will be solved mostly by Proposal Phases and Reputation, but I want to call it out here as a weak point of the current treasury system.

I have reviewed and approved many different proposals on both the Polkadot and Kusama, however, I find it very hard to track or follow the specific impact of those treasury spends.

I think there is a lot of meta things we can do to improve this kind of stuff.

For example:

• Add a logo at the top/bottom of applications and websites with things like “Funded by the Polkadot Treasury”
• At certain funding amounts, expect / require teams to create videos highlighting their work.
  • Tie those videos on-chain or off-chain to the proposals themselves, and the reputation of the proposers.
• Require teams to describe expected impact on the ecosystem, and measure those goals.
• etc…

Decentralizing Data

At the moment, there is no metadata about treasury spends on-chain. If you want to learn what a proposal, bounty, or tip is trying to do, you need to visit a third party website like Polkassembly to get that data. (tips have a small amount of data, but not that good)

I think we should look to add decentralized forms of the treasury spend metadata on-chain. So, adding some new fields to store and update some IPFS hash, which then links to the actual proposal metadata. This would allow anyone to build their own version of a treasury application, and allow us to iterate much more quickly on providing high quality user experiences.

Ideally, we could do the same thing here with the conversation around treasury spends too, but I am not sure what exactly that would look like.

Metrics

I think the general consensus is that the treasury does not spend enough of its funds, but I have still yet to find a place which really paints a clear picture of what is happening with the treasury funds at a high level:

• Which team(s) has been allocated the most overall funds?
• Which teams have had the most proposals approved?
• What was the most expensive proposal approved?
• What is the ratio of approved to denied proposals?
• What percentage of the treasury is spent between spending periods?
• What categories have had the most treasury spending?
  • Wallets
  • Defi
  • Identity
  • Privacy
  • Block Explorers
  • RPC Nodes
  • etc…
• How much is being burnt from the treasury, and what would that look like at different spending amounts?

Once we know at a high level what is happening with the treasury, we can start to give direction and planning to it too. While I am sure that many people are very excited about funding defi projects, my guess is these kinds of proposals are over-represented compared to privacy and identity projects, which is probably a much more compelling use case of Polkadot.

---

I could probably keep going on, but let’s start here, and see what other improvements you all have in mind for the treasury, and what you think about my comments above.

[RTTI-5220]

• For the use of stable coins by treasury (aka. the treasury holding stable coins), we need XCM, right? do we have an estimate on how long until treasury can do that?
• For some statistics and overview on treasury spending, you can check HERE. This is by far a perfect overview, and ideally a platform like Dotreasury would provide this info (and does for some points) but it might help.

[28KX]

This is an insightful writeup from a council point of view which I’m sure isn’t only felt by yourself. Being on the other side from a team that’s in the middle of a large, multi-year project funded through the Ku**ma treasury, maybe I can provide some helpful observations.

Our first proposal was divided into two milestones which totalled $85,000 USD. Our second proposal for milestone 3 is approximately $195K. I think the idea of a stable coin payment is interesting. In hindsight, that would have helped us for our first because the drop in value of KSM from time of award to completion was significant. We likely wouldn’t have been tight on the budget end. We’re lucky to have team members that went over and above what they were doing and that’s what pulled us through.

Our second round of funding was converted into a stable coin immediately which stung a little when KSM went to high $60s but not so much when it was low $40s. At the end of day, making sure everyone is compensated properly is more important.

We really didn’t need all of the funds upfront. The only reason why we opted to go that route was because after reviewing other awarded proposals, it felt like that was standard.

I think this is a great way to balance trust on both sides. If proposers were to be given starting/recurring/end payments, there would definitely need to be adjustments of the token value to USD ratio at time of payout. What would that process look like?

Asking for the amount that we received was nerve-wracking for exactly the points that you have mentioned. I was quite amazed that as a relative unknown person (I had only been in the ecosystem for a few months at the time) with no track record to top it off was granted funds. Because of that, we made a conscious effort to keep a couple of council members updated throughout the milestones so as not to cause any reason for uneccessary concern. A more formal reporting system on behalf of proposers I don’t think is unreasonable considering the opportunity and trust being given to us.

Would you be able to clarify what the post-approval adjustment of spend amounts entails? Is this performance based? I’m assuming it is because of your following point. That’s a tough one to think about. We’re a small team with a conscious budget and wise spending practices. In actual fact, this is a side project, each of us are fully employed elsewhere, this isn’t our main source of income and do this more out of enthusiasm than profit. If we were in a position of having funds adjusted mid-way or at the end, I may not have a team to continue with in the future.

Same applies to the next point about a fractional payment, how is okay vs great measured? Who would make that call? If there was issue with a final product, maybe there could be a chance for the team to bring it up to par before something this would be considered. But back to my point above, if a reporting system throughout was in place for review, this might be avoidable altogether, including how funds are spent. Maybe it could rid of having to pause for audit as well which might be an issue for teams who do this full time and rely on incoming funds.

The funds awarded in relation to number of proposals is a good idea, the amounts could be dependant on the size of the project overall. I just wonder how far $10k would go and what kind of valid proof can be presented to show progress for a large, multi-year project.

Everything mentioned in Follow Up + Imapact should definitely be implemented, the first two points were something we did and could extend further imo and we do wherever possible. We are currently working on how to measure goals as well. It’s different for every sector. Our focus is marketing which would have different metrics vs a project on the technical side.

We’re very thankful for everything, any improvement would be beneficial to everyone involved.

[olanod]

As someone “living of the treasury”, having walked the happy path of starting small with Kusama, a W3F grant and a couple of Polkadot treasury proposals that have been more ambitious over time perhaps I can chime in and share some experiences.

Stable coin payments need to happen, dealing with price fluctuations is a stressful situation that should not be on the builder’s shoulders. But how? it might not be so trivial and would be interesting to discuss as well. Which stable coin? do we want to chose a favorite coin? a group of favorite coins that teams are allowed to chose from? where do stable funds live? use XCM to periodically move and convert collected funds to a specialized (common good?) parachain where the spending takes place? how/when to convert DOT reserves into designated stable coins? should the relay-chain’s governance participate in DeFi protocols directly(e.g. minting stable coin using DOT as collateral)?
Solving all this might become more of a governance challenge than a technical one, perhaps Gov2 could save the day here creating a space for experts in finance(a branch of the Polkadot fellowship?) to suggest the community conservative actions on how to turn DOT into the stable assets of choice?

Feedback on proposals is not always very meaningful/sufficient or agile and I don’t blame anyone for it, on one hand proposals can be very diverse and it’s unreal to think the few people participating in discussions will be experts on every topic, also reviewing proposals is a very time consuming activity that requires reviewers to spend hours or even days to gather all the context necessary to give an educated opinion, the council system falls short as we currently don’t have enough members that can be full time devoted to treasury topics. The W3F grants experience feels more mature even if it’s more cumbersome for applicants, I think the treasury should learn from their experience and try to replicate it in a decentralized manner.

An idea that pops up is, again with the help of Gov2 and the fellowship(or a parallel “builders track”), to use the ranked collective as the reputation system that determines if a team can apply for a given amount of funds, similarly experts reviewing, doing follow-ups and evaluating milestones of proposals should be members of a collective that given track+rank entitles them to a recurring payment. This could be extended the many different kinds of professional activities needed to sustain the ecosystem, I imagine Parity and the Web3 foundation for example breaking up and letting the chain develop itself using this advanced treasury system. Aren’t we aiming for an unstoppable ecosystem?

A better payments system that gives the treasury some certainty that projects will be completed is crucial, also for builders, it might seem that getting a “no strings attached” full payment in advance is good but comes with drawbacks, for one like @28KX mentions we don’t need the full amount up front, there’s an extra worry with price fluctuations if DOT is not converted right away, then there is the fact that we’d like to apply for projects that are more ambitious and with larger scope but there’s pressure to first prove yourself as a team with smaller proposals. It isn’t easy to find team mates that are willing to give up their steady jobs to join the cause, I know several talented people that I’d love to have on board but those doors are closed for now while the resources are not as steady and reliable.

On a related note, some months ago I proposed in Polkassembly Kreivo as a common good chain for Kusama but the conversation died. Now we’ll likely adjust things a bit to proceed with a crowdloan approach but I’d still ask the community to consider at least the usage of orml-payments somewhere since it nicely tackles most of the issues mentioned here. It’s a core functionality of our chain that we completed with the W3F grant and is part of the reason I suggested Kreivo could be seen as common good. In our domain(sustainable marketplaces of real world products and services) we use the pallet to allow for example decentralized on&off-ramps, where its escrow-like system keeps tokens locked until an off-chain action like a bank transfer is confirmed to have happened. The treasury could use this system to pay builders(specially with our planned recurring payments) in a way that funds are only unlocked until the “service” is fully provided whether that is a one time job or an unlimited (transferable)“contract” that pays regularly freeing funds after the corresponding thumbs up. It’s very generic with more features and ways to configure it so I’d argue is better than packing more functionality in the treasury pallet.

Regarding data decentralization, besides the metadata I’d be very interested to see proposals and associated discussions to be decentralized, not necessarily putting things on-chain(a URL perhaps?). I’ve been hesitant to use alternatives to Polkassembly mainly because of the network effect, it’s where everybody already is and there’s going to be more exposure there, it would also be annoying to answer in multiple forums similar questions.
Here my suggestion that I’ve shared in the Kusama direction in the past would be to use Matrix, it’s a great protocol to be used as a general purpose “decentralized storage”, it doesn’t have to be about chat. IPFS based solutions are ok-ish but not the best when adding more complex use cases(like lots of replies, edits, deletions, etc. and reflect them real-time in the UI), it’s easy to end up with poor UX. Each forum is still its own server with its own database but the federated nature of the protocol makes it easy to keep all the different forums in sync and achieve eventual consistency of the data without polluting the blockchain’s expensive storage.

[burdges]

I do think phases clearly help of course, especially for less clear applicants.

We also need some lower bond for doing applications however, like maybe 1%, and separately some process for reducing the bond further. In practice, this process would mirror the community work required to ensure a proposal gets approved anyways.

It’s possible these could be merged so the bond was lower because it only covered the first phase, perhaps plus some small fraction of the total.

[ross]

I see Polkassembly as “governance” platform, and not necessarily a “funding / freelance / job opportunity” platform for expanding the ecosystem. In my eyes this (lack of?) messaging is throwing people off track, and not necessarily allowing them to realise the huge potential that the treasury has.

Polkadot (in Gov2 and beyond) in my eyes has huge potential to capture many development teams’ interests and have the scalability to process a large amount of treasury activity, and this is something we should leverage as much as we can.

Having used a number of freelance platforms in the past (Upwork, Fiverr, Gitcoin, etc) I feel the Polkadot treasury, (in Gov2 and beyond) is in a unique place to have its own dedicated product for discovering proposals, bounty and tipping opportunities in a similar fashion, albeit with decentralisation. This hopefully could bring together many of ideas @shawntabrizi has in mind to an excellent user experience.

[ChrawnnaCorp]

Great ideas, Shawn. It would be great for phase two if there was also an Ongoing Spend option for projects that provide an continuous service to token holders with no end in sight. With it, an option for holders to feather the amount each period – say every 3 months, with an interface for pushing the spend above or below a standard amount.

Not sure if you’re looking at building a gov interface here…

but on the reputation idea, profiles of spenders with all their past projects would be handy. Also a consolidated place for the journey of a proposed spend instead of a new page generated for each step like it is on PA.

Treasury Stable coins obv make everything a lot easier too! Thanks shawn!

[shawntabrizi]

There are at least two reasons I can think of to not to add a perpetual spend option, but nothing is really a huge deal breaker.

First, making a new yearly proposal is low work to a development team, but high signal to the community that their work is relevant, that they have produced an appropriate output for the previous year, and that the amount funding them makes sense for the needs and costs associated with those services.

Second, the treasury is not guaranteed to be funded all the time, and not with certain kinds of tokens. Thus, many perpetual spends may actually lead to the treasury being drained, and some people not getting their payout. Usually, the treasury works by allocating all funds up front, and holding it in a special place to then get spent. Of course, we can only do this for concrete amounts, versus some kind of perpetual amount.

Anyway, I think such an idea makes sense from the human / UX perspective, however not sure if that necessarily outweighs the downsides of a system like that. I would prefer to be conservative with such kinds of features, until it is shown that it is necessary.

[ChrawnnaCorp]

Okay i can see your points here. In such a system, there would be regular presentations of progress, and an opportunity to stop the funding, as well as increase or decrease it. This is how I see the bounty system at the moment, a sort of open account that can be refilled or put to an end. With the Metrics you mentioned and a better idea of an actually workable balance sheet we could have an idea of the output in this way. But points taken.

One of the hardest part about planning with the treasury right now is getting a handle on what the treasury will look like if a spend occurs. There is a lot of guess work and rough math to predict how the treasury will look in 1 week or 1 month especially with the variable income!

[crystalin]

Thank you @shawntabrizi , those are definitely greats ideas.
We also worked on changing our treasury in Moonbeam and have implemented ideas similar to the one you suggested. We also added an initial phase that is off-chain, mostly to help and guide the proposers, providing feedback through our treasury dedicated channel (forum like this one).

I also think the idea of paying with stable coin is better, but I see a lot of challenges maintaining stable coin for the treasury (how do you get those coin in the first place?). Maybe it could:

• Still pay in DOT
• Use an oracle (maybe from a parachain?)
• Have some range of price variation set when the proposal is created.

Ex: Proposing a project with $10,000 in DOTs from treasury (with 20% price variation allowed from the price of the DOT when this proposal was created)

Not sure it is better than others, but simply suggesting some ideas

[rphmeier]

Stablecoin/arbitrary token spends is a use-case we could use XCM for. Two approaches:

1. By maintaining a desired portfolio balance for the Treasury with scheduled XCM processes which gradually trade with DEXes to balance out with low slippage, the Treasury can spend any token T it holds.
2. To have the treasury spend DOT by issuing an XCM which first trades it into token T via a DEX and then transmits to the end-recipient.

[GabrielJ]

Thank you for sharing this Shawn!

I think all these ideas are excellent and hope to see them implemented in practice soon.

Especially the part about aligning spend amounts with the proposer’s reputation would not require any technical changes and could potentially be implemented right away.

Perhaps we can put this up for community discussion in a more “official” capacity on Polkassembly to fine tune the fund allowance for each reputation group? Following the discussion we could then create a democracy proposal (merely a formality) before we potentially implement the reputation system into our proposal creation process and guidelines?

[shawntabrizi]

The lacking treasury spending has been called out in the latest Messari report about Polkadot:

Source

He says that Governance V2 will help this, which certainly it should, but more so, I think an overhaul of the treasury system both in the backend and frontend (as described in this post) will be more impactful.

I think for the time being, the lowest hanging fruit could be banners which can be included in projects that have been funded by the Polkadot treasury as a note for people to go to the Polkadot treasury with their ideas and also get funded.

[rphmeier]

The most impactful way that Gov2 can impact the treasury is for delegates to propose their own ‘agenda’ and ‘budget’ for treasury spending. Clearly communicated areas for spending serve as a beacon to attract further proposals or interested developers.

[shawntabrizi]

I want to write down more concrete ideas for UI/UX which I think can be worked on in the near future and have positive impact into the involvement of users into our democracy system.

I am not a UX guy, so here are some very rough mocks:

The goal is to make a proactive and simple to use application for people to vote with.

• Users can be notified on their mobile / desktop when new proposals are available to vote on.
• Users are presented with a card containing all the relevant information users need to make their decision.
• Voting can be as easy as swiping left or right to the card.
• Users can go through all proposals and make their decisions.
• At the end, a summary page is shown to the user, and a single batch transaction is submitted for all of the votes.

I think something like this could greatly increase voter participation. We would probably need custom cards for different kinds of proposals like:

• Runtime Upgrades
• Treasury Spends (tips, proposals, etc…)
• Fellowship / Society
• Configuration changes (staking, parachains, etc…)
• General extrinsics which do not match a category above

Beyond this, I think we need to create a “dashboard” for governance similar to the successful Staking Dashboard.

The main features I would want to see in the dashboard is individual / group profiles, and a simple to use proposal creation form. It is possible we would want to build these functionalities on top of an existing platform like Polkassembly.

For profiles, we will need a history of treasury spends in the past so that we can do the reputation and follow up / impact ideas I originally posted.

• There should be a process for organizations to easily create a multisig with the individual users
• Organization profiles should list the users of that multisig
• All profiles should have a list of previous proposals they submitted, whether they passed, and any details on the impact of those proposals.
• Any other details which allows organizations and individuals to build up a reputation which can help sway the vote of people one way or another.

Finally, the current method for people to create proposals is to fill out a word document, but I think this process can be made much more streamlined and easy with a web form to fill out.

Compare that to this: Proposal: The operating cost for the nonprofit organization Polkadot Ecology Research Institute for 2022/9-2023/2 - Google Dokumenter

In this case, the UI can do a few things:

• Give users a template expected for filling out treasury proposals.
• Detect organizations, and make suggestions based on that.
  • For example, if the beneficiary has no identity, we can suggest that the user creates an on-chain identity for the account.
  • If the beneficiary has little or no reputation, we can put a warning if the user is asking for too mach funds. Otherwise, we can suggest to the user an upper limit based on their history and reputation.
• We can submit the proposal into a public review draft, which is handled off-chain, and allows people to get fast feedback before officially making the submission on-chain.
• The entire proposal can be turned into a well defined format, and uploaded to the chain using the preimage pallet and on-chain metadata. See Metadata for proposal and referendum by muharem · Pull Request #12568 · paritytech/substrate · GitHub

As always, these are just ideas, probably a lot has been built already, and some people with better design tastes than me can make these things a reality.

[ale]

Hi Shawn, hi all -

Thanks, Shawn for opening up this conversation!

These topics are quite important and I agree with the outline of ideas around Treasury 2. I will provide some further thoughts.

I believe that it’s mission-critical to intervene rapidly to optimize treasury management. At a constant rate of growth over the past 2 years, this is the treasury pot’s longitudinal projection:

Shawn, your thoughts lead into three topic areas:

• Proposal improvements (start spending, recurring, ending)

• Stable coins introduction

• Improvements in the area of reputation, progress tracking, and impact assessment of the treasury proposal with on-chain data

I agree with all of them and add two additional areas of interest, scalability with liaisons and dispute resolution.

#1 Scalability: Liaisons

Introducing a modular capability of Proposals with ongoing milestones makes complete sense. At the same time, it creates the following considerations which will need to be addressed:

Voting to approve a milestone for a treasury expenditure is time-consuming and often requires vertical expertise. To do that properly, it’s often necessary to ensure a back-and-forth with the project. To vote well, one must get information and ask questions iteratively. One must also have access to detailed documentation. Introducing milestones is a great opportunity, with the caveat that there should be a system for updating the milestones throughout the execution period.

In my opinion, we are in a different situation from a startup. There is already a value (in a bear market) of over $200M that the Treasury has to allocate; the Pot was equivalent to $800M in October '21. The Treasury2 system needs to be scalable and comprehensive.

Can a community-based system and delegates scale? I share a thought and am curious to hear your opinion. If it were a matter of voting 10 times a month, a community-based and delegate-based system could work.

However, it seems to me that we are in a different situation. Let’s consider a hypothetical example: let’s assume that the Treasury has to allocate $100M worth of DOT per year. Assuming an average proposal is $250K, it would mean 400 proposals/Y. With a milestone-based approach, we assume an average of 3 milestones per proposal (maybe low?). If so, 1200/Y assessments and 100/monthly are needed. That would mean 25 per week or 5 per day (Monday-Friday).

Now, 5 votes a day assessing project progress is more than a full-time job. With good probability, a full-time person could not even cover all 5. Also, there is an issue of expertise.

Do we imagine it is the delegates who do that? If so, I guess the system is in danger of re-centralizing: the community is unlikely to check so many projects well, especially for the mid and large-size proposal tracks. Full-time delegates would divide the work among themselves. It is not unreasonable to imagine that there would be a small number of delegates doing and voting (actually deciding).

Do we expect delegates to be to produce detailed reports for the community? If so, I doubt a full-time delegate can produce more than one report a day (at best). Even in this circumstance, moreover, there would be two problems:

1. possible collusion: the delegate is the one who has to vote by doing the best interests of the Network. It cannot be the same person who produces objective reports on the work done by a team.

2. unnecessary multiplication of work: do we expect each delegate to make his own report? Doesn’t this risk multiplying the work?

I hope there are no aspects of Gov2 that I am not missing.

In my opinion, it is worthwhile to imagine alternative systems. One of them could be introducing a “truth and management layer”-- a project manager role that provides clear reports and empowers the community and delegates to vote qualitatively and quickly. One report per project - everyone can challenge it.

The most immediate goal would be to lower the time needed for voting from 2.5h to 20 minutes without sacrificing quality. This could be an idea in the direction of identifying some sort of middle ground that ensures decentralization but also efficiency.

This “project manager” could be called a “Liaison,” an expert figure who takes on the obligation to:

• produce objective reports by doing the heavy work of acquiring data

• onboarding and constant dialogue with the team

• guiding the team on bureaucratic aspects, simplifying their work

• taking care of milestones change request

In this way, a kind of “truth layer” and “management layer” is created that can give quality but at the same time facilitate delegate voting and community review.

Such a system can be designed in various ways, for example:

• Liaison does staking and loses in case of challenge

• Liaison also has a reputation

• Liaison is paid with % of value managed

• Etc…

Such an approach could create additional benefits:

• Anti-collusion mechanism. I think an optimistic approach to Web3 governance makes sense. However, it’s good to structure different roles to avoid conflicts of interest. The delegate who dialogues with the project can’t also be the one who votes, especially in a context where delegates will have significant decision-making power.

• Transparency. Objective reports allow the community to vote, leveraging the expertise of the Liaison and the time they devote. Remember that the Liaison can be challenged, and a third party would judge in the case (see next point).

• Project-side efficiency. The liaison becomes the interface for projects, providing clarification and guidance to ensure smooth governance. Treasury must incentivize capable teams to apply and apply for grants: the experience should be efficient and pleasant, the least bureaucratic as possible.

• Dynamic management of milestones: the need to adapt and change milestones is frequent in tech. The Liaison could be the figure in charge of helping to make proposals so that delegates and users can vote easily.

These are just ideas… Obviously, for Proposals below a specific value (e.g., $25000), this system might be overbuilt. But for a proposal worth $1M, this system could be a fit.

These ideas are based on the consensus that seems to be common in Dotsama that the Treasury should be able to efficiently allocate expenditures for large projects, say even $5M. If the direction of thought is interesting, I can expand on those.

#2 Dispute Resolution

Reputation should play a central role in Treasury2 - totally agreed. A good UX, in my opinion, can certainly bring value to the system. There is no necessary need for complex game-theory-based reputation systems for Treasury2. But in my view, there is a need for a system of remedies for disagreements.

Why? Without a disagreement resolution system, there are certain risks, for instance:

• “Super conservative” milestones. Without remedies, a reasonable risk is to end up with a tendency to ask for dozens of mini-milestones. Why? Because once Treasury has sent the money there are no remedies whatsoever.

• Attractiveness for projects. It is important to attract serious actors into the ecosystem. If you are a company or team willing to deliver something in the range of $1M or above, you need to have certainties. One needs a remedy in case of disagreement or, for any reason, a second opinion on milestone progress. Cash flow and committed expenses depend on it.

• Avoidance of slow reputational paths: an effective remedial system allows reputation to be supported and be faster in allowing a newcomer to progress by progressively applying for larger work assignments

• Treasury protection: in the case of a missed milestone there is a remedy. Depending on how it is constructed, the remedy may even have legally binding force in offline jurisdictions.

Also, I don’t want to oversimplify it, but it’s likely there will be over 1B in the treasury to be allocated. Even with a milestone-based system, I think we should seriously consider that once the money is moved to a wallet, there is no remedy of any sort: Treasury and Polkadot are not legal entities– there is no remedy once the money is paid .

For cases like Treasury management, I don’t think a traditional jurisdictional system is fit (slow and expensive), but a system of “review” of the decision by a neutral third party can help. Again, I place a lot of importance on the fact that in October '21 there was $800M of value in treasury, and every 12 months, the number of DOT doubles: Treasury2 should be made for managing these values confidently.

In general, on-chain, rapid, and qualitative dispute resolution systems stimulate growth. It’s counterintuitive. The transaction cost (choice and reliance on the commercial counterparty) becomes lower. The actors know there is a remedy, and are keener to approve new investments rather than prefer to be over-conservative because worried about the risks deriving from the absence of an adequate remedy in case of need.

Depending on the direction, I am prepared with ideas and solutions that can also offer enforceability in offline jurisdictions.

We have a lot of experience in dispute resolution. We contributed to the definition of the Digital Dispute Resolutions (UK Jurisdictional Taskforce), won a related public tender (LawTechUK), and much more in the past years. More recently, we have moved to Substrate, and after months of hard work, we are ready to contribute to the ecosystem.

We are available to contribute, offer feedback, and help.

I’m convinced that the next iteration in Web3 will shift the focus more and more to governance, and as Jur, we intend to provide as much support on the topic.

I would be curious to hear feedback and am always happy to help.

Thanks,

Alessandro

[rich]

@shawntabrizi

I think something like this could greatly increase voter participation. We would probably need custom cards for different kinds of proposals like:

Hey shawn - this is a good approach, and marries closely to where we’re moving with our approach to designing a more engaging, interactive and exciting governance stack.

A few thoughts based on our experience / what we’re working on / where this can get better.

My primary point is what is the fundamental outcome we have in mind when designing all of this stuff.

We should be very clear as to what certain developments aim to optimise, for who and what purpose, since these problems are all part of a bigger picture wrt to driving ‘intelligent adoption’ of the underlying tech/resources/funding, rather than just creating incentives that independently optimise for one narrow but specific outcome.

Without aligning on a core motivation we are in danger of collectively making the overall system worse in aggregate.

A starting point for this is sourcing, sustaining and scaling collective network intelligence.

This is a very different proposition to simply ‘driving adoption / participation’.

First problem, outcome, solution:

• Problem: complex voting systems
• Outcome: poor voter participation
• Solution: simpler mobile app UX/UI w/ swipe / notifications

Making governance voting easier is definitely something we should aim for and simple more proactive UX/UI is important, but it can also optimise for dumb decisions - aka, there should be some time cost to making a good decision and that should be implicit in the design principles.

Other projects such as Proof of Chaos also aim to create incentive systems for encouraging voters - an idea that’s both brilliant in its simplicity, but also potentially dangerous in its current design… e.g. you earn an NFT for voting, but that NFT is not necessarily non-transferable, and so might be tradeable, which leans into the emergence of financial incentives which abstract away the actual ‘vote’ as the purpose of the interaction, ultimately making the system dumber over time.

When seen this way, we can also understand voter participation as an entertainment problem. Yes we want to get people to swipe easily, (tinder for governance) but we also need to make proposals more engaging, so people will stop and read / listen / watch and make decisions in a proactive way - delegating their intelligence, as well as their vote.

Second problem, outcome, solution:

• Problem: no standardisation of proposal data
• Outcome: standardised proposals
• Solution: proposal forms

This is a problem I’m very well aware of, having written Edgeware’s proposal templates, written / structured many proposals for myself and others and reviewed/voted/commented on many more.

The standardising of data inputs - is something we have debated endlessly, since we have no lack of proposals, but a lack of data standardisation causes issues nonetheless, with everyone essentially creating their own structures.

The issues of no standardisation:

• For proposers: a blank sheet of paper is harder to fill out than a few boxes which trends towards proposer apathy / missing info / administrative time suck.

• For voters: makes comparison hard when comparing two proposals on a like for like basis this effects voter engagement, participation and confuses overall sentiment.

A form is the obvious answer to address short term issues, but when we approach this challenge from a longer term perspective of optimising for a bigger picture - sourcing, sustaining and scaling collective network intelligence we can see that some standardisation is useful, but given the diversity of talent we have the potential to fund, across many domains, who each may prefer a different medium of expression, we can then see that standardisation also constrains the intelligence of the collective - voters and proposers.

Put more simply - when we start with the idea that no proposal is final, or correct, or cannot be improved, then we begin to design different systems, optimising for advancing coherence between proposers and also voters. who we should aim to move towards contributors and even co-creators of proposals.

This starting intention has two primary effects on the way we imagine and design these systems:

1. We take the pressure off people to write ‘great proposals’ to convince voters.

Currently we are headed towards ever longer documents, associated materials, references, spreadsheets, colourful language and big promises that adds to the administrative burden on everyone and further reduces voter / proposer participation and makes the whole process into something that optimises for a certain type of specialist proposal writer.

2. We move the system away from binaries - proposers / voters who end up in an adversarial relationship, and towards outcomes that prioritise collective endeavours.

This is perhaps a radical, but obvious approach, that aims to optimise once again for a larger aim, than simply engineering away the symptoms of much bigger issues.

Preferendums

Referendums offer binary votes on some package of information, but as we know they are very dumb tools.

We are developing Root - a collective creation and decision making system that uses a composable voting system inspired by Borda’s Count to compute voting and allow contributors to create preferendums directly linked to the governance pallets.

As a proposer, I can create a draft with as much or as little information as I am able, using whatever titles / headings / structures or even in the future mediums (code/text/gif/image/video etc).

As a participant, I can create alternatives to a proposal’s content, structure or subject, add my own view directly on-chain, and tend to a consensus by voting for my preferences for a better decision-making process.

On first impression, this might sound like it will have an even greater administrative burden on proposers and voters - but this is before we consider:

1. Economic participation.

Suddenly we can open up proposals as economic opportunities for anyone to review/improve/iterate proposals and indeed the projects themselves.

Engagement can have a reputational, financial and creative upside, that aligns incentives between all parties better than the current system.

It also starts to solve other issues - namely, information assymetry between voters (who are likely more familiar with the core chain/tech/culture) and outsiders, namely those wandering into the lion’s den - with excitement and energy ready to be pummeled out of them…

We can see how from here we also begin to solve issues such as talent acquistion, development and accreditation using the system to bootstrap the sourcing, sustaining and scaling collective network intelligence.

2. Imaginative proposals

We inspire more originality and opportunity. By pushing in exactly the opposite direction to form creation and data standardisation, we design in a more humane way… appreciating that what works for some, will not work for all.

2. Boostrapping on-chain organisations (creative collectives)

If the process just ends with voters approving funds into a ‘project’multsig’, we essentially leave the funded team successful in one part of the process (getting funding approval) but left entirely on their own to figure out delivery of what is in essence something that almost always needs to mesh with a complex and ever changing underlying system.

This leads to proposals taking far longer, teams being paid far less, whilst voters get irate at the time taken, which leads to mistrust, which further exacerbates tensions, which further degrates the governance process. Both sides move apart, and lessons are never learned.

If we can drive forward more nuanced and interactive decision making, that leads to more imaginative proposals that enable us to share financial value and credit more fairly across a group, we can then begin to see this whole process as the pre-formation process for talent sourcing and the setup of fluid and optimistic on-chain organisational structures like shokunin’s proxies.

I’ve written more about this approach in a previous post.

@rich

t has been said that Polkadot is the biggest bet yet on multi-chain maximalism, but it is also unquestionably the biggest bet yet on the power to change and the ability to direct - to coordinate not just on-chain orgs, but a whole armada of chains… with the arrival of parathreads able to spin up and down, we also have another dimension of change to think about - transitory projects,

For the multi-chain vision of relays, parachains and XCM to succeed, it demands active and sustained creative collaboration across chains, communities and contributors, in a manner that is far harder to coordinate that anything yet attempted in any other ecosystem.

And what is more, it needs to ensure this coordination ensures primacy of the founding aims of Web3 - of the mission over the market cap…

This is DotSama’s greatest strength, and weakness…

If Bitcoin is a slab of rock, and Ethereum a giant container ship changing direction once every few years, then DotSama aims to be…

We need to manifest the murmeration - in many ways, with this forum, we are already seeing that happen…

This is core to realising and indeed releasing polkadot’s potential - if we don’t, the existing incentives will exert their own gravity and pull inwards with inevitable consequences.

[rich]

@ale

This “project manager” could be called a “Liaison,” an expert figure who takes on the obligation to:

• produce objective reports by doing the heavy work of acquiring data
• onboarding and constant dialogue with the team
• guiding the team on bureaucratic aspects, simplifying their work
• taking care of milestones change request

this is what we have been doing at a small scale for 2+ years in Edgeware - we call it 'network services’.

@ale

Also, I don’t want to oversimplify it, but it’s likely there will be over 1B in the treasury to be allocated. Even with a milestone-based system, I think we should seriously consider that once the money is moved to a wallet, there is no remedy of any sort: Treasury and Polkadot are not legal entities– there is no remedy once the money is paid .

oversight can be achieved using anon-proxy based organisations w/ governance oversight from relay/parachains.

@rich

There is an opportunity to use basic organisational structures such as Optimistic Orgs (as pioneered by Shokunin Network) which leverage time delayed proxies.

and

@rich

ParaNotes utilise DotSama’s basic financial, governance and organisational super-powers - those introduced and expanded by common good parachains.

ParaNotes create a secured loan with a pre-agreed loan to value (LTV) ratio that is updated in real time through price oracles. This LTV is reviewed annually, with relay on-chain governance able to writeoff, recall, top up or expand the underlying collateral.

Both relay and parachain governance has cancel permissions with appropriate time delays to enable emergency oversight over delegated funds.

Saw this too - we’re also UK based, worth chatting.

@ale

We have a lot of experience in dispute resolution. We contributed to the definition of the Digital Dispute Resolutions (UK Jurisdictional Taskforce), won a related public tender (LawTechUK), and much more in the past years. More recently, we have moved to Substrate, and after months of hard work, we are ready to contribute to the ecosystem.

[ale]

Thank you, Rich. Very interesting. I will delve into it over the weekend, with pleasure.

Regarding Network Services in Edgeware, it would be interesting if you could share the learnings from these experiments: what worked better, what worked worse? If you happen to have any links to recommend where there is some commentary on the model results, I would happily read them.

About optimistic orgs or other solutions to ensure oversight, I will look into that, I am intrigued. In general, an oversight function or optimistic organizations and dispute resolution are two tools that fulfill different needs. Dispute resolution should be handled neutrally, ensuring both sides of the relationship (a fair judgment). Oversight through anon proxy seems to me more like a governance tool to protect the money proxy.

Gladly! We are not UK based, but let’s surely chat

[XyloDrone]

Hey Folks,

I’ve conducted an analysis of all things mentioned in this post, let me try to sum these up and add my own suggestions, as Ordum is building solutions for parts of this user journey and we’d be happy to expand our scope if additional features are in the interest of the community.

Let’s start from the beginning as @rich mentioned: what is the treasury for and for whom does it need to be optimised for.

@rich

We should be very clear as to what certain developments aim to optimise, for who and what purpose, since these problems are all part of a bigger picture wrt to driving ‘intelligent adoption’ of the underlying tech/resources/funding, rather than just creating incentives that independently optimise for one narrow but specific outcome.

@shawntabrizi has opened the initial post with this answer:

@shawntabrizi

Ultimately, the Polkadot treasury is the one way that the Polkadot network can reach its hand out into the real world, and make things happen. The treasury is quite a unique feature of Polkadot compared to the last generation of chains.

If we can make sure that the treasury is easy to access for the Polkadot community, it will ensure that we will be able to fund and support growth and development of our ecosystem.

Based on this response, I think we need further segregation and project references to demonstrate to new teams what the treasury is looking for (eg. Events, media…).

Let me share a user journey map which documents:

• Off chan processes
• On chains processes
• Different groups/users involved in the process (delegates / delegators , community, fellowship, applicants)

Now let’s sum up all the pain points everyone mentioned and see where they create friction within the user journey:

Let’s breakdown every step and address problems / solutions:

1. Understanding of Blockchain / crypto currency (For an example, we can have a Polkadot educational site where a new user can generally learn about blockchain. One of the issues we are facing is this GENERAL lack of education and understanding of what cryptocurrency is, let alone what DOT/KSM tokens are used for. The general public needs to comprehend the utility behind our tokens… and stop perceiving them as purely an investment / security - which clearly they are not. This would increase participation and voter turnout if our current holders / investors are interested in doing so, they just did not know).

2. Understanding of the Paraverse technology and functionalities; Substrate, Rust, Pallets etc—> I believe we are tackling these with the educational content that keeps coming out(academies, videos quizes etc) as well as plenty of builders programs which we wish to aggregate within Ordum and guide potential applicants to relevant programs and grants within the ecosystem. There will be a steep learning curve but we can tackle this friction with time and links within a dash board to relevant educational information. Also; we need 1 place for all of our documentation, currently it is a bit scattered.

3. Understanding the treasury system and submissions

Our system is quite complex and we have 3 types of grants(+ NORMAL grants lol ). In my honest opinion, the new Polkadot site explains very well how all of these work. If we link in our dashboard the relevant docs and videos, this would probably be very clear(would need data to confirm, it’s obviously an assumption). There is also a question here to be raised. Do we want to make our treasuries available to non crypto people? Eg. what if someone wants to build a power grid in a third world country?

I would personally like to see more examples of different types of projects such as events etc.
Additionally, it could be helpful to have a more detailed list of projects the treasury is interested in funding, as well as a detailed breakdown of the active bounties so that projects are directed to the right place (eg. Why go to the ksm/dot treasury if there is an events bounty? And if the events bounty rejects an event I think the treasury should do so as well and vice versa. This protocol would prevent bad actors).

@burdges

We also need some lower bond for doing applications however, like maybe 1%, and separately some process for reducing the bond further. In practice, this process would mirror the community work required to ensure a proposal gets approved anyways.

Bonds could be lower for cheap projects, but I think for very high amounts it should be relatively high just to prevent spam (not personally sure what this price be. Possibly just on Polkadot and not on Kusama as it currently stands).

4. Idea - I think this is self explanatory lol

5. Application
   I have to admit, filing out those google docs templates feels like torture and that whole process feels like a crime against humanity. On that note, I agree here with Rich and Shawn here;

@ale

Treasury must incentivize capable teams to apply and apply for grants: the experience should be efficient and pleasant, the least bureaucratic as possible.

@rich

For proposers: a blank sheet of paper is harder to fill out than a few boxes which trends towards proposer apathy / missing info / administrative time suck.

We need to make our template much more UX friendly, precise, with boxes(lol). Within Ordum, each grant issuer / foundation would be able to custom build their own boxes(lol again xD) for each program and grant. Filling out a non UX friendly, hardly legible and low customisable template with serious, academic content is off putting. This needs to change. Now.

It is bad for the applicant due to a straining process, while the delegators / delegates and community will have a tough time reading these due to low legibility. We have summaries on Polkassembly / Subsquare / Commonwealth. We should have clear guidelines for TL;DRs so delegates/delegators and the community can quickly read the summary and additional details if needed to make a decision(eg. problem, solution, amount, category).

@rich

For voters: makes comparison hard when comparing two proposals on a like for like basis this effects voter engagement, participation and confuses overall sentiment.

(we can also hint here to voters that there are multiple proposals in the same Origin they can vote for, so they can choose which one they prefer)

I’d also like to touch upon Shawn’s other two points regarding guidelines:

@shawntabrizi

For example, if the beneficiary has no identity, we can suggest that the user creates an on-chain identity for the account.

—> we can add these guides within Ordum and were thinking of doing so

@shawntabrizi

If the beneficiary has little or no reputation, we can put a warning if the user is asking for too mach funds. Otherwise, we can suggest to the user an upper limit based on their history and reputation.

@ale

Improvements in the area of reputation, progress tracking, and impact assessment of the treasury proposal with on-chain data

We are capable and interested in adding all of these to Ordum. One of our research milestones focuses on the interaction of non-transferable, reputation based NFTs, smart contracts and DIDs / wallet addresses. So we will be working on the reputation system which will be displayed in an applicant’s profile. Since we are building on Phala, I think it would be good for applicant / grant recipients to be able to showcase when, by whom and to what extent have they been funded in their road maps. Each grant issuer would be able to mint their reports as non-transferable, reputation based NFTs which would be bound to the teams wallets or DIDs. We can continue the discussion and see which metrics would be beneficial to this system.

—> on the other side, we can add warning signs to the community for teams asking for high amounts with a low delivery score. But we must be very careful here, as this might have ethical consequences. In terms of plagiarism, we could implement machine learning to compare the published proposals with existing ones (like we have for academic papers in universities etc) and flag them for plagiarism or some kind of non-compliance. Again, touchy subject, we would have to be careful here.

@shawntabrizi

• Starting Spend
• Reoccurring Spend
• Final Spend

We can add this as a drop down when applying for a grant within Ordum.

@shawntabrizi

Additionally, we could potentially simplify UI/UX by combining the behaviors of bounties and proposals under a single unified process.

—> as well as all funding types and builders programs.

6. Evaluation & 7. Voting

Again, I very much agree here with Rich and have raised the same issues regarding proof of chaos; our users should not be “bribed to vote”. I can understand entities issuing non transferable NFTs to voters… but tradable… IRL this would be considered bribery.

@rich

Making governance voting easier is definitely something we should aim for and simple more proactive UX/UI is important, but it can also optimise for dumb decisions - aka, there should be some time cost to making a good decision and that should be implicit in the design principles.

Other projects such as Proof of Chaos also aim to create incentive systems for encouraging voters - an idea that’s both brilliant in its simplicity, but also potentially dangerous in its current design… e.g. you earn an NFT for voting, but that NFT is not necessarily non-transferable, and so might be tradeable, which leans into the emergence of financial incentives which abstract away the actual ‘vote’ as the purpose of the interaction, ultimately making the system dumber over time.

When seen this way, we can also understand voter participation as an entertainment problem. Yes we want to get people to swipe easily, (tinder for governance) but we also need to make proposals more engaging, so people will stop and read / listen / watch and make decisions in a proactive way - delegating their intelligence, as well as their vote.

On that note, I disagree with the Tinder interface (it already dehumanised people, let’s not bring it into something as serious as voting. If linked with proof of chaos then people will just press vote to get NFTs. However, I think there should be quizes around technical referendums which grant awards for some kind of completion and comprehending knowledge, rather than the vote itself). I think Nova Wallet has an amazing governance integration. Let’s face it, most people don’t know that there are motions and proposals out there that they can vote on. With mobile notifications and such a slick UI, everyone can easily be reminded of what is going on.

@rich

Put more simply - when we start with the idea that no proposal is final, or correct, or cannot be improved, then we begin to design different systems, optimising for advancing coherence between proposers and also voters. who we should aim to move towards contributors and even co-creators of proposals.

I agree with this statement. Until we put an idea out there and get constructive feedback on how to go on about some things, gather information and data in the fields that we are not experts in or exposed to… then we simply do not know what is out there. Hence why we should let the community speak and give feedback. And perhaps this is where something like proof of chaos comes in… to incentives those giving constructive feedback.

@olanod

Feedback on proposals is not always very meaningful/sufficient or agile and I don’t blame anyone for it, on one hand proposals can be very diverse and it’s unreal to think the few people participating in discussions will be experts on every topic, also reviewing proposals is a very time consuming activity that requires reviewers to spend hours or even days to gather all the context necessary to give an educated opinion, the council system falls short as we currently don’t have enough members that can be full time devoted to treasury topics. The W3F grants experience feels more mature even if it’s more cumbersome for applicants, I think the treasury should learn from their experience and try to replicate it in a decentralized manner.

I think we should have relevant sub-daos and bounties set up for evaluating projects within their expertise. I am sure that all councillors in the past needed to vote on something which was not their area of expertise. In my opinion, those providing feedback should be incentivised and compensated, ESPECIALLY if they are experts in their own rights. We need their help to shape better proposals. These could also be groups to which we delegate our votes to (eg. Shokunin Network could put forward and evaluate \ give feedback to public goods, VR projects, etc). I am not saying these should be official bodies like councils, nor that their opinions can sway the vote, but they provide relevant and quick feedback on the proposals relevant to their fields. These “experts” can be ranked the same way as the fellowship, but let’s say the group consists of UX/UI experts.

@shawntabrizi

• We can submit the proposal into a public review draft, which is handled off-chain, and allows people to get fast feedback before officially making the submission on-chain.
• The entire proposal can be turned into a well defined format, and uploaded to the chain using the preimage pallet and on-chain metadata. See Metadata for proposal and referendum by muharem · Pull Request #12568 · paritytech/substrate · GitHub

Once the applicant is ready to submit the proposal on chain, we can enable this in Ordum with a simple UI when they are ready with their draft.

One thing from my perspective that is missing is some kind of timeframe to signal that the proposal is ready to go on chain or some kind of notification that says: OK FOLKS YOU HAVE ENOUGH INFO GO AND SORT THIS OUT. Not sure how to automate this, but would be good to do so, as it would take a lot of responsibilities from other people… but I differ.

Payment execution, accountability(I’ve broken the solutions for this down above so I won’t comment further on it) and volatility -

a. Accountability —> resolved with reputation management, DIDs, non transferable NFTs

b. In case the payment is a reoccurring spend, I suggest that we have an X amount of time until it lasts, then the spend of the teams gets re-evaluated and adjusted based on metrics and delivery success ratio.

c. We either create or use existing web3 accounting software or on chain / off chain statements and databases to see how the funding was spent

d. If someone from the community sounds the alarm that the funds were given to back actors, we should be able to put the proposals up again for a vote, have AMAs, look into data etc to clarify situations —> then add this to the rep score.

e. Build custom pallets for payment systems so we can automate this process but also block it

f. Stable coins - this is erm… a touchy subject, especially in regards to the Luna crash, aUSD de-peg, questionable affairs by USDT etc. If we would to issue our own algorithmic stable coin, we would have to keep in mind that regulators will probably put a giant magnifying glass on us . The other option would be to use USDC (which I am not a fan of for certain reasons, but I have my reasons to believe that it won’t ever de-peg) and/or encourage teams to use a preferred stable coin or which one NOT to use.

g. It was mentioned elsewhere that is up to the team to decide what they do with the grant finances, however, I would personally prohibit them from using these funds in defi etc, just to prevent, erm the loss of funds.

Report + 10. credit -

a. Once a milestone is complete the team will be able to submit these via Github and/or Ordum UI for evaluation (the grant issuers can define the template on their side of the UI)

b. if the team had any changes to the milestones they can mention it here and adjust accordingly

c. I think the sub-daos, delegators and community should together evaluate the proposal they voted on or consulted on

d. Each treasury / foundation / grant issuer mints a non-transferable NFT with the report that is bound to the address of the applicant. This would be displayed in the Ordum profile section or an entity can enquire to see it if needed.

11. Analytics
a. We can define specific parameters and scrape data from the chain and reports(and we have some awesome tools already out there for this purpose)

b. We’d need to define KPIs by which we measure treasury impact in order to see what the project success rate it

Right. So I think this kind of sums it up. I won’t refer further to Shawn’s UX/UI post as I think we need to define the overall architecture of these systems and how they interact together. After all, we discussed 3 different things:

• treasury
• governance
• designing dapps for both

I’d love to hear your feedback above on the user journeys and the summary… and once you do share your thoughts I’d personally be very eager to:

• design the information architecture
• we at Ordum can conduct technical research and actually build this in cohesion with other projects
• design the UI
• Build with the help of treasury backings

Thanks for your time, I hope we can all work together to make this experience amazing and our ecosystem even better.