The accountability gap is the operational risk.
A distributed ledger can spread verification while upgrade authority, infrastructure, data feeds, applications and emergency decisions remain concentrated elsewhere. BRM maps who can affect an outcome and who must operate the corresponding controls.
Decisions before production
Identify privileged functions, external dependencies and recovery paths, then assign the party that can actually operate each control.
Governance ownerBefore launchTest recovery, emergency, monitoring and rollback assumptions under realistic conditions.
Service ownerRisk-basedPreserve approvals, changes, exceptions and incident decisions as traceable evidence.
Risk ownerContinuous“Decentralised” describes aspects of technical architecture. It is a poor substitute for an accountability model. A protocol can be open and replicated while outcomes still depend on upgrade keys, node operators, cloud services, oracle feeds, front ends, custody arrangements and emergency governance.
The useful question is therefore not “who owns the blockchain?” It is: which party can prevent, detect, contain or recover from this failure, and which party has authority to decide what happens next?
Why responsibility becomes unclear
Protocol authors, validators, infrastructure operators, custodians, wallet providers, application teams, data providers, governance participants and users can all affect one service. Their capabilities are different. A protocol maintainer may correct code but cannot restore a compromised user device. A node operator may restore availability but cannot reverse a valid transaction. An application may warn a user but cannot change consensus.
This is why I start with control capability, not a generic RACI table. Responsibility should be assigned to the party that has the technical and organisational means to operate the relevant control. Legal accountability may follow different rules and must be assessed separately.
The model: five responsibility layers
Accountability is layered — not diluted.
Protocol & code
Rules, privileged functions and release integrity.
→Infrastructure
Availability, identity, key custody and recovery.
→External inputs
Data provenance, freshness and safe failure states.
→Applications
Permissions, transaction safety and integration control.
→Governance & use
Decision rights, risk acceptance and communications.
→How to read the diagram. The five layers separate distinct control surfaces: protocol/code; network/infrastructure; data/external inputs; application/integration; governance/use. A real organisation can occupy several layers and one layer can contain several organisations. Arrows or adjacency should be read as dependency and influence, not as transfer of liability.
What it does not claim. The model does not prove that responsibility is exclusive, that every failure has one legal owner, or that the five layers correspond to MiCA, DORA, NIS2 or ISO clauses. It is an operational mapping device. Shared and residual risks remain possible.
Protocol and code
Correctness, release discipline, privileged functions, upgrade mechanisms, compatibility and vulnerability handling.
Network and infrastructure
Availability, configuration, access, secrets, monitoring, backup, capacity, suppliers and recovery.
Data and external inputs
Integrity, freshness, provenance, transformation and failure handling for facts imported from outside the chain.
Applications and integration
Authentication, permissions, transaction construction, dependency configuration and user-facing safety controls.
Governance and use
Decision rights, approval thresholds, emergency authority, communication, custody choices and business/legal context.
Layer 1: protocol and code
Protocol responsibility includes more than source-code defects. The operating boundary includes upgrade authority, administrator functions, emergency controls, treasury permissions and dependencies that can alter outcomes. Each privileged capability needs an owner, purpose, threshold, protection method, change process and recovery path.
The evidence should follow the change: reviewed code, test results, approvals, release artefacts and a record of the authority used. The appropriate depth depends on impact. BRM does not assert that every protocol requires the same approval structure.
Layer 2: network and infrastructure
Ledger replication does not guarantee operational independence. Several nodes can still share one cloud account, image, region, identity provider or deployment pipeline. The control objective is therefore resilience of the service dependency, not a count of nodes.
For organisations in scope, DORA provides a strong regulatory example of ICT risk management and third-party risk in the EU financial sector. NIS2 provides a broader cybersecurity risk-management baseline for covered entities. ISO/IEC 27001 provides a general ISMS baseline. Applicability must be assessed before any of these are treated as requirements for a particular blockchain project.
Layer 3: data and external inputs
A blockchain can preserve an accepted input without proving that the off-chain fact was correct. Oracle data, identity assertions, prices and attestations therefore need explicit provenance, freshness criteria, validation, fallback behaviour and decision impact.
Failure states matter. “No update” is not automatically equivalent to “the previous value remains safe.” A stale price may be harmless for a dashboard and material for liquidation. Responsibility therefore depends on the use of the data, not only its provider.
Layer 4: applications and integrations
Most users interact through wallets, exchanges, APIs and applications rather than consensus directly. These interfaces construct transactions, select networks and contracts, request permissions and communicate consequences. That makes integration configuration and transaction construction separate control surfaces.
Contract addresses, chain identifiers, RPC endpoints, administrator accounts, SDK versions and feature flags should be treated as controlled configuration where changes can materially affect outcomes. The exact control strength should follow risk.
Layer 5: governance and use
Operational governance is broader than voting. It includes who may propose and approve changes, emergency powers, expiry of exceptional authority, conflicts, communications and records. “The community decides” is not sufficient when an incident requires a time-bounded action by identifiable actors.
Users and organisations also make decisions about custody, transaction approval and fitness for purpose. This is not an argument for shifting all risk to users. The system should make the user-controlled boundary explicit and avoid implying guarantees that the architecture cannot provide.
Regulatory and standards context
MiCA. Regulation (EU) 2023/1114 creates requirements for crypto-asset issuers and crypto-asset service providers within its scope. BRM can help map operational control surfaces, but its layers do not determine MiCA role classification or legal responsibility.
DORA. Regulation (EU) 2022/2554 applies to specified financial entities and addresses ICT risk management, incidents, resilience testing and ICT third-party risk. It is relevant when a blockchain service forms part of an in-scope financial entity's ICT environment.
NIS2. Directive (EU) 2022/2555 requires cybersecurity risk-management measures for covered entities and sectors. National transposition and entity classification matter.
ISO/IEC 27001. The standard provides a risk-based information security management baseline. It can support control design across BRM layers, but certification does not validate the BRM or prove a blockchain system is safe.
A responsibility matrix
Upgrade authority
Map proposal rights, approval threshold, key holders, execution identity, rollback and retained evidence.
Oracle failure
Map source owner, feed operator, freshness rule, decision threshold, fallback and incident evidence.
Signing authority
Map custody owner, authorised signers, transaction policy, review path, recovery and access evidence.
Critical incident
Map service owner, incident authority, technical responders, legal/regulatory consultation and decision record.
Diagram note. These examples illustrate the fields a responsibility record can contain. They are not universal RACI assignments. The accountable party changes with architecture, contract, regulatory role and actual control capability.
Claim boundaries
- Established: distributed systems still depend on identifiable operational controls; applicable law and standards impose governance, resilience or security duties on defined actors.
- Supported synthesis: mapping responsibility by control surface exposes dependencies that a component-only architecture can hide.
- Hypothesis: the five-layer BRM can reduce unowned risks and improve design review across heterogeneous blockchain projects.
- Not claimed: that one party must own every risk, that BRM determines legal liability, that decentralisation is undesirable, or that a BRM mapping demonstrates compliance.
Limitations and falsification
The model is intentionally coarse. Layer boundaries can blur, especially with DAOs, shared sequencers, cross-chain systems, modular protocols and outsourced custody. Legal responsibility may not follow technical control. Some risks are systemic and cannot be mitigated by one project owner. The model has not been validated through a representative empirical study.
BRM should be changed or rejected where another method maps control capability, shared responsibility, evidence and escalation with less overhead. Validation should measure unresolved ownership before and after mapping, incident decision latency, control-test coverage and the number of dependencies with no viable recovery owner.
Evidence notes
- E1: MiCA, Regulation (EU) 2023/1114. Supports regulated actor obligations in the crypto-asset market; does not define BRM layers.
- E2: DORA, Regulation (EU) 2022/2554. Supports ICT risk, resilience and third-party governance for entities in scope; not generally applicable to every blockchain project.
- E3: NIS2, Directive (EU) 2022/2555. Supports cybersecurity risk-management duties for covered entities subject to national transposition.
- E4: ISO/IEC 27001:2022. Supports risk-based information-security management; does not allocate blockchain responsibility.
- Reassessment trigger: regulatory guidance changing actor obligations, architecture patterns that do not fit the five layers, or operational evidence that the model fails to expose material ownership gaps.
Authoritative references
- Regulation (EU) 2023/1114, MiCA
- Regulation (EU) 2022/2554, DORA
- Directive (EU) 2022/2555, NIS2
- ISO/IEC 27001:2022
A practical first pass
- Map the five control surfaces and every privileged or externally dependent function.
- Assign the party that can actually operate each material control, and separately record legal/contractual accountability where known.
- Test the highest-impact recovery and emergency assumptions, then retain the evidence and unresolved gaps.
A 30-day baseline can be useful for a bounded system, but it is a planning heuristic, not a guaranteed implementation duration.