The smart contract doesn't have a lawyer. It doesn't need one — it's code, it executes exactly as written, and it has never been sued. The people who wrote it, deployed it, and vote on its upgrades are a different story entirely.

That gap is where most dApp founders get it wrong. They treat "decentralized" as a legal status, when it's actually just an architecture choice. The application can be as decentralized as you like; the humans behind it are not, and the law has a default answer for what happens to a group of humans building something together with no entity in sight: general partnership. Joint and several liability. Everyone on the hook for everyone else's mistakes.

In what follows, we look at why an unwrapped dApp is a liability trap, what happened when that trap sprang shut on real projects, and the three-entity structure that fixes it — DevCo, token issuance vehicle, and Foundation — plus where each one should actually live.

A dApp without an entity is a general partnership, whether you meant it to be or not

To many people, a dApp is a Discord server, a GitHub repo, and a protocol doing several hundred thousand dollars — or several hundred million — of onchain volume. When it's a hobby project, that informality costs nothing. When it's a product holding user funds, it costs everything.

Badger, Beanstalk, and bZx collectively lost $357 million to hacks and exploits within 2021 and 2022. bZx alone had $55 million stolen after a phishing attack exposed a developer's private keys. Fourteen users who lost over $1.5 million sued the bZx founders, investors, and affiliated companies personally — not some abstract "protocol," but the people behind it.

The reason that lawsuit could even be filed against individuals is structural: without a company, foundation, or association wrapping it, a dApp's contributors are, in the eyes of most lawmakers, a general partnership. General partnerships have no legal personality of their own — they're not independent from the people running them, which means every partner can be held personally, jointly, and severally liable for the whole partnership's conduct. As one lawyer put it after the bZx suit: those who form DAOs "apparently believe that they can use the word 'decentralized' to evade corporate and individual responsibility. The opposite is true."

Community voting and flat governance don't change this. A democratic process for deciding what the code does is not the same thing as a legal shield for the people who deployed it.

Token classification doesn't get easier just because there's a front-end

A dApp with a native token inherits the same question every fundraise faces: is this token a security? The Howey test asks whether buyers have a reasonable expectation of profit from the managerial efforts of others — and a U.S. District Court's decision that the LBRY token was a security under exactly that test rattled the DeFi space harder than most exchange collapses, because it narrowed the window for compliant token offerings without SEC registration.

Decentralizing quickly is one of the few real defenses here: the more the token's value depends on ongoing efforts by an identifiable team, the more it looks like a security. That's not a reason to fake decentralization — it's a reason to actually distribute governance and treat the "when" of decentralization as a legal question, not just a roadmap milestone.

The fix: three entities, three jobs

Rather than wrapping the whole dApp in a single legal entity — which either straitjackets its governance (companies centralize decision-making by design) or leaves everyone personally exposed (no entity at all) — the structure that holds up is a stack of three purpose-built entities, each doing one job:

DevCo — builds and gets paid, nothing else. Incorporate this early, before a single line of code ships, and own the GitHub organization through it rather than through an individual (the Tornado Cash developer's arrest is the cautionary tale here). Keep it simple: a low-cost LLC or equivalent, ideally wherever the team actually lives, since it needs access to ordinary banking and local hiring. DevCo's running costs are covered by grants from the Foundation below, so it never books a taxable profit — unless you're raising equity directly into it, in which case it becomes a proper C-Corp or local company and revenue lands there instead.

Token issuance vehicle — sells the token, then gets out of the way. This should be a separate, ringfenced entity: no cross-shareholding and no shared board seats with DevCo, and it's never the DAO itself that issues tokens, which would expose token holders directly. The British Virgin Islands is the standard choice for this vehicle — no sales tax if the token sale is treated as a sale of goods, no tax on fundraise proceeds, and a Virtual Asset Service Provider regime that exempts non-security tokens, defined more broadly than in most other jurisdictions. The proceeds and any unsold token balance then typically get pledged to the Foundation.

Foundation — holds the treasury, answers to the DAO, owned by no one. Companies aren't built for decentralized control — someone's fiduciary duty always runs toward "the best interest of the company," which centralizes power by design. A Cayman Islands memberless foundation solves this differently: no named founder, no named beneficiaries (just "whoever holds token X at a given time"), and a Board that can be reduced to a Nominee Director acting under a narrow power of attorney — one that only ever executes what the DAO already voted on. Structured properly, the Director never even holds the private keys; an internally appointed Treasurer does. The DAO controls the Foundation without owning it, which is about as close to "the code is the law, but the law still exists" as current legal tooling gets.

Don't build the FTX stack

The failure mode on the other side is over-engineering. Sam Bankman-Fried's FTX/Alameda entity stack — a sprawling web of interrelated companies across multiple jurisdictions — should have been a red flag to any investor who saw the diagram, and it's a useful gut-check for founders too: unless you're deliberately trying to obscure something, there is no version of "legitimate simplicity" that requires that many entities before you have meaningful revenue. Three entities, clearly separated by function, is the ceiling most dApps need until profits — not just token proceeds — actually materialize.

Document everything, from day one

The weakest point in most early dApps isn't the legal structure — it's the paper trail behind it. Wallets get opened and transactions get made faster than anyone writes down why. That's fine for a weekend hackathon project; it's a liability when the same wallet has been moving six figures for a year with no record of which entity it belongs to or what each transaction was for. Pair every wallet with an entity, and every entity with a reason it holds what it holds.

How Otonomos helps

This is precisely the stack Otonomos sets up for Web3 builders every week: a DevCo where your team actually is, a BVI token issuance vehicle ringfenced from it, and a Cayman memberless foundation with a Nominee Director to hold the whole thing together — controlled by your DAO, owned by no one.

Structure your dApp's entity stack with Otonomos: Book a free call

Sources: Otonomos, "Ten Dos and Don'ts for Web3 Entrepreneurs Deciding If and Where to Incorporate", The Otonomist, Nov 2022; Otonomos, "DAO Safety 101: Legal risks", The Otonomist, Jun 2022.

Disclaimer: No legal, tax, or regulatory advice.