Guide to Tokenisation through VARA in the UAE

Article Overview

1. Dubai has moved tokenisation from concept to execution: DLD launched a tokenised real estate project in May 2025, and the ecosystem has since expanded to broader tokenisation use-cases.

2. VARA is the core regulator for virtual assets in Dubai (excluding DIFC), and any tokenisation project with a Dubai nexus must be structured around VARA’s rulebooks.

3. Tokenisation is a legal + operational wrapper: it turns asset rights into programmable digital units with enforceable rules on holding, transfer, distributions, and redemptions.

4. Tokenisation through VARA” is a regulated stack, typically involving VA Issuance, a VARA-licensed Broker-Dealer for distribution, and VA Custody where client assets are held or controlled, plus marketing compliance throughout.

5. Token structures vary (equity-like, debt-like, fund interests, asset-backed/reference), and regulatory characterisation depends on substance, not labels.

6. The most common structuring approach is the SPV model, separating the asset-holding SPV, issuer responsibilities, and regulated distribution.

7. Success depends on lifecycle discipline: asset readiness → compliant issuance → ongoing governance/reporting → controlled secondary transfer, with strong disclosure and control design.

8. Fees and prudential requirements are specified: VARA imposes application/supervision fees and paid-up capital thresholds, so budgeting must reflect the full regulated perimeter.

Update: Tokenisation has gone live in Dubai (and regulators are building the rails)

Dubai is no longer “testing” tokenisation as a concept. In May 2025, the Dubai Land Department (DLD) launched the region’s first tokenised real estate investment project through the Prypco Mint platform, under a framework developed with VARA, the Central Bank of the UAE, and the Dubai Future Foundation.Since then, VARA has signalled that tokenisation is not confined to real estate; opening the door to broader, cross-sector tokenisation models; and, in October 2025, VARA and DMCC launched a commodities tokenisation partnership with pilot projects focused on assets such as gold and diamonds. Globally, tokenisation has also moved far beyond property, projects have tokenised everything from fine art and luxury collectibles (including luxury handbags) to high-value assets like yachts, as well as real-economy inventories and production such as coffee plantations and even oil barrels.

It is significant because it shows how regulators are starting to treat tokenisation in practice: tokenised ownership can be designed to link into official registries and recognised record-keeping systems, and tokenisation is increasingly being handled as regulated market infrastructure; with rules around disclosures, investor protection, custody, settlement, and ongoing supervision; rather than as a standalone fintech experiment.

Read more about Tokenisation of Real Estate here.

Why tokenisation, and why VARA?

Tokenisation is best understood as a legal and operational re-packaging of an asset interest into transferable digital units recorded on a distributed ledger. Those units (tokens) can be engineered to represent beneficial ownership, revenue participation, or debt-like claims, and to embed “rules” directly into the asset’s lifecycle- who can hold it, how it can be transferred, when distributions are paid, and what happens on redemption or default. In a well-structured model, tokenisation is therefore not only about fractionalisation; it is about building an issuance and settlement pathway that can support compliant onboarding, allocation, custody, and (where permitted) secondary transfer, using a combination of legal documentation and smart-contract controls.

Dubai positioned itself early by establishing a dedicated regulator for virtual assets: the Virtual Assets Regulatory Authority (VARA). VARA was created under Dubai Law No. (4) of 2022 Regulating Virtual Assets and has jurisdiction across Dubai’s mainland, free zones, and special development zones, excluding the DIFC.

For tokenisation projects with a Dubai nexus, whether the issuer is based in Dubai, the distribution/placement is carried out in or from Dubai, a trading venue is operated in Dubai, or the project is marketed into Dubai, VARA becomes the perimeter you must design around. In practice, this means mapping the project across regulated touchpoints (issuance, brokerage/distribution, custody, exchange/marketplace, and marketing), and ensuring each function sits within the correct permissioning and compliance framework under VARA’s rulebooks. 

What does “tokenisation through VARA” actually mean?

Tokenisation is not treated by VARA as a single standalone permission. In a typical tokenisation project, the “token” is only one component of a wider regulated lifecycle, and VARA will assess who is issuing, who is distributing, who is safeguarding client assets, where (and how) secondary transfers may occur, and how the product is being marketed into Dubai. In practice, a compliant tokenisation model is built as a ‘regulatory stack’, with each function mapped to a VA Activity and delivered by an entity holding the relevant VARA licence (or approval/permission) for that role. 

