Howdy. Here are some thoughts about the DAO design (as it currently sits) for trustless finance. The intent is to provide ideas and constructive criticism for the community around the project. Please take them as such. Remember: “strong opinions loosely held.”
A few disclaimers first. I am not a tokenomics ‘expert.’ I’ve participated in a lot of DeFi, and have done so since early 2021. I’ve never designed a protocol. I don’t have any secret bags.
I’m a signatory on a multisig for mStable, another stablecoin project that launched in late 2020. I own a small amount of the MTA token, which I use to vote. I also use the Save product with a relatively small amount deposited.
My background is in information security. Part of that job is adversarial thinking, so I’m used to dissenting with a given plan or implementation. Please don’t take it personally.
I am in favor of the removal of vesting schedules. Vesting is a contentious setup that seems to address one problem (“sell pressure,” an over-rated concern for sure) but doesn’t. Further, it locks your users into the (statistically likely) drawdown of token value. Success isn’t guaranteed, anon.
Users have all sorts of needs financially, and it shouldn’t be surprising that selling your token in order to fund other activities is something users desire to do. Without a compelling reason to hold the token, it will be dumped. No amount of “community alignment” initiative will prevent that. Putting off the dumping doesn’t do anything to correct the weak tokenomics.
Vesting also has UX issues. It’s difficult to cleanly describe someone’s vesting state, especially when you can claim before the full period is done. I’ve personally only seen one vested token with an open claim window ($ACA from Acala’s crowdloan on Polkadot) that was relatively easy to use.
I think voluntary token locking is a much better mechanism overall for getting involvement from users. Users who lock are motivated and have some level of buy-in for the project. It’s up to the project to design a model that rewards that buy-in and grows it over time.
Locking to vote isn’t very interesting by itself. A veTKN that allows you to participate in governance is worth very little in most cases. Instead, the veTKN should have desirable utility (controlling liquidity flow like Curve/Balancer) or accrue a portion of protocol profits (LQTY). The first relies on emergent behavior though; no one cares about a gauge vote on a protocol with 500K USD of treasury and liquidity, for example. Even if you do get a fair amount of liquidity in your protocol, your token value can still languish (TOKE).
Profit-sharing is easy to understand for users and makes the stakes easily digestible. Anyone can look at protocol revenue, the price of the token, and do some math and estimate their returns. It also allows recognizable measures (like ‘APY’) to be used, easing integration on tracking platforms like DeFiLlama.
I strongly dislike the idea of removing the controller in order to artificially give governors something to vote on. In addition to introducing lag to market responses, it could cause a large volume of votes in a short span, causing fatigue; for example, look at the exact chart for UST as it was attempting to recover. Imagine all of the votes that would have had to take place, reacting to large pitches up and down, if HUE were riding that same rollercoaster.
Seems untenable to me.
Going further, removing the algorithmic element makes the protocol much harder to audit. It becomes a bunch of game-theory guesses about what might happen. It also makes exactly what is being voted upon very stressful. Some individual has to write up the proposal. What if they don’t clearly communicate what’s changing, or what’s at stake? What if the normal person who writes these is asleep for 10 hours (see the self-post-mortem of the 2021 Rari hack from here for the real individual costs involved).
Then May 2021 happened…the hardest month of my life. My phone died one night and I woke up, plugged it in and thought it was going to be a normal day. I wake up to 100+ missed calls from friends, family and co-workers. Rari had been hacked for $10m+ when I was asleep. I felt a pit growing in my stomach, I wanted to throw up. While we were truly a decentralized organization, knowing that technology that I helped design caused people to lose money made me feel sick. We needed to lead the community to solutions. We hosted a Discord audio call with 400 people to discuss what we could do, the community helped put together a solutions document and the community eventually voted on the outcome. I tried to speak to nearly every victim to understand them. While it was cool to see human coordination happening at this level, I struggled to sleep for months after.
That ⬆️ versus understanding how the algorithm works with invariants and the state of the system. Good property-based testing would grow confidence in the contract. The problem space seems much more bounded to me. This isn’t to say that it’s not hard though. 😂
Keeping the algorithmic controller makes it easier to copy successful existing designs. As a over-collateralized stable, HUE should look to Liquity LUSD for most of the design cues, in my opinion. LUSD has proven very strong, with the only major downside being a lack of capital efficiency (though more efficient than other over-collat stables).
If there is an insistence on retaining a human element in this core aspect of the protocol (which I would say erodes a fundamental aspect of the ethos), then the controller should allow governance to vote on a range of rates. As I said in a recent call, this would allow some attempts at profit-taking, or making the protocol cheaper to use in a market downturn. Governors could reduce rates to avoid liquidation events as well.
I think the cons outweigh the pros though. My final opinion will pivot on emissions, how easily substantial voting power could be accrued, and the rejection of delegation for voting.
This was a good point to get out in front of. Naturally you would want to avoid the chance of hyper-inflation by virtue of spamming votes. The point in question:
The number of TCP proposals that emit inflation rewards is capped at the maximum possible cadence of interest rate updates.
This was a little difficult to untangle, but the implication is that only votes to the interest-rate would qualify for token rewards.
I suggest that this shouldn’t be the case. All votes (inside of a ‘session’ or time period) should qualify for rewards. A minimum number could be specified, although this is hard to control in times of less governance activity and would result in useless “presence” votes. Combined with a ‘session,’ this allows participation without being overly strict.
Any setup, no matter its final shape, should be paired with multiple avenues for notifications of governance actions requiring votes. EPNS, forum notifications, discord, etc.
I would be interested in a vigorous defense of the suggested model, minting tokens specifically to the “Foundation” (I presume this is ‘the entity that is employing developers and other staff’). This seems unorthodox, though at the edge of my memory it seems like another big protocol does this. Sushi maybe? Not sure.
I’m specifically interested in why the Foundation should be the recipient of new mints, rather than a percentage of existing emissions. This adds to supply, which has to be accounted for by investors and would be harder to track (though not impossible obviously).
I would rather Foundation funding come from protocol revenues, denominated in HUE or an LP token.
I implore the current developers to spend a reasonable amount of time engaging in critical thinking about malicious governance. Fully decentralized governance (on its face) sounds simple to users but is very hard to actually pull off in a resilient way. I’d argue it actually hasn’t been.
I would push for HUE, and the mechanisms around it, to be as governance-minimized as possible. Ideally, it should continue to run without functioning governance endlessly. Governance should be concerned with what to do with profits, how to fund new projects, cooperation with other protocols (treasury swaps, integrations) and getting structure around day-to-day things that need to be done for the community.
The effect is minimizing the attack surface of the protocol; if malicious governance can’t affect the stable directly, that removes a lot of desire to engage in the behavior and limits damage.
Linked with the above, this should be phased out on-chain, in the contracts. I actually don’t think this should be done via public governance, but via the Foundation with a multisig.
The UI of the project, during the first X months, should shout loudly that there are currently admin keys and to factor the risk accordingly (to make Chris Blec happy ⛽🔥). Including a countdown to the block when the keys are destroyed would be a neat feature, IMO.
I definitely push back against attempts to set very lengthy spans for this security functionality. It should be short. 6 months seems like a good target. A year tops.
This provides indemnity benefits; if the protocol gets rekt, it’s much easier to say “there are no admin keys, there’s nothing we could have done, risks were prominently posted” then to be stuck with admin keys over a year to year and a half. If you’re holding keys, then it’s going to be argued that you’re in some way culpable. Further, admin keys make rugs possible.
The Foundation should also consider a phased launch on HUE, with strict limits on the amount of ETH that can be taken in. This limits the damage that can be done early on.
The proposed ‘governance mining’ style is fine. It works reasonably well for PieDAO. I would suggest taking a hard look at bonding (dutch auction style like Olympus Pro, now called just Bond Protocol). Combined with a strong revenue share (driven in part by PCV as deployed liquidity) this would be just about the best start a protocol can get that anyone has devised thus far in DeFi.
This could be done in such a way as to initialize the protocol TCP distribution with bonds, and once a certain quantity was sold kick off ‘normal’ governance. Bonds could be shut off once PCV targets had been met (can you ever have too much PCV?)
I haven’t heard any discussion about how this is planned to be done, but something has to be drawn up for providing trading pools for HUE and TCP. The protocol should make it a priority (as outlined above) to control as much of these two pools as possible, in order to gain as much profit from trading fees as it can. It is deeply unlikely that any other projects are going to just up and pair HUE with their tokens, so it’s incumbent on us to seed these pools, and do so organically.
That’s all I had. Thanks for reading.