Is Your dApp Really Decentralised? Who Bears Legal Responsibility in a Web3 Product?

Take a fictional lending protocol, LendLoop. Its smart contracts run on a public blockchain. A foundation holds the treasury. A separate development company writes the code and runs the website. A 3-of-5 multisig can upgrade the contracts and three of the five signers work for the development company. The homepage says: "Fully decentralised. Nobody can touch your funds."

One night an attacker finds a bug. The team uses the multisig to pause lending within the hour. Users are relieved. Then a regulator and a user's lawyer ask the same question. Who was able to do that, and why does the homepage say nobody can?

That gap is the subject of this article.

The short answer is this. A decentralised architecture does not decide who is legally responsible. Responsibility follows real control, what the product actually does, and the law that applies. Depending on the facts, that can point to a company, a group of people, and several actors at once or, for some functions, nobody identifiable. No label answers the question in advance.

So Product Counsel maps control first and reaches conclusions second. This article shows how that works, what evidence matters and where founders most often get caught. It draws on EU, UK, US and Indian materials and names the jurisdiction each time.

Does decentralised technology mean decentralised responsibility?

No. Technology and liability answer different questions. Technology asks whether one party can rewrite the ledger or stop transactions. Law asks who designed, promoted, profited from, operated or could change the product, and what duties follow.

A product can sit on a public blockchain with thousands of independent validators and still have a company running the interface, a team holding upgrade keys and a treasury paying the developers. The ledger is distributed. The control may not be.

The Danish Financial Supervisory Authority makes this point in its principles for assessing decentralisation. It separates distribution from decentralisation and notes that one entity can run many nodes and still control all of them.

There is no universal rule. Two products with identical code can land in different places because their teams behave differently. Facts come first.

Who are the actors in a Web3 product, and what should counsel ask about each?

List everyone who touches the product, and then gather evidence for each. Assumptions do not count.

People and entities. For the foundation or development company, ask where it is incorporated, who owns it, who it employs and what it signs. For founders and core developers, ask whether they are employees, contractors or token-holding contributors, and whether they hold signing authority. For the marketing and community team, ask who speaks for the project and in which channels.

Technical control. For the contract deployer, ask which address deployed the code, who controls that address now, and whether the code is verified and audited. For admin and multisig key holders, ask how many signers there are, what the threshold is and who employs them. For validators, oracles and infrastructure providers, ask whether they can change outcomes or only relay data and process transactions under fixed rules.

Money and rights. For treasury controllers, ask who can move funds and what approvals apply. For the token issuer or distributor, ask which entity sold or airdropped tokens and on what terms. For governance participants, ask who holds voting power and how concentrated it is.

Keep a short record for each actor: role, evidence, jurisdiction. Contracts, on-chain addresses, org charts and signing logs are all useful evidence. Gaps matter too. If nobody can say who holds a key, that is a finding.

Does running the front end create legal responsibility?

It can matter a great deal. It rarely settles the question alone.

Most users never call a contract directly. They arrive through a website or app that handles branding, wallet connection, onboarding, fee display, disclosures, geoblocking, analytics and support. Whoever runs that layer makes real choices. It can block certain countries or screen wallet addresses against sanctions lists. The contracts usually cannot.

Hosting an interface on decentralised storage does not remove the question. Domain names, app-store listings and the team behind them usually remain identifiable.

Regulators have noticed. The Danish FSA's principles say that offering an interface as a service implies a third party controls the software, and that interface providers may fall under MiCA even when the service behind the interface is decentralised. In its worked example, a company running an interface to a decentralised exchange needed authorisation for activities it controlled, such as receiving and transmitting or executing orders. It was not treated as the operator of the trading platform, because it did not control the exchange contracts. Operating a front end does not, by itself, establish that a regulated crypto-asset service is being provided. The conclusion depends on the operator’s actual activities, control and role in delivering the service.

That is one national regulator's view of one EU regulation. It does not bind other authorities. It is still a useful method. Ask what each actor actually does. The same product can be a service the team provides at the front end and an open protocol underneath, and each layer gets its own analysis.