Under VARA’s regime, tokenisation structures commonly involve a combination of the following licences and permissions:

• VA Broker-Dealer (regulated intermediary for placement/distribution): where tokens are being placed with, sold to, or distributed to investors, a VARA-licensed Broker-Dealer typically serves as the regulated intermediary, handling investor onboarding and order execution, applying conduct-of-business controls, and (where applicable) fulfilling the “licensed distributor” function in the offer structure. 

• Virtual Asset Issuance (Issuer permissioning): the issuer entity creates and offers a Virtual Asset representing defined rights in the underlying asset (for example, beneficial ownership, profit participation, or debt-like claims). The issuer’s disclosure obligations (including whitepaper and risk disclosures, where applicable) and the approval pathway will depend on the issuance category and distribution method.

• VA Custody: if client assets are held, controlled, or safeguarded, whether the tokens themselves or client funds/settlement assets, then a VARA Custody permission becomes central. VARA will expect clear custody terms, robust governance over wallet controls/private keys, segregation and reconciliation controls, and operational resilience arrangements.

On that basis, “tokenisation through VARA” is best understood as designing a legally compliant end-to-end lifecycle- issuance, distribution (often via a Broker-Dealer), sometimes custody as an add-on, and regulated marketing under VARA’s rulebooks, while ensuring that each regulated function is performed by an entity holding the correct VARA licence/permission and the appropriate governance and controls for that role.

What kinds of tokens are typically issued?

In tokenisation projects, the token can be engineered to represent different legal and economic outcomes, depending on how the underlying rights are documented and enforced. Common structures include:

• Equity-like tokens: tokens that represent beneficial interests comparable to shares- often issued by, or linked to, an SPV that holds the underlying asset. These models typically focus on governance rights (where relevant), entitlement to profits/distributions, and a clear investor rights framework tied back to the SPV’s constitutional and offering documents.
  
  
• Debt-like tokens: tokens structured as fixed-income or credit instruments; such as bond-style tokens, revenue participation notes, or other structured payment obligations; where the token holder’s primary right is to receive defined cashflows (coupons, profit shares, or repayment/redemption amounts) rather than ownership of the underlying asset itself.
  
  
• Fund interests: tokens representing units or interests in a pooled vehicle, where investor monies are aggregated and managed according to a defined strategy. These structures are more sensitive from a regulatory standpoint because they raise questions of collective investment features, governance, valuation, and ongoing reporting; so they must be carefully structured and assessed for local permissioning requirements.
  
  
• Asset-backed or reference tokens: tokens designed to track or be backed by a defined asset or basket; either through direct backing mechanisms (with reserves, custody, and redemption terms) or through reference/linked economics. The regulatory analysis here often turns on the robustness of the backing, the enforceability of redemption rights, and the transparency of reserves and valuation.

Across all models, regulatory characterisation is design-dependent. VARA and other regulators will look beyond the label and focus on substance: what rights the token confers, how transfers and restrictions work in practice, whether redemption is promised or discretionary, who the target investors are, and whether the token functions more like a capital markets instrument, a payment/settlement token, or a utility/access token. Small differences in features; such as guaranteed yield language, early redemption rights, or broad retail marketing; can materially change the regulatory perimeter and the approvals or licences required.

What are the benefits of tokenisation?

Tokenisation is often pursued for a combination of commercial and market-infrastructure reasons. When executed within a regulated perimeter, it can reshape both how capital is raised and how assets are administered across their lifecycle. The most common drivers include:

