The DevCo: Understanding the development company in Web3 project structures

There are those who want their economic life to exist entirely on-chain - a brave new(ish) world of smart contracts, wallets, and free capital flows, one that circumvents the corrupt hierarchies of the old order. It's an intriguing thought, but one sadly unlikely to interest your landlord, wifi provider, or bank. As a web3 concept evolves from idea to reality, founders quickly realise that they need some sort of ‘real’ legal entity in order to interact with the off-chain economy. For this, you need a DevCo — short for development company.

The DevCo is an important component of a Web3 project's legal structure. It’s where core contributors are hired, contracts are signed, salaries are paid, and intellectual property (IP) is developed. And unlike a protocol or DAO, which typically find legal form offshore in places like the Cayman Islands or Switzerland, the DevCo is a for-profit operating company that often exists on-shore, and with tax and regulatory obligations to match.

In this post, we’ll explain:

• What a DevCo is
• How it differs from the other vehicles in a Web3 structure
• What functions it performs
• How to choose the right jurisdiction for your DevCo
• What legal and tax criteria founders should use when deciding

What Is a DevCo?

The DevCo is the core operating company of a Web3 project. It is typically responsible for:

• Hiring and paying contributors
• Owning or developing intellectual property (IP)
• Providing services to a foundation, DAO or protocol (the latter two sometimes as represented by a foundation)
• Participating in fundraising rounds (e.g., equity or SAFEs)
• Holding shares for founders and early employees

Although many projects present themselves as decentralised, early-stage development is rarely so. In practice, a single team will typically build the MVP, write the smart contracts, design the token model, and orchestrate the launch — often under the umbrella of a single legal entity. That’s your DevCo.

How the DevCo Fits into a Web3 Structure

A typical Web3 project might involve several entities:

• A foundation or association: Often non-profit, set up offshore (e.g. Cayman, Switzerland, Panama) to steward governance, act as a token treasury, and shield other entities from regulatory liability
• A DevCo: For-profit company incorporated in a jurisdiction like the UK, Singapore, or the U.S., which contracts with the foundation or association to build and maintain the protocol. Alternatively, if the project has no foundation layer, it simply gets on with building on its own account.
• A token issuance vehicle: Separate from the devco and potential foundation, especially where regulatory separation of concerns is needed.
• SPVs or IP Holding Companies: Used in more complex structures to isolate risk or protect IP.

In this constellation, the DevCo is the engineering and ops hub. It doesn’t (usually) issue tokens itself — but it may be compensated in tokens by the foundation or the token issuance vehcile, or retain rights to future governance allocations via contributor vesting plans.

Core functions of a DevCo

Let’s unpack what the DevCo typically does:

1. Product and protocol development

• Employs software engineers and designers
• Manages the GitHub repo and codebase
• Leads upgrades, bug fixes, and audits

2. Business operations

• Handles marketing, legal, admin, and HR
• Runs day-to-day operations of the core team
• Enters into service contracts (e.g., with exchanges, vendors, and the governance entity of the project)

3. Intellectual property development

• Creates and owns proprietary software, trademarks, and documentation
• May license IP to the foundation or DAO under clear terms

4. Fundraising

• Raises equity capital (via SAFEs or equity rounds)
• May convert tokens to cash for runway (with clear tax treatment)

5. Commercial activities

• Provides services to the foundation or other entities (for example, development services for milestones)
• May monetise parts of the product (e.g., SaaS dashboards, APIs, or private versions of the protocol)

Why not just use the foundation?

Foundations (and associations) are typically non-profit and limited purpose. In most jurisdictions, they are:

• Not allowed to distribute profits to insiders
• Limited in their commercial activities
• Subject to special reporting and governance obligations

This makes them poor vehicles for:

• Employing founders or contributors directly
• Issuing equity or SAFEs
• Operating a for-profit product or spinout

In addition, foundations are often used to shield DevCos from regulatory and fiscal liability. This means that they need to be separate entities from the devco. If a devco directly profit from token issuance, for instance, this can create tax issues. 

Instead, the foundation often grants tokens or funds to the DevCo in exchange for services — a relationship that needs clear legal agreements and careful transfer pricing.

Where should you set up your DevCo?

