In this piece, we provide web3 builders with a legal guide for utility token launches, exploring three key dimensions of token legal qualification (use cases, transactions, and the state of decentralization) across project stages: pre-token, token launch, and post-token launch (DAO).
We'll explore how legal setups may vary based on the technical layer where the token is launched (double-entity setups for infrastructure projects and triple-entity setups for applications), and learn more about the specific use cases of different entity types (DevCo, TokenCo, Foundation) at each stage of the project.
Before jumping into this guide (or while working with it), you might want to check out our previous guides on Web3 project legal structuring. We've explored legal strategies for token launches, token types based on their use cases, and launch strategies, and also created a progressive decentralization roadmap that focuses on the legal aspects that arise at each stage.
Why should a token’s legal status be considered dynamic?
Before diving into the guide, let’s make one point clear: no token’s legal status should be considered static at all times. As an example, the same token being considered a utility token in 2017, when it was first launched, is likely to have a different legal status when examined again in 2024.
The concept that a token's legal status is not static is supported by Ethereum-related case law, where U.S. courts changed their approach to ETH's legal qualification (security/non-security) multiple times. These changes were triggered by different stages of the Ethereum network's development (PoW → PoS). Consequently, a Web3 project may face varying legal and regulatory risks at different stages of its development, potentially requiring different types of legal work for risk mitigation, depending on how each dimension varies at each specific stage of the project.
Given this hypothesis about the possible dynamics in token legal qualification, it is critical that this is examined further, to provide Web3 builders with a helpful legal structuring guide for their token launch. We will explore legal options and best practices at each stage of a Web3 project, and will approach the legal structuring of a utility token launch in three stages:
- pre-token (testnet)
- token launch (mainnet in the form of a fair token launch or a token pre-mint)
- post-token (DAO)
Infrastructure and application projects with tokens
Before analyzing the stages of token launch and their associated legal work, we must consider another crucial differentiating factor: the type of underlying Web3 project in which the token will have its utilities. This criterion is important because token launch methods differ depending on whether a decentralized project aims to build infrastructure or an application. This classification was suggested by a16z in their recent token playbooks.
Infrastructure projects (and some applications using appchain/parachain technologies) typically use a fair token launch approach. In this model, there's no token pre-mint, no centralized entity or team deploying the token smart contract, and no manual token distribution at the beginning. Everything happens in a decentralized manner, with validators deploying and supporting autonomous software with algorithmic token generation and distribution processes. The most popular examples of infrastructure projects with fair token launch models are L1/L2 networks. Some application projects (appchains/parachains) also fall into this category.
However, application projects with more traditional token generation events (TGEs) are structured differently. These involve the deployment of the token smart contract by the project's team, manual token minting, and manual management of the token treasury—resulting in a centralized entity overseeing this stage. In the following paragraphs, we'll consider this difference from the legal point of view when discussing token legal structuring at each stage.
Key parameters for building a legal strategy for token launch
In the preceding paragraphs, we've outlined three key considerations to account for when exploring a legal guide for token launch:
- Key dimensions of tokens (use cases, transactions, and the state of decentralization)
- Types of underlying projects where tokens have utilities (infrastructure and application projects)
- Dynamic nature of token legality depending on the project's stages (pre-token, TGE, and post-token)
Now, let's delve into the main part of the article, and explore each stage of a token launch in turn.
1. Pre-token (testnet) stage and the choice between double- and triple-entity structures
At this stage, Web3 teams typically focus on developing tokenomics and conducting experiments with tokens on a testnet, where no real value is involved. However, fundraising activities often occur simultaneously, involving future token rights (promises to issue tokens to investors later). In some cases, these future token rights may be classified as securities.
To raise funds in accordance with the project roadmap, it's crucial to have an appropriate corporate structure in place. Depending on the project type, two structural approaches can be considered:
- Double-entity structure (more common for infrastructure projects)
- Triple-entity structure (more common for application projects)
Let's explore each of these in more detail.
Double-entity structure for infrastructure projects
When future token rights are offered alongside future equity rights (e.g., SAFE + Token Warrant model) as a side letter to the equity investment agreement—allowing investors to buy tokens in the future—the risk of token rights being classified as securities is partially mitigated. This is because there's no monetary consideration for token rights; it's an additional benefit for equity investors who put money into equity.
In this scenario, a double-entity structure can be considered. The DevCo is used for project and tokenomics development (signing employment/freelancer agreements with the team and accumulating the IP of the project) as well as for equity + token warrant fundraising. The Foundation can be added before the fair token launch to operate as the holder of the ecosystem token treasury in the future (after the network begins gradually producing tokens based on network epochs or other consensus algorithm intervals).
Therefore, at the pre-token stage of infrastructure projects with a fair token launch approach, it's usually sufficient to have only one entity (DevCo). This entity is typically registered either in the jurisdiction where most team members are based or in a commonly recognized venture-friendly jurisdiction (e.g., UK, Singapore, UAE, Cayman Islands).
You can see how the double-entity structure works in the diagram below. Please note that a FoundingCo (or a holding company) is optional and we don’t cover this aspect here as it doesn’t relate to the token issuance.
Triple-entity structure for application projects
If the team plans to raise funds via a SAFT (Simple Agreement for Future Tokens), there's a high likelihood that these token rights will be classified as securities. This is because there's a future token offering, consideration in the form of investments, and investors' expectations to receive returns based on the team's efforts (this assumption was confirmed in the case of SEC against Ripple).
Consequently, a triple-entity structure might be considered, comprising:
- DevCo: the entity responsible for project development
- TokenCo: registered to handle pre-token stage activities (SAFT fundraising, regulatory, financial and securities compliance)
- Foundation: established to pave the way for future decentralization
The creation of this triple-entity structure can be approached in two ways:
- Either a regulated structure requiring token authorization from regulators (involving onshore jurisdictions like Switzerland, Liechtenstein, or Singapore, where a TokenCo can obtain token authorization).
- Or a non-regulated structure where utility token issuance generally doesn't require authorizations or licenses (involving offshore jurisdictions such as the Cayman Islands, BVI, or Panama).
The diagram below illustrates what the triple-entity structure looks like compared to the above-mentioned double-entity structure.
In the following sections, we'll examine stages 2 (Token Generation Event) and 3 (Post-token / DAO) for each corporate structure.
2. TGE & DAO stages for a double-entity structure (infrastructure projects)
TGE stage
In a double-entity structure, the DevCo is responsible for project development, SAFE+token fundraising, and validator bootstrapping. Also, as the TGE stage is usually fully covered autonomously by validators, the team doesn't need to register a separate entity to handle these activities manually.
Once the network starts producing tokens for the ecosystem, the foundation—as a DAO entity—becomes necessary to maintain and manage a wallet serving the ecosystem treasury. The blockchain networks will autonomously (in a permissionless way) send a portion of gradually minted tokens to this wallet. Such token foundations for infrastructure projects are typically registered in either onshore jurisdictions (e.g., Swiss Foundation, DLT Foundation in UAE) or offshore jurisdictions (e.g., Cayman Islands, Panama).
This process is illustrated in the diagram below. The foundation is also responsible for distributing the community token via airdrop campaigns and liquidity provision to exchanges, launchpads, and LBPs (Liquidity Boostrapping Pool).
.png)
Post-token (DAO) stage
For the post-token (DAO) stage, the project's corporate structure can be updated or improved based on the planned governance structure for maintaining and managing the ecosystem token treasury. Here are a couple of market practices for this:
- Keeping the foundation as an entity with the sole non-profit purpose of ecosystem development and oversight (issuing token grants for builders, ensuring network compliance & security, etc.).
- Making the foundation an ownerless entity with a pass-through governance model, where the foundation acts as a representative of the network of token holders (DAO).
- Implementing a dual-governance structure with the foundation for ecosystem treasury management and a DAO LLC for community treasury management and voting.
The diagram below illustrates the point and also shows that the projects still use the DevCo at this stage too for development and operational purposes, where the foundation issues grants to the DevCo for the development and the DevCo provides the services.
.png)
3. TGE & DAO stages for a triple-entity structure
TGE stage
In the triple-entity structure, the TokenCo plays a crucial role during the token generation event stage. This entity is responsible for:
- Deploying the token smart contract to the mainnet
- Pre-minting tokens and managing the token treasury
- Distributing pre-minted tokens among SAFT investors, core contributors, community, and ecosystem foundation
For community token distribution, TokenCo conducts airdrops, organizes IDO and launchpad campaigns, and launches liquidity bootstrapping pools. Additionally, TokenCo sets aside a portion of tokens for future ecosystem development, which will later be contributed to the ecosystem foundation (future grants, strategic reserve). The primary objective of TokenCo during the TGE stage is to ensure equitable token distribution between early contributors and the community in a compliant manner. This process is illustrated in the diagram below.
.png)
Post-token (DAO) stage
Once the TGE stage concludes, the project's next milestone is to enhance decentralization. This post-token (DAO) stage involves implementing token-based DAO membership, establishing a proposal-based governance process, and further improving regulatory, financial, and sanctions compliance for the project. These activities fall under the purview of the Foundation—the third entity within the triple-entity structure.
Also, after all of the pre-minted tokens have been distributed the TokenCo is dissolved and the legal setup becomes similar to the double-entity structure for infrastructure projects.
.png)
To determine your token’s qualification, timing is everything
Since the ICO boom in 2017, Web3 projects have become more sophisticated. New types of projects have emerged, and novel kinds of tokens have been launched. Concurrently, Web3-related regulations and case law have evolved, resulting in an expanded list of legal considerations for token launches. Today, these considerations extend beyond token rights—which was the primary focus in 2017 when the Howey Test was first applied to crypto projects.
The current expanded list of legal considerations includes:
- Token use cases and the type of underlying project (infrastructure or application)
- Types of transactions involving the tokens
- The state of decentralization of the underlying network
As mentioned already in this guide, timing is also crucial. A token's legal status isn't static; it may change depending on the stage of Web3 project development. Consequently, we've proposed a stage-based playbook that outlines the scope of work and necessary legal entities for the Pre-token, TGE, and Post-token (DAO) stages. This approach varies depending on whether the Web3 team is building an infrastructure or application project.
Use a dynamic approach to legally structure your token launches
If your Web3 project team is planning to issue tokens or exploring potential future token releases, it's crucial to carefully consider the legal implications of your token strategy.
By understanding that token legality is essentially a dynamic issue, one that differs greatly depending on which stage within a project is under scrutiny, you’ll be able to determine the legal status of your tokens and their utility with more clarity.
At Legal Nodes, we assist Web3 teams by offering an international perspective on legal options for token issuance. From drafting the appropriate documents to consulting with industry experts, we help teams explore their options, identify risks, and meet legal obligations. Through our integrated platform, we connect you with service providers worldwide to guide you through a compliant token launch. Contact us today to get started with confidence.
Structure your token launch
