With OpenGov treasury proposals spend about 2 weeks in the voting phase. This is more than enough time to see some major price swings in our volatile crypto markets. This post aims to collect feedback and ideas on short term solutions to help better manage our treasury in light of price movements specifically.
Currently proposal creators âlock inâ a KSM amount at proposal creation. While a treasury spend referenda is then going through the voting process, markets may swing either way. This means that sometimes the value of the KSM paid out to the proposal beneficiaries (assuming the referenda passed) varies significantly in its USD value from the funds requested.
During the bear market the swings were usually downward: the received funds were actually not enough. The council was mostly sympathetic in these cases and granted a top-up of the difference through a tip request.
We currently have the opposite happening with payout amounts being 40% above the value requested (due to a sharp increase in KSM price during the past 2 weeks). To put things into perspective, for some of the current referenda we are talking about bonus amounts of 25k USD.
How should we deal with price swings when it comes to treasury spend proposals? Should proposers pay back excess funds to the treasury? Can proposers ask the treasury for extra funds in case of KSM price drops? How should we go about it all?
It would be great to get some consensus on the topic and potentially set some guidelines to which we can fall back and hold proposers accountable to.
I think some proposals already account for some volatility be adding a padding of 10% or more in some cases, which they plan to return to the treasury if unspent. This is the right way to go for now. ie, request for an amount with a padding of around 10% to account for possible votality against the beneficiary, keep the requested amount in the beneficiaryâs address and only make withdrawals based on the milestones that have been achieved.
Once all the milestones have been achieved and thereâre funds remaining (due to favorable market volatility), those funds should be returned to the treasury or another proposal should be submitted to use the remaining funds for new milestones.
Of course, at most, this would be a guideline and thereâs no way to assure that beneficiaries stick to it (unless the proposal is bountied). But the community is a watchful one, and it would be in beneficiariesâ best interest not to deviate as this may reduce their chances of getting their future proposals passed.
If the option above is to come into play, then beneficiaries should also be allowed to top-up their proposal to cover unfunded milestones in case volatility goes against them and their funds dry out earlier than expected.
This solution benefits the beneficiaries short term and could drain the treasury faster, but could do wonders for the treasury in the long-term.
Iâd however advise that we should be consistent with whichever option we choose to stick to. For example, if I prefer USD denominations during a market downturn, I should also be okay with it when volatility turns in my favour and I have to return large chunks back to the treasury.
This is pain point weâve felt for 2/3 years in Edgeware having submitted / delivered and curated about 25 different proposals and projects. Weâve only ever seen the downside (plus thin liquidity which compounds the issue) as EDG price peaked at $0.056 and then consistently fell to around $0.004.
This was majority caused by consistent sell pressure from the requirement to bootstrap contributors and them in turn needing to sell to live as we sought to adapt, evolve and discover the tech in an organic way. The same challenge and associated concern is beginning to be felt in Kusama and across the ecosystem.
We ended up debating the top up / recoup model a lot - and it was divisive. In the end, we agreed only two top ups (via simplemajority, not council tips), where immediate price volatility between submission and receipt threatened the viability of the team delivering.
In all other cases, it was seen as being the price of contributing and the risk / reward on offer.
All proposals we submitted had a 10% network service fee which was calculated on top of the budget - this became our standard way of billing.
With the suggestions above - top ups and recoups, weâre moving closer to a structure that may please voters and holders (accountability/protecting the treasury), but a far worse deal for contributors.
This is a pattern that follows the general trend of treasury conservatism which seems like an inevitable slide in on-chain governed networks with shared pots of money that are subject to wild price swings in fiat denominated terms. (Side note - most conversations focus on how to spend less, almost none focus on how to build greater demand and direct value accrual, this was true in EDG and so far in KSM and DOT.)
If upside is returned (and presumably downside topped up) where is the margin for growing an on-chain service provider? It doesnât make sense to operate at cost if the upside potential is removed, which is imo the whole point of the incentives (when done right).
There can be a bonus earmarked and pre-agreed onchain which is paid at the discretion of the community - which was the direction @shawntabrizi was going in with this post:
However the likely outcome of this retrospective funding is we get into all sorts of issues with voters having ability to approve a job well done, which leans once again into a dangerous path and more bureaucratic stagnation.
There could of course be a âremuneration review collectiveâ - this again exists in most big businesses and is generally known as âcost controlâ.
Ultimately teams donât just need to make ends meet - they need to be trusted and supported financially, culturally until bad behaviour proves otherwise - aka an optimistic stance.
Suggestions
All proposals should be able to charge a fee on top of their costs.
There are no top ups, except in demonstrably extreme situations, where a team has hard costs to cover and the downside swing is prior to payout, and before they can sell.
There is no return of KSM or DOT to the treasury - this removes the incentive to work at the most difficult and early stages of networks.
Consistent contribution through bull and bear should be the convention we aim for - akin to contributors dollar cost averaging into the networks via their contributions.
People believe stable-coins will solve a lot of this - it solves one dimension of the issue but in reality, it also removes the upside and stake that these networks provide to contributors and is a path to detaching them from the incentives that make these networks so interesting, so its important to not see it as panacea.
Per this post I made a while ago, one potential solution to price volatility is to diversify the treasury into multiple assets (particularly stablecoins), so that some proposals can be (either partially or fully) denominated in fiat / stablecoins instead of DOT/KSM.
Of course trying to manage the treasury with mulitple kinds of assets might be a bit tricky, but imo having it all in DOT/KSM might not be best long term, especially in bear markets.
Allow the team to buy âinsuranceâ from the treasury by paying a premium per 1000KSM/DOT to the treasury, in return the treasury will fund the approved amount at the most favorable rate observed during the voting phase.
Is this an approach people are in favour of?
If so, details to be worked out via some grant?
If so, which of the grant avenues?
Thanks Gabe, as I mentioned in Direction, the best short term solutions imo are social:
a culture around Proof of Work, reputation building, project treasury management (treasurer on payroll!), and peer-accountability.
Mid to long term solutions come with the introduction of stable assets where tokenholders can withhold funds until certain milestones are met without bearing the risk of volatility themselves. Offering stable assets will also solve another inefficiency on the project side: liquidation.
I would see any codified solution before the introduction of stable assets to be problematic for the risk put on token holders. When building community and a social layer we should be wary of technocratic solutions deployed prematurely!
Adding to the convo, as discussed some months prior, Iâm in favour of letting projects handle assets as they wish (after returning any excess at initial payment). But token holders should not be expected to bail out projects who risk and lose. Projects should deliver regardless of failed treasury management.
Until stable solutions arise I would love to see more treasury managers in project proposals! It is a big job keeping up with liquidity and risk within our networks!
I think itâs a reasonable temporary measure to ask teams to payback the treasury right after the enactment but perhaps only to selected few cases when the volatility was clearly off the charts.
If I thought of that before and suggested it in our proposal we might not have generated as much controversy, the price swing created a difference of around 200K USD which immediately alerted the community. But most of the time we shouldnât care, as Rich mentions it becomes an incentive. If our team were to have that 200K surplus, since we asked to fund a team instead more than concrete projects we would have just built more things and for longer time which I think is good for the community. On the opposite case of receiving less as it has usually been the case for us(e.g. ~30%), sure it would have been nice to receive a tip to cover the loss but we are âshyâ and just deal with it, what we do now is to make it explicit in the proposal that we need a buffer(e.g. 20%) that weâd likely lock in staking to cover for volatility and possible delays.
Besides staking the buffer, other practices weâll try to follow because I think can improve transparency and give more guarantees to the community but also put us at greater risk are keeping the funds on-chain not cashing them out immediately to a CEX and then fiat like most teams do, but in Kusama at least with big spender funds things become tricky, itâs hard to swap funds to stables as there is not enough liquidity, we would need to convert them slowly(more volatility exposure) and leave the stabilized funds for the later stages of development(a nice side effect can be to move the ecosystem economy more incentivizing liquidity providers in parachains). For the short term spends(still in KSM) we would pay team members with the vesting pallet, it could be monthly or quarterly, but then again even more risk and exposure. A lot of hassle to do the âright thingâ no ? itâs also to show how badly we need to improve the system so the community gets the reassurance it needs.
Getting the best of convenience for the proposer and security for the community requires a lot of work but as usual we can move in steps and make use of the tools already available at least for prototyping. Statemine getting a DEX will be quite interesting as it can be used as the official place for asset conversion on the fly based on user preference or to diversify itâs holdings and keep a stash of different assets, specially stable coins. Hopefully we will have more options besides USDT, but even this we can already use for some initial tests, how about making an XCM that buys a small quantity of USDT in one of the parachains and sends it back to the sovereign account of the treasury in Statemine to allow small tips in USDT for a while? Assets pallet also has approve_transfer to allow third-parties manage part of the funds of an account to have a bounties like functionality. For larger spends we would definitely benefit form at least an equivalent of the vesting pallet but for assets, I think something more powerful would be an adaptation of our orml-payments pallet that would enable the treasury to pay people in any asset, with funds remaining locked in the beneficiary account until some deliverables are finished, we also have the concept of a reviewers/judges that can be unique to each payment, when âsummonedâ they take a tiny percentage of the total amount and then have the final saying if the recipient gets all, nothing or a partial payment whether or not the milestone was completed. Recurrent payments would also be part of its functionality.
Once we figure out payments in stable assets and ways to have some control over how to hand over the funds securely minimizing risk for all the parties involved, a lot of the issues will simply vanish, no more police work form the community
The issue here is youâre risking losing 20% + in a day, and then making your work a massive struggle. We donât speculate up or down other than with pre-agreed margin - 10% network service fee and to be honest we have generally ended up having to sell that too.
Ultimately we need to think about more balanced incentives and ways to create more stability through ecosystem native designs, rather than always falling back to USDT or USDC.
Irrespective of the arguments about them being both untrustworthy (USDT) and part of the system weâre trying to upgrade (USDC), we need to be thinking more deeply about how we design so the value can stay within a closed loop and
regenerative DotSama economy.
Since starting this conversation I have asked proposal creators on whether they will be returning excess funds to the treasury on their respective PA discussions before referenda expiry.
This question is of course still contentious as proposers (understandably) feel like in the absence of clear rules and guidelines around the matter they are losing something.
In the past 1.5 months proposers have pocketed $200,000 excess funds where in some cases the treasury has paid almost 50% above the actual asking amount. These funds could have been used to fund the next amazing ideas!
? itâs also to show how badly we need to improve the system so the community gets the reassurance it needs.
