Look at control, not labels.
Responsibility follows factual control, performed activity, decision authority and economic benefit, not simply the label ‘decentralized’.
Responsibility decisions
Map who can actually modify, stop, authorize or recover each material component.
Architecture / governance ownerBefore launchSeparate technical control from legal accountability and test both against activity and jurisdiction.
GRC / LegalBefore relianceLink responsibility to control evidence and assurance claims.
Control ownerContinuous“Decentralized” is useful when describing some technical architectures. It is a poor answer to the question: who is responsible when something goes wrong?
In blockchain systems, protocol developers, governance participants, validators, infrastructure providers, oracle operators, bridge operators, interface providers, custodians and users may each control different parts of the system. Responsibility rarely follows one clean organisational boundary.
The problem with the word “decentralized”
A DeFi application may run on a decentralized network while identifiable actors still control upgrade keys, frontends, domains, treasury resources, oracle configuration, emergency functions, protocol parameters, repositories or governance proposals.
Calling the whole system decentralized tells us little about who can actually change what. The useful question is: which actor can exercise which control over which component, under which conditions?
Architecture is only the first layer
A responsibility analysis can start with the technical stack: infrastructure, protocol, consensus, interoperability, smart contracts, wallets and applications. But control planes cut across those layers: governance, upgrades, emergency powers, privileged keys, treasury and economic incentives.
Regulation then adds another overlay. Depending on activity and jurisdiction, obligations may relate to authorization, operational resilience, cybersecurity, privacy, custody, market integrity, consumer protection, outsourcing and records. Assurance adds another question: who owns the control, who owns the evidence, and who independently validates it?
Responsibility follows control
Imagine a vulnerability in a smart contract. The developer may understand the defect. Another actor may control the upgrade mechanism. A multisig may control emergency actions. Governance participants may approve a permanent change. An interface operator may warn users or restrict access.
Potentially all of them have responsibilities, but for different things. Useful dimensions include design authority, implementation responsibility, operational control, change authority, emergency authority, key custody, economic benefit, risk ownership, control ownership, evidence ownership and assurance.
A useful unit of analysis
Instead of assigning responsibility to “the blockchain”, I use a more granular unit:
Network profile × component × actor × control right × activity × jurisdiction × lifecycle event
The network profile describes the environment. The component identifies the affected part. The actor identifies who participates. The control right asks what that actor can actually do. Activity focuses on behaviour rather than labels. Jurisdiction determines the legal overlay. Lifecycle event adds time: deployment, normal operation, upgrade, incident, recovery and retirement can create different allocations.
Control rights matter more than titles
An organisation may say it does not operate a protocol while retaining an administrative key. A foundation may call governance community-controlled while maintaining material influence over proposals or treasury resources. A frontend operator may have no control over the underlying protocol but substantial control over how users access it.
Therefore role name ≠ actual authority. For each important component, ask who can modify it, stop it, authorize another party to modify it, control the necessary privileges, and materially benefit from its operation.
Incidents expose hidden responsibility
Normal operation can hide these relationships. Incidents expose them. If direct deletion or unilateral remediation is impossible, that does not mean no one has responsibility.
The analysis shifts to the controls that remain: who controls exposure, interfaces, warnings, future upgrades, coordination and residual-risk acceptance? What evidence demonstrates that available mitigation was actually performed?
Regulation is increasingly activity-based
MiCA, DORA, NIS2, the Cyber Resilience Act, the Data Act and GDPR address different objects, actors and activities. They should not be flattened into one generic “EU blockchain compliance” checklist.
Applicability needs to be tested against facts: what activity is performed, what product or service is involved, who controls it, where the actor is established, who the users are, what data is processed and which lifecycle event is being analysed.
This is where architecture, Legal and GRC need a shared responsibility model. Legal teams need facts about control. Engineering teams need to understand the accountability consequences. GRC needs to connect both to controls and evidence.
Decentralization changes assurance too
Evidence can be distributed between actors. One organisation may hold application-security evidence, another infrastructure evidence, another oracle evidence, while protocol governance provides public records about upgrades. No single actor necessarily owns the complete assurance package.
The useful chain is therefore: responsibility → control → evidence → assurance claim.
If responsibility is unclear, evidence collection becomes unclear. If evidence ownership is unclear, assurance becomes expensive quickly.
What decentralization actually changes
Decentralization can distribute authority, remove traditional control mechanisms, introduce governance dependencies, slow remediation, distribute evidence and make unilateral action impossible. It may also reduce the ability of any single actor to cause harm.
These are real architectural properties. But they do not justify treating decentralization as an accountability exemption.
From responsibility model to control system
The practical objective is not another taxonomy. The model should allow us to move from component → actor → control right → responsibility to responsibility → risk → control → evidence → assurance.
That makes the model useful for architecture reviews, threat modelling, RACI design, regulatory applicability analysis, incident response, dependency risk, control ownership, audit preparation and regulator discussions.
The broader pattern
There is a direct connection with AI governance. In autonomous AI systems, capability is not authority. An agent may technically be capable of an action without being authorized to perform it.
Blockchain systems expose the inverse problem: absence of centralized ownership does not imply absence of authority.
In both cases, governance starts by mapping the real control surface: who can observe, decide, change state, stop an action, delegate, benefit and remain accountable.
Conclusion
“Decentralized” should describe an architecture. It should not end a responsibility analysis.
When ownership, control and operation are distributed, we need a more precise model, not less accountability. The practical test is simple: show me who can actually change the system, who can mitigate harm, who benefits from the activity, and who can provide the evidence.