Entity Structuring for Crypto Projects

Multi-entity structures have become standard for sophisticated crypto projects. Rather than centralizing all functions in a single company, successful projects separate governance, development, and fundraising into distinct entities with defined relationships. This reduces regulatory risk, demonstrates genuine decentralization, and provides operational flexibility.

A typical structure includes: a Foundation providing neutral governance, a DevCo operating company handling development, an optional SPV for token issuance, and sometimes subsidiaries in other jurisdictions for regional operations. Each entity serves a defined purpose; their relationships are formalized through service agreements and IP licensing.

Multi-entity structures are not required. Simpler projects can succeed with a single entity. However, as projects scale and process significant capital or serve regulated jurisdictions, multi-entity structures become valuable. They demonstrate genuine decentralization (not pure profit motive), compartmentalize regulatory risk, and separate governance from operations.

This guide covers the structure, each entity's purpose, IP licensing, fund flows, and whether this approach makes sense for your project. The framework adapts to your circumstances - no single required structure, but the principles are consistent across successful implementations.

Multi-entity structures serve several critical functions. First, they support the legal argument that token holders lack profit expectations derived from management efforts - the core issue in US securities law. When a neutral Foundation provides governance and a DevCo builds technology through service contracts, it's easier to argue that token value derives from utility rather than management performance.

Second, they demonstrate decentralization. A Foundation owning treasury assets and making governance decisions creates visible separation from any individual's profit motive. This matters particularly for DAO tokens and community-governed projects.

Third, they enable jurisdictional optimization. A Swiss Foundation provides governance credibility, Singapore DevCo offers tax efficiency, and a US entity handles regulatory monitoring and US market compliance. Each function operates in its optimal jurisdiction without requiring a unified global structure.

Fourth, they compartmentalize risk. If a DevCo faces regulatory enforcement, Foundation assets and governance remain separate. If the Foundation faces governance challenges, DevCo technology operations continue. This separation is valuable during regulatory uncertainty.

Fifth, they enable clean IP ownership and licensing. Technology developed by the DevCo can be licensed to the Foundation or community through clear contracts. This allows evolution while maintaining clear ownership and preventing any single entity from controlling development indefinitely.

The Foundation serves as the project's governance and treasury entity. It holds raised capital, manages strategic direction, and stewards protocol evolution. Foundations are structured as non-profits - either formal legal entities or associations - depending on jurisdiction.

Switzerland's Stiftung is the standard for crypto projects. Swiss foundations are non-profit legal entities existing in perpetuity to advance a specific purpose. Their assets are held for public benefit and cannot be distributed to founders or shareholders. This structure demonstrates lack of profit motive and aligns incentives toward long-term development rather than short-term returns.

Swiss foundations offer flexible governance. You establish a Board of Directors with preferred composition, set governance processes through bylaws, and maintain operational control while remaining non-profit. Foundations file annual reports with cantonal authorities but face minimal regulatory burden beyond that.

Alternatives include Cayman Islands Foundation Companies (similar structure, offshore), US charitable foundations (complex and expensive), and Association structures in various jurisdictions. Each has tradeoffs; Swiss foundations remain most popular for serious projects.

The Foundation: holds treasury assets, makes major governance decisions on protocol evolution, manages grants and ecosystem funding, and maintains compliance with its founding documents and applicable law. It typically contracts with the DevCo for development services, maintaining contractual rights over created IP.

The DevCo builds and maintains protocol technology. It employs engineers and product managers, contracts with service providers, manages community interactions, and handles development work. The DevCo is typically a for-profit entity (LLC, corporation, or equivalent) in a business-friendly jurisdiction.

The DevCo derives revenue from Foundation service contracts, Foundation grants, or ecosystem services (validator operations, infrastructure provision). Critically, the DevCo doesn't receive token fundraising proceeds - the Foundation does and pays the DevCo for services.

DevCos are commonly based in Singapore, Switzerland, or US jurisdictions (Delaware, Wyoming). Singapore offers operational efficiency and favorable tax treatment. Switzerland provides regulatory clarity. US jurisdictions offer American investor familiarity and legal infrastructure access.

The DevCo must maintain clear Foundation separation to avoid appearing profit-driven. Formal service agreements specify: development scope, Foundation-to-DevCo fees, IP ownership (Foundation typically owns all created IP), and termination/transition rights if the relationship ends.

Clear internal governance - separate boards, documented technical decision processes - further demonstrates development is driven by technical merit and community consensus, not DevCo profit maximization.

Some projects create a special purpose vehicle (SPV) solely for token issuance and distribution. This entity mints and distributes tokens, then becomes dormant or dissolves. Creating a separate SPV provides advantages: it isolates the issuance event (with securities law implications) from ongoing operations, it allows future transition of issuance rights if governance evolves, and it demonstrates clear separation between fundraising and operations.

