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

By Ed Roman, Managing Partner at Hack VC

This article covers a series of considerations for successful web3 protocol token launches. These ideas have been curated from hands-on experience at Hack VC assisting our portfolio companies with token launches over recent years. 

The information herein is for general information purposes and should not be relied upon for accounting, legal, tax, business, investment or other relevant advice.

1. Build relationships with liquidity providers

When a token project first launches, a large float (supply) of tokens typically is not available on the market. This is because your investors and employees are normally vesting / locked for several years. This results in a lack of liquidity depth on exchanges, causing the price of the token to be unreliable. Small buy/sell orders on exchanges can drastically impact your token price.

Is having a volatile token price a problem? Not necessarily—but it becomes very important if your token has some form of utility. Your network might not function as intended since users won’t be able to acquire tokens to utilize your network at reasonable volumes or prices, which could throttle your network growth.

To solve for this, you can engage one or more liquidity providers to help create liquidity for your token.  Liquidity providers are effectively borrowing tokens from your treasury and creating a market by providing their own stablecoins to be paired with your token on exchanges, and they generally have algorithmic bots that serve as a “middleman” between buyers/sellers on exchanges, creating a liquid market.

A typical deal with a liquidity provider involves them borrowing your tokens for 18 months, after which they have an option to purchase those tokens at the then-current price. So these engagements clearly have their costs.

Examples of liquidity providers include Amber Group, Dexterity Capital and Wintermute. Recently, the concept of an on-chain liquidity provider has hit the scene, where a web3 protocol effectively serves as the liquidity provider. In this paradigm, the stablecoins are provided by dynamic LPs—who could even be members of your own DAO (which creates a strong alignment of interests and a nice way to reward your DAO members for participating). Elixir.xyz is pioneering this concept.

Coinwatch is also an option you may want to consider—they are a “buyer’s agent” for liquidity providers that helps protocols negotiate these deals. Coinwatch helps startups to negotiate cheaper, more effective and more aligned deals. They also track what your liquidity provider is doing so you can ensure you get what you paid for.

2. If you’re a DeFi protocol (or L1/L2 protocol), have a TVL plan for day-0 and beyond

We’ve seen many technical founders launch DeFi protocols with the hope that the motto “if we build it, they will come” will apply. However, that’s not typically the case—You need a strong go-to-market strategy to attract capital. The yardstick that measures a DeFi protocol’s traction is total value locked (TVL). If on day-0 you begin with zero TVL, then it can create a chicken-and-egg dilemma for LPs, where nobody wants to take the risk and be the first LP to enter into a pool.

LPs these days tend to be conservative (in light of some of the recent catastrophes that have happened in web3). They’ll typically worry about two things:

• Are the displayed yields accurate relative to realized yields?  
• Do I risk loss of principal (from a hack or otherwise)? 

You only get one launch, so it’s rational to invest in that launch to ensure it goes well. By having TVL on day-0, it can help start a flywheel for social proof and growth.

One way to solve for this is via strong social proof from other investors trusting the protocol on day-0. You can effectively “pre-negotiate” TVL prior to your launch with private parties. This can be venture firms, family offices or high net worth individuals. A reasonable goal for social proof would be 7-8 figures of TVL before others start to feel comfortable to jump-in.

Ultimately, the best long-term solution to getting LPs comfortable is by having your protocol operate long enough as intended without hacks. But this can be a helpful way to encourage early adoption to start to build that track record.

There tends to be an 80/20 rule with users and TVL (i.e., the top 20% of users can represent 80%+ of the TVL), so getting the big deposits should be the focus as you grow TVL.

Beyond the initial phase, you should also plan out an emission schedule for liquidity mining.  Initially it’s fine to subsidize via token incentives, but longer term you’ll want to transition from that into sustainable fee-driven yield.

An interesting technique to juice early TVL can be to create an “overflow” bucket for investors.  Once you reach your dilution limit for your round, you can consider investors only if they’ll also pledge TVL.

3. Follow best security practices

Security for protocols is of paramount importance. If your protocol gets hacked, then it’s a permanent stain on your record and may discourage users from participating. A few key steps to follow:

• Consider choosing technologies in advance that help reduce the risk of smart contract hacks. For example:
  • Programming using the Move language, which is formally verified and type-safe and is generally going to be safer than Solidity (e.g., via MovementLabs.xyz).
  • Another approach is to introduce delays in finalization of transactions to give a window to catch smart contract hacks (e.g., via UseFirewall.com).
  • One additional approach can be to use zero-knowledge verification of code (e.g., in the case of bridges) via technologies such as AlignedLayer.com.
