Creating software that issues a token is not automatically illegal. What matters is what the token represents, how it is sold, what purchasers are promised, where the team and users are located, and what services continue after launch. The same contract can sit inside a harmless technical experiment, a regulated public offering, a payment product, or a fraudulent promotion depending on those surrounding facts.
This article is a risk map, not legal advice. Crypto rules change quickly and differ by jurisdiction. Before accepting money, marketing broadly, or operating a market, obtain advice from counsel who can analyse the actual product and countries involved.
Begin with activities, not the word “token”
Regulators usually examine substance. Renaming an investment “utility,” calling a sale a “community mint,” or stating that something “is not a security” does not determine its legal treatment. Build a factual description of every activity:
- A smart contract creates units.
- A team allocates or sells some units.
- Marketing explains why people may want them.
- A pool or venue enables exchange.
- A treasury holds proceeds or reserves.
- The team may continue developing, promoting, administering, redeeming, or supporting the system.
Each step can engage different rules. A pure deployment with no sale and no promotion is not the same as raising money from the public. A token redeemable for fiat or linked to an asset is not the same as an unbacked community badge. A team that matches orders, holds customer assets, or exchanges tokens for users may be performing a service beyond issuance.
Classification changes the entire launch plan
Ask what rights and expectations a holder receives. Does the token claim a share of revenue, profit, interest, assets, or liquidation proceeds? Does it promise redemption at a fixed value? Is its value marketed as depending on the team’s future work? Is it required to access a functioning service, or is the service only an aspiration? Can holders vote, and does that vote have enforceable effect?
Common classification questions include:
| Token characteristic | Legal concern to investigate |
|---|---|
| Profit, revenue, or asset rights | Securities or investment-product rules |
| Stable value or redemption promise | E-money, payment, reserve, or stablecoin rules |
| Access to an existing product | Consumer, contract, marketing, and data rules still apply |
| Governance power | Whether control is real, disclosed, and consistent with entity obligations |
| Collectible or membership claim | Advertising, intellectual-property, and consumer rights |
| Anonymous transferable value | Anti-money-laundering, sanctions, and financial-crime exposure |
Classification is rarely answered by one feature in isolation. Distribution, purchaser expectations, central control, and promotional language can be as important as code.
Selling a token is more consequential than creating it
A private test deployment and a public fundraising campaign are different projects. If purchasers provide fiat, stablecoins, or other assets, document what they receive, when delivery occurs, what happens if the launch fails, how proceeds may be used, and whether refunds exist. Pre-sales create particular risk because buyers may be funding future work rather than obtaining a functioning product.
Do not assume that excluding one country solves the problem. Teams, directors, servers, promoters, purchasers, and service providers can create connections to several jurisdictions. Geo-blocking and contractual exclusions may support a legitimate compliance plan, but a checkbox is not a substitute for analysing where an offer is made and who can participate.
In the European Union, the Markets in Crypto-Assets framework includes rules for certain crypto-asset offers, issuers, white papers, and service providers. ESMA maintains MiCA information and registers, and stresses that the offeror or issuer is responsible for white-paper content. Other tokens may fall under existing financial-instrument rules rather than MiCA. The category must be determined before choosing a disclosure template.
Marketing can create liability even when code is correct
Public statements should be accurate, balanced, and supported. Avoid promises of guaranteed returns, “risk-free” language, fabricated partnerships, false scarcity, undisclosed paid endorsements, or claims that a listing is confirmed when it is merely requested. Screenshots of rising prices without liquidity context can mislead even if the numbers are technically real.
Separate product facts from forecasts. “The contract has a fixed supply of one million units” is verifiable. “Demand will make each unit worth ten dollars” is speculation. If incentives, referral payments, allocations, or sponsorships influence a promoter, disclose them clearly where the promotion appears.
Marketing rules can apply to websites, social posts, private groups, influencer scripts, paid search, referral schemes, and communications made by third parties on the project’s behalf. Build an approval process and preserve copies of claims, dates, audiences, and evidence.
A white paper is a disclosure document, not decoration
A useful disclosure explains the token and the operating reality in language a reasonable reader can test. It should cover the entity or people responsible, purpose, rights, supply, allocation, vesting, technology, dependencies, privileged controls, treasury, market plans, conflicts, material risks, and contact process.
Do not paste generic risks underneath specific promotional promises. If administrators can pause transfers or upgrade code, say who holds the keys and under what policy. If liquidity can be removed, say so. If there is no legal right to revenue, redemption, governance, or continued development, state that plainly.
Version disclosures and preserve historical copies. Updating a website after a dispute does not reconstruct what purchasers were shown at the time.
Financial crime controls depend on what you operate
Issuing code does not necessarily make a team an exchange or custodian. But accepting customer funds, transmitting value, arranging exchange, controlling wallets, redeeming tokens, or running certain services can create registration, anti-money-laundering, customer due-diligence, sanctions, monitoring, and reporting obligations.
Map money and control flows. Identify which addresses receive sale proceeds, fees, treasury assets, liquidity positions, and administrative powers. Screen counterparties where legally required, avoid sanctioned activity, keep decision records, and design a process for lawful requests. “The blockchain is public” does not satisfy every compliance obligation.
Consumer, privacy, and intellectual-property rules still exist
Token projects collect ordinary data: email addresses, IP logs, support tickets, analytics identifiers, wallet addresses, allowlist entries, and community moderation records. Decide the purpose, lawful basis, retention period, access controls, processors, and deletion process. Wallet addresses can become personal data when linked to individuals or account activity.
Terms should identify the operator, explain eligibility, describe the service, allocate risks fairly, and match the product. Privacy notices should describe actual processing rather than a generic template. Neither document cures misleading conduct or removes mandatory consumer rights.
Check names, logos, artwork, code licences, fonts, and marketing assets. A decentralised deployment does not grant permission to copy a trademark. Search relevant registries and app stores before building a brand around a name that another business controls.
Governance and “decentralisation” must be factual
If a multisignature can upgrade contracts, move treasury funds, change fees, pause transfers, or dominate voting, disclose that control. Publishing a governance token does not eliminate company, director, fiduciary, contractual, or regulatory obligations. Nor does using anonymous screen names guarantee that contributors cannot be identified from operational evidence.
Create a control register listing each privileged function, current holder, signing threshold, emergency process, replacement process, and public evidence. Update it when control changes. If the stated goal is progressive decentralisation, define measurable stages instead of using the phrase as a permanent excuse for central control.
A launch-readiness legal checklist
Before public release, obtain written answers to these questions:
- Which entities and people issue, develop, market, and operate the project?
- Which jurisdictions connect to those activities and intended users?
- How is the token likely to be classified in each important jurisdiction?
- Is a registration, authorisation, filing, white paper, prospectus, or exemption needed?
- What sale, refund, consumer, privacy, sanctions, and recordkeeping rules apply?
- Who approves public claims and paid promotion?
- What rights do holders actually receive?
- Which risks and conflicts must be disclosed?
- What tax and accounting treatment follows from issuance and treasury activity?
- What is the process for incidents, complaints, legal requests, and winding down?
The safest time to ask these questions is before collecting funds or promising a market. Legal review may change distribution, contract permissions, geography, marketing, or even whether a token is appropriate. That is not friction around the launch; it is part of designing a launch that can survive attention.