RL1 Goes Live: Why Shared DLT Infrastructure Is a Governance Challenge, Not Just a Technology Project

Europe is building shared infrastructure for tokenised finance. The real test will be whether governance, responsibilities and operational controls become as interoperable as the technology.

Europe has spent years proving that distributed ledger technology can support digital securities, tokenised assets and new forms of settlement.

The harder question is no longer whether the technology can process a transaction.

It is whether several regulated institutions can rely on the same infrastructure while preserving clear accountability, consistent controls and workable arrangements for decisions, incidents and change.

The launch of Regulated Layer One — RL1 — provides a timely example.

RL1 is not presented as another proprietary blockchain controlled by a single technology provider. It has been established in Luxembourg as a European Cooperative Society owned and governed by financial institutions with equal decision-making rights.

Its stated purpose is to provide neutral, shared DLT infrastructure for tokenised assets, digital money and institutional financial-market use cases.

That cooperative model is important. But common ownership does not automatically create a common operating model.

A shared ledger may reduce technical fragmentation. It does not, by itself, align legal responsibilities, control standards or operational decision-making across the institutions using it.

RL1 is more than another blockchain launch

RL1 commenced operations on 28 July 2026 with ten founding institutions:

• ABN AMRO;

• Cecabank;

• Chartered Investment;

• Crédit Mutuel Alliance Fédérale;

• DekaBank;

• DZ BANK;

• LBBW;

• Natixis CIB;

• SC Ventures;

• Seturion.

  
  

The initiative remains open to additional financial-market participants. NatWest is currently shown as joining soon, while KfW and L-Bank continue to support the initiative without being listed among the ten founding members.

The network is based on SWIAT’s production DLT infrastructure, which has been transferred to the cooperative.

According to RL1, the underlying network had already operated for approximately three years and processed more than 50 transactions with a combined volume exceeding €700 million before the new SCE commenced operations.

That distinction matters.

The transaction history demonstrates prior production use of the underlying infrastructure. It should not be presented as activity generated by the newly established RL1 cooperative after 28 July.

The real significance of the launch lies elsewhere: a shared network has moved into a member-owned governance structure.

The question is therefore not simply:

Can several financial institutions transact on the same ledger?

It is:

Can they govern that ledger as shared institutional infrastructure while preserving clear individual accountability?

The governance problem RL1 is designed to address

Institution-specific DLT platforms may allow firms to innovate quickly, but they can also create isolated technical environments, separate asset pools and incompatible operating rules.

A security issued on one network may not move easily to another. Different platforms may apply different access models, technical standards, identity arrangements and settlement processes. Every additional connection introduces cost, complexity and another operational dependency.

RL1 aims to reduce that fragmentation through a neutral, permissioned infrastructure governed collectively by its members.

Each member institution is described as having an equal voice, with no single institution or small group of node operators intended to exercise excessive control.

This is a credible response to one governance risk: concentration of authority in a single platform owner.

It also creates a different set of questions.

Equal voting rights do not explain:

• which matters require a simple or qualified majority;

• which decisions are reserved for particular governing bodies;

• how conflicts between members are handled;

• how urgent decisions are made during an operational incident;

• what happens when members face different regulatory constraints;

• how technical changes are approved;

• how deadlock is resolved.

  
  

A member-owned model may support neutrality. It still needs detailed rules that turn collective ownership into timely, controlled and accountable decision-making.

What the public governance model already tells us

RL1 currently describes four layers within its governance and operating structure.

General Assembly

All member institutions form the General Assembly, described as the collective sovereign of the network.

Supervisory Board

The Supervisory Board is elected by the members and oversees strategy, governance and compliance.

Management Board

The Management Board is responsible for the network’s day-to-day management.

Technical Operations

SWIAT operates the technical infrastructure on behalf of the cooperative. This gives the public a useful high-level picture. What it does not yet show is how those layers interact when an actual decision must be made.

Consider a protocol upgrade.

A complete operating model would need to establish:

• who may propose the change;

• who assesses its legal, regulatory and operational impact;

• whether validators and application providers participate in the assessment;

• which governing body approves it;

• what testing is required;

• who authorises deployment;

• how members are informed;

• whether emergency changes follow a different process;

• how the decision and supporting evidence are recorded.

  
  