• Perform multiple smart contract audits prior to your protocol going live to convey confidence to your users and also your team that your code is solid. Note that this is not a guarantee that you can’t be exploited, but it’s a great step. Examples include Trail of Bits and Quantstamp.
• Institute a code change process where if you commit additional changes to your smart contracts over time, you get each delta of code re-inspected via a lightweight audit.  This is a step often overlooked by teams and can be critical for catching vulnerabilities made in a hasty code commit.
• Consider using formal verification or fuzz-testing. Formal verification is an exhaustive mathematical verification of your code system. It provides comprehensive coverage analysis, which can increase your confidence against exploits. Fuzz-testing is a process of slightly varying the input to a system to discover corner cases that could also be exploits. An example of a vendor providing formal verification and fuzz-testing is Veridise.
• Consider investing in a bug bounty program. This can incentivize white-hat hackers to discover exploits due to the rewards given to them. The current market-leader in web3 bug bounties is ImmuneFi.

4. Gauge product market fit prior to mainnet

Web3 projects are notorious for listing tokens prior to confirming that their projects solve real pain-points for customers. If you follow this approach, you’re setting yourself up for a precipitous drop of your token price, because your KPIs will be suspicious at best.

But how can one gauge product market fit prior to launch? Some teams attempt to confirm this via test-net, but the challenge with a testnet is that customer behavior may differ compared to main-net. This is especially true when financials are involved (e.g., a DeFi protocol on test-net) since users are using “play money” and may not take their actions as seriously, and may simply be airdrop farming and may not be serious users.

To iron this out, I recommend launching a “private mainnet” (distinct from a testnet) where your service is live with real users with real capital to confirm product market fit. The users are invite-only (e.g., your investors, friends and team) so that you don’t blow your marketing launch with a small cohort of private users.

5. Make sure you get your launch timeframe correct

When is the right time to launch a token? Most of the time, I would advise startups to delay launching their token until they’ve created significant real value with their protocol. It’s similar to how web2 startups that are pre-IPO tend to not rush their IPO until they’ve built a solid business.

There is a danger in launching a token during specific market windows. If retail users acquire your token in the depths of a bear market, and if there’s a future bull market, then there’s a higher probability of price appreciation for those users, which can create strong loyalty and evangelism for your project. If you compare this approach to launching a token during a bull market, with a precipitous drop that occurs in a future bear market, those users will naturally be much less enthusiastic.

One way to mitigate this risk is to create an entry price for investors that’s more attractive via an initial exchange offering. To understand this concept, consider that most web3 projects plan to airdrop users a large percentage of their token supply. When you do this, your users aren’t typically offering anything material in exchange for the tokens—the airdrop is free to them.  This gives the widest possible distribution, but doesn’t necessarily cause users to “care” about your protocol, since they didn’t invest/risk anything. That is to say, they have no skin in the game.  

How can you create skin in the game? You’ll probably want to avoid selling tokens to retail users (for legal/regulatory reasons). One potential solution is an initial exchange offering (IEO). The way this works is to allocate a portion of your token-supply to exchanges, who then sell it to users at a low price (creating an easy win for retail investors to see appreciation). This is also a good method to build trust with exchanges.

The Sui blockchain is a good example of this working. Sui is a layer-1 based on the Move programming language, created by former Meta employees. They performed an IEO and it was very successful.

6. Beware cliffs when architecting your token vesting schedule

Most web3 projects have their employees and investors vesting their tokens over multiple years. In a carry-over from web2, it’s common to see a “cliff” for this vesting. This means there’s a minimum vesting period before any tokens are vested (e.g., with a one-year cliff, there’s no vesting for the first 12 months, and then at the end of the 12th month, you vest a full year’s worth of tokens at once).

This sounds good (in principle) since it encourages loyalty and discourages dumping of tokens.  However, in practice, if you have a large number of employees or investors all selling tokens on a similar date, the sudden large dump on the market can cause negative price action. To avoid this, we’ve recently started to recommend continuous vesting (where tokens accumulate steadily over a smooth curve). In this way, there’s a slow trickle of tokens into the market which avoids a sudden drop.

7. Set aside a budget for exchange listings

Many exchanges will charge fees to list your token, so you’ll need to plan ahead and have a budget for this if you want to be listed on some of the more popular ones. Some of the most prominent exchanges have been known to charge in the range of $1 million for a token listing, so the listing process can get expensive very quickly.

One exception would be if you’re a tier-1 project backed by well known funds, in which case sometimes exchanges will list you for free since it will attract users to their exchange. This is one advantage of going with respected VCs in your financing round (due to the social proof it can buy you with exchanges).

