On April 10, 2025, the U.S. Securities and Exchange Commission (SEC) Division of Corporation Finance released a heavyweight policy document: (Offerings and Registrations of Securities in the Crypto Asset Markets). Although the title is mild, for the Web3 industry, it is essentially a standardized 'disclosure document guide' for issuing tokens.
This is not a new enforcement announcement, nor is it a penalty notice for a particular project, but a highly practical disclosure guideline. The SEC rarely uses nearly four thousand words to tell you point by point: if you want to legally issue Tokens and raise funds in the U.S., you must write these matters clearly.
You can think of this as a prospectus for Web3 projects to enter the U.S. capital market, as well as a clear boundary map drawn by the SEC for the industry.
Background: Why did the SEC issue this document?
In recent years, more and more Web3 projects are taking compliant paths, attempting to publicly raise funds in the form of securities, and many projects have adopted the following methods:
• Register for a public offering (similar to an IPO) with the SEC through Form S-1;
• Use Reg A+ for small fundraising, bypassing the complete IPO process;
• Submit Form 20-F to enter the U.S. market by an overseas team;
• Even issue ETF products linked to Tokens using a trust structure.
The SEC has noticed that the registration documents submitted by different projects are varied; some completely copy the white paper, some pile up technical terms but lack substantive content, and others even obscure basic risk factors. To standardize industry practices, the SEC's Division of Corporation Finance has released this policy, listing the core content that must be disclosed when issuing tokens for fundraising. It does not have legal effect but has practically become the industry default registration reference standard.
The document opens with a specific mention: 'to provide greater clarity on the application of the federal securities laws to crypto assets...'
— to provide clearer guidance on how securities laws apply to crypto assets.
Business disclosure: it's not about talking dreams, but about what you are actually doing.
The SEC emphasizes that project teams must submit a complete description of their own business. This statement is standard in traditional IPOs and is now explicitly introduced into the Token registration process.
"Issuers are required to disclose information material to an understanding of the general development of their business."
In short, you can no longer use the narrative of 'blockchain + future vision' to confuse investors, but must write clearly and concretely:
• What project are you working on? Is it L2? DEX? GameFi? DePIN?
• Where is the project currently? Is there a mainnet? User volume? On-chain active data?
• Are you still operating after going live? Is the project team dissolved? Or is it handed over to the DAO? Does the DAO have a clear governance structure?
• How do you make a profit? Is there a clear monetization path? Is it through fees, Token premiums, or ecosystem feedback?
• What exactly is the Token for? Is it governance, gas, a service voucher, or an investment voucher?
The SEC specifically points out that you cannot substitute 'talking about technology and ecology' for the actual business situation, nor can you copy the white paper verbatim. The materials must reflect your specific, clear, and quantifiable business model.
Technical structure disclosure: if you say you have a chain, you must clearly explain the structure of that chain.
The biggest highlight of this SEC document is that the technical disclosure section is written in unprecedented detail.
"The objectives of the network and how the technology… functions and accomplishes its objectives, including architecture, software, key management…"
Specifically includes the following content:
Goals, uses, and operating mechanisms of the network and applications;
Consensus mechanism, transaction confirmation methods, block size, gas mechanisms, transaction throughput;
Wallet systems and key management methods (whether self-custody, whether multi-signature supported);
Is the network open-source? Who owns the intellectual property? Are there any patent disputes?
Is there a mechanism for network upgrades? What is the upgrade proposal process? Who has execution authority?
If governance is conducted through smart contracts, have these contracts been audited? Who maintains them? Are they upgradable?
The SEC also requires projects to explain the roles within the network— including users, developers, validators, governance participants, off-chain service providers, etc.—and their responsibilities and interaction methods. You can no longer just say 'we have a chain, it operates on-chain,' but must explain the technical details, governance mechanisms, and upgrade logic of the chain as if describing a company's governance structure.
The aforementioned projects may not all apply to every project; the SEC has not mandated that all projects disclose this content, but says, 'If this content is a part of your project and significant to investors, then you must disclose it.'
Token disclosure: if you are issuing securities, then disclose according to the standards for securities.
This part is very straightforward from the SEC: if the Tokens you issue fall into the category of securities (which is highly probable), then you must explain their attributes and rights structure just as you would for stock disclosures.
"Rights, obligations, and preferences… including voting rights, liquidation rights, redemption terms, etc."
You need to answer the following questions:
Does the Token represent asset income rights? Liquidation rights? Voting rights?
Is the Token transferable? Are there restrictions such as lock-ups, prohibitions on sales, or circulation limits?
Does it have functions such as splitting, staking, repurchasing, or destroying? How are the rules set?
What is the mechanism for generating Tokens? Is it a one-time mint? Periodic releases? Is there an upper limit?
Is there a special Token structure set up for the DAO (e.g., governance Token vs. economic Token)?
Does the contract support upgrades? If so, who has the authority to modify the logic?
Has a third-party audit been conducted? Is the audit report public?
You can design your Token model using strong technical logic, but ultimately you still have to translate this model into the language familiar to the SEC for review. This is not about innovation, but about 'whether you can explain it clearly.'
Risk disclosure: not just price fluctuations, but every point you worry might go wrong must be clearly stated.
The SEC has always been particularly sensitive to risk disclosures. It emphasizes that risks are not just decorative in the process but are an obligation of the project.
"Material factors that make an investment speculative or risky… including technological, regulatory, and operational risks."
The risks you must disclose are not limited to 'Token price fluctuations':
Risks related to the issuer's planned business operations, such as risks related to technology and network security, as well as the implementation of the issuer's business, and reliance on other networks or applications.
Risks related to securities, such as risks associated with any unique features of the securities, including their form, price fluctuations, rights of holders or lack thereof, valuation, liquidity, supply, and custody.
Risks related to other applicable laws and regulations, such as whether the issuer's activities require registration with the Financial Crimes Enforcement Network or certain state financial services agencies under money transmission laws, or registration with other regulatory bodies such as federal or state banking regulators or the Commodity Futures Trading Commission.
All of these must be disclosed truthfully, even if they sound like they will 'affect fundraising.' The SEC's bottom line is 'don't hide,' otherwise, you can expect a letter from the SEC.
Disclosure of issuer management information: who the operator is, who received the money, must all be written out.
You can claim to be a DAO project or controlled by a foundation, but the SEC won't listen to your self-introduction; it looks at 'who makes the decisions, who can issue tokens, and who receives substantive benefits.'
"Disclosure is required for persons who do not hold formal titles… but who perform policy-making functions."
Who is the issuer's management? Information related to their identity and experience.
Who participated in the project governance, funding decisions, and roadmap formulation?
Which service providers are operating the project? Were consulting fees or technical fees paid?
Do any employees or teams hold a large number of tokens?
Are smart contracts or network code hosted by specific teams/organizations?
Even if you use the most complex structures, you must disclose the actual controlling party. The SEC is not hostile to structural design; it just wants you not to 'hang a sheep's head while selling dog meat.'
Finance and auditing: you didn't just issue a token, but brought yourself into the SEC's field of vision.
Many project teams say, 'I don't have operating income; why do I need financial statements?' The SEC does not want you to beautify financial statements; it wants you to clarify these matters:
Are Tokens counted as assets? Is the pre-sale treated as a liability?
Is Token used as consideration for services? How is it measured?
Do Token incentives, token releases, staking interests, etc., constitute expenses?
Is there an on-chain income stream? How is it confirmed and audited?
Do Tokens generate dividends, rebates, or compound interest similar to traditional securities?
The original text states: 'Issuers are required to provide financial statements that comply with applicable requirements...'
You need to submit financial statements in standard format (especially S-1, Reg A+, 20-F), and provide clear accounting treatment for assets, liabilities, income, and expenses related to Tokens.
The SEC specifically points out that if your Token rules are written in the contract, and on-chain governance rules are determined by code, then this code itself must be submitted as an Exhibit (formal appendix), and updates must be synchronized.
"We have observed filings include as an exhibit the code of the smart contract(s)…"
In other words:
Smart contract addresses, versions, and audit situations must be disclosed synchronously;
Whether upgrade logic exists, and whether it is controlled by a few people, must also be explained;
If the contract controls Token release rules, then this is your project's 'securities agreement.'
Lawyer Mankun summarizes: Compliance is a collective coming-of-age ceremony for the industry.
Many entrepreneurs' first reaction upon seeing the SEC document is: 'It's too complicated; let's change countries.' But this document does not reject Web3; rather, it is an invitation for Web3 to move towards the public market and institutionalization.
It is not a red light, but a roadmap.
Do you really want to get traditional institutional money? Do you want your project to trade on mainstream markets? Do you want to survive in the long term without fearing any legal letters? Then you must adapt to these disclosure requirements, manage your tokens with the logic of securities, and operate your project with the mindset of a public company.
The SEC does not tell you how to design a token, but it tells you which information cannot be hidden and which structures cannot be manipulated. This list is your compass for compliant fundraising in the U.S. market.
If you are a Web3 project team, trading platform, fund, lawyer, or auditing institution—now is the time to pick up this document and reevaluate everything you are preparing to submit to the SEC.
/ END.