A governance chart shows where authority sits in principle. An operating model shows how that authority is exercised.

Collective ownership and technical operation must work together

The network is owned by the cooperative, while SWIAT remains responsible for technical operations and continues to maintain its separate ecosystem of applications and regulated registry services.

This separation is not unusual. Financial infrastructures often depend on specialist technology providers.

The important issue is how the relationship works in practice.

The cooperative must remain capable of setting requirements, overseeing performance and controlling material decisions. The technical operator must have enough authority to maintain security, reliability and day-to-day service continuity.

That balance must function not only during normal operations, but also when something goes wrong.

For example:

• Who determines that a vulnerability requires immediate action?

• Can SWIAT suspend part of the service without prior member approval?

• Who decides whether transactions should be paused?

• Who communicates with members and regulators?

• Who classifies the incident?

• Who may disconnect a validator?

• Who approves restoration of service?

• Who owns the remediation plan?

  
  

The answers may already exist in RL1’s internal arrangements. They are not currently visible in the public materials reviewed for this article. That is not a criticism of a newly established cooperative. It illustrates why the underlying governance documentation matters more than the organisational diagram alone.

The validator layer creates a separate control challenge

RL1’s website currently lists eight technical operators maintaining the integrity of the underlying network:

• adesso;

• DekaBank;

• GFT Technologies;

• LBBW;

• NTT DATA Deutschland;

• SC Ventures;

• Sopra Steria;

• SWIAT.

  
  

The website also includes an important qualification: these are the current validators of the SWIAT network, and their migration to RL1 is intended.

It would therefore be premature to describe all eight as fully migrated RL1 validators.

More importantly, validators are not simply ordinary service providers.

Depending on the network design, they may influence transaction validation, ledger integrity, network availability, consensus and the point at which a transaction is treated as final.

A complete validator-governance framework would therefore need to address:

• appointment and approval criteria;

• technical and security standards;

• conflicts of interest;

• institutional and geographic concentration;

• performance monitoring;

• quorum and consensus thresholds;

• suspension and removal;

• replacement of an unavailable validator;

• persistent underperformance;

• collusion or coordinated misconduct;

• responsibility for incorrect or delayed validation.

  
  

Distributed validation does not remove the need for accountability.

It changes where that accountability must be defined.

Earlier RL1 design work anticipated a broader rulebook

An RL1 presentation made available through the ECB’s New Technologies for Wholesale Settlement Contact Group in November 2024 described a broader governance framework.

The proposed structure included:

• Network Terms;

• a Code of Conduct;

• Operating Rules;

• validator onboarding and KYC;

• membership and participant procedures;

• technology and standards governance;

• legal and regulatory governance;

• network-management and interoperability arrangements.

  
  

The materials organised the intended model around four themes: access, coordination, operations and accountability.

This is useful because it shows that governance was considered part of the infrastructure design rather than an administrative issue to be addressed after launch.

The document must nevertheless be used carefully.

It reflects an earlier design stage. The current public website does not provide the final Articles of Association, Network Terms, Code of Conduct, Operating Rules or committee mandates.

It is therefore possible to say:

Earlier RL1 design materials contemplated a detailed governance and operating rulebook.

It is not yet possible to say:

RL1’s current Operating Rules require…

without access to the final documents.

Shared infrastructure needs more than network-access rules

RL1 identifies a wide range of potential institutional use cases:

• digital bonds;

• tokenised real-world assets;

• on-chain collateral;

• stablecoins;

• central and commercial bank money;

• digital funds;

• repo and securities lending;

• derivatives margining.

• 
  

These use cases do not create identical risks.

A digital bond, a tokenised fund and a bank-issued stablecoin involve different legal rights, regulated functions, lifecycle events, data requirements and settlement arrangements.

A common technical network therefore needs a controlled process for determining what may be introduced onto it.

That process may need to establish:

• which asset and transaction types are permitted;

• who performs the legal and regulatory assessment;

• whether a use case requires additional licences or regulated participants;

• who approves the application or smart contract;

• which technical and security standards apply;

• how lifecycle events are managed;

• where settlement finality occurs;

• what information participants must retain;

• how an incident affecting one application is isolated from the wider network;

• who may suspend or withdraw a use case.

  
  

The network and application layers cannot be governed independently.