8. Fundraise prior to listing

We’ve met with many token projects that have attempted to raise after they launch their token.  This can be more challenging than a startup may expect.

Most private investors are arbitraging between public and private markets. There’s a much larger market of funds who will do private rounds versus public token rounds, limiting the potential number of suitors. For example, you’d be excluding most early-stage funds.

It’s also hard to raise post-token launch because the negotiation itself can be challenging. A typical structure is a discount to public token price. But that token price will likely fluctuate greatly during the fundraising process. How do you benchmark a price and agree on that price with a private investor if the token price is a moving target?

These issues go away if you fundraise prior to listing your token. The token price is unknown at that point, and you can include a much larger cohort of private funds who will invest in that asset class.

9. Invest in high-quality counsel for TGE

We’ve met a large number of teams over the years that are grossly under-served by their legal counsel. Founders in web3 are taking inherently larger risks than web2, so securing strong crypto-native legal advice is essential. I would encourage founders to ensure their counsel have a crypto-specific practice area of experience in preparation for TGE.

As an aside, the regulatory landscape in web3 is still developing. Often, a decision will be subjective rather than objective. Keep in mind that most lawyers aren’t business people and are often optimizing advice on hypothetical legal arguments, rather than practical decision-making in the real world. Said another way, don’t follow your lawyers off the cliff when it comes to regulation—you’ll need to apply your own judgment, and assess your own risk appetite, especially given that laws change frequently and are themselves a moving target.

10. Decide on the right timing for enabling monetization via a “fee switch”

Many protocols (especially DeFi) will defer their fees until a future date via a fee switch. The purpose of this is to subsidize maximum short-term growth and defer monetization until later. This is analogous to how in web2, Facebook and other social networks deferred advertising/monetization until they had a critical mass of their social graphs. If you’re optimizing for attracting new users, then deferring monetization makes complete sense.

The danger with deferring monetization is that it could interfere with product-market-fit. Generally speaking, if users are willing to pay for your service, then it’s the strongest indicator that you have “serious” users who will be sticky. But if your fees would materially impact the economics of your user base, then by deferring monetization you may be hiding core issues in your protocol. However, if your take rate is modest, this is likely a lower risk.

“Flicking” that fee switch is effectively transitioning from a pure governance or placeholder token structure to one that accrues value via platform fees to tokenholders. Often this is easier when done out the gate (GMX for example) but of course that’s not always the case (UNI and many others)

Here are some characteristics of projects where a fee switch flick may be warranted:

• Critical mass of users
• Strong liquidity on token
• Wide holder base
• Takers (traders) paying healthy fees to liquidity providers (makers)
  • Perhaps consider giving LPs tokens at the same time as the fee switch via airdrop or similar distribution, so even though they are not getting 100% of the fees anymore they still feel like they’re getting some back via tokens
  • Think about hurdle rate target APY yield for token holders relative to other opportunities/markets and construct fee parameters that make sense in that context and that are fair
    • For staking rewards for example, 5% is considered standard while 10% is considered high (LIDO can command 10%)
    • For trading venues, 2.5-5.0bps is standard, 10-25+bps is high; better venues can take higher fees
    • For lending, a reasonable net interest margin (NIM) between borrowers and lenders is typically 1-2% with an expectation of compression over time
      

Conclusion

I hope you find these ideas to be useful considerations with respect to token launches. Note that best practices for launching tokens are evolving and the ideas in this article are merely a starting point.  Please feel free to reach out if you’d like to debate or discuss further!

—

Note that several of the companies and protocols discussed in this article are portfolio companies of funds managed by Hack VC.

The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment, or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment, or other relevant advice, including with respect to anything discussed herein.

This post reflects the current opinions of the author(s) and is not made on behalf of Hack VC or its affiliates, including any funds managed by Hack VC, and does not necessarily reflect the opinions of Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC. Certain information contained herein has been obtained from published sources and/or prepared by third parties and in certain cases has not been updated through the date hereof. While such sources are believed to be reliable, neither Hack VC, its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC are making representations as to their accuracy or completeness, and they should not be relied on as such or be the basis for an accounting, legal, tax, business, investment, or other decision. The information herein does not purport to be complete and is subject to change and Hack VC does not have any obligation to update such information or make any notification if such information becomes inaccurate.

Past performance is not necessarily indicative of future results. Any forward-looking statements made  herein are based on certain assumptions and analyses made by the author in light of his experience and perception of historical trends, current conditions, and expected future developments, as well as other factors he believes are appropriate under the circumstances. Such statements are not guarantees of future performance and are subject to certain risks, uncertainties, and assumptions that are difficult to predict.