Smart contracts, upgrade keys and emergency powers: who holds the controls?

Start with the contracts. Some are deployed once and cannot be changed. Many can. A common pattern uses a proxy contract that users interact with. The proxy forwards calls to a separate logic contract. An admin can point the proxy at a new logic contract. That is an upgrade, and whoever holds the admin key holds the power.

Other powers sit in functions rather than upgrades. A pause switch can halt deposits or withdrawals. Parameter controls can change fees, collateral rules or oracle sources. Some contracts include blocklists or recovery functions that freeze or move assets. Each is a reasonable security tool. Each also shows that someone can act. The ability to pause deposits, withdrawals or other protocol functions does not necessarily confer authority to transfer or seize user assets; each administrative permission must be assessed separately.

A multisig changes the picture without removing it. It needs a set number of signatures from a set of keys, say three of five. That reduces single-key risk. But if three signers work for one company, the arrangement may operate as company control with extra steps. Timelocks, which delay changes so users can exit first, are another fact. So are signer independence, key storage and whether signing decisions are documented.

Back to LendLoop. The pause worked because the team held power. That is good security practice. It also means "nobody can touch your funds" needs checking against what the contracts allow.

The Danish FSA applies similar logic. Contracts with built-in editing access are less decentralised as control over them grows, and fee payments hard-coded to particular addresses may link a contract to identifiable people.

These facts feed into security duties, user disclosures and contracts with auditors and vendors. Immutability does not remove legal remedies either. Courts and regulators deal with people and entities, not bytecode.

Our article on contractual considerations in AI and blockchain systems covers how smart contracts sit alongside ordinary contract law.

Why do treasury, fees and economic control matter?

Follow the money. It often shows how a product really operates.

Ask who receives protocol or platform fees, and whether they go to a contract, a multisig, a foundation or a company. Ask who controls treasury assets and under what approvals. Ask who pays contributors, funds audits and marketing, and bears losses. Ask whether any party has fee rights written into the contracts.

Economic flows are evidence, not verdicts. Receiving fees does not automatically make anyone liable. But a business that earns revenue from an interface, sets the roadmap and pays the developers looks different from strangers who merely hold governance tokens. A fee map tests whether the "decentralised" story matches the commercial reality.

Governance is not immunity: what does calling a project a DAO change?

Less than founders hope. A DAO generally describes a model of decentralised governance rather than a single, universally recognised legal form. Its legal status depends on the jurisdiction, whether it operates through a recognised legal entity or statutory structure, and the relationships between its participants.

Practice varies. Some DAOs use token voting with delegation to a handful of large delegates. Some hold an off-chain signalling vote, then have a multisig carry out the result. Others use governor contracts that execute approved proposals after a timelock. In the multisig model, people carry out the outcome, which matters when asking who acts.

Courts and law reformers are still working out how unwrapped DAOs are treated. In the US, a federal court in California refused to dismiss claims in Sarcuni v bZx DAO (March 2023). It found a general partnership plausibly alleged among governance token holders. That was a pleading-stage ruling under California law. In CFTC v Ooki DAO, another federal court in California entered default judgment in June 2023, treating the DAO as an unincorporated association that could be sued. The DAO did not appear, and the CFTC said it was not seeking judgment against individual members.

In England and Wales, the Law Commission's July 2024 scoping paper concluded that no DAO-specific legal entity is needed for now. Commentary on the paper notes that a DAO with no legal structure may be characterised as a partnership, an unincorporated association, and a set of contracts or a trust, depending on the facts. Wyoming has a DAO-specific statute.

None of this makes token holders automatically partners or personally liable. These are findings under particular laws on particular facts. Counsel assesses the wrapper or entity structure, decision rights, contributor roles and jurisdiction together.

How do token issuers, foundations and development companies fit together?