An SPV structure works as follows: The SPV is incorporated in the Foundation's jurisdiction with narrow charter - issue tokens, hold tokens on behalf of buyers during holding periods, and manage distribution mechanics. After initial distribution, the SPV becomes dormant or dissolves. The Foundation and DevCo retain all operational authority.

The SPV structure is optional and adds complexity. Many projects skip it and have the Foundation directly issue tokens. The SPV is most valuable for projects raising significant capital through SAFTs where clear separation between the fundraising event and token utility matters.

When used, clear agreements specify: SPV issuance authority, token distribution mechanics and timing, SPV-Foundation-DevCo interactions, and post-distribution SPV status (wind-down, dissolution, dormancy).

Whether to use an SPV depends on your circumstances. Simple utility token launches to few investors don't benefit from a dedicated SPV. Complex fundraising or substantial capital raises benefit from the added clarity and risk compartmentalization.

In multi-entity structures, the Foundation typically owns intellectual property (code, trademarks, branding). The DevCo accesses IP through formal licenses. This arrangement ensures: the Foundation maintains control over project assets even if the DevCo relationship changes, clear IP title for potential future governance transitions, and demonstration that technology is controlled by the community-governed Foundation, not a for-profit entity.

IP licensing agreements specify: what IP is licensed (code, documentation, trademarks, branding), license scope (exclusive or non-exclusive, sublicensing rights), royalties or fees (usually minimal), and termination rights. If the DevCo relationship ends, the Foundation can license IP to replacement partners, ensuring continuity.

In practice: DevCo develops code or improvements. Under the service agreement, all work is "work made for hire" owned by the Foundation. The Foundation grants the DevCo a non-exclusive license to use this IP in providing development services. If the DevCo is replaced, the new partner receives a similar license.

This prevents any development partner from holding the project hostage. If the original DevCo ceases work, the Foundation owns all developed IP and can engage new developers immediately. For open-source decentralized protocols, IP licensing becomes routine - the Foundation owns the code, opens sources it, and the community develops it.

Trademark licensing similarly restricts DevCo ability to license the project brand to third parties. The Foundation maintains control, ensuring brand integrity and preventing opportunism.

Fund flows between entities must clearly demonstrate genuine separation, not merely formal structure. Proper flows show regulators that entities operate independently and exchange value for services.

Typical structure: capital is raised to the Foundation's treasury, the Foundation budgets development and contracts with the DevCo for services, the DevCo invoices the Foundation monthly for costs plus a management fee, the Foundation pays invoices from its treasury, the DevCo uses funds for team and operating expenses.

This flow demonstrates the DevCo doesn't receive token sale windfalls - it provides services. DevCo profits derive from operational efficiency, not token price speculation. Foundation expenditures are transparent and purposeful, not opaque profit-taking.

Some structures allow the DevCo a small token allocation (team allocation) alongside salary. If so, document it clearly in allocation schedules. However, most sophisticated structures avoid direct DevCo token exposure, keeping incentives tied to operational performance rather than token appreciation.

Multi-jurisdiction structures involve cross-border fund flows. For example: Swiss Foundation, Singapore DevCo, subsidiary operations in other regions. Establish clear intercompany agreements documenting service flows and payments. This enables tax optimization (Singapore DevCo efficiency, Swiss Foundation non-profit status) while maintaining clear separation and demonstrating arm's-length pricing.

Multi-entity structures require jurisdiction selection for each layer. Optimal jurisdictions differ for Foundations, DevCos, and regional subsidiaries.

For Foundations, Switzerland is the standard. Swiss Stiftungen are well-established non-profit entities with clear legal treatment and regulatory recognition. FINMA explicitly recognizes crypto foundations. Switzerland's financial integrity reputation adds credibility. The cost is substantial: 5,000–15,000 CHF initially, 2,000–5,000 CHF annually.

Alternatives: Cayman Islands (lower cost, similar legal clarity, less regulatory recognition), Singapore (increasingly popular, growing crypto frameworks), Mauritius (low cost, reasonable frameworks). These work if cost is critical; Switzerland is optimal if affordable.

For DevCos, Singapore and Switzerland are popular for operational efficiency and tax treatment. Singapore offers excellent infrastructure, sophisticated regulation, and favorable IP-holding tax treatment. Switzerland offers regulatory clarity and similar tax benefits. Delaware and other US jurisdictions are common for US-focused projects. Hong Kong and Asian hubs work for Asia-Pacific focused projects.

When choosing jurisdictions, assess: regulatory clarity (how the jurisdiction treats crypto), tax efficiency (operations and IP licensing tax burden), operational costs (compliance maintenance expense), strategic fit (Switzerland signals seriousness; Singapore signals efficiency; US signals North American focus), and talent access (can you hire locally needed team).

Most sophisticated projects use 2–3 jurisdictions. Geographic diversity demonstrates maturity and international scope while capturing tax and regulatory advantages in each.