So, I'm Kelly, I'm a fellow at the European decentralization institute, which is an independent
think tank for the decentralized economy.
And this talk is about a layer of digital infrastructure that rarely appears in European
digital policy.
I know that sovereignty, digital sovereignty, is a hot topic today and for a good reason,
that's a good thing, but especially on the EU level, the focus usually stays on things
like cloud, AI, semiconductors, big US tech platforms and software, because these are the
things that institutions already know how to deal with, right?
They fit into existing legal categories and they map clearly onto procurement frameworks.
But what tends to be invisible is the protocol layer that runs beneath everything.
And yet this is the layer that determines how systems communicate, how they remain
inoperative and how they evolve over time.
It's the coordination infrastructure that makes everything else function.
Public institutions increasingly depend on open protocols, sometimes at very large scale,
which we'll see in a minute, while the governance of these protocols remains largely absent
from strategy, procurement and long-term planning.
The dependencies already exist, but the understanding of protocol governance, how the
protocol evolves, often does not.
And this talk is about exactly that blind spot.
But before I continue, let me be very explicit what I will not argue for.
I'm not here, of course, to advocate for regulating protocols.
I'm not here, even, to argue that governments should enter protocol governance in all cases.
The goal is much more basic and much more necessary.
It is to make the protocol layer legible, so that institutions and technical communities
share an understanding of what it means to be dependent on the systems over time.
So I think it's helpful to first start with how European digital policy tends to look at
technology.
First, of course, there is the infrastructure, the chip, status, and the networks, cloud
regions, the underlying hardware and functions that can be owned geographically located
and audited.
Second, of course, something we're very familiar with in Brussels, regulation, the legal
instruments that govern digital infrastructure and services, and most of the aforementioned
infrastructure items they are already regulated through data protection rules, the AI Act,
platform obligations, cybersecurity frameworks, and so on.
And of course, the institutions, the formal authorities, the agencies, funding programs,
and governance bodies, with budget mandates and formal authority to implement policy.
Now, open protocols, by contrast, are, of course, they're borderless, they're non-onable,
and they're maintained by loose global communities.
They determine how systems inoperative it, inoperate, but they do so without ownership, without
jurisdiction, and without institutional control.
And that's a good thing, of course, but as a result, they sit outside the field of
vision of most policy frameworks.
In practice, this means that protocols are often treated as technical background conditions,
something that is almost assumed to be stable, neutral, and external to governance.
That assumption, of course, as most of you here will know, is wrong.
Protocols are not static.
They are continuously modified through governance processes, proposal mechanism, consensus
norms, backwards compatibility decisions, and informal power that accrues over time.
These processes determine what the protocol allows, what it forbids, and what kinds of
behavior are allowed to build on top of it.
In other words, protocols make rules.
They just do so without being recognized as rule-making systems by law or policy.
And this creates a structural blind spots.
Digital policy already routinely produces dependencies on open protocols, but without
identifying them explicitly, without funding the work that keeps them scalable, without
assessing how their evolution might react with regulatory goals.
And I think the distinction becomes even more obvious when you look at the procurement processes.
Now, when an institution adopts the software, it, of course, does so through a contract.
There is a vendor, a liability regime, a defined update path.
Governance is externalized.
On the contrast, when an institution adopts an open protocol, even though they might not
be fully aware of it, none of that exists.
The institution enters an existing coordination system whose evolution is shaped by participation,
not authority.
There is no counterparty to contract with and no mechanism to align change with public objectives.
Protocol governance is simply how those coordination systems change over time, who can
propose changes, how do proposals gain adoption, and what constraints a well-funded actor
from steering the system when there's no formal video, no regulator, or no enforceable obligation.
From within the protocol communities, this is all super obvious, right?
But from a legal and policy perspective, it is not what is visible is the repository,
the documentation, and so on.
What is not visible is decision thresholds, the power dynamics, and the coordination costs
that shape future behavior.
That opacity makes it quite difficult for institutions to assess in what ways they are dependent
on open protocols.
Institutions are not only relying on how a protocol behaves today, but also how it might
change in the future.
And it is really a big mismatch with existing policy and procurement frameworks, because
policy tools and procurement frameworks usually assume at least one of three things.
First, a regulatory move, subject a contractual counterparty or an accountable entity, but
Ethereum has no central governance body, matrix has no vendor relationship.
They have moved through distributed coordination proposals, discussions, and voluntary
adoption.
None of the usual levers apply, and that makes it very complicated for policy makers.
But I would argue that in network systems, sovereignty does not come from formal ownership
or formal control.
It comes from understanding how rule changes occur, who participates in them, and where
influence actually sits.
Open protocols already structure behavior at scale.
Policy simply doesn't see that yet, and this, I would argue, is a massive gap that we
should address.
But what exactly is the issue here?
Why does it matter that protocol governance is a blind spot in digital policy?
The problem is, of course, not that open protocols lack governance, most of them are
governed carefully and completely.
The problem is that digital policy increasingly, whether they're aware not to create dependencies
on protocols without accounting for their governance.
Through standard references, interoperability mandates, and funding programs, and long-term
compliance requirements, policy choices, already determined which protocols institutions
come to rely on.
But the governance of these protocols remain largely outside institutional awareness,
though there are, of course, some examples.
When governance is invisible, dependencies do not disappear.
They simply move downstream into procurement decisions, operational risk, and incident
responses.
When their institutions are left managing the consequences, they did not anticipate and cannot
easily influence, and this creates three structural risks.
First of all, interoperability becomes fragile, thought about the deployments assume long-term
capability, but of course, protocols evolve.
Specifications change, methods get depreciated.
The decisions make today can surface later as breakage, and are far away from the original
discussion.
There is no contract enforcing compatibility.
Governments are users of the protocol, not parties to its governments, usually.
Unlike traditional interoperability mandates, which assume bilateral or multilateral
agreements between accountable parties.
So when a breaking change happens, and an institution relies on open protocols, they have
to absorb the risk.
Seconds, and I think this is an important one, exit options become costly.
When protocol evolution diverges from institutional constraints, the options become very
narrow, because working a protocol at the deployed at scale is very expensive.
It's operationally risky, and politically difficult.
You inherit the full main in spurdon, and slowly lose alignment with the wider ecosystem,
which gives you network benefits.
Abandoning the protocol also often means falling back to vendor-centric alternatives,
recreating the very dependencies that sovereignty strategies are meant to avoid.
There's no one to negotiate with when you are adopting an open protocol.
Governance is distributed by design.
You either participate in shaping it, or you accept what the community decides.
And finally, change arrives at an operational surprise.
So yeah, when a protocol changes through open coordination, if institutions do not track
these processes, governance decisions, surface-as-urgent incidents, instead of predictable
lifecycle maintenance work.
So security fixes, specification protocols, protocol upgrades.
Of course, these are not failures of a protocol.
They are completely normal, but usually there is no institutional capacity to track these.
So what does that look like in practice?
I want to use matrix protocol as an example, because matrix is already used for governance
communications at a very large scale.
France teach-up serves hundreds of thousands of civil servants on a daily basis.
And in Germany, you have PMV messenger, which serves over a hundred thousand users, and is
used in the Bundeswehr and parts of public administration.
And TI messenger, the German healthcare sector, is a user, and over a hundred and fifty
thousand healthcare organizations, large and small reliance.
So these deployments stay work very well, right?
They scale.
An adoption of the matrix protocol is increasing, accelerating.
I know Sweden, the Netherlands, and the European Commission, they all have matrix deployments
in process.
And this is mainly driven by the EU's push for digital security, but also new interoperability
mandates.
But here is where the dependency looks like operationally.
In matrix addresses a security vulnerability through a coordinated release, server operators
must decide whether they to upgrade immediately or run a version with a known issue.
Of course, the decision is not made in a vacuum.
The timing scope and mitigation are shaped upstream through matrix governance, through the
MCSC sorry discussions, embargo coordination and release planning.
But if your institution is not tracking these, you do not learn about them when decisions
are being debated.
You learn when the security advisory becomes public.
And at that point, the choice is no longer strategic.
It's reactive.
You have to respond almost immediately, and you have to choose between operational risk
or compatibility risk.
The same dynamic applies, of course, to room version upgrades.
matrix has introduced multiple room versions to improve security and federation behavior.
If a critical coordination room upgrades and your deployment will not update clients,
users can lose access.
And decisions about when a room version are introduced, backwards compatibility is handled,
and what migration pad exists are all made through the official governance process of matrix.
So it's very important to track this.
And this is not something hypothetical, because since France has adopted matrix, for example,
there was the authenticated media that was rolled out across the matrix network in 2024, and
every client and bridge had to adapt.
So governance decisions in the protocol directly translated into operational work for
institutional deployments.
Now, here's the fragility.
These deployments, they succeed because a small number of individuals understood the protocol
governance and the institutional deployments.
So people inside DINAM, for example, in France, in engineers at GMATIC in Germany.
These people are very capable of following the governance.
And I think in the case of matrix, since October, they have actually, in the case of T-CAP,
they have actually joined the matrix foundation in October, so quite recently.
So matrix is, France is doing quite well there.
But the knowledge is highly concentrated in a few people.
Does not scale automatically.
And when those individuals move on, there is a risk that the institutional understanding disappears
with them.
So I think Europe does definitely not lack the technical capacity to rely on open protocols.
But they do lack a systematic institutional capacity, and that is a risk.
So they need the capacity to monitor governance process processes and security advisories.
The capacity to plan upgrades as part of regular life cycle management, not as an incident
response.
And the capacity to understand how specification changes affect operational continuity before
they become breakage or big failures.
Without that capacity, institutions depend on protocol governance that they do not track,
and discover the consequences only when it's almost too late.
And of course matrix is not an exception here.
This goes for any open protocol used in life deployments that scale by institutions
from identity to messaging, from payments to data exchange, right?
They can all create the same dependence on protocol governance indirectly.
Once institutions adopt something that uses that open protocol at scale.
Now there is some very good news.
There is an opportunity to address the challenges I just mentioned.
As we speak, the European Commission is preparing its open source digital ecosystems strategy.
In fact, the public consultation is closing this Tuesday.
So if you want to get your comments in, there's still some time.
And the ambition of the European Commission is very well placed.
It is to support the full open source life cycle, right?
From deployment to market update, mainly across cloud AI and digital commons.
And the European Commission also has directly identified
that a significant share of value created by European open source
flows outside Europe.
Of course, this is an important diagnosis.
And I'm sure the Commission will look at all the public consultation inputs.
But I, in my view, it remains incomplete unless the strategy also addresses what happens once
open technologies are deployed at scale.
If the open digital ecosystem strategy only focuses on supply site measures.
For example, funding projects encouraging adoption and building markets.
It will continue to underestimate a central source of digital dependency.
Many public deployments rely on protocols whose evolution Europe does not yet track resource or plan for.
And to address this gap, I argue that there should be four pillars in this new strategy.
First, require protocol governance assessment in public procurement.
Second, recognize protocol stewardship as a critical to digital infrastructure.
And of course, funding accordingly and sustainably.
Third, build institutional capacity to track and plan for protocol evolution and
force a line for procurement incentives with upstream contribution.
Now go through them quickly.
So as I said, first, the strategy should require protocol governance assessment in public procurement.
And I think this is one of the biggest blind spots we have right now.
Because today, institutions routinely make strategic procurement decisions based on the
assumption that protocols are technically stable, but in reality, of course, they are not.
And this is a huge issue because public tenders specify the use of open protocol sometimes.
But they do not include the needs to assess the protocol itself only the supplier.
So I think when you look at public procurement, it should include an understanding of where
protocol decisions are made, how changes proposed and adopted and how backwards compatibility
is managed and how breaking changes can surface.
The objective is not to influence governance outcomes of course, but to make protocol risk visible.
Second, the strategy should recognize protocols towards ship as digital infrastructure and fundates.
Because of course, protocols require often invisible work maintaining specifications,
reviewing proposed changes and so on.
But this work is rarely funded through market mechanisms and is systematically missed by project-based funding.
And when it is under resource fragility becomes, yeah, accumulates.
I think here the great example is the German sovereign tech funds,
which demonstrates that it's problem can be addressed without exercising control.
Since 2020, it's invested more than 23 million in over 60 open source components.
And I think the open digital ecosystem strategy should apply this logic as at European level.
Third, the strategy should build institutional capacity to track and plan for protocol evolution.
Public agencies need practical literacy and how protocol changes happens,
knowing where the discussion stake place, which forums and repositories carry authority,
how timelines are set, etc. Without this capacity, institutions will remain only reactive
and repeatedly surprise by upstream governance decisions.
And I think this is already quite visible and at risk in regulated deployments.
For example, under the EID does two member states are required to roll out digital identity.
wallets at population scale by late 2026. And these wallets depend on internationally developed
identity and credential specifications that continue to evolve.
And if European wallets implementations do not actively track and plan for this evolution,
cross-border interoperability might feel because member states will be implementing different
assumptions based on the same underlying standards. And finally, the strategies should
align procurement incentives with upstream contribution.
For now, public procurement rewards systems integrators who resell or deploy protocol-based
systems, while the maintainers usually do not benefit from this procurement value.
This is risky because vendors that actively contribute to protocol specifications.
And so, on their far better position to anticipate change and fix issues quickly,
while keeping deployments aligned with upstream evolution. The strategy should therefore support
procurement models that recognize contribution as a sort of resilience signal.
And I think proposals from initiatives such as euro stack are already points in this direction
to make contribution and explicit procurement criterion points.
This is not only just about a ideological preference for open source, but also about
sound risk management. And taken together, this would really help
taking the strategy from a real framework to supporting open protocols.
So, of course, the first responsibility lies with institutions to track an account for
protocol governance. But then there is a natural question. Is there anything that
protocol communities can do to help the dependencies easier to understand?
Not to change how government works, of course, but to reduce misunderstanding.
Now, I know some of you are thinking, you know, ready documents your governance.
Why is it my problem that institutions don't know how open source works?
And I think it's a fair question, but it matters because when institutions don't
understand your governance and something breaks, they tend to not absorb the risk quietly.
They write regulations. And they could, uh,
really, and change your even the developers of the open protocol we've seen that before.
So, matrix documented governance very early and clearly. So, when governments like France
and Germany adopted it at scale, it helped them understand what they were depending on.
So, here are some practical tips you could do. Make sure that government's
documentation is easy to understand because usually it's written for
contributors, of course, and not for dependence. If the ministry official asks,
how does the protocol decision make, how does the protocol make decisions? Is there
one's documents or a repository that is very clear that you could point them to or do the kind
of have to reverse engineer everything? If you're inclined to formalize something like this,
you should think about covering decision venues, propose a life cycle, participation norms,
safeguards, and upgrade expectations. For example, it could be just even a single
realm written page that could provide significant defensive value. I think you can look here at
a posh Linux foundation product foundation project and matrix as a good example. And seconds
be clear about the on-ramps for participation without, of course, promising influence. So,
means being explicit about which calls are open and relevant, what participation looks like
without disturbing governance. And importantly, and this is something that
protocol communities are often not explicit about, what does participation not confirm? So,
being very explicit that participation does not mean the ability to influence or guarantee
response to feedback. But when governance is legible to institutions,
institutions make better procurement decisions, unrealistic expectations are avoided,
and communities are also less likely to be pulled into very bad regulatory or legal dynamics.
So, it allows institutions to depend on you responsibly without you having to constantly explain
or mediates. So, finally, in conclusion, protocols already underpin many of Europe's digital
infrastructure. Digital sovereignty does not mean controlling open protocols, but it means
accounting for their governance, through stewardship, through clarity, and through institutional
literacy. For policy makers and institutional adopters, this means naming protocol dependencies,
planning for their evolution, and funding the work that keeps them reliable over time.
For developers, it means making your stewardship legible not to invite control, but to prevent
misunderstanding and backlash. And I think if we can get this right, then Europe does not need to
choose between sovereignty and openness. Because, of course, I think many in this room here
will say that sovereignty depends on open technologies, but if we can strengthen the
institutional understanding of the protocol layer, that can strengthen the layer where the
sovereignty actually begins. Thank you.
We have time for one short question. So, we can have one short question, and then we have to go
on to the next talk. So, just go ahead and then please repeat the question. Can you speak
loudly or do you need microphone?
Can you repeat the question?
I was referring mainly to open source protocols. I'm sorry if that wasn't clear, but of course,
I think the problems usually do not occur at the technical level where institutions participate
in standardization meetings, but higher up when the commissioner for digital decides
something she also needs some basic awareness of what her decisions might imply, and so I think
yeah, it's more like at the higher political level that these things are not well understood.