• Fractionalisation: enabling smaller ticket sizes for high-value assets (such as property, commodities, or collectible assets), which can widen the potential investor base and support more flexible capital formation.
  
  
• Liquidity design: creating a structured pathway for secondary transfers, where authorised, so that investors are not locked into traditional illiquidity periods by default, and liquidity can be engineered through compliant venues, transfer rules, and market-making arrangements.
  
  
• Operational efficiency: reducing manual administrative burden by automating parts of the investor journey (onboarding and allocation) and post-issuance administration (corporate actions, distributions, redemptions, and reporting) through smart-contract logic and integrated workflows.
  
  
• Faster settlement and reduced friction: enabling more streamlined settlement processes, potentially reducing reliance on multi-layer intermediary chains and decreasing reconciliation complexity; particularly where custody, transfer restrictions, and settlement finality are designed coherently across the stack.
  
  
• Transparency and auditability: providing verifiable transaction histories and event logs that support stronger audit trails and monitoring; while still requiring deliberate privacy design, access controls, and data protection alignment where sensitive investor information is involved.
  
  
• Programmable compliance: embedding key compliance controls directly into transfer logic- such as whitelisting, eligibility gating, jurisdictional restrictions, lock-ups, and concentration limits; so the asset itself can enforce portions of the regulatory and contractual rule set.
  
  
• Improved investor experience: supporting a more seamless issuance and lifecycle experience; clearer ownership records, easier transfers (where permitted), automated distributions, and more responsive servicing; provided the UX sits on top of compliant onboarding and custody arrangements.
  
  
• Portfolio construction and diversification: enabling investors to build exposure across multiple assets through fractional ownership, which can be particularly relevant where underlying assets are otherwise inaccessible due to minimum investment sizes or operational complexity.
  
  

How do you structure a VARA-ready tokenisation project?

While tokenisation can be structured through a range of legal and operational models depending on the asset class and target investors, one of the most widely adopted approaches, particularly for real-world assets, is the Special Purpose Vehicle (SPV) model, which we outline below.

1) The legal wrapper 

Most regulator-ready tokenisation projects deliberately separate the key functions and entities in the structure, typically including:

• The asset-holding entity (SPV): a special purpose vehicle that legally owns or controls the underlying asset (for example, a property-holding SPV, a commodity-holding SPV, or an SPV holding contractual rights to cashflows).
  
  
• The issuing entity: the entity responsible for issuing the Virtual Asset and making the relevant disclosures, offering documentation, and ongoing statements to token holders (where required).
  
  
• The distribution layer: the regulated interface to investors- most commonly a VARA-licensed Broker-Dealer that conducts onboarding, placement/distribution, order execution, and sales conduct controls in accordance with the applicable permissions.

This separation is not merely cosmetic. It is used to strengthen ring-fencing, clarify governance and decision-making, support investor protection outcomes, improve legal enforceability of token-holder rights, and make the structure more manageable from a regulatory supervision standpoint. 

2) The token design (rights, governance, and transfer logic)

A token is only as credible as the rights and processes it enforces. A regulator-ready design therefore documents, with precision:

• What the token represents: the legal and economic rights conferred (ownership-like interests, participation rights, payment claims), the issuer’s obligations, and the risk profile.
  
  
• Who may hold it: eligibility criteria, investor categories, jurisdictional restrictions, concentration limits, and any constraints that reflect the offering terms and compliance requirements.
  
  
• How transfers occur: the transfer rule set- whitelisting, lock-ups, permitted counterparties, and the conditions under which secondary transfers are allowed (including whether they must occur through an authorised venue or controlled mechanism).
  
  
• How value flows are delivered: the mechanics for distributions and payments; dividends, profit shares, coupons, redemption proceeds; and the governance process for corporate actions.
  
  
• What happens in downside scenarios: default and enforcement outcomes, wind-down provisions, dispute handling, and the practical steps token holders can rely on if things go wrong.

What must token issuers keep in mind about VARA’s issuance regime?

VARA’s Virtual Asset Issuance Rulebook applies where an entity issues a Virtual Asset “in the course of a business”, a threshold VARA assesses on the facts and context of the issuance. In practical terms, if the token is being issued as part of a structured investment proposition (rather than a purely technical proof-of-concept), the project should be designed on the basis that VARA’s issuance perimeter is likely to apply. 

Key issuer-facing expectations include:

Whitepaper and risk disclosure (the disclosure baseline)

VARA’s issuance framework generally requires issuers, subject to category and any applicable exemptions, to publish:

• a Whitepaper containing prescribed disclosures; and
• a Risk Disclosure Statement, with limited exceptions for certain exempt issuances. 

