Web3 Token Project Legal Entity Structure: When to Split Dev Co, Foundation and Token Issuer

By Jenga Anderson Web3 & Cross-Border Structuring Team

Most token projects launch as a single company. The ones that scale — and survive regulatory scrutiny — rarely stay that way.

At some point, almost every project that issues a token with real market presence finds itself managing a structural mismatch: the entity that built the protocol is the same entity exposed to token-related litigation, regulatory enforcement, and investor claims. That concentration of risk is both unnecessary and, in most cases, avoidable.

This article explains the three-entity model that has become standard practice among well-structured Web3 projects: the Development Company (Dev Co), the Foundation, and the Token Issuer. We cover when to split them, what each entity does, which jurisdiction fits which role, and what triggers the structural decision in the first place.

1. Why Token Issuance Changes the Risk Profile of a Project

Before a token exists, a Web3 project looks structurally similar to any early-stage technology company: there is a team, some IP, a product roadmap, and investors holding equity. Standard VC structures apply.

Once a token enters the picture, the risk profile shifts across three dimensions simultaneously.

Regulatory exposure becomes multi-jurisdictional

A token can be received, traded, or held by anyone with a crypto wallet, which means the project is immediately subject to the securities and financial services laws of every major market — whether or not the project intended to operate there. A single entity carrying both the development function and the token issuance function is exposed in all of those jurisdictions at once.

Liability surfaces multiply

Token holders may assert claims against the project as issuer. Investors in the protocol company may assert claims related to token economics. Developers may later dispute IP ownership if equity and token compensation were not cleanly separated from the start. A single-entity structure makes all of these claims land in the same place.

Decentralisation narratives require structural backing

Regulators, particularly in the US, UK, and EU, increasingly scrutinise whether a project’s claimed decentralisation is genuine or nominal. A single company issuing and controlling a token is a centralised issuer by any standard. A properly structured Foundation with a defined governance mandate and limited control rights is a materially different regulatory posture.

These three pressures are what drive the move to a multi-entity structure. The structure is not cosmetic. It is functional.

2. The Three Entities and What Each One Does

The three-entity model assigns distinct functions, liability pools, and governance mandates to separate legal vehicles. Here is how each works in practice.

Development Company (Dev Co)

The Dev Co is the commercial engine of the project. It holds the IP, employs the technical team, manages investor equity, and signs contracts with service providers. Dev Co is where venture capital enters the project.

Because Dev Co is a conventional company, it can issue equity, hire employees, enforce contracts, and be held accountable in normal commercial disputes. It does not issue tokens and should not hold significant token reserves on its balance sheet.

Dev Co jurisdiction is typically Singapore or the US, depending on where the founding team is based and where institutional capital is sourced. A Singapore private limited company (Pte. Ltd.) works well when the project has Asian LP exposure or intends to seek MAS regulatory engagement. A Delaware C-Corp is preferred for US-led VC rounds.

Foundation

The Foundation’s mandate is stewardship, not operation. It holds the token reserve, manages the protocol treasury, administers grants to third-party developers, and serves as the governance body for network-level decisions.

Critically, the Foundation is structurally separate from Dev Co. It is not a subsidiary. It does not employ the core development team. It does not owe obligations to Dev Co’s shareholders. This separation is what gives the Foundation its decentralisation claim.

The dominant jurisdiction for Web3 Foundations is the Cayman Islands, using the Foundation Company structure under the Foundation Companies Law (2017 Revision). Cayman Foundation Companies can have no members — meaning no equity holders with economic rights — and are instead governed by a board of directors and a statutory Supervisor whose role is to ensure the Foundation operates within its stated objects.

Cayman Foundation note: Unlike BVI or Singapore foundations, the Cayman Foundation Company Law requires a Supervisor when the Foundation has no members. The Supervisor does not manage day-to-day operations but holds a defined oversight role and can appoint and remove directors in certain circumstances. Founders need to understand this structure before agreeing to it — the Supervisor is a real legal role, not a formality.

Token Issuer

The Token Issuer is the entity that legally issues the token into the market. In most well-structured projects, the Token Issuer is a special-purpose vehicle (SPV) separate from both Dev Co and the Foundation.