A technically valid transaction may still create a legal or operational problem if the underlying use case has not been properly assessed.

Interoperability is not only a technology question

RL1 presents interoperability as part of its response to market fragmentation.

This is particularly relevant as the Eurosystem advances two complementary initiatives for tokenised wholesale finance.

Pontes is intended to connect market DLT platforms with TARGET Services so that DLT-based wholesale transactions can settle in central bank money.

Appia takes a longer-term view and is examining possible models for an integrated European tokenised financial ecosystem.

As those initiatives develop, private DLT infrastructures will increasingly need to interact with:

• central bank settlement systems;

• other private networks;

• traditional securities infrastructures;

• identity and compliance services;

• cash and asset applications;

• institutions operating across several jurisdictions.

  
  

Technical connectivity is only one part of that interaction.

True interoperability also requires agreement on:

• the legal recognition of asset and transaction records;

• the timing and meaning of settlement finality;

• participant identity and permissioning;

• data standards;

• exception handling;

• incident coordination;

• responsibility when connected systems produce different outcomes;

• change management across dependent infrastructures.

  
  

Two platforms may be capable of exchanging messages while applying different rules to the same event. That is connectivity. It is not necessarily operational interoperability.

Collective infrastructure does not remove individual accountability

Participation in member-owned infrastructure does not transfer a financial institution’s regulatory responsibilities to the cooperative.

Each institution must still understand:

• the activities it performs;

• the risks it assumes;

• the services on which it relies;

• the controls operated by other parties;

• the evidence available to support its own oversight.

  
  

For a bank using RL1, this may require documentation showing:

• which services and applications it uses;

• which regulated role it performs;

• how it assessed the network;

• which controls are operated by RL1, SWIAT, validators and the bank itself;

• how infrastructure changes are monitored;

• how network incidents connect to the bank’s own incident process;

• what information reaches management;

• how continued reliance on the network is reviewed.

  
  

The cooperative may manage common infrastructure risk.

The member institution remains responsible for deciding whether reliance on that infrastructure is appropriate for its own business.

Collective ownership does not replace individual institutional accountability.

DORA adds another layer to the operating model

SWIAT is publicly identified as the technical operator acting on behalf of RL1.

The exact application of DORA to each member’s arrangements will depend on the contractual structure, the services received and whether those services support critical or important functions.

It would therefore be too broad to describe every RL1-related relationship automatically as outsourcing or as a critical ICT arrangement.

DORA nevertheless provides a relevant control framework.

Financial entities are expected to assess ICT providers, define contractual rights, maintain access and audit arrangements, monitor performance, address subcontracting, plan for disruption and maintain credible exit strategies where ICT services support important functions.

In the RL1 model, dependencies may operate through several connected layers:

Financial institution

→ RL1 cooperative

→ SWIAT as technical operator

→ validators and other infrastructure providers

A participant should therefore understand:

• who its contractual counterparty is;

• which entity provides each service;

• who holds operational and security data;

• where audit and access rights may be exercised;

• how incidents move through the chain;

• whether material subcontractors are involved;

• how concentration risk is assessed;

• whether the technical operator could be replaced;

• how the participant could exit without losing access to assets, records or transaction history.

  
  

A contractual right to exit is not the same as an operational ability to exit.

Established FMI principles provide a useful benchmark

Public information does not establish that RL1 is itself a licensed central securities depository, securities settlement system, payment system or formally designated financial market infrastructure.

The Principles for Financial Market Infrastructures should therefore not be presented as automatically applicable to RL1.

They do, however, offer a useful benchmark as shared DLT networks begin supporting more material institutional activity.

The PFMI place emphasis on:

• clear and transparent governance;

• direct lines of responsibility;

• comprehensive risk management;

• objective participation criteria;

• operational resilience;

• management of service-provider dependencies;

• business continuity;

• recovery and orderly wind-down;

• clear rules and procedures;

• controlled changes to those rules.

  
  

The underlying message is important.

As the economic significance of a shared network increases, institutions will expect more than secure technology.

They will also need confidence that the network can:

• make decisions under pressure;

• manage participant or validator failures;

• change its rules without creating uncontrolled risk;

• preserve critical records;

• restore operations;

• coordinate with connected infrastructures;

• continue or wind down services in an orderly manner.

  
  

What is not yet visible publicly

