Hack VC: 10 Considerations to Focus on During Project TGE

Original Title: 10 Things to Consider When Preparing for your Token Generation Event (TGE)

Original Author: Ed Roman, Managing Partner at Hack VC

Original Compilation: 1912212.eth, Foresight News

Engaging with Liquidity Providers

When a token launches for the first time, there is often not a large supply of tokens available in the market. This is because tokens allocated to investors and employees are typically vested/locked for years, resulting in a lack of liquidity depth on exchanges, which can lead to excessive price volatility for the token. Small buy and sell orders on exchanges can significantly impact the token price. Is price volatility a problem? Not necessarily, but if your token has some form of utility, it becomes very important. Your network may not function as expected if users cannot acquire tokens in reasonable quantities or prices to use the network, which could stifle network growth. To address this issue, you can hire one or more liquidity providers to help create liquidity for your token. Liquidity providers can borrow tokens from your treasury and create a market by pairing your tokens with their stablecoins on exchanges; they typically have algorithmic bots that act as intermediaries between buyers and sellers on exchanges, thus creating a liquidity market. A typical arrangement with liquidity providers involves them borrowing your tokens for 18 months, after which they can choose to purchase those tokens at the then-current price. Therefore, these activities are clearly costly. Examples of liquidity providers include Amber Group, Dexterity Capital, and Wintermute. Recently, the concept of on-chain liquidity providers has emerged, where Web3 protocols effectively act as liquidity providers. Stablecoins are provided by dynamic LPs, who can even be members of your own DAO (creating a strong alignment of interests and a great way to reward participating DAO members).

DeFi Protocols (or L1/L2 Protocols) Need to Have a TVL Plan from the Start

We see many technical founders launching DeFi protocols and hoping that the motto "if we build it, they will come" applies. However, this is often not the case— you need a strong go-to-market strategy to attract capital. The metric for measuring the attractiveness of a DeFi protocol is TVL (Total Value Locked). If you start with 0 TVL, it may present a chicken-and-egg dilemma for LPs, as no one wants to take the risk of being the first LP to enter the pool. Today's LPs tend to be more conservative (considering some recent blowups in Web3). They typically worry about two things:

• Is the displayed yield accurate compared to the actual yield?
• Am I at risk of losing my principal (due to hacks or other reasons)?

One way to address this issue is to have strong social proof from other investors who trust the protocol from the start. You can effectively "pre-negotiate" TVL with private groups before launch. This could be VCs, family offices, or high-net-worth individuals. A reasonable target to achieve before others start to feel comfortable joining is to reach a 7-8 figure TVL. Ultimately, the best long-term solution to make LPs feel comfortable is to have your protocol running as expected for a sufficient amount of time without being hacked. This could be a useful way to encourage early adoption and start building a track record. Users and TVL often follow the 80/20 rule (i.e., the top 20% of users can account for over 80% of TVL), so securing large deposits should be a focus when growing TVL. Besides the initial phase, you should also plan the release schedule for liquidity mining. Initially, subsidizing through token incentives is acceptable, but in the long run, transitioning to sustainable fee-driven yields is recommended. An interesting tactic to increase early TVL is to create a "spillover" bucket for investors. Once the dilution cap for this round is reached, you can only consider them if they also commit TVL.

Follow Best Security Practices

The security of the protocol is crucial. If your protocol gets hacked, it will be a permanent stain on your record and may deter users from participating. Several key steps to follow:

• Consider selecting technologies in advance that help reduce the risk of smart contract hacks. For example: using the Move language for programming, which is formally verified and type-safe, is generally more secure than Solidity (e.g., through Move mentLabs.xyz). Another approach is to introduce a delay at the completion of transactions to provide a window for intercepting smart contract hacks (e.g., through UseFirewall.com). Use zero-knowledge formal verification of code with technologies like AlignedLayer.com (e.g., in the case of bridges).
• Conduct multiple smart contract audits before the protocol goes live to communicate to users and the team that your code is reliable. Note that this does not guarantee you won't be exploited, but it's the right step. Examples include Trail of Bits and Quantstamp.
• Establish a code change process so that if you make further changes to the smart contract over time, you can recheck each code increment through lightweight audits. This is a step that teams often overlook and is crucial for capturing vulnerabilities arising from hasty code submissions.
• Consider using formal verification or fuzz testing. Formal verification is a thorough mathematical validation of the code system. It provides comprehensive coverage analysis that can enhance your confidence against attacks. Fuzz testing is a process of slightly altering system inputs to discover extreme cases that could be exploited. Veridise is an example of a vendor providing formal verification and fuzz testing.
• Consider investing in a bug bounty program. This can incentivize white-hat hackers to discover vulnerabilities by rewarding them. Currently, the market leader in Web3 bug bounties is ImmuneFi.

Measure Product-Market Fit Before Mainnet Launch

Web3 projects often suffer from a bad reputation for launching tokens before addressing the real pain points of customers. If you take this approach, the token price may plummet sharply, as your KPIs are at best questionable. But how do you measure product-market fit before launching the product? Some teams try to confirm this through testnets, but the challenge with testnets is that customer behavior may differ from the mainnet. This is especially true in the financial sector (e.g., DeFi protocols on testnets), as users are using "test tokens" and may not take their behavior seriously, possibly just engaging in airdrop mining and not being serious users. To address this issue, I recommend launching a "private mainnet" (distinct from a testnet) where your service is used with real users who have real capital to confirm product-market fit. These users should be invite-only (e.g., your investors, friends, and team) so that you do not mess up your marketing efforts due to a small group of private users.

