Hello. This capstone module moves from creating a token and AMM liquidity on devnet toward the question that determines whether a mainnet launch is viable: what exactly are we offering, to whom, through which channels, and under which regulatory perimeter?
This lesson gives you a reusable regulatory issue-spotting matrix for a hypothetical Solana token. It is a product-and-engineering planning tool, not legal advice and not a substitute for advice from qualified counsel in each relevant jurisdiction. Crypto rules, transitional periods, and regulator guidance change quickly; a pre-launch legal review must verify the rules in force on the actual launch date.
By the end, you should be able to turn a token’s technical and commercial facts into a structured set of US, UK, EU, and UAE questions, risks, owners, and evidence requirements.
Start with facts, not labels
Calling something a “utility token,” “community token,” or “governance token” does not decide its legal treatment. Regulators will look at the rights embedded in the token, how it is sold, what the issuer promises, who is targeted, and which services surround it.
For this lesson, use the following deliberately realistic hypothetical.
AURORA is a fungible SPL token issued on Solana by Aurora Labs. Holders can vote on a community treasury and receive fee discounts in a planned creator marketplace. AURORA provides no contractual claim on Aurora Labs’ revenue, profits, equity, or assets.
Aurora Labs proposes to:
- sell 15% of supply before the marketplace is live, using proceeds for development;
- retain 25% for the team and treasury, subject to vesting;
- market globally through a website, X, Discord, influencer campaigns, and a React dApp;
- airdrop tokens to prior devnet users;
- create an initial constant-product AMM pool;
- retain control of the mint authority initially, then transfer key authorities to a multisig.
That is enough to create regulatory questions. The following facts would materially change the analysis:
| Fact to establish | Why it matters |
|---|---|
| Who issues the token and where it is incorporated, managed, and staffed | Determines potentially relevant issuer, tax, AML, and licensing perimeters. |
| Token holder rights | Profit, redemption, yield, repayment, ownership, and governance rights each point toward different classifications. |
| Sale mechanics and use of proceeds | A pre-functional sale funding future development is more sensitive than distribution of a working tool. |
| Official communications | A roadmap, whitepaper, website, Discord announcement, influencer brief, and UI copy can all create expectations. |
| Targeting and access | Country targeting, language, paid ads, geo-blocking, KYC, and acceptance of local payment methods affect jurisdictional exposure. |
| Intermediated services | Custody, exchange, brokerage, launchpad operation, token swaps, and advice can trigger obligations independently of the token. |
| Technical authority design | Mint, freeze, metadata, upgrade, and treasury authorities affect both disclosure and consumer-protection risk. |
A useful engineering analogy is a frontend user journey: the underlying program may be unchanged, but the way a user is invited, onboarded, shown a “Buy” button, or promised a future benefit materially changes the system’s outcome. Here, that communication layer can also change the regulatory analysis.
The US: separate the token from the offering
The most important US distinction is between:
- the crypto asset itself, and
- the contract, transaction, or scheme through which it is offered or sold.
The SEC’s 2026 interpretive release is particularly helpful for issue-spotting because it categorizes crypto assets while emphasizing that a non-security crypto asset can still be sold through an investment contract.
[PDF] Application of the Federal Securities Laws to Certain Types of ...
Read the SEC release to understand why token functionality alone is not enough. Its framework is useful for classifying AURORA’s features and, separately, examining the sale and promotional campaign.
In Section III, read the discussion beginning the five categories. Focus on the distinction between a digital commodity, collectible, tool, stablecoin, and digital security. Then move to Section IV.A, “How Crypto Assets Become Subject to an Investment Contract.” Read from the investment contract analysis. Note the emphasis on the issuer’s representations, timing, official communication channels, milestones, funding, and promised managerial efforts.
For AURORA, a fee discount and access to a functioning marketplace might support a digital-tool-like characterization. Governance voting may be compatible with a functional network or application. But those features do not end the inquiry.
The risk increases sharply if Aurora Labs sells tokens before the marketplace exists while official materials say, in substance:
- “Buy now before the platform launches.”
- “The team will build the marketplace and drive adoption.”
- “Token scarcity and our partnerships will increase the price.”
- “Funds from this sale will finance the roadmap.”
- “Early participants will benefit from our future work.”
Those statements can create an expectation that purchasers will profit from Aurora Labs’ essential managerial efforts. Under the SEC framework, it is the combined transaction and representations, rather than merely the token’s ticker or technical standard, that matter.
A carefully designed airdrop is not automatically risk-free. The SEC release addresses certain airdrops of non-security crypto assets where recipients provide no money, goods, services, or other consideration in exchange. For AURORA, a retroactive devnet-user airdrop is less problematic than an announced campaign requiring users to post promotional content, recruit others, or buy another token to qualify. The latter may involve consideration and also creates marketing and consumer-protection issues.
US securities analysis is not the only perimeter. The matrix should also flag:
- CFTC concerns, especially if tokens are commodities and the project offers derivatives, leveraged products, or trading-related services.
- FinCEN and state money-transmission analysis where the project or an affiliate accepts and transmits value, exchanges tokens, or operates custodial flows.
- OFAC sanctions controls for blocked persons, prohibited jurisdictions, and sanctioned wallet exposure.
- State-level rules, which may differ materially; New York is commonly treated as a separate high-priority review.
- FTC and state consumer-protection law, including misleading marketing, undisclosed influencer compensation, and deceptive claims.
The practical lesson: a token may avoid one classification while the launch process, marketing campaign, or surrounding service still creates obligations.
US issue-spotting matrix for AURORA
| Issue | AURORA trigger | Preliminary risk | Evidence and action |
|---|---|---|---|
| Securities / investment-contract analysis | Pre-functional token sale funds a roadmap; team retains meaningful authority and allocation. | High if purchasers are led to expect value growth from Aurora Labs’ future work. | Freeze and archive every official claim. Obtain US counsel’s analysis of rights, sale terms, use of proceeds, purchaser restrictions, and communications. |
| Token rights and tokenomics | Governance rights, fee discount, vesting, treasury allocation, possible future yield proposals. | Medium to high; profit rights, revenue sharing, fixed returns, or redemption promises would raise risk substantially. | Publish a rights schedule: what holders receive, do not receive, and what can be changed. Prohibit unreviewed additions such as buyback or yield language. |
| Airdrop | Distribution to prior devnet users. | Medium; lower where genuinely retroactive and without consideration, but facts matter. | Record eligibility criteria and announcement timing. Do not require promotion, referrals, purchases, or tasks as the exchange for tokens without review. |
| AMM and liquidity | Team creates pool, provides liquidity, and may control liquidity-position tokens. | Medium; users may infer liquidity support, price support, or exit assurances. | Disclose liquidity ownership, lock terms, withdrawal authority, and market-making arrangements. Avoid “guaranteed liquidity” or price-stability claims. |
| Sanctions / financial-crime controls | Global dApp, token claims, sale proceeds, possible wallet interactions. | High operational priority. | Implement a sanctions-risk policy, wallet-screening decision, escalation process, record retention, and controls for restricted locations. |
| Influencer and social marketing | Paid campaigns, referral mechanics, public roadmap. | High if claims are misleading or compensation is undisclosed. | Use approved copy, disclosure requirements, monitoring, takedown procedures, and an auditable campaign archive. |
| Intermediated services | Aurora Labs or an affiliate might custody user assets, run exchange functions, or facilitate fiat conversion. | High if present; this is separate from issuer analysis. | Diagram every asset flow and private-key holder. Obtain specific licensing analysis before launching such services. |
The UK: promotions are a product requirement, not an afterthought
The UK’s financial-promotion regime matters whenever promotions are communicated to UK consumers, even if the issuer is organized elsewhere. In practice, a public website, social campaign, launch announcement, or dApp flow that is directed at UK users can be relevant.
The FCA treats qualifying cryptoassets as Restricted Mass Market Investments for financial-promotion purposes. In broad terms, a fungible and transferable cryptoasset will often fall within this concept unless an exclusion applies. The regime focuses heavily on how retail consumers are invited to invest.
[PDF] PS23/6: Financial promotion rules for cryptoassets
Read the FCA policy statement as a design specification for a UK-facing token-sale and dApp journey. It explains why a compliant launch cannot treat warnings, onboarding, and purchase flows as merely legal footer text.
In Chapter 2, read the FCA rationale for treating cryptoassets as high-risk investments. Pay attention to volatility, firm failure, fund comingling, cyber-attacks, and financial crime. Then, in Chapter 3, read the “Cooling-off period” discussion beginning the distinction between information and a direct offer. Follow the surrounding text on risk warnings, the ban on incentives, onboarding, investor categorisation, and appropriateness assessments.
For an AURORA launch, the key distinction is between a page that gives neutral technical information and a direct offer financial promotion that supplies a way for the consumer to act, such as a “Buy AURORA” button, transaction form, or a route to invest.
A UK-facing promotion needs a lawful route. Depending on the facts, this may involve communication by an appropriately authorized firm, approval by an authorized person, or a relevant exemption. The FCA policy statement describes the narrow route available to certain FCA-registered cryptoasset businesses communicating their own promotions. It does not mean that any offshore token issuer can publish UK-targeted sales promotions freely.
At a practical level, a UK retail journey must be designed for regulatory friction rather than conversion optimization alone. Relevant requirements can include:
- prominent prescribed risk warnings and a tailored risk summary;
- a ban on incentives to invest, such as “free bonus tokens,” time-limited giveaways tied to purchase, or referral rewards;
- a personalized risk-warning step;
- investor categorization and an appropriateness assessment;
- a cooling-off period for first-time investors before certain direct offer promotions;
- records demonstrating the process and the basis for any tailored risk content.
This is where frontend implementation directly intersects with compliance. A UK-targeting decision affects route guards, the visibility of purchase controls, consent records, content management, analytics, and the state machine for a transaction journey.
UK issue-spotting matrix for AURORA
| Issue | AURORA trigger | Preliminary risk | Evidence and action |
|---|---|---|---|
| Qualifying cryptoasset / promotion scope | Fungible, transferable SPL token promoted to UK consumers. | High unless counsel confirms an exclusion or a different regulated classification. | Identify every UK-facing communication: website, dApp, X post, Discord, video, influencer, email, and launchpad listing. |
| Lawful route for promotions | Aurora Labs is offshore and intends to promote a public sale. | High if it has no lawful route to communicate promotions. | Decide whether to exclude UK users or engage the required authorized / registered counterparties. Document the decision before publishing launch content. |
| Direct offer promotion | “Buy,” “Swap,” “Claim,” or wallet-connected purchase flow on the UK-facing site. | High because consumer-journey rules may apply. | Build a separate UK flow or prevent access. Preserve user-event logs for warnings, categorization, appropriateness, and consents. |
| Incentives | Referral bonus, early-buyer allocation, “buy before listing,” or extra-token reward. | High; non-intrinsic purchase incentives are particularly sensitive. | Remove incentives from UK promotions unless specifically approved. Distinguish the token’s core utility from a promotional inducement. |
| Risk disclosure | Volatile token, team-controlled authorities, AMM liquidity, technical and smart-contract risks. | High operational priority. | Maintain a UK-specific risk-summary content model; include realistic risks rather than generic disclaimers. |
| AML registration / wider UK regime | A UK entity exchanges, custodies, or otherwise conducts regulated cryptoasset activities. | High if services are provided from or into the UK. | Map operational roles and obtain UK regulatory advice. Confirm the current status of the evolving wider UK cryptoasset regime before go-live. |
| Consumer-protection and advertising | Influencer campaigns and claims about utility, liquidity, or future development. | Medium to high. | Require substantiation, influencer disclosures, approval workflow, version history, and rapid removal capability. |
The FCA policy statement is from 2023 and must be treated as a foundation, not as a complete 2026 launch checklist. Before mainnet, confirm the then-current FCA Handbook, legislation, and implementation status of the wider UK cryptoasset regime.
The EU: MiCA classification, whitepaper, and service perimeter
For EU issue-spotting, begin with the Markets in Crypto-Assets Regulation (MiCA). It establishes a harmonized regime across EU Member States, but it does not make every token launch legally identical.
AURORA’s likely starting point is an “other crypto-asset”, potentially a utility token, if it gives access to a service and does not qualify as a financial instrument or another excluded asset. But this is a conclusion to be tested, not assumed.
The first EU classification questions are:
- Is AURORA a financial instrument, deposit, fund, insurance product, or another product outside MiCA’s scope?
- Is it an e-money token that purports to maintain stable value against one official currency?
- Is it an asset-referenced token seeking stable value by reference to several assets, rights, or a combination?
- If none of those applies, is it another crypto-asset, perhaps a utility token?
For AURORA as described, the major risk is not stablecoin regulation but whether the design or marketing crosses into financial-instrument territory, and whether an EU offer to the public or admission to trading triggers MiCA obligations. Issuers of “other crypto-assets” may need, subject to facts and exemptions, a legal entity, a compliant crypto-asset whitepaper, notifications, publication arrangements, fair and clear marketing communications, and processes for complaints and conflicts.
A whitepaper is not merely a technical document. For a Solana token, it should align with what the chain can actually demonstrate:
- total and circulating supply;
- allocation and vesting;
- mint, freeze, metadata-update, and upgrade authorities;
- treasury controls;
- token functionality and limitations;
- technical and smart-contract risks;
- liquidity and trading risks;
- environmental disclosures where applicable;
- issuer identity and responsibility.
MiCA also creates a separate crypto-asset service provider perimeter. Operating a trading platform, custody, exchange, execution, placement, transfer services, advice, or portfolio management can require authorization. A public AMM is not automatically outside this analysis merely because it uses smart contracts; the relevant question is who operates, controls, promotes, administers, or intermediates the service. “Decentralized” is not a magic label.
EU anti-money-laundering obligations, sanctions controls, data protection, and the crypto-asset transfer “travel rule” should also be assessed where a business qualifies as a service provider or transfers are performed through its systems.
EU issue-spotting matrix for AURORA
| Issue | AURORA trigger | Preliminary risk | Evidence and action |
|---|---|---|---|
| MiCA / financial-instrument boundary | Transferable token, governance rights, sale, secondary trading, possible future economic rights. | High classification priority. | Obtain legal classification in the Member States targeted. Maintain a rights matrix that expressly excludes profit, repayment, and ownership claims if that reflects the product. |
| Public offer or admission to trading | Website sale, launchpad listing, EU marketing, AMM or centralized venue listing. | High if EU residents are targeted. | Determine whether a MiCA whitepaper, notification, publication, or an exemption is available. Do not describe a document as regulator-approved unless it actually is. |
| Marketing communications | Paid ads, X posts, influencer content, translated pages, token-price discussion. | High operational priority. | Ensure promotions are fair, clear, and not misleading, and remain consistent with the whitepaper and token reality. Archive localized versions. |
| CASP services | Custody, exchange, token purchase facilitation, order handling, platform operation, advice. | High if Aurora Labs provides any of these. | Create a role map for every entity and smart-contract admin. Analyze authorization, passporting, outsourcing, and AML obligations. |
| Stable-value features | Any future peg, redemption commitment, reserve narrative, or “stable yield” design. | Very high if introduced. | Treat this as a fresh product review; do not add such features through marketing or governance without specialist review. |
| AML, sanctions, and transfers | Fiat on-ramp, hosted wallets, custody, transfers arranged for users, or service-provider activity. | High operational priority. | Establish customer, sanctions, transaction-monitoring, reporting, and Travel Rule analysis where applicable. |
| Privacy and consumer law | Wallet analytics, tracking, profiling, targeted ads, community data. | Medium to high. | Conduct GDPR and consumer-law review, publish appropriate notices, minimize data, and define retention and deletion controls. |
The UAE: identify the regulator before assessing the token
“UAE” is not one uniform licensing answer. A launch plan must identify the relevant emirate and financial free zone before it chooses a regulatory path.
The high-level map is:
| Location or activity | Regulatory issue to identify |
|---|---|
| Dubai outside the Dubai International Financial Centre | Dubai’s Virtual Assets Regulatory Authority, commonly called VARA, is a central consideration for virtual-asset activity. |
| Abu Dhabi Global Market | The Financial Services Regulatory Authority of ADGM has its own digital-asset framework. |
| Dubai International Financial Centre | The Dubai Financial Services Authority regulates financial services in the DIFC under its own regime. |
| UAE federal / other emirates | The Securities and Commodities Authority and other federal or local rules may be relevant, depending on the activity and location. |
Therefore, “we have a UAE entity” or “we block Dubai IP addresses” is not an adequate conclusion. The team must determine where it is operating, where clients are solicited, which entity performs each activity, and whether the token is treated as a virtual asset, a security-like product, or another regulated financial product under the applicable local regime.
For AURORA, the principal UAE questions are likely to be:
- Does issuing, promoting, selling, arranging, or operating a venue for AURORA require a permit or authorization in the relevant jurisdiction?
- Is Aurora Labs marketing to UAE retail users through Arabic-language material, UAE events, local influencers, or local payment methods?
- Does the project’s AMM, custody, or wallet-connected interface amount to a regulated virtual-asset activity?
- Do any token rights resemble a security, collective investment, derivative, or other financial product?
- Who is responsible for AML, sanctions screening, suspicious-activity reporting, and customer due diligence?
A UAE review should also consider marketing and consumer-facing communications. A technically decentralized swap contract does not necessarily remove risk when a known team actively manages the frontend, liquidity, promotional campaign, upgrades, or user support.
UAE issue-spotting matrix for AURORA
| Issue | AURORA trigger | Preliminary risk | Evidence and action |
|---|---|---|---|
| Correct jurisdiction | UAE users may be targeted, but launch team has not identified whether activity relates to Dubai, DIFC, ADGM, or another emirate. | Very high; choosing the wrong perimeter invalidates the rest of the review. | Maintain an entity-and-activity map: location, personnel, servers, marketing, customers, wallet custody, and contracting party. |
| Virtual-asset issuance and promotion | Token sale, launch campaign, UAE community events, localized web pages, local influencers. | High. | Obtain UAE counsel’s view on issuer, marketing, and offering permissions before outreach or sale. Treat Arabic and English campaigns alike in approval controls. |
| Exchange, brokerage, custody, or AMM operations | Aurora Labs controls the frontend, liquidity, fees, routing, or user assets. | High if present. | Map which party performs each activity and holds which keys. Analyze VARA, ADGM, DIFC, and federal implications before launch. |
| Token classification | Governance and fee-discount token; future proposals could add buybacks, rewards, or redemption. | Medium to high, depending on rights and promotion. | Use a controlled token-rights specification. Require legal approval for any governance proposal that changes holder economics. |
| AML / counter-terrorist financing / sanctions | Global sale, token claims, fiat links, hosted-wallet or transfer services. | High operational priority. | Implement a jurisdiction-specific AML and sanctions framework where required; define screening, escalation, reporting, training, and audit records. |
| Market conduct and disclosures | Team-held allocation, vesting, liquidity control, market-making, public statements. | High reputational and compliance risk. | Disclose allocations, related parties, liquidity arrangements, authority controls, and conflicts. Maintain an insider-information and trading policy. |
One consolidated issue-spotting matrix
The following is the format to use in a real launch repository. It is intentionally designed to be maintained like an engineering risk register rather than written once as a legal memo.
| Topic | US | UK | EU | UAE | Launch decision |
|---|---|---|---|---|---|
| Token classification | Assess asset and offering under federal securities laws; avoid relying on label alone. | Determine whether it is a qualifying cryptoasset or a different regulated product. | Assess MiCA category and whether it is instead a financial instrument or stablecoin-type token. | Assess virtual-asset and possible security / financial-product treatment in the specific UAE jurisdiction. | Obtain written multi-jurisdiction classification advice before public sale. |
| Pre-functional sale | Highest securities risk if proceeds fund promised development and purchasers expect profit from team efforts. | Likely promotional and direct-offer issues for UK retail users. | May trigger MiCA offer-to-public obligations. | May trigger issuance, offering, or promotion permissions. | Prefer a functional-product launch or narrowly controlled distribution only after legal review. |
| Airdrop | Free, retroactive distribution differs from a task-for-token campaign; still review the facts. | May still be a financial promotion if used to induce later purchase. | Check MiCA disclosure and marketing implications. | Check promotional and AML implications in the relevant zone. | Document eligibility, timing, consideration, claims, and excluded jurisdictions. |
| AMM and liquidity | Examine trading, intermediary, market-manipulation, and disclosure risks. | Avoid presenting liquidity as an investment inducement; assess service role. | Analyze CASP role and MiCA trading / service implications. | Analyze exchange or platform-like activity and local permissions. | Disclose liquidity ownership, LP lock or withdrawal terms, market makers, and related parties. |
| Marketing | Securities, consumer-protection, influencer-disclosure, and anti-fraud concerns. | Stringent financial-promotion rules for UK retail consumers. | Communications must align with whitepaper and be fair, clear, and not misleading. | Promotional content can be regulated and must be reviewed by the relevant local perimeter. | Use approved copy, jurisdiction rules, content versioning, and campaign archives. |
| AML and sanctions | FinCEN, OFAC, state-law and activity-specific review. | MLR and sanctions implications, especially for relevant cryptoasset businesses. | AML, sanctions, and Travel Rule analysis for service-provider activity. | UAE AML / CTF and sanctions review, particularly for licensed or in-scope virtual-asset activity. | Decide which flows require KYC, wallet screening, monitoring, blocking, escalation, and recordkeeping. |
| Technical authority | Hidden powers undermine disclosures and may intensify reliance concerns. | Authority risk belongs in the risk summary and consumer disclosures. | Authority, supply, conflicts, and technical risks belong in the whitepaper and operational controls. | Governance and market-conduct disclosures remain relevant. | Publish authority plan; use multisig, timelocks where appropriate, and verifiable on-chain evidence. |
The last column matters most. An issue matrix should never end at “legal risk: medium.” It must produce a decision:
- Proceed with a defined control.
- Proceed only in selected jurisdictions with access controls.
- Change the design, claims, or distribution method.
- Obtain authorization or an approved partner.
- Do not launch until the issue is resolved.
Translate legal questions into Solana and dApp controls
Regulation cannot be solved purely by program code, but architecture can make compliance claims credible or expose them as misleading.
For AURORA, the technical evidence package should include:
| Product claim | On-chain or application evidence |
|---|---|
| “Fixed total supply” | Verified mint configuration and a documented plan to revoke or control mint authority. |
| “Team tokens are vested” | Vesting accounts or a verifiable vesting program, public allocation addresses, and an explanation of unlock conditions. |
| “No hidden freeze control” | Clear disclosure of freeze authority status; if retained, explain who controls it and under what conditions it can be used. |
| “Community governance controls the treasury” | Governance configuration, quorum and voting rules, treasury addresses, upgrade authority, and any emergency powers. |
| “Liquidity is locked” | LP-token ownership, lock contract details, lock duration, withdrawal authority, and circumstances permitting changes. |
| “UK users cannot access an unapproved purchase flow” | Jurisdiction-aware frontend routing, country controls, content separation, audit logs, and operational processes—not IP blocking alone. |
| “We do not target sanctioned users” | Written policy, vendor / tooling decisions, alert handling, escalation, and evidence of enforcement where legally required. |
This is one reason to keep legal, product, and engineering work in the same launch workspace. A whitepaper claiming immutable supply is weak if the mint authority is still held by a single hot wallet. A user-interface disclosure is weak if the liquidity provider can silently remove liquidity. And geo-blocking is weak if paid promotions explicitly target the supposedly excluded market.
A practical workflow for maintaining the matrix
Before a devnet simulation becomes a mainnet launch plan, use this sequence:
-
Freeze the current fact pattern. Record token rights, entity structure, distribution, allocation, vesting, authority controls, liquidity design, services, and target audience.
-
Create a communications inventory. Include whitepaper drafts, landing pages, UI labels, tutorials, FAQs, Discord messages, press releases, influencer briefs, and founder posts. Treat all official channels as controlled release artifacts.
-
Classify both token and activity. Do not stop after classifying the SPL token. Separately classify issuance, sale, airdrop, liquidity provision, custody, exchange, advice, and advertising.
-
Apply jurisdiction triggers. For each region, identify resident targeting, active solicitation, local entity activity, local staff, local events, localized language, payment rails, and available services.
-
Assign owners and evidence. Legal owns conclusions; product owns approved claims; engineering owns technical controls; operations owns AML and sanctions processes; marketing owns campaign governance.
-
Set a change-control rule. Any proposal to add yield, buybacks, revenue sharing, price-support language, new token rights, or a new country must reopen the matrix. A governance vote does not eliminate the need for a regulatory review.
Key takeaways
A defensible token-launch matrix begins with facts rather than labels. For AURORA, the central concern is not simply whether the token has “utility,” but whether the pre-functional sale, promises of future development, and promotional design cause purchasers to rely on Aurora Labs’ efforts.
Across the four perimeters:
- US: distinguish the crypto asset from the offering and promotional scheme; assess securities, services, sanctions, and state-law exposure.
- UK: treat financial-promotion compliance as a required part of the retail user journey, particularly where a direct route to purchase is offered.
- EU: assess MiCA classification, whitepaper and marketing obligations, and whether any party provides regulated crypto-asset services.
- UAE: identify the relevant emirate or financial free zone first; there is no single generic UAE answer.
The next lesson converts this issue matrix into a pre-mainnet compliance checklist covering disclosures, promotions, KYC/AML and sanctions, geographic restrictions, market integrity, records, tax considerations, and professional-adviser sign-off.
Can't find a good explanation? Sign up and we'll make it for you
Sign up