Many projects use several entities. A foundation may hold the treasury and issue tokens. A development company may write software, employ staff, own IP and sign vendor contracts. A third entity may run the website and talk to users. That is common and not a problem in itself. Trouble starts when nobody has mapped who does what.

Counsel asks which entity issues or distributes tokens, and to whom. Which one employs contributors? Which owns the code and trademarks, and on what licences? Which signs with auditors and cloud providers? Which communicates with users, and in whose name? Where each entity sits changes the applicable law. The right structure depends on the facts, and this article does not recommend a jurisdiction or a model.

For the Indian position on digital assets, see cryptocurrency as property under Indian law.

Who is the GDPR controller in a dApp?

Privacy is where "nobody is in charge" fails fastest. On 7 July 2026 the EDPB adopted the final version of its Guidelines 02/2025 on processing personal data through blockchain technologies, following consultation on a draft adopted in April 2025. Guidelines are not legislation, but they show how data protection authorities are likely to read the GDPR.

Three points matter for product teams.

First, roles must be assessed when the processing is designed. The EDPB says a multiplicity of actors and decentralised governance cannot justify non-compliance. Each processing activity needs a factual assessment of the governance model, technical features and relationships between actors. A controller is whoever decides the purposes and means of processing, alone or with others.

Second, personal data reaches further than many teams expect. Public keys and wallet addresses can be personal data where individuals can be identified by means reasonably likely to be used. So can data around the chain, such as IP addresses captured by a dApp or wallet, analytics events and off-chain databases. Encrypting or hashing data does not take it outside the GDPR. The EDPB's general position is that personal data should not be stored on-chain in plain form, and that additional personal data belongs off-chain, because erasure and rectification are hard on an append only ledger.

Third, nodes are judged case by case. The EDPB says nodes with limited decision-making power might not be controllers, while in permissionless networks some may be controllers or joint controllers if they exert decisive influence. A team deciding what its website, analytics and onboarding flows collect looks far more like a controller than a validator does.

Before deployment, teams should assess whether blockchain processing is necessary, what personal data may be recorded on-chain, which blockchain architecture is appropriate and what safeguards are available. Where the proposed processing is likely to result in a high risk to individuals’ rights and freedoms, that assessment should inform a formal DPIA under Article 35 GDPR. The Guidelines add that running a smart contract can, in some cases, amount to automated decision-making under Article 22.

Indian users raise the same factual question. The Digital Personal Data Protection Act, 2023 uses "data fiduciary" for the party that decides purpose and means. The DPDP Rules were notified in November 2025, and most operative obligations begin around May 2027. Our explainer on the DPDP Rules and the 18-month roadmap covers the timeline.

Can terms of use cure a mismatch with reality?

No. Terms should describe the product as it is.

A clause saying "we do not control the protocol" is hard to defend if the team holds upgrade keys, can pause contracts and runs the interface. The issue is not drafting style. The statement does not match the architecture, and it can be tested against evidence in a dispute or consumer complaint.

Better terms say what the team does and does not control. They disclose the main technical risks: contract bugs, oracle failure, upgrade and pause powers, irreversible transactions and lost keys. They set out user responsibilities. They allocate risk with care, because limitation and exclusion clauses face local rules that vary by jurisdiction and by whether the user is a consumer. Most of all, they match what the contracts really do. For the basics, see our guide on why websites and businesses need terms and conditions.

What happens when "decentralised" appears in your marketing?

Public claims should be accurate and supportable. Compare what the website, white paper, documentation and governance forum say with the real admin powers and economic control. Where they diverge, treat it as a consistency and regulatory-risk question. It is not an accusation.

It matters for two reasons. Consumer and advertising rules in many places look at whether statements are accurate. And in regulated sectors, "decentralised" can be a legal position and not a slogan.

Take MiCA, which has applied in full since 30 December 2024. Recital 22 says crypto-asset services provided in a fully decentralised manner without any intermediary should fall outside the Regulation. It also says the Regulation covers services controlled directly or indirectly by persons, even where part of the activity is decentralised. "Fully decentralised" is not defined. The Danish FSA warns that wrongly treating a service as fully decentralised may amount to providing unlawful services, and that it assesses the position when the service becomes available to the public. A plan to decentralise later does not change that. Again, this is one authority's view. Check the regulator in each market you serve.