The underlying principle is that investors should receive decision-grade information, not promotional messaging. A tokenomics deck or website narrative may explain the concept, but VARA’s disclosure approach is closer to a structured investment disclosure: it focuses on what the token represents, how it operates, what rights and constraints attach to it, and what risks a reasonable investor must understand before participating.

What is the lifecycle of a tokenisation project?

A tokenisation project is best approached as a full lifecycle- from preparing the underlying asset and its records, through issuance and onboarding, and into ongoing administration and (where permitted) secondary transfer. Each stage has distinct legal, operational, and compliance requirements, and weaknesses early in the lifecycle typically create regulatory and investor-protection issues later.

1) Digitisation (asset readiness, data quality, and registry alignment)

Tokenisation cannot fix weak asset fundamentals. The credibility of the token depends on the quality of the underlying asset records, the valuation methodology, and most importantly the enforceability of the rights that token holders are meant to receive. This stage therefore focuses on “asset readiness”: clean title or ownership evidence, verified contracts, consistent data, and clear mapping between the token and the underlying legal interest.

For example, Dubai’s DLD tokenised real estate initiative is instructive because it demonstrates the direction of market infrastructure: tokenised ownership records were designed to interface with official property registry processes, and the initiative was developed under a coordinated framework involving multiple public bodies and regulatory stakeholders. 

2) Primary issuance (subscription, allocation, and settlement)

A compliant primary issuance is essentially a regulated investment onboarding and settlement process, delivered through a token structure. The workflow usually includes the following components:

• Investor eligibility and onboarding (KYC/AML; sanctions screening): This involves collecting and verifying investor identity (individuals and corporates), identifying beneficial owners, screening against sanctions and adverse media databases, and applying AML risk-based controls. Where the offering is restricted (for example, to professional/qualified investors), onboarding must also include investor classification and eligibility gating, so that only permitted investors can subscribe.
  
  
• Subscription documentation aligned to token rights: Investors should not be subscribing to “a token” in the abstract, they are subscribing to a defined package of legal and economic rights. The subscription terms must clearly describe what the token represents (ownership-like interest, payment claim, participation right), the key restrictions (transfer limits, lock-ups, jurisdictional limits), the return mechanics (profit share, coupon, redemption), fees and expenses, and the principal risks. Importantly, the legal documents and the token’s smart-contract behaviour must be consistent; misalignment here is a common source of disputes.
  
  
• Allocation and issuance logic (smart contracts): The allocation process sets out how tokens are minted and delivered to investors following subscription, whether allocations are immediate, staged, or subject to conditions (minimum raise, closing mechanics, verification of eligibility). Smart contracts can automate issuance, but they must incorporate the project’s control environment (for example, whitelist-based transfers, pause/freeze functionality where appropriate, supply controls, and auditability). This is also where projects define how to handle failed subscriptions, refunds, and exception processing.
  
  
• Custody and settlement arrangements: Settlement is the practical step where value changes hands: investor funds (or permitted settlement assets) are received and tokens are delivered. A compliant structure clarifies who holds client assets, how wallets and private keys are governed, how segregation and reconciliation are performed, and how settlement finality is achieved (including cut-off times, failed settlement processes, and record-keeping). Where third-party custodians or wallet providers are used, outsourcing oversight and operational resilience expectations become central.
  
  
• Disclosure delivery: Disclosures must be delivered in a way that is usable and legally meaningful i.e., investors receive the whitepaper and risk disclosures before they commit capital, and the project can evidence that delivery (acknowledgements, timestamps, controlled document versions). In practice, disclosure delivery is tied into the onboarding and subscription flow so that the investor accepts the relevant terms, understands the key risks, and receives consistent information across materials (whitepaper, subscription agreement, platform screens, and marketing statements).

3) Post-issuance management (governance, servicing, and reporting)

Post-issuance is where tokenisation becomes an ongoing operating model, not a one-time issuance event. Regulators and investors will typically assess whether the project can administer the asset and the token holder relationship in a stable, transparent, and well-governed manner over time. Core post-issuance responsibilities usually include:

