Below are some of my opinions and research regarding Trustless.fi 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. Since we do not have a forum yet, I felt this was the best place to write a longer reply.

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

Agree:

• 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: https://twitter.com/BarryFried1/status/1552399926466088961?s=20&t=PTVcGCGpn0istGh-fVYWvg
• 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 (https://ecosystem.zksync.io/). 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

Existential

• 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: https://twitter.com/barryfried1/status/1553051635609485313?s=21&t=l-ab0rPHSt5D1R98LHANsA
• And another tweet about how an LP rewards formula was gamed by institutions and hurt governance as a result: https://twitter.com/gametheorizing/status/1552704306679369732?s=20&t=dEJrIGW_O7O-VDbNBUZxjQ
• 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 https://eliasimos.xyz/home-2/2019/2/13/token-value-accrual-models-the-good-the-bad-and-the-ugly), 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.

Governance

• 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 (https://docs.reflexer.finance/ungovernance/governance-minimization-guide).
• 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 ethresear.ch 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. https://ethresear.ch/t/incentivized-voting-a-theory-on-greater-network-engagement/6457

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 (https://docs.liquity.org/documentation/resources#economic-modelling-and-simulation). 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: https://twitter.com/_benjaminhughes/status/1554527455087558658?s=21&t=l-ab0rPHSt5D1R98LHANsA
• 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: https://app.gmx.io/#/dashboard
• 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. https://ecosystem.zksync.io/

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

Liquity

• 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. https://docs.liquity.org/
• 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. https://etherscan.io/tx/0x2357714c655b0248abbfc95ec5e27c25fdc360b9c5cc29b7d5a23bf4acdd4cbe
• 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.

Abracadabra

• 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 (https://docs.abracadabra.money/tokens/tokenomics).
• 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. https://forum.abracadabra.money/t/aip-8-an-update-on-abracadabra-fee-distribution-introducing-mspell-staking-pools/3218
• 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.

GMX

• Project summary: GMX is a perp DEX with a utility and governance token, GMX. https://gmxio.gitbook.io/gmx/rewards
• 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.

Curve

• Project Summary: A stableswap DEX with a native DAO token, CRV. https://curve.readthedocs.io/
• 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: https://resources.curve.fi/reward-gauges/boosting-your-crv-rewards
• 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? https://curve.readthedocs.io/factory-oracles.html

Reflexer

• 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. https://docs.reflexer.finance/
• 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: https://docs.reflexer.finance/rai/rai-integrations-and-partners

Clearpool

• Project summary: A lending marketplace for unsecured institutional capital. https://clearpool-finance.gitbook.io/
• 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.

tl;dr

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.

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: https://docs.reflexer.finance/ungovernance/governance-minimization-guide
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: https://dune.com/dani/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: https://snapshot.org/#/gearbox.eth/proposal/0x79c4a499f9cc66ee55d6f2944bdc6af0ebe09e7753f43c969c38dfcc871a03ef
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:

• Discussions on Trustless community calls, 7/14 and 7/12: https://www.youtube.com/channel/UCR-m4t_KveQYPRAxeGHgWqA
• Trustless Proposed DAO design update: https://www.trustless.fi/blog/proposed-dao-design-update
• Trustless Currency Protocol whitepaper: https://github.com/TrustlessFi/Whitepapers/blob/main/TCP_Whitepaper.pdf
• Trustless DAO Tokenomic Ramblings post from trustindistrust.eth: https://mirror.xyz/trustindistrust.eth/85jFA1NGhlMCuKUT9mLYMdbRvCITS3ImFPidp32qfmU
• This website, which I cited in my earlier post about token value accrual, breaks down some common token value accrual models in an easy-to-read table. https://eliasimos.xyz/home-2/2019/2/13/token-value-accrual-models-the-good-the-bad-and-the-ugly
• Liquity launch details from 2021: https://www.liquity.org/blog/liquity-launch-details
• Liquity founder responding to criticism from Maker community: https://medium.com/liquity/addressing-concerns-about-liquity-2af3e1d0a946
• Twitter thread about GMX multiplier points: https://twitter.com/dLuxGMI/status/1553728788046954498
• Twitter thread about cautionary tales regarding governance and tokenomics, but ignore his suggestions for that “British style” BS (credit to Lucas for sharing): https://twitter.com/gametheorizing/status/1552704270855725057?s=20&t=dEJrIGW_O7O-VDbNBUZxjQ

Written by: jaypowcrypto.ethDiscord: jaypow#0101
Twitter: @jaypowcrypto