The Token Issuer’s purpose is narrow: it manages the technical issuance mechanics, interfaces with exchanges and market makers, and bears the direct regulatory exposure of token sales and distributions. By isolating this function in its own entity, the project limits the blast radius if a token sale is later challenged by a regulator.

Token Issuer jurisdiction depends on where the token is expected to trade and which regulatory regime the project prefers to engage with. Common choices include the Cayman Islands (for US-investor-facing projects seeking securities law distance), Singapore (for projects actively engaging with MAS), and the British Virgin Islands (for simpler structures with limited regulatory engagement).

Entity	Primary Function	Jurisdiction (Common)	Who It Interfaces With
Dev Co	IP ownership, team employment, equity capital	Singapore Pte. Ltd. / US Delaware C-Corp	VC investors, employees, contractors
Foundation	Token reserve, treasury, protocol governance, grants	Cayman Islands Foundation Company	Token holders, ecosystem developers, DAO
Token Issuer	Token issuance, exchange relations, regulatory interface	Cayman Islands SPV / Singapore / BVI	Exchanges, market makers, regulators

3. Three Structural Models: Which One Fits Your Stage

Not every project needs all three entities from day one. The right structure depends on the project’s current stage, token issuance timeline, regulatory posture, and investor composition. Three broad models cover most situations.

Model A: Single Entity (Pre-Token)

A single Dev Co is appropriate when the project has not yet issued a token, has no near-term issuance plan, and is operating purely as a technology development business. All capital is equity, all IP is in one place, and all regulatory exposure is conventional commercial exposure.

This is the starting point for most projects, but it is a temporary state. Building the full three-entity structure before it is needed is unnecessary overhead. Attempting to add entities after token issuance has created regulatory exposure is reactive and more expensive.

Model B: Dev Co + Foundation (Pre-Issuance, Governance Active)

When the project is building toward token issuance — writing the whitepaper, finalising tokenomics, engaging with ecosystem partners — it is time to establish the Foundation. The Foundation can begin operating the treasury, administering early grants, and building the governance framework before the token exists.

This model is appropriate for projects that want to demonstrate genuine decentralisation from an early stage. Regulators and institutional investors increasingly look at the timeline of Foundation establishment relative to token issuance: a Foundation set up the week before a token sale is less credible than one that has been operating independently for six months.

Model C: Full Three-Entity (Post-Issuance or Pre-TGE with Legal Advice)

The full three-entity structure — Dev Co, Foundation, Token Issuer — is appropriate when the project is preparing for a Token Generation Event (TGE), listing on centralised exchanges, or seeking to actively manage multi-jurisdictional regulatory exposure.

Most projects that reach meaningful market cap operate in this structure. The Token Issuer SPV is established specifically for the issuance mechanics and exchange interface. The Foundation continues to hold the treasury and govern the protocol. Dev Co continues to develop the product and hold IP.

Intercompany agreements — IP licences, service agreements, token allocation frameworks — link the three entities. These agreements need to be commercially arms-length and correctly structured to withstand regulatory and tax scrutiny.

4. Singapore-Nexus Projects: MAS and the DPT Licensing Regime

For projects with Singapore-based founders, Singapore-registered entities, or that intend to operate in Singapore’s digital asset market, the Monetary Authority of Singapore’s licensing framework under the Payment Services Act (PSA) is directly relevant.

When MAS licensing is triggered

Under the PSA, a company carrying on the business of providing digital payment token (DPT) services in Singapore is required to hold a licence. DPT services include buying, selling, or facilitating the exchange of digital payment tokens. A Token Issuer or a Dev Co that runs a swap interface, exchange aggregator, or market-making function in Singapore may trigger this requirement.

The licensing classes

MAS offers two main classes under the DPT service framework:

• Standard Payment Institution (SPI): for lower-volume DPT activity, with transaction thresholds
• Major Payment Institution (MPI): for higher-volume DPT activity, with stronger capital and compliance requirements

A Cayman Foundation or a foreign-registered Token Issuer that has no Singapore nexus typically falls outside MAS’s direct jurisdiction. However, if Singapore-based individuals are managing the entity, or if the entity actively markets to Singapore users, MAS may take the view that the activity is conducted in Singapore.

Structuring for regulatory clarity