• Governance and decision-making: Clear rules for how key decisions are made and documented, such as changes to token terms, appointment or replacement of service providers, asset sales, refinancing, or restructuring events. Where token holders have voting or consent rights, the governance process must be practical (quorum, notice periods, voting mechanics) and aligned with the legal documentation and on-chain features.
  
  
• Investor servicing and communications: A credible servicing framework for handling investor queries, issuing updates, and maintaining consistent communications. This typically includes periodic investor statements, notices of material events, and a structured complaints handling process, particularly important where the investor base is broad or cross-border.
  
  
• Distributions, redemptions, and lifecycle events: If the token carries entitlement to dividends, profit shares, coupons, or redemption proceeds, the project must define how cashflows are calculated, approved, and paid, including timing, fees, deductions, and exception handling. Tokenisation can automate parts of this process, but it still requires robust off-chain controls (accounting, audit trails, approvals, and reconciliation).
  
  
• Ongoing reporting and record-keeping: Maintenance of reliable records covering token holder registers, transfer history, corporate actions, asset performance metrics, and financial reporting. This is also where audit readiness becomes important: the project should be able to evidence decisions, transactions, and disclosures in a way that is consistent and reviewable.
  
  
• Material change management: Tokenisation projects evolve, but changes can create legal and regulatory risk if not managed properly. A good operating model includes a disciplined process for identifying material changes (for example, changes to custody arrangements, redemption terms, valuation methodology, or key risk factors) and ensuring disclosures and investor communications are updated accordingly.
  
  
• Technology governance and incident response: Ongoing oversight of smart contracts, wallet controls, cybersecurity, and third-party technology providers. This includes managing upgrades and patches, controlling privileged access, monitoring for vulnerabilities, and maintaining an incident response plan for events such as key compromise, smart contract bugs, or operational outages.

4) Secondary transfer / trading (the liquidity layer)

Secondary transfer is where tokenisation most visibly resembles regulated market infrastructure. If liquidity is part of the proposition, the project must treat secondary activity as a controlled and rule-governed pathway, not an informal assumption that tokens can circulate freely. From a regulatory and investor-protection perspective, this stage typically requires:

• A defined transfer framework (who can transfer, to whom, and when): Secondary transfers usually need clear eligibility rules; such as permitted investor categories, jurisdictional restrictions, concentration limits, and lock-up periods. In practice, these restrictions are often implemented through whitelisting and permissioned transfer logic, so the token cannot be transferred to ineligible holders.
  
  
• Venue and execution alignment (how trades are matched and settled): If transfers occur through an organised venue or marketplace, the trading model must align with the permitted regulatory approach; particularly around order handling, pricing transparency, fair access, and orderly markets. Even where transfers are bilateral, there must be a credible process for documenting trade terms and achieving settlement finality.
  
  
• Market conduct and conflicts controls: Secondary markets create heightened risks of misleading promotions, price manipulation, insider dealing-type behaviour, and conflicts of interest (for example, where the issuer or affiliates are also active traders, market makers, or liquidity providers). A robust model therefore includes governance around who can trade, how conflicts are managed, and what disclosures apply.
  
  
• Custody, settlement integrity, and reconciliation: Liquidity increases operational complexity: more transfers, more settlement events, and more opportunities for errors. Secondary activity therefore intensifies expectations around safeguarding of client assets, wallet governance, segregation and reconciliation processes, and clear handling of failed or reversed transfers.
  
  
• Monitoring and operational resilience: Where an ecosystem supports active transfers, it must also support monitoring for abnormal activity and operational continuity; covering system uptime, cybersecurity, smart contract risk management, and incident response. This is particularly important because disruptions at the secondary layer directly affect investor confidence and market integrity.

Fees and capital requirements (Broker-Dealer + Token Issuance under VARA)

Tokenisation budgets are often underestimated because VARA treats the project as a regulated stack: the issuer-facing permissions (issuance) and the investor-facing permissions (distribution via a Broker-Dealer) each carry their own fees and prudential expectations. The figures below reflect VARA’s published fee schedule and capital framework.

1) VARA fees (authorisation + ongoing supervision)

Broker-Dealer Services

• Licence application fee:  US$ 27,300 (AED 100,000) (for this VA Activity).
  
  
• Annual supervision fee: US$ 54,500 (AED 200,000) (per year, for this VA Activity).
  
  

Category 1 VA Issuance (Token issuance licence category)

