Blog discussion: TnD and jaypow

At request, here’s the body of my post from way back in July:

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.

Removal of automatic lockups

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.

Token locking

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.

Interest rate controller

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 :arrow_up: 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. :joy:

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.

Voting and inflation

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.

Foundation funding

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.

Wargaming governance

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.

Accelerated Execution

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 :fuelpump::fire:). 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.

Distribution models

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?)

Bootstrapping liquidity

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.

1 Like

Thanks TnD! To avoid making a new thread I will copy and paste my post below. Mine is lengthy so it will require two replies.

But before I do, there was a discussion in the recent community call about value capture and competitive advantage. I wanted to point out that we had a forum discussion going about that topic which I will link to here. I changed the title to make it clearer. Anyone is welcome to join in if they’d like.

Now, here is the Mirror post from August 2022:

Below are some of my opinions and research regarding governance and value accrual. They are in response to the discussions we have had in recent community calls, the “Proposed DAO Design Update” blog post from the Trustless Team, and trustindistrust.eth’s DAO design blog post. Links to these and more can be found at the bottom of the page.

Table of contents

1. My responses to trustindistrust.eth’s blog post

2. Questions & thoughts about the Trustless future

3. Case studies from other projects

4. tl;dr

5. Actionable steps

6. Sources

Firstly, my responses to trustindistrust.eth’s great blog post DAO tokenomic ramblings DAO tokenomic ramblings
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.”


  • No automatic lockups. Voluntary lockups are better (though for how long, and will they be time weighted?).
  • A fee/revenue/profit sharing mechanism(s) for token holders (which must eventually become as decentralized as possible). We don’t want some version of this to happen:
  • Completely open governance proposals and free voting on interest rates are untenable.
  • Governance surrounding Hue and most monetary interventions should be minimized. Similarly, Hue liquidity should be prioritized. The basic product itself must be protected from manipulation and made autonomous ASAP. If we can imagine the protocol continuing to function without a gov/incentive token, then we have done something right (in my opinion).
  • Phased/capped Hue launch.
  • “…the controller should allow governance to vote on a range of (interest) rates”. I mentioned in the chat prior to last week’s call that Reflexer allows optional governance control over stability fees, with a suggestion for "bounded control” of stability fees between 1-2% annually. This is one option to consider if we will allow governance voting on interest rates. We could also just allow governance voting on how wide the bands are rather than the interest rates themselves, to reduce the impact and time concerns of direct voting on the interest rate.
  • Liquidity bootstrapping, but not traditional liquidity mining. The goal is to obtain protocol ownership of liquidity and thus “PCV” (protocol-controlled value).
  • The Foundation needs more explanation about its management and reasons for the funding source from inflation rewards. I believe Miles said that this would be a unique feature of Trustless and I am open to hearing arguments in favor of it. From a user perspective, the foundation accruing quite a bit of TCP inflation would raise a number of questions so I think this should be made as explicit as possible.
  • Inflation rewards for voters, instead of being attached specifically to interest rate votes, should be generalized for all vote types. If we want to cap inflation rewards, there are a number of ways to do it, each with pros and cons. In the next section of this post, I will share about a “voting credits” idea that represents one potential solution.
  • Accelerated decentralization schedule. I partially agree with this, especially to avoid the complications that inevitably arise from governance as well as the liability risks that were mentioned. However, the benefit of having the longer decentralization schedule specified in the whitepaper will allow for more of a decentralized approach to improving the Trustless brand while the zkSync ecosystem is in growth mode. There might be opportunities that arise after 6 months or 1 year that would benefit from having a decentralized vote to avoid later accusations of centralization (especially considering that the foundation will be receiving a decent chunk of the distribution), such as allocating a portion of the Foundation funds towards a special partnership. The Trustless whitepaper currently states that the Foundation will use the TCP tokens for whatever the community decides. However, I am willing to listen to further arguments about this topic.