Projects with Singapore exposure have two options: seek MAS DPT licensing for the relevant entity, or structure the Singapore-nexus entities (Dev Co, Singapore offices, Singapore employees) so that their activities are clearly development and support rather than DPT services. The intercompany agreement framework is critical to making this distinction legible to regulators.

Practical note: MAS’s enforcement posture on unlicensed DPT activity has tightened since 2023. Projects with any Singapore nexus should take regulatory position advice before proceeding with token issuance mechanics. This is not optional due diligence — it is a prerequisite for operating credibly in the Singapore market.

5. Three Decisions That Determine the Structure

In practice, the structural design of a token project is driven by three decisions. Getting clear on these three questions early resolves most of the downstream complexity.

Decision 1: Where is the primary regulatory engagement?

If the project’s primary market and investor base is in the US, the structure typically needs to address US securities law from the outset. This usually means a Cayman Foundation (to maintain distance from US securities jurisdiction) and careful management of whether the token constitutes a security under the Howey test.

If the primary engagement is in Asia — Singapore, Hong Kong, Japan, South Korea — the structure needs to engage with the relevant financial regulators in those markets. Singapore’s PSA, Hong Kong’s VASP regime, and Japan’s JFSA requirements each have different triggering conditions and different licensing pathways.

A project trying to operate across all markets simultaneously needs to map which activities happen in which jurisdiction and ensure the entity that performs those activities holds the relevant licence or falls within an applicable exemption.

Decision 2: What is the governance model for the token and protocol?

If the project genuinely intends to operate as a decentralised protocol over time, the Foundation’s governance structure needs to reflect that. A Foundation that is controlled by the Dev Co’s shareholders through appointment rights is not functionally independent, regardless of what the structure chart shows.

Genuine decentralisation requires that the Foundation has independent directors, a defined mandate that cannot be altered by Dev Co, and a token holder governance mechanism that has real decision-making authority. Projects that want credit for decentralisation — from regulators, from institutional investors, from ecosystem participants — need to build that independence into the legal documents, not just claim it in the whitepaper.

Decision 3: How is the token allocated across entities, team, and community?

Token allocation is a structural decision as much as a financial one. How much of the total supply goes to Dev Co equity holders, how much to the Foundation’s ecosystem reserve, how much to the team vesting pool, and how much to early contributors — these decisions need to be reflected in intercompany agreements before any tokens are issued.

Allocation agreements that are reconstructed after issuance are a common source of disputes, tax exposure, and regulatory questions. The time to document the allocation framework is before the TGE, not after.

6. Common Mistakes and How to Avoid Them

Setting up the Foundation too late

A Foundation established immediately before a TGE has limited credibility as an independent governance body. Regulators and institutional investors look at the operational history of the Foundation — its grant activity, its governance decisions, its independent director track record. Projects that want genuine decentralisation benefit from establishing the Foundation at least 12–18 months before token issuance.

Conflating Foundation independence with Foundation isolation

Foundation independence means the Foundation can operate without instruction from Dev Co. It does not mean the Foundation has no relationship with Dev Co. In practice, Dev Co typically provides protocol development services to the Foundation under a service agreement, and the Foundation licences the protocol IP back to Dev Co for commercial use. These relationships should be documented at commercial arms-length terms, not ignored.

Underestimating intercompany agreement complexity

The three-entity structure is only as clean as the agreements that link the entities. IP licence agreements, service agreements, token allocation frameworks, and treasury management policies each need to be drafted with attention to the tax treatment in each jurisdiction involved. A structure that looks clean on paper but has undocumented or commercially unreasonable intercompany terms will not survive regulatory or tax scrutiny.

Choosing jurisdiction on cost alone

Cayman Foundation Companies are popular partly because they are well-understood by US legal counsel and partly because they have a well-established regulatory environment for crypto structures. But Cayman is not the only option, and for projects with no US investor exposure, it may not be the most cost-efficient or operationally appropriate choice. Singapore VCC structures, Swiss foundations, and UAE-based entities each have different profiles. The jurisdiction choice should follow the regulatory strategy, not the other way around.

Frequently Asked Questions

Do I need all three entities from the start?

No. Most projects start with a single Dev Co and add entities as the project matures. The Foundation should be in place well before the TGE, and the Token Issuer SPV is typically established specifically for the issuance event. The key is to plan the full structure early and build toward it, rather than retrofitting entities after the fact.