There are a range of criteria that founders should think through in deciding where to base their DevCo, bearing upon talent, investment, tax, and simple preferences. 

1. Talent access and local hiring

Ask:

• Where is your core team located?
• Where will you want to hire staff and contractors?
• Will you need to sponsor visas?
• Do local laws support flexible work arrangements?

Each of these will have an impact. To pick a British example - if all your team are based in the UK and you will mainly have UK based clients, it may be best simply to have an English company for your project.

For more distributed teams and projects, jurisdictions like Estonia, Malta, and the Isle of Man are popular for their liberal labour laws and support for remote or cross-border teams.

2. Taxes: corporate tax, withholding tax, and relationship to the rest of your structure

While offshore tax havens sound attractive, most founders want to:

• Pay reasonable tax where they live
• Avoid double taxation
• Access tax treaties to avoid withholding on payments

Singapore, Ireland, and Malta are often favoured for their moderate tax rates and strong treaty networks.

If you are in a position where you can pick any jurisdiction - and remember, sometimes it really can be better just to have the DevCo where you already live - you may want to consider avoiding jurisdictions with:

• High corporate tax and strict transfer pricing (unless you must be there for talent or regulatory reasons): the more tax you pay, the more it will affect your bottom line
• Limited double treaty networks (you’ll pay withholding tax on royalties and dividends). If a jurisdiction does not have a double tax treaty (DTA) with another country, and you conduct activities in both places, your entity may be taxed in each place. Where they are in place DTAs mean that only one tax bill is taken.

3. Regulatory reputation and legal certainty

You want a jurisdiction where:

• Investors are comfortable wiring funds
• Banks will open accounts
• The jurisdiction has a good international reputation
• The legal system is clear and reliable

While Panama or the Marshall Islands certainly have their uses, they are not ideal for an operating company. Reputational issues mean investors may be reluctant to invest in companies based in these jurisdictions;  at the same time, counterparties and banks may automatically see what you do as high risk, and limit their services to you. The U.S. (primarily Delaware), UK, Singapore, and Malta tend to win here.

 4. IP Ownership and tax treatment

If your DevCo will develop valuable IP (such as software protocols, trademarks, or proprietary algorithms), you should consider:

• Where that IP is domiciled
• What taxes apply on licensing or sale
• Whether R&D credits or deductions are available

All of this has an impact on the kind of investment you will get, the kind of taxes you may receive, and the kind of support you can expect from government programs. 

Ireland, UK, Malta, and Singapore all offer IP-friendly tax regimes, sometimes including innovation boxes or IP incentives.

5. Fundraising Infrastructure

If you plan to raise capital through:

• Incubators like Y Combinator, or U.S. VCs
• Token sales via SAFEs
• Simple equity rounds

You may want to use Delaware C-Corp or British Virgin Islands holding structures. These are widely understood and supported by lawyers and investors.

5. Cost

Some jurisdictions are more expensive than others. Cost can creep into company administration in a few different ways - incorporation fees, government fees, mandatory local directors, audit, accounting, not to mention the varying staff costs between the jurisdictions. Economic substance requirements also generate costs; the more staff and premises you need locally, the more money you will need to spend. 

Singapore, for instance, is comparatively expensive, as you are required to have local directors. Delaware is very cheap indeed - but the project is then within the regulatory ambit of the USA, which may not be what you want. In Malta, it is mandatory to have an annual audit, meaning costs can be higher than elsewhere.

Popular DevCo Jurisdictions: A Quick Comparison

Final thoughts: The devco is where the real work happens

In the decentralised world of Web3, it’s easy to assume that everything can be done through DAOs and anonymous wallets. But at the end of the day, someone needs to write the code, pay the salaries, sign the deals, and talk to investors. That someone is usually the DevCo.

A well-structured DevCo:

• Enables real-world legal and economic activity
• Bridges the decentralised and traditional financial worlds
• Supports token launches, fundraising, and hiring

Getting the structure — and the jurisdiction — right is one of the most important strategic decisions you’ll make as a founder.

Plan ahead. Get tax and legal advice. And build something that’s not just decentralised — but sustainable. DAO SPV is on hand to assit you with any enquiries.