I would do differently:

  • Regarding the suggestion for foundation funding to come only from protocol revenues: Will there be enough funding for this, and how can we make sure there isn’t too much revenue being diverted to the point that it reduces user incentives? I’m not opposed to the idea, but we’ll have to do the math on this and forecast what the yields might look like. Some consulting from outside sources might help.
  • The post suggests that ve-tokens rely on emergent behavior and that gauge votes on a protocol with a small treasury and liquidity aren’t enough to interest users. Also, that “Even if you do get a fair amount of liquidity in your protocol, your token value can still languish (TOKE).” Wouldn’t this suggest that there are other reasons why ve-token models work for some projects but not others? While it is true that TOKE’s price is down 97.7% from its ATH, LQTY’s price is down 99.4% from its ATH and its FDV/TVL ratio is nearly as low as Maker’s is, while also having the lowest PE ratio of major CDP projects. While we seem to be taking influence from projects like Liquity and Reflexer (and for good reasons), neither of their gov/utility tokens have fared better than projects with ve-tokens have - for now.
  • Olympus Pro’s bond marketplace is a novel mechanism, but it also requires a high upfront cost to begin buying back liquidity. Also, I haven’t seen info indicating whether or not it is available on zkSync. It is listed on a zkSync ecosystem page but isn’t live yet, and there is very little talk of it in the Olympus discord ( Additionally, assuming Olympus Pro will be available on zkSync 2.0 for Uniswap v3 shortly after the mainnet launch, wouldn’t we have to involve Charm in the partnership since Charm will be the automated Uni v3 position manager for Trustless? My understanding is that Olympus Pro only recently allowed the use of Uni v3 bonding via partnerships with Uni v3 managers like Gamma and Visor, but not Charm and not on zkSync. I know that some of the team at Rift Finance (another protocol owned liquidity project) have been experimenting with zkSync 2.0, but I’m not sure about their progress. If anyone is interested, I’d be happy to reach out to them and other liquidity bootstrapping protocols to see what options Trustless would have.

The next section includes questions and thoughts related to the future direction of Trustless, separated into categories


  • Does Trustless see itself as existing alongside the other CDP and stablecoin competition coming to xkSync? If so, what specifically will make Trustless different and valuable enough to distinguish itself from projects like Liquity or Reflexer?
  • As Steve mentioned in the Trustless chat, what can we realistically achieve in 3 months or less (when zkSync 2.0 launches)? Miles also rightfully pointed out that changing or creating fundamental features may add more smart contract risk. Will there be enough time to get some external audits and bug bounties done after the plans are solidified? If so, how will this be funded?

Revenue Sharing

  • Where will fees for revenue sharing come from and how much should be taken: Borrowing interest, Hue staking rewards, liquidations, surplus auctions, UI provider rewards? We need to crunch the numbers. If we are doing this, can we hire a second party to audit the formulas to make sure it is economically and logically feasible? Here is a relevant thread about how the proposed fee sharing in Uniswap v3 might not make as much sense as people think:
  • And another tweet about how an LP rewards formula was gamed by institutions and hurt governance as a result:
  • Fee distributions. If this is going to happen in intervals, how will it be implemented to avoid front-runners? Projects such as Spell used to distribute fees at random times to avoid front-runners, while using OTC desks for the buybacks. If buybacks are involved in Trustless fee-sharing, how will they be achieved?
  • In what asset(s) will revenue sharing be distributed? Users often appreciate revenue sharing in “stable” assets or other established assets like ETH.
  • Some protocols charge a small deposit and withdrawal fee for borrowers which is distributed as protocol revenue, sometimes in addition to interest rates (Abracadabra, for example). Thoughts about Trustless doing this?
  • A DAO or protocol-managed insurance fund is another possible use case for some of the fees. I mentioned Aave’s safety module in my previous post. For Trustless, this could be used in the case of an unexpected depegging, hack, etc. After decentralization, Trustless could outsource this to third party insurance protocols.
  • I think that Trustless should adopt a hybrid model of value accrual (see this link, also included at the bottom of the page Token value accrual models; the good, the bad and the ugly — - Cryptoassets, Data and Markets), and thus believe that including an access-based TCP staking or locking incentive would be a great supplement to fee sharing. We could do something like a capped rewards boost for Uniswap v3 pool LPs we want to incentivize liquidity in, vote escrow for inflation boosting like Curve does for emissions, a special Charm vault, or granting access to rewards from liquidations performed by the protocol itself as Lucas mentioned (currently, the plan is for liquidation rewards to go directly to keepers). However, it is also generally true that Uni v3 positions are more advantageous for firms who have the time and resources available to actively manage them compared to individual users. We need to make sure that whatever revenue sharing mechanisms (and governance) we select cannot be gamed by whales. See more ideas in the “Case studies” section of this post.


  • If we are doing voluntary lockups instead of just staking, will the voting and/or rewards power be time-weighted? How will that be calculated to align with TCP’s decentralization schedule?
  • Before launch, it is very important to plan what specific parameters that users can make proposals about. We can look to Reflexer’s decentralization schedule document for cues about this (Governance Minimization Guide - GEB Docs).
  • Using only Uniswap v3 pools means having a reliance on Uniswap, which if we are being honest, has centralization concerns like Maker has (see the ongoing fee sharing debate). Does anyone have thoughts about using Curve TWAPs and pools? I have shared some more info about this topic in the case study about Curve later in this post.
  • Has the TDAO token idea been discarded? It seems that in the past there was an idea for a rewards multiplier for staked & locked TCP to earn more TDAO tokens via an NFT, but not sure what happened with that.
  • If we want to have voting incentives with a capped number of inflation rewards, this post from some time ago suggested a “voting credits” idea. This could be tied in with the proposed changes section of the blog post from July 26. Voting credits could be stacked to increase a multiplier or claim on inflation, could be used as a rewards boost in other ways, or redeemed for something else entirely. The credits should be capped at a max value to avoid users spamming proposals, and in my opinion a reasonable max value with a time-weighted and time-based cutoff could be tied to each governance phase to avoid this. For example, 5 credits and a 1-year cutoff (to avoid last minute vote spamming) for phase 1. This function could be integrated into NFTs as well. Incentivized Voting - A theory on greater network engagement - Economics - Ethereum Research

Launch and early phases

  • We have been discussing methods for liquidity bootstrapping to avoid traditional liquidity mining, but which of these services will be available on zkSync 2.0 mainnet at or shortly after its launch? Most of the major services I know (Olympus Pro, Curve bribes, Ondo, Tokemak, Rift) haven’t released details about launches on zkSync. I have a suggestion for researching this further in the “Actionable steps” section of this post.
  • Audits and economic simulations. Will Trustless be getting any? For example, if we’re using Liquity as a model, it had 4 audits from 2 auditing firms prior to its launch, as well as two economic simulations/models (Technical Resources - Liquity Docs). While it brings me no joy to think of the following incidents happening, what if something goes wrong with Charm, or a popular frontend exploit that leads to many users’ funds being lost, or an issue with Uni v3 on zkSync, or zkSync 2.0 going down for a period of time leading to instability? The protocol is named “Trustless” and we should take steps to keep it as trustless as possible.
  • What about bug bounties as another option? Here is an example of a small project having success using Code4rena with a $50k bounty:
  • If Trustless will be using protocol owned liquidity, what will it do with the fees generated from the liquidity it owns or funds received through bonds? Should they go to the foundation, or be re-distributed via incentives to long-term supporters? For example, GMX splits these fees between a “Floor Price Fund” (which may also be used for bug bounties) and marketing.
  • Can we determine a forecasted max supply of TCP tokens, particularly if we are capping inflation rewards for voting proposals? Community members like to know information such as this, as well as charts showing emissions with trend lines. I don’t recall seeing this in the docs. For example, GMX states in their documents that the forecasted max supply is 13.25 million tokens, and ”Minting beyond the max supply of 13.25 million is controlled by a 28 day timelock. This option will only be used if more products are launched and liquidity mining is required, a governance vote will be conducted before any changes.”
  • Can we build a dashboard showing the supply of TCP tokens and a few other relevant stats? For example: GMX
  • Insurance. Some projects have insurance options listed directly in their UI, such as Reflexer. If Trustless partners with insurance providers, it should encourage frontend hosters to include this in their UIs or even on the main Trustless page itself.
  • What methods do we have in place to avoid sybil attackers (and even whales) taking advantage of TCP or governance, apart from the March 21st cutoff date? While this is a controversial point that I know many will disagree with, I tend to favor decentralized ID solutions as a means of avoiding sybil attackers. The zkSync ecosystem has a few of these in development.

Case studies from other projects, focused on concepts that I think are relevant for Trustless governance and token incentives


  • Project summary: A CDP (collateralized debt position) protocol using only ETH as collateral with a one-time borrowing fee instead of an interest rate, plus a decentralized stablecoin called LUSD. The LQTY token is used for incentives.
  • Explanation of mechanism(s): Rewards are earned by depositing LUSD into the stability pool (like a reserve pool), hosting UI frontends, and providing liquidity into the LUSD/ETH Uniswap pool. These rewards are paid out in both ETH and LQTY. The LQTY token is not used as a backstop nor for governance (since Liquity is “governance free”). 35.3% of the genesis distribution overall went to the community, with 64.7% going to the team, advisors, investors, the Liquity AG company, and service providers. For the first 6 weeks after launch, they distributed 1.3% of the LQTY supply via Uniswap v2 liquidity mining. After that, the LQTY price generally trended down significantly even while the rest of the market reached ATHs, long before the investor and team token unlocks happened on April 5, 2022. The LUSD price has been above peg for the past 3 months or so, and this is supposedly because the majority of LUSD has been held in the stability pool to earn LQTY rewards. These rewards will decrease over time. The Liquity team is hoping that new products they are creating (Chicken Bonds on LUSD) and partnerships (FRAX-LUSD Pool) will help to coax that LUSD liquidity out and restore the peg. All of this new product launch and partnerships is being done by the Liquity team (or possibly the Liquity AG company) without governance decisions made by the community.
  • Liquity claims to be “governance free”, but what that seems to actually mean is that it has a governance free monetary policy. Other decisions are made entirely by the team. There is a “Liquity AG endowment”, which operates as a company (I believe registered in Switzerland). The Liquity AG endowment which received 6.1% of the LQTY supply “for use by the company”, and 2% to a “Community Reserve”. Both of these seem to be operated in a centralized manner. The Liquity AG endowment develops new products and works on marketing, growth, and partnerships. E.g., the community grant program, partnerships and integrations, newer products (e.g. Chicken Bonds), receiving a veNFT from Velodrome, and more. They say that there is no multisig for the protocol, but there is a multisig for the “Liquity AG endowment”, of which 6.1% of LQTY tokens were allocated at launch. A user tracked transfers of larger than this amount of the LQTY supply to the official Liquity AG wallet address on the blockchain, and a team member said that it was for “Liquity company transactions between its own multisigs, for internal accounting”. It isn’t clear why this amount was larger than the allocation for the Liquity AG endowment, and why there is more than one multisig. Note the date of this transaction: April 5th, one year after launch and around the time when LQTY token unlocks were possible.
  • I’m not implying nefarious activity here, and all of this was trackable on-chain. However, it does make me wonder: Liquity may be governance free, but is it sufficiently decentralized? Could more decentralization bring more value to the LQTY token, or would that just be “decentralization theater”? I am trying my best not to invoke the r-word here, but I can’t help wondering what they might think.
  • Relevance for Trustless: A classic question in researching tokenomics is: “Can the protocol function without a token?” In the case of Liquity, I’d say the answer is yes, and that is worthy of respect. However, the LQTY token doesn’t seem to be accruing much value, had decreased significantly in value long before the token unlocks for insiders, and decreased at a greater rate than competitor tokens, so we can’t blame token unlocks or market performance for all of it. Also, the team is making centralized decisions on topics via the Liquity AG company, decisions that would be up to governance votes in other projects. For example, a user in the discord recently asked if fees from the new Chicken Bonds product would go to LQTY stakers. A team member’s response was “TBD”. Since Liquity is “governance free”, I’m wondering how they plan to do this.


  • Project summary: A CDP protocol that allows users to deposit a range of yield-bearing tokens as collateral (e.g. yvUSDT) and borrow their MIM stablecoin. The SPELL token is used for governance and/or other incentives and had a relatively community-oriented token distribution compared to most of the competition (
  • Explanation of mechanism(s): Before getting started I will recognize that there is a debate over the quality of the collateralization assets and a longer explanation needed to understand the SPELL supply, but that is for a separate topic. I am going to zoom in on incentives surrounding the SPELL token. The SPELL token has an incentive structure which allows holders to decide which they value more: More ownership of the protocol (SPELL) or stablecoin income (via their native stablecoin, MIM). Users can stake their SPELL for mSPELL, in which fees from lending markets are paid in the MIM stablecoin. They can claim their MIM rewards anytime they want using a claim button. Or, users can stake SPELL to receive sSPELL, where MIM is used to buy Spell on open markets on a constant basis which is used for fee-sharing and governance. sSPELL is continuously compounding until it is unstaked, when all original and earned SPELL is returned. For fee-sharing, the interest rate fees are collected to buy SPELL off the market on a constant basis, depending on the number of users in the sSPELL pool. A 25% cut is sent to the treasury before the remaining 75% is distributed to users. Both staking options have a 24 hour lockup period, and users can choose to mix their staked SPELL deposits however they wish. This is supposed to decrease selling pressure from sSPELL holders. Fees for sSPELL come from interest, a borrow fee, and 10% of the liquidation fee for certain markets. sSPELL is also the governance token. AIP #8 - An update on Abracadabra fee distribution, introducing mSpell staking pools - Voted Proposals - Abracadabra Forum
  • Relevance for Trustless: Trustless could offer two staking pool options for TCP, hTCP and sTCP. The hTCP pool earns Hue, and the sTCP pool earns more TCP. Voting for TCP could be based on the amount of sTCP held by users. I like this concept for its simplicity and the ability to earn “stable” income, though I think it only works if there is enough sustainable liquidity for Hue on open markets.


  • Project summary: GMX is a perp DEX with a utility and governance token, GMX. Rewards - GMX
  • Explanation of mechanism(s): While the project is quite different from Trustless, there are some token mechanisms that are worth a look. For the sake of simplicity, we are going to ignore the GLP token and focus only on the GMX token. Staking GMX receives a staked GMX token and provides 3 types of rewards: A portion of fees generated from swaps & trading (in ETH or AVAX), escrowed GMX, and multiplier points. Fees are distributed after deducting referral rewards and keeper costs. I want to focus on the escrowed GMX and multiplier points, which are rewards for longer-term users of the protocol. GMX offers the ability to compound or claim rewards. Compounding will stake earned multiplier points and escrowed GMX to increase the amount of rewards received. Multiplier points, when staked, earn fee rewards at a fixed 100% APR rate meaning that they earn the same amount of ETH/AVAX rewards as GMX tokens do. When GMX or escrowed GMX tokens are unstaked, the total amount of multiplier points (staked and unstaked) are burnt. There is also a 1 year vesting mechanism for converting escrowed GMX into GMX tokens.
  • Relevance for Trustless: GMX demonstrates an alternative to ve-token models that includes rewards boosts (via multiplier points) but avoids token locks (for those who want to earn protocol fees, not for those who want to convert escrowed ve-tokens into actual tokens), doesn’t contribute to inflation, and includes a boost burning mechanism to incentivize longer-term participants. Trustless could consider implementing a similar model. For example, let’s imagine that the genesis distribution is done in veTCP tokens instead of regular TCP tokens, to give everyone the ability to vote and receive inflation from proposals from the beginning. After that, regular TCP tokens are distributed as per the original plan and can be staked for a combination of revenue sharing rewards, veTCP rewards, and multiplier points with the same mechanisms that GMX has. Caveats are that the tokenomics would need to be modified to align with TCP’s decentralization schedule, there is complexity in terms of managing the supply of the various forms of the TCP token, and it might be a bit confusing for some new users. Also, GMX hasn’t been around for quite as long as some of the other projects mentioned.


  • Project Summary: A stableswap DEX with a native DAO token, CRV.
  • Explanation of mechanism(s): Curve is one of the pioneers of having boosted CRV rewards for users who lock their CRV tokens into the Curve DAO and stake their LP tokens in the DAO gauge, with boost benefits on provided liquidity up to 2.5x. An explanation, along with links for boost calculations, are included here: Boosting your CRV Rewards - Curve Finance
  • Relevance for Trustless: In an earlier post on discord, I mentioned an idea for locked TCP tokens to provide a (capped) reward bonus for Uni v3 liquidity providers using Charm, since Miles mentioned that inflation rewards for Uni v2 LPers will only go to those LPers who are using Charm. This would need to be modified for TCP’s decentralization schedule, and the amount of incentivization for which pools must be decided. 4 year lockups doesn’t make sense for Trustless for many reasons. Instead, lockup schedules could be time-limited to phases of the Trustless decentralization schedule, to avoid users becoming confused when their unlocked tokens have less governing abilities.
  • Side note - Curve is coming to zkSync and stable swaps will be happening on it. Abracadabra was famous for utilizing bribes to create liquidity for MIM in the MIM Curve pool. Who knows when or if Curve will have bribes on zkSync, but I imagine this represents an opportunity for Hue liquidity as well as diversification. Curve also has their own TWAP price oracles, inspired by Uniswap. Would Trustless ever consider incentivizing Curve pools, or this is this something the DAO could consider? Metapool Factory: Oracles — Curve 1.0.0 documentation


  • Project summary: A CDP protocol for a stablecoin, RAI, that is not pegged to a fiat currency. There is also a governance/utility token called FLX.
  • Explanation of mechanism(s): The FLX token is used as a backstop mechanism and also for “ungovernance”, both of which have inspired aspects of Trustless (the TCP “collateral of last resort” and decentralization schedule). Fees collected from borrowers (called stability fees) are distributed between the stability fee treasury, FLX stakers, and for buyback & burn. There is a “thawing period” for users who want to unstake FLX tokens.
  • Relevance for Trustless: I don’t have much more to say about Reflexer that hasn’t already been discussed, but felt it necessary to include since it has had some influence over the conceptualization of Trustless. (Tangentially, I actually like the concept of “stablecoins” not pegged to fiat currencies for many reasons, but often receive pushback on this!). I think we are all in agreement that TCP’s mostly fixed decentralization schedule and use of Charm for Uni v3 LPs is an improvement on what Reflexer has in some ways. There is some discussion to be had about the length of the decentralization schedule, as it seems that trustindistrust.eth prefers a much shorter decentralization schedule and no community input on its length, compared to what the Trustless white paper suggests. I understand both points of view. That said, what I think Reflexer has done well which could further inspire Trustless are the many RAI integrations and partners, the detailed governance minimization guide, insurance integrations into the UI, and risk assessments, about all of which further info can be found in the docs. Examples of RAI integrations: RAI Integrations - GEB Docs


  • Project summary: A lending marketplace for unsecured institutional capital.
  • Explanation of mechanism(s): This demonstrates a way to combine vote escrow with automated interest rate changes. The CPOOL token delegates voting power to a Clearpool oracle, which ensures the interest rates fall within a median level of current market conditions for an epoch. Rewards are distributed to CPOOL holders who delegated voting power to the successful oracles, minus the Oracle’s fee. Note that this is an early stage protocol and we don’t have evidence for the success of this model in practice.
  • Relevance for Trustless: I know that Trustless doesn’t use oracles, but a similar concept could be delegating TCP voting power to keepers instead of governance voting directly on banded interest rates. E.g., votes that are delegated to keepers who update interest rates within a range of the median (to avoid power accruing to one in particular) will receive a greater proportion of inflation rewards. This could help to incentivize a fine-tuning of keeper functions and allow the interest rate algorithm to improve itself while decoupling direct governance control from interest rates.


Trustless is deciding how to restructure token incentives for sustainable growth, as well as establish frameworks for decision-making in the DAO and the Foundation. After being launched, Trustless governance will be decentralized in hardcoded phases and any decisions must take this schedule into account. However, significant changes to the underlying protocol could push the launch timeline too far and introduce other risks. The recent discussions, trustindistrust.eth’s post, and Trustless blog posts, and this post have shared various ideas for the protocol. In my view, Trustless should choose whatever is realistically achievable within the time frame and select resources to incentivize longer-term liquidity and longer-term borrowers, in a way that will encourage healthy growth and continuous functioning after governance becomes completely decentralized.

1 Like

Part 2

Actionable steps (in no particular order and by no means comprehensive):

  1. Decide what can be done given the time frame and resources we have.
  2. Determine the voting mechanisms and if there will be voting schedules.
  3. Write some form of a governance constitution or a Decentralization Schedule guide with specific parameters that the DAO can control in various stages. Here an an example from Reflexer: Governance Minimization Guide - GEB Docs
  4. Perform economic modeling, particularly if any fundamental changes to the tokenomics, revenue sharing, and/or protocol are made. Make plans for receiving third-party audits and consider sybil resistance solutions. Publish charts and explanations for the community.
  5. Work on a stats or analytics page for Trustless. Since Trustless will not host its own frontend, this could be a project delegated to the community to build. For example, Liquidity’s analytics page from their website links to this Dune dashboard: Liquity
  6. Outreach for partnerships or integrations, especially if Trustless is considering liquidity bootstrapping. The zkSync team suggested reaching out in the #dev-support or #developers-general channels for projects interested in launching on zkSync (as well as looking into Argent). That could be another place to start.
  7. General marketing to alert users who may wish to be keepers, frontend hosters, etc.
  8. Define the Foundation, its responsibilities, proposed members, how it will be managed (e.g. a multisig), how it will be funded, how it specifically plans to use funds, what happens to the funds after phase 3 and onwards, etc. Will it hinge upon a multi-sig for day to day operations? Will there be compensation for contributors? For example, Gearbox DAO has done a great job of outlining this explicitly: Snapshot
  9. Brainstorm and begin taking steps to make the DAO and the protocol as transparent and easy to understand as possible. Analytics pages, notifications, simple explanations and language, UI improvements, inviting more feedback from various users, reducing vagueness, etc. Start a governance forum and a new discord channel for longer-form DAO discussions.
  10. Delegate further responsibilities to the team and community members. For example, I bet myself, trustindistrust.eth, and other users such as Theo (is he still around? He had some good ideas in the Discord a while back) would be willing to lend a hand in some of this.

Other sources:


I can’t seem to edit my post for some reason, but if @miles_trustless or another mod wants to edit the title of the thread to reflect that both my and jaypow’s posts are present, that’d be cool.

not sure why you can’t edit, but I did as you requested.