Compliance Guide for the Issuance of Utility Tokens

Original Author: Shao Jiadian

Introduction

In recent years, the words “token issuance” have become the most sensitive phrase in the Web3 world. Some have become famous overnight through it, while others have been investigated, had their tokens withdrawn, or been banned. The real issue isn’t “issuing,” but “how to issue.” The same token, some projects are listed on mainstream exchanges, have communities, and DAO governance; others are deemed to be illegally issuing securities. The difference lies in whether they are issued within a legal framework.

The reality in 2025 is that utility tokens are no longer in a gray area. Regulations are scrutinizing every TGE, every SAFT, and every “airdrop” with a magnifying glass.

This article is written for every Web3 project founder: on the journey from Testnet to DAO, the legal structure is the skeleton of your project. Before issuing tokens, learn to build the framework first.

Note: This article is based on an international legal perspective and does not target or apply to Mainland Chinese legal environments.

The “Identity” of Tokens Is Not Decided by Your Whitepaper

Many teams say: “Our tokens are purely functional, with no profit sharing, so it should be fine, right?”

But the reality is different. In the eyes of regulators, the “identity” of a token depends on market behavior, not how you describe it.

A typical example is Telegram’s TON project.

Telegram raised $1.7 billion through private placement, claiming the tokens are just “fuel” for future communication networks;

But the US SEC considered this financing as an unregistered securities offering—because the investors’ purchase purpose was clearly “appreciation in value” in the future, not “immediate use.”

As a result, Telegram refunded the investors and paid fines, 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, it has securities attributes.

So, don’t rely on the “functional” label to eliminate risks. The nature of tokens is dynamically evolving—early-stage projects are investment contracts, and only after mainnet launch can they become true utility tokens.

Identify Your Project Type First

What determines your compliance path is not the token’s name or total supply, but the project type.

• Infrastructure (Infra):

For example, Layer1, Layer2, public chains, ZK, storage protocols.

Typically launched via “Fair Launch,” with no pre-mining or SAFT, tokens generated through node consensus.

Examples include Bitcoin, Celestia, EigenLayer.

Advantages: inherently distributed, low regulatory risk; disadvantages: difficult fundraising, long development cycles.

• Application Layer Projects (App Layer):

For example, DeFi, GameFi, SocialFi.

Tokens are pre-minted by the team (TGE) and the ecosystem treasury is controlled by them, with typical projects like Uniswap, Axie Infinity, Friend.tech.

Business models are clear, but compliance risks are high: sales, airdrops, circulation all require regulatory disclosure and KYC.

Conclusion: Infrastructure survives on consensus; application projects rely on structural safeguards. Without a well-designed structure, all “Tokenomics” are empty talk.

Testnet Stage: Don’t Rush to Issue Tokens, First Build the “Legal Skeleton”

Many teams start seeking 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 “these are just functional tokens.”

Filecoin in the US is a warning case. It raised about $200 million via SAFT before mainnet, received SEC exemption, but due to delays in launch and tokens being temporarily unavailable, investors questioned its “security” status, ultimately leading to high compliance costs for the project.

The correct approach is:

• Distinguish between two entities:
  • DevCo (Development Company): responsible for technology R&D and IP;
  • Foundation / TokenCo: responsible for ecosystem development and future governance.
• Financing method: use a structure of Equity + Token Warrant, rather than directly selling tokens.

Investors gain rights to future tokens, not existing assets.

This approach was first adopted by projects like Solana and Avalanche, allowing early investors to participate in ecosystem development while avoiding direct securities sales.

Principle: The legal structure at the project’s inception is like the genesis block. A single miswrite can multiply compliance costs tenfold.

Mainnet Launch (TGE): The Moment Most Likely to Attract Regulatory Attention

Once tokens can be traded and have a price, they enter the regulatory radar—especially when involving airdrops, LBP (Liquidity Bootstrapping Pools), Launchpads, and other public distributions.

• Public Chain Projects:

For example, Celestia, Aptos, Sui, where tokens are usually generated automatically by validator networks at TGE.

The team does not directly participate in sales; the distribution process is decentralized, minimizing regulatory risk.

• Application Layer Projects:

Such as Arbitrum, Optimism airdrops, or community distributions like Blur, Friend.tech.

Some regulatory agencies focus on whether the “distribution and voting incentives” constitute securities sales.

The safety line at TGE involves disclosure and usability:

1. Clarify token use cases and functions;

2. Publish token distribution ratios, lock-up periods, and unlocking mechanisms;

3. Conduct KYC/AML for investors and users;

4. Avoid promotional language implying “expected returns.”

For example, Arbitrum Foundation explicitly stated during TGE that its airdrop was solely for governance purposes, not representing investment or profit rights; and gradually reduced the Foundation’s control in community governance—this is a key path to “de-securitization” of tokens.

DAO Stage: Learn to “Let Go” and Truly Decentralize the Project

Many projects “finish issuing tokens” and then end, but the real challenge is—how to exit control and let tokens become a public good.

Take Uniswap DAO as an example:

• Early development and governance led by Uniswap Labs;
• Later, the Uniswap Foundation manages the treasury and funds ecosystem projects;
• The community votes with UNI tokens to decide protocol upgrades and parameter adjustments.

This structure makes it harder for regulators to classify as a “centralized issuer” and increases community trust.

However, some projects that poorly handle DAO transition, such as certain GameFi or NFT ecosystems, where the team still controls most tokens and voting rights, are ultimately seen as “pseudo-decentralized” and still carry securities risks.

Decentralization is not “laissez-faire,” but “verifiable exit.” Achieving a balance among code, foundation, and community is the safest DAO architecture.

What Regulators Are Looking For: Can You Prove “This Is Not a Security”

Regulators are not afraid of you issuing tokens; they fear you claiming “it’s not a security” while your actions resemble securities.

In 2023, SEC lawsuits against Coinbase, Kraken, Binance.US listed dozens of “functional tokens,” recognizing that during sales and marketing, they exhibited “investment contract” features. This means that as long as a project conveys “expected returns” during token sales, even if the token has functional use, it will be considered a security.

Therefore, compliance requires dynamic responses:

• Testnet → Focus on technical development and compliance;
• TGE → Emphasize use cases and functional attributes;
• DAO → Reduce team control, strengthen governance mechanisms.

Risks differ at each stage; each upgrade requires re-evaluating token positioning. Compliance is not a stamp, but an ongoing iteration.

Conclusion: Projects That Survive Cycles Never Rely on “Speed,” But on “Stability”

Many projects fail not because of technical issues, but because of poor structure. While others are still talking about “price swings,” “airdrops,” and “listing,” smart founders are already building legal frameworks, writing compliance logic, and planning DAO transitions.

Issuing functional tokens is not about bypassing regulation but proving legally that you don’t need regulation. When code takes over rules, law becomes your firewall.