Based on an international jurisdiction perspective, this article focuses on the compliance of Web3 utility token issuance. It breaks down the distinct compliance paths for infrastructure and application-layer projects, details key points of legal structure construction across the three phases (Testnet, TGE, DAO) — such as dual-entity setup and equity + token warrant financing — and warns of securitization risks through cases like Telegram and Filecoin. It provides dynamic compliance strategies to help project founders build a legitimate framework and navigate regulatory cycles.
Introduction
In the past few years, the phrase “token issuance” has become the most sensitive term in the Web3 world. Some people rose to fame overnight because of it, while others were investigated, forced to refund funds, or had their accounts banned. In fact, the problem does not lie in “issuing tokens”, but in “how to issue them”. For tokens, some projects have been listed on mainstream exchanges, have communities, and have DAOs; while others have been determined to be illegal securities offerings. The difference lies in whether the issuance was carried out within a legal framework.
The reality in 2025 is that Utility Tokens are no longer in a gray area. Regulators are scrutinizing every TGE, every SAFT, and every “airdrop” with a magnifying glass.
This article is written for every Web3 project founder: on the road from Testnet to DAO, the legal structure is the backbone of your project. Before issuing tokens, learn to build this backbone first.
Note: This article is based on an international jurisdiction perspective and is not targeted at or applicable to the legal environment of mainland China.
A Token’s “Identity” Is Not Defined by Your Whitepaper
Many teams will say: “Our token is only a utility token, with no profit distribution, so it should be fine, right?”
But the reality is not like this. In the eyes of regulators, a token’s “identity” depends on market behavior, not how you describe it.
A typical case is Telegram’s TON project.
Telegram raised $1.7 billion in a private placement from investors, claiming that the token was only the “fuel” for the future communication network;
However, the U.S. SEC believed that this financing constituted an unregistered securities offering — because the obvious purpose of investors’ purchase was “future appreciation”, rather than “immediate use”.
As a result, Telegram refunded the investment funds and paid a fine, and the TON network was forced to operate independently from Telegram.
Lesson: Regulators look at “investment expectations”, not “technical vision”. As long as you use investors’ money to build an ecosystem, the token will have securities attributes.
Therefore, do not fantasize about eliminating risks with the label of “utility token”. The nature of a token evolves dynamically — it is an investment contract in the early stage of the project, and may only become a real usage certificate after the mainnet launch.
First, Clarify What Type of Project You Are Running
What determines your compliance path is not the name of the token, nor the total supply, but the type of project.
Infrastructure (Infra) Projects:
Such as Layer1, Layer2, public chains, ZK, and storage protocols.
They usually adopt a “Fair Launch” model, with no pre-mining and no SAFT, and tokens are generated through node consensus.
Examples include Bitcoin, Celestia, and EigenLayer.
Advantages: Naturally decentralized, with low regulatory risks; Disadvantages: Difficult to raise funds, long development cycle.
App Layer Projects:
Such as DeFi, GameFi, and SocialFi.
Tokens are pre-minted (TGE) by the team, and the team leads the ecological treasury. Typical examples include Uniswap, Axie Infinity, and Friend.tech.
Clear business model, but high compliance risks: Sales, airdrops, and circulation all require handling regulatory disclosure and KYC issues.
Conclusion: Infrastructure projects survive on consensus, while application projects depend on structure to survive. Without a well-designed structure, all “Tokenomics” are empty talk.
Testnet Phase: Don’t Rush to Issue Tokens, Build the “Legal Backbone” First
Many teams start looking for investors, signing SAFTs, and pre-mining tokens during the Testnet phase.
But the most common mistake at this stage is:
Taking investors’ money while claiming “this is only a utility token”.
Filecoin in the U.S. is a warning case. It raised about $200 million through SAFT before the mainnet launch. Although it was exempted by the SEC, due to the delayed launch and the tokens being unavailable for the time being, investors questioned its “securities attributes”. Eventually, the project spent huge compliance costs to fix the problem.
The correct approach is:
Distinguish between two entities:
DevCo (Development Company): Responsible for technology research and development and intellectual property rights;
Foundation / TokenCo: Responsible for ecological construction and future governance.
Financing method: Adopt a structure of Equity + Token Warrant, instead of directly selling tokens.
Investors obtain the right to future tokens, not ready-made token assets.
This method was first adopted by projects such as Solana and Avalanche, allowing early investors to participate in ecological construction while avoiding directly triggering securities sales.
Principle: The legal structure in the early stage of a project is like the genesis block. A single logical error may multiply the compliance costs tenfold.
Mainnet Launch (TGE): The Moment Most Likely to Attract Regulatory Attention
Once a token can be traded and has a price, it enters the regulatory radar. This is especially true for public distributions involving airdrops, LBPs (Liquidity Bootstrapping Pools), or Launchpads.
Public Chain Projects:
Such as Celestia, Aptos, and Sui. Tokens are usually automatically generated by the validator network during TGE.
The team does not directly participate in sales, and the distribution process is decentralized, resulting in the lowest regulatory risk.
App Layer Projects:
Airdrops such as those from Arbitrum and Optimism, or community distributions such as those from Blur and Friend.tech,
have been focused on by regulators in some jurisdictions regarding whether “distribution and voting incentives constitute securities sales”.
The safety line during the TGE phase lies in disclosure and usability:
Clearly define the token’s usage scenarios and functions;
Announce the token allocation ratio, lock-up period, and unlocking mechanism;
Implement KYC/AML for investors and users;
Avoid “expected return”-style promotion.
For example, the Arbitrum Foundation clearly stated during TGE that its airdrop was only for governance purposes and did not represent investment or profit rights; and gradually reduced the proportion of Foundation-led governance in community governance — this is exactly the key path to “de-securitize” the token.
DAO Phase: Learn to “Let Go” and Make the Project Truly Decentralized
Many projects “end” after issuing tokens, but the real challenge is — how to transfer control and let the token return to being a public good.
Take Uniswap DAO as an example:
In the early stage, Uniswap Labs led the development and governance;
In the later stage, the Uniswap Foundation managed the treasury and funded ecological projects;
The community decides on protocol upgrades and parameter adjustments through UNI voting.
This structure makes it more difficult for regulators to identify it as a “centralized issuer” and also improves community trust.
However, some projects that failed to handle the DAO transition properly, such as some GameFi or NFT ecosystems, were still regarded as “pseudo-decentralized” due to the team still controlling most of the tokens and holding voting rights, and still faced securities risks.
Decentralization is not “letting go”, but “verifiable transfer of control”. Achieving a triangular balance between code, foundation, and community is the safe DAO architecture.
What Regulators Are Looking At: Can You Prove “This Is Not a Security”
Regulators are not afraid of you issuing tokens; they are afraid that you say “it is not a security” but act like it is a security.
In 2023, in the SEC’s lawsuits against Coinbase, Kraken, and Binance.US, dozens of “utility tokens” were listed, and it was determined that they all had the characteristics of “investment contracts” during the sales and marketing stages. This means that as long as a project conveys “expected returns” during token sales, even if the token itself has functions, it will be regarded as a security.
Therefore, the key to compliance is to respond dynamically:
Testnet: Focus on technology and development compliance;
TGE: Emphasize usage scenarios and functional attributes;
DAO: Reduce team control and strengthen governance mechanisms.
The risks are different at each stage, and the token positioning must be re-evaluated with each upgrade. Compliance is not a one-time approval, but a continuous iteration.
Conclusion: Projects That Survive Cycles Rely Not on “Speed”, But on “Stability”
Many projects fail not because of poor technology, but because of a bad structure. While others are still talking about “price fluctuations”, “airdrops”, and “listing on exchanges”, truly smart founders are already building legal frameworks, writing compliance logic, and planning DAO transformation.
The issuance of utility tokens is not about circumventing regulation, but using the law to prove that you do not need regulation. When code takes over the rules, the law becomes your firewall.
〈Utility Token Launch Compliance Playbook〉這篇文章最早發佈於《CoinRank》。