RL1 has disclosed its legal form, founding membership, high-level governance structure, technical operator and intended use cases.

The public sources reviewed for this article do not yet provide detailed information on several areas.

Corporate decision-making

• voting thresholds and quorum;

• reserved matters;

• conflicts of interest;

• deadlock resolution;

• emergency decision-making;

• committee structures.

  
  

Membership and participation

• detailed admission criteria;

• rights of non-member users;

• suspension and exclusion;

• orderly exit;

• continuing obligations after exit;

• treatment of a member that is also a validator.

  
  

Technical governance

• consensus architecture;

• protocol-change approval;

• software-release governance;

• emergency changes;

• testing and assurance;

• validator replacement;

• finality rules;

• network-level security standards.

  
  

Operational resilience

• incident classification;

• escalation timeframes;

• crisis authority;

• communications with participants and authorities;

• recovery objectives;

• continuity testing;

• liability and loss allocation.

  
  

Use-case governance

• asset-admission criteria;

• application and smart-contract approval;

• lifecycle responsibility;

• data-quality controls;

• interoperability standards;

• suspension and withdrawal of applications.

  
  

Some of these rules may already exist and be available only to members.

Their absence from public sources should not be treated as evidence that RL1 lacks them.

It does mean that external observers cannot yet assess how the high-level governance model translates into operational practice.

Questions institutions should ask before relying on shared DLT infrastructure

An institution’s review should not be limited to cybersecurity or technical architecture.

It should connect governance, legal responsibility, operations and evidence.

Governance and decision rights

Which body decides what? Which matters require member approval? How are conflicts and deadlocks resolved? Who has authority during an emergency?

Roles and accountability

What is operated by RL1, SWIAT, validators, application providers and the participant itself? Where do responsibilities overlap? Who remains accountable when several parties contribute to one failure?

Change management

How are protocol and application changes proposed, assessed and approved? What testing is required? How much notice do participants receive? Can a participant object to a material change?

Incident management

Who classifies an incident? Who may pause activity or disconnect a validator? How are members and authorities informed? Who leads remediation and post-incident review?

Participation and exit

What requirements apply to members, validators and other users? How is continued compliance monitored? What happens when a participant no longer meets the requirements? Can data, assets and services be migrated safely?

Legal and operational finality

When does a transaction become irrevocable? Which law governs the relevant records and rights? How are inconsistencies between connected infrastructures resolved? Who bears loss where technical and legal outcomes diverge?

Evidence and assurance

What records are available to participants? Can members exercise access and audit rights? How are validator performance, system changes, incidents and remediation evidenced? What information reaches the participant’s management body?

These questions are not unique to RL1. They apply to any institution considering reliance on shared DLT infrastructure for regulated financial activity.

Lynsora perspective

RL1 represents a meaningful development in Europe’s tokenised-finance landscape.

Its cooperative structure offers a credible alternative to infrastructure controlled by a single institution or technology provider. Equal member rights may support neutrality, broader participation and the development of common standards.

But collective ownership is only the beginning of the governance model.

The success of shared DLT infrastructure will depend on whether the institutions involved can establish one coherent framework for:

• decision-making;

• network and validator oversight;

• asset and application approval;

• change management;

• incident response;

• third-party dependencies;

• continuity and exit;

• legal and operational accountability.

  
  

A shared ledger can place institutions on the same technical infrastructure.

It cannot, by itself, ensure that they apply the same interpretation of responsibility, risk and control.

The real test for shared DLT infrastructure is not only whether institutions can transact on the same ledger. It is whether they can make decisions, manage disruption and demonstrate accountability within one connected operating model.

Official sources

• RL1 — European blockchain initiative “Regulated Layer One” goes live, 28 July 2026.

• RL1 — Network, participants, governance and potential use cases.

• ECB New Technologies for Wholesale Settlement Contact Group — SWIAT & DekaBank presentation on Regulated Layer One, November 2024.

• ECB — Pontes.

• ECB — Appia roadmap.

• Regulation (EU) 2022/2554 — Digital Operational Resilience Act.

• Basel Committee — Prudential treatment of cryptoasset exposures, SCO60.

• CPMI-IOSCO — Principles for Financial Market Infrastructures.

  
  

Disclaimer

This article is provided for general information purposes only and does not constitute legal, regulatory or professional advice.