Ensure the Launch Timeline is Correct

When is the right time to launch a token? Most of the time, I would advise startups to delay launching their tokens until they have created significant real value with the protocol. This is similar to how Web2 startups often do not rush to IPO until they have established a solid business. There are dangers in launching a token during specific market windows. If retail investors buy your token during a deep bear market, the likelihood of price appreciation in a future bull market is higher, which can create strong loyalty and virality for your project. If you issue tokens only during a bull market, and a sharp decline occurs during a future bear market, the enthusiasm of those users will naturally be much lower. One way to mitigate this risk is to set more attractive entry prices for investors through an IEO. To understand this concept, consider that most Web3 projects plan to airdrop a large portion of their token supply to users. When you do this, users typically do not provide any information in exchange for tokens; the airdrop is free for them. This provides a broad distribution of tokens, but does not necessarily lead to users caring about your protocol, as they have not invested/risked anything. In other words, they are not invested in it. You may want to avoid selling tokens to retail investors (for legal/regulatory reasons). A potential solution is an IEO. The way it works is that a portion of the token supply is allocated to an exchange, which then sells it to users at a low price (creating an easy win opportunity for retail investors to see appreciation). This is also a good way to build trust with exchanges. Sui is a great example. Sui is an L1 based on the Move programming language, created by former Meta employees. They conducted an IEO and were very successful.

Be Mindful of Cliff Unlocks When Designing Token Vesting

Most Web3 projects have tokens for employees and investors released over several years, often with cliffs set at the beginning. In practice, if you have a large number of employees or investors selling tokens on similar dates, a sudden large sell-off in the market could lead to negative price movements. To avoid this, we have recently begun recommending continuous vesting (tokens accumulating steadily on a smooth curve). This way, tokens flow into the market slowly, avoiding sudden drops.

Allocate a Budget for Exchange Listings

Many exchanges charge fees to list your token, so if you want to list your token on some of the more popular exchanges, you need to plan ahead and budget for it. It is understood that some of the most well-known exchanges charge up to $1 million for token listings, so the listing process can quickly become expensive. One exception is if you are a tier-one project backed by a well-known fund; in this case, exchanges may sometimes list you for free, as it attracts users to their exchange. This is one of the advantages of collaborating with large venture capital firms during funding rounds (as it can buy you social proof through exchanges).

Fundraising Before Token Launch

We have encountered many projects that attempt to raise funds after launching their tokens. This can be more challenging than startups expect. Most private investors arbitrage between public and private markets. The market for private fundraising is much larger than for public fundraising, which limits the number of potential pursuers. For example, you will be excluded from most early funds. Raising funds after the token release is also difficult, as the negotiations themselves can be challenging. The typical structure involves a discount on the public token price. However, during the fundraising process, the token price may fluctuate significantly. If the token price is a constantly changing target, how do you establish a price benchmark and agree on that price with private investors? If you raise funds before launching the token, these issues disappear. At that time, the token price is unknown, and you can include more private funds that will invest in that asset class.

Provide High-Quality Consulting Services for TGE

Over the years, we have encountered many teams that are severely underserved by legal advisory services. Founders in Web3 inherently take on greater risks than in Web2, so obtaining strong crypto-native legal advice is crucial. I encourage founders to ensure that their advisors have experience in cryptocurrency-specific practice areas when preparing for TGE. By the way, the regulatory environment for Web3 is still evolving. Generally, decisions are subjective rather than objective. Keep in mind that most lawyers are not businesspeople; they often optimize advice based on hypothetical legal arguments rather than actual decisions in the real world. In other words, do not follow your lawyer blindly on regulatory matters— you need to exercise your own judgment and assess your risk tolerance, especially considering that the law itself is constantly changing.

Choose the Right Timing to Monetize through "Fee Switch"

Many protocols (especially DeFi) delay "fee revenue" to a future date through fee switches. The purpose of this is to subsidize maximum short-term growth and postpone monetization. This is similar to how Web2, Facebook, and other social networks delayed advertising/monetization until they had a sufficient number of social graphs. If you are optimizing to attract new users, then delaying monetization makes complete sense. The danger of delaying monetization is that it may obscure the product-market fit. Generally, if users are willing to pay for your service, that is the strongest indicator that you have "real" users and that they are sticky. However, if your fees significantly impact the economics of the user base, then delaying monetization may hide core issues within the protocol. However, if your acceptance rate is moderate, the risk may be lower. Fee switches effectively transition from pure governance to accumulating value by distributing platform fees to token holders. Typically, it is easier to do this after completion (e.g., GMX), but of course, this is not always the case (UNI and many others). Here are some characteristics of projects that may need to implement fee switches:

• Reaching a critical mass of users;
• Strong token liquidity;
• A broad base of holders;
• Takers (traders) paying reasonable fees to liquidity providers.
  Perhaps consider providing LP tokens through airdrops or similar allocations while implementing fee switches, so even if they no longer receive 100% of the fees, they still feel rewarded through tokens.
  Consider the minimum threshold interest rate target APY yield for token holders relative to other opportunities/markets, and build fee parameters that make sense and are fair in this context.
  For example, for staking rewards, 5% is considered standard, while 10% is considered high (LIDO can set 10%).
  For trading venues, 2.5-5.0 bps is standard, while 10-25+ bps is high; better venues can charge higher fees.
  For lending, a reasonable net interest margin (NIM) between borrowers and lenders is typically 1-2%, and is expected to compress over time.