Can Dev Co and the Foundation be in the same jurisdiction?

Yes, but it is less common. If Dev Co is a Singapore Pte. Ltd., the Foundation could also be a Singapore entity. However, many projects use a Cayman Foundation for the Foundation layer because of the specific legal features of the Cayman Foundation Companies Law — particularly the ability to have no members — and then use a Singapore or US entity for Dev Co. The choice should reflect the governance and regulatory goals, not just simplicity.

What is the Supervisor role in a Cayman Foundation Company?

Under the Cayman Foundation Companies Law, a Foundation Company that has no members must appoint a Supervisor. The Supervisor’s role is to ensure the Foundation operates within its stated objects and to provide oversight of the directors. The Supervisor has defined powers, including in some cases the ability to appoint or remove directors. Founders should understand the Supervisor’s rights before agreeing to the structure — this is a statutory role with real authority, not a nominal title.

Does a Cayman Foundation Company need to file accounts publicly?

Cayman Foundation Companies have relatively limited public disclosure requirements compared to UK or Singapore entities. However, they are subject to Cayman Islands regulatory requirements, including the requirement to maintain a register of beneficial owners and to comply with anti-money laundering obligations. The privacy profile is significantly better than a UK entity but requires ongoing compliance with Cayman regulatory requirements.

When does a Singapore-based project need a MAS DPT licence?

A Singapore-registered entity or an entity that carries on DPT service business in Singapore needs to be licensed under the Payment Services Act. ‘Carrying on business in Singapore’ includes activities managed or controlled from Singapore, even if the entity is registered offshore. Projects with Singapore-based founders managing token-related activities should take specific advice on whether their activity triggers MAS jurisdiction before proceeding.

Can a VC investor hold equity in Dev Co and also receive token allocation?

Yes, this is common. VC investors in Dev Co may negotiate for equity in the company and a separate token allocation, typically held in a SAFT (Simple Agreement for Future Tokens) or equivalent instrument. The equity and token rights are held separately — equity in Dev Co, token rights in a separate agreement typically with the Foundation or Token Issuer. The tax and securities law treatment of the token allocation varies significantly by jurisdiction.

How long does it take to set up the full three-entity structure?

A single entity (Dev Co) can typically be set up in one to two weeks in Singapore or two to four weeks in Delaware. A Cayman Foundation Company takes four to eight weeks depending on the complexity of the governance documents and Supervisor arrangements. A full three-entity structure, with all intercompany agreements drafted and executed, typically takes three to five months from initial planning to completion. Projects should not begin marketing token sales before the legal structure is in place.

About the Author

Jenga Anderson Global Singapore Web3 & Cross-Border Structuring Team advises token projects, Web3 protocols, and digital asset businesses on entity structure, regulatory positioning, and cross-border compliance. Jenga Anderson holds ACRA CSP, MOM EA, CPA, Certified Tax Adviser, and fund administration qualifications. The parent entity, Anderson Global, operates across 15 offices worldwide with 23 years of practice history. All work is delivered by our in-house team.

Planning a token project and unsure whether your current entity structure fits your regulatory goals? Contact Jenga Anderson for a confidential structure review.

Disclaimer: This article is for general informational purposes only and does not constitute legal, tax, regulatory, or investment advice. The structuring considerations described are general in nature. Specific entity structure, jurisdiction selection, and regulatory compliance must be assessed in light of each project’s particular facts and applicable law. Readers should consult qualified legal and tax advisers before making any structural decisions.

References and Further Reading

• Monetary Authority of Singapore: Payment Services Act — Digital Payment Token Services (mas.gov.sg)
• Cayman Islands Foundation Companies Law (2017 Revision) — Cayman Islands Government
• MAS: Guidelines on Licensing for Payment Service Providers (PSN02)
• Jenga Anderson: “Singapore VCC for Family Offices: Structure, Tax Incentives and Re-Domiciliation Guide”
• Jenga Anderson: “Six Cross-Border Structures for International Business: When to Use Each One”
• Jenga Anderson: “MAS 13O and 13U Approved Fund Scheme: What Changed in 2023 and What It Means for Family Offices”