A practical control-and-responsibility matrix

Use a table like this one to turn the actor map into a working document. The entries show typical questions. Your own facts will fill the cells differently.

Read the table across, not down. Start with the rows where user funds are involved, then work outward.

What should founders review before calling a product "decentralised"?

Work through this list before the claim goes live, and again before each major release.

1. An architecture diagram showing contracts, front end, off-chain services and every admin permission
2. An entity chart with owners, roles and jurisdictions
3. A key and control register covering each key, signer, threshold, timelock and emergency power
4. A treasury and fee map
5. Token and governance rights, including how concentrated voting power is
6. IP ownership and licences for code, brand and documentation
7. A data map covering on-chain identifiers, analytics, RPC providers and off-chain databases
8. User terms and risk disclosures checked against actual behaviour
9. Marketing, white paper and documentation statements checked against the control register
10. Incident powers and a response plan
11. A jurisdiction matrix of where users, entities and contributors sit
12. Escalation points for local counsel where a regulated activity may be involved

If the review exposes a gap, fix the product or fix the claim. Either is better than leaving the gap for a regulator to find.

Frequently asked questions

1)     Does decentralisation mean nobody is legally responsible?

No blanket conclusion is safe. Responsibility depends on who the actors are, what control they have, what activity is involved and which law governs. Some functions may be run by identifiable parties and others by none.

2)     Can a DAO be sued or incur legal obligations?

It depends on jurisdiction and structure. A DAO using a recognised legal wrapper is analysed under the law of that wrapper. For unwrapped DAOs, one US federal court treated Ooki DAO as an unincorporated association, and English commentary notes several possible characterisations. Neither result is a global rule.

3)     Does using a multisig make a product decentralised?

No. A multisig is one technical and governance fact. It does not make a legal entity, and it is not a regulatory exemption. Who the signers are, and who they answer to, matters more than the mechanism.

4)     Can developers be responsible for smart-contract problems?

Possibly, but there is no universal answer. The analysis turns on contractual duties, representations made, level of control, negligence or tort principles and any statutory or regulatory regime. Each depends on the facts and the jurisdiction.

5)     Who is the GDPR controller in a dApp?

Whoever determines the purposes and means of a given processing activity, alone or jointly. That is assessed activity by activity. A distributed ledger does not mean there is no controller.

When to get legal review

Legal review is most useful before a Web3 product’s governance, control architecture and public representations are finalised, and again when material functionality or administrative powers change. The appropriate analysis depends on the product’s architecture, actual control arrangements, users and jurisdictions. Regulated activities may require advice from appropriately qualified local counsel.

Author

Gaurav Saxena is the Founding Partner of SolvLegal Law Offices LLP, with over 14 years of experience advising startups, technology companies, and global businesses on commercial, technology, intellectual property, and regulatory matters. He focuses on delivering practical, business-oriented legal solutions for companies operating in fast-evolving digital and cross-border environments.

Disclaimer

This article is intended solely for general informational and educational purposes. It does not constitute legal, tax or financial advice, advertising or solicitation. How legal responsibility is allocated in a Web3 product depends on the product’s architecture, the control different actors hold, the services offered, the entities involved, the users and the jurisdictions concerned. Regulatory timelines, guidance and case law discussed here, including the application of MiCA, the EDPB’s Guidelines 02/2025 and the commencement of India’s DPDP obligations, may change. Decisions from one jurisdiction, such as the US cases mentioned, do not set a rule elsewhere. The position should be verified against current primary sources before any product launch or reliance on this article. This article reflects the position as at 16 October 2026. Regulated activities in the EU, UK, US, India or other markets may require advice from qualified local counsel. Independent professional advice should be obtained before making decisions about a product’s structure, governance or public claims.