• Licence application fee: US$ 27,300 (AED 100,000) (for this VA Activity).
  
  
• Annual supervision fee: US$ 54,500 (AED 200,000) (per year, for this VA Activity).
  
  

If you apply for more than one VA Activity: VARA applies a Licence Extension Fee for each additional VA Activity within the same application (rather than re-charging the full application fee each time).

Issuance disclosure review fees (whitepaper review): where an issuer seeks VARA review under the VA Issuance Rulebook, VARA has published a whitepaper submission fee of AED 5,000, plus a further fee of up to AED 50,000 for detailed review (maximum AED 55,000 total).

2) Paid-up capital (baseline prudential expectations)

VARA’s capital framework is activity-specific and is designed to ensure the entity can operate on an ongoing basis (including absorbing operational shocks and meeting obligations). VARA also retains discretion to require higher capital depending on size, complexity, and risk profile.

Broker-Dealer Services (paid-up capital)

VARA’s Company Rulebook sets the Broker-Dealer paid-up capital requirement as the higher of a fixed minimum or a percentage of fixed annual overheads, with the minimum depending on the custody model:

• If the Broker-Dealer uses a VARA-licensed custodian (or another arrangement approved during licensing): the higher of approximately US$ 110,000 (AED 400,000) or 15% of fixed annual overheads.
  
  
• In all other instances: the higher of approximately US$ 164,000 (AED 600,000) or 25% of fixed annual overheads.
  
  

Category 1 VA Issuance (paid-up capital)

VARA’s Company Rulebook points Category 1 VA Issuance capital to the VA Issuance Rulebook / annexes, and (for certain issuance types) specifies higher capital mechanics, for example, where issuance involves reserve-asset models. By way of illustration, VARA’s published capital rules for reserve-asset issuance include a baseline US$ 410,000 (AED 1,500,000), plus a variable component linked to reserve asset value in some cases.

Practical note for tokenisation projects

In a typical tokenisation SPV model, Category 1 VA Issuance relates to the issuer’s regulatory posture (and disclosure obligations), while Broker-Dealer Services covers the regulated investor interface (distribution, onboarding, order handling, and execution). Where both activities are in scope, you should budget for both application/supervision fees and ensure each regulated entity meets its own capital requirements.

Frequently asked questions (FAQ)

 

1) Does VARA regulate all of the UAE?

No. VARA’s jurisdiction is Dubai (including free zones and special development zones), but it excludes DIFC. If your project sits inside DIFC, the perimeter is different and you must assess the relevant DIFC regulator framework instead. 

2) If our company is outside Dubai, do we still need to care about VARA?

If you are carrying out regulated VA activities “in or from” Dubai, or marketing into Dubai, VARA can be relevant even if your holding company is elsewhere. VARA’s own guidance is that entities wishing to carry out regulated VA activities/services in or from Dubai must apply for a VASP licence. 

3) Can we tokenise assets that are not located in the UAE?

Often yes in principle, but the compliance work increases. Tokenising a non-UAE asset typically requires stronger work on: (i) enforceability of token-holder rights under the asset’s governing law, (ii) title and security interests, (iii) cross-border investor disclosures, and (iv) clear statements on where disputes will be resolved. VARA will still focus on whether the token issuance/distribution/marketing activity is happening in or from Dubai and whether the relevant VA Activity permissions are in place. 

4) Do we always need a Whitepaper and Risk Disclosure Statement?

Under the VA Issuance Rulebook, issuers must publish both a Whitepaper and a Risk Disclosure Statement, with a limited exception for Exempt VAs. 

5) How “technical” can the risk disclosures be?

VARA’s rulebook is explicit that the Risk Disclosure Statement should be clear, non-technical, and comprehensible for owners of the Virtual Asset. In practice, this means writing for investors and being specific about the material risks (asset, legal, operational, custody, smart contract, liquidity, valuation, conflicts). 

6) Do all token launches require VARA approval before issuance?

Not always. VARA’s issuance framework distinguishes issuance categories and sets different prior requirements depending on classification (including exemptions). The design decision is not only “what token are we issuing?”, but also how it will be distributed and to whom, because this can affect the approvals pathway and role requirements (including use of a Licensed Distributor in certain structures). 

7) Who can legally distribute tokens to investors in a VARA-aligned model?

Where distribution activities fall within regulated VA Activities (for example, arranging/soliciting/accepting orders and facilitating transactions), the distribution layer is typically delivered through a VARA-licensed intermediary, commonly the Broker-Dealer permission depending on the model. 

8) Can anyone market a tokenised offering in Dubai?

No. VARA’s marketing regime applies broadly: all market participants, licensed or not, must adhere to the Marketing Regulations, and businesses are not permitted to offer regulated VA services/activities in Dubai without VARA approval or a confirmation of no objection. This is why influencer posts, “waitlist” pages, and public calls-to-action need careful review.

9) What’s the most common compliance mistake tokenisation teams make?

A frequent misstep is treating tokenisation as “minting plus marketing”, rather than an end-to-end regulated lifecycle. The usual failures are: (i) marketing before the licensing/approval pathway is aligned, (ii) substituting promotional materials for proper disclosure, and (iii) omitting enforceable eligibility and transfer controls in both the legal terms and the token/onboarding design from the outset.

10) Do we need to build the whole stack ourselves?

Not necessarily. Many projects separate roles: an issuer/asset SPV structure, a licensed distribution partner (Broker-Dealer), and regulated custody arrangements where client assets are held or controlled. VARA’s rulebook approach is function-based, so the key is ensuring each function is performed by an appropriately permitted entity with coherent governance and disclosures. 

Case study: Tokenising a high-value painting (fine art)

A typical fine-art tokenisation project can be structured through the SPV model in a clear, sequential way:

First, the sponsor acquires a high-value painting and transfers legal ownership into an asset-holding SPV, supported by verified provenance and authenticity documentation, independent valuation, appropriate insurance, and a professional storage/custody arrangement for the physical artwork.

Second, the project defines the investor right, for example, whether token holders participate pro-rata in net sale proceeds, whether distributions can occur during the holding period, and how fees, expenses, and decision-making are handled, anchoring these terms in the SPV’s constitutional documents and the offering documentation. 

Third, the issuing entity creates a Virtual Asset that represents those defined interests, with transfer restrictions (eligibility gating, whitelisting, lock-ups where relevant) reflected both legally and in token logic. 

Fourth, the offering is distributed through a VARA-licensed Broker-Dealer, which manages KYC/AML onboarding, investor eligibility checks, delivery of the disclosure package (including whitepaper and risk disclosures where applicable), and the subscription/allocation workflow. 

Finally, post-issuance administration is treated as an ongoing operating model: periodic reporting and valuation updates, clear governance for key actions (such as approving a sale of the painting), controlled servicing and investor communications, and a defined pathway for secondary transfers, if permitted, so that any liquidity feature remains consistent with investor eligibility and compliance controls.

Our services

10 Leaves provides turnkey services for tokenization projects. From transactional advisory, to assistance in authorisations, to assistance in preparation of the legal documentation, 10 Leaves helps you consider, evaluate and execute tokenization projects in the UAE.  

Our services include assistance in:

• Reviewing the business model and advice on the applicable regulatory framework;
• Preparation of the detailed Business Plan, tokenomics and comprehensive financial projections;
• Advice on regulatory and compliance aspects of issuing, marketing and distribution of tokenised assets;
• Identification of technology partners, including tokenization platforms, protocol experts and digitization platforms;
• Setting up the associated legal structures including Special Purpose Vehicles and token issuers;
• Ongoing advice on marketing and distribution of tokenised assets, and secondary issuances.

We also assist with corporate and commercial documentation through our legal consultancy - 10 Leaves Legability. We assist in the drafting of:

• Crypto-asset Purchase Agreements.
• Crypto-asset Terms and Conditions.
• Key Features Documents for Security Tokens.
• Private Placement Memorandums for Tokenised Funds.
• STO Prospectuses.
• Simple Agreement for Future Tokens (SAFT).
• Privacy Notices.
• Founder agreements.
• Shareholder agreements.
• Investor agreements.
• Share vesting/ESOP plans.
• Client/Supplier/Distributor agreements.
• Employment agreements.

We also provide services in Luxembourg, Saudi Arabia, India and Mauritius

For More Details about Tokenisation of  Real Estate in the UAE, Contact us here