Who Permissioned This? A Critical Review of the EU Commission’s Report on Permissionless Blockchains
Bridging the Gap Between Blockchain Hype and Practicality, While Raising Important Questions About Fairness and Ethical Responsibilities Glaringly Missing From the Discussion.
The EU Commission published a report titled “Enhancing Financial Services with Permissionless Blockchains” at the end of 2024.
“The functional scope of a blockchain closely mirrors that of a traditional database.”
Nope. I will come back to this—because this is the main issue I want to write about.
“A smart contract-based token can be deployed on a local test network just as easily as on a public permissionless blockchain. Thus, programmability does not require a public permissionless blockchain.”
That is a nonsensical argument. A smart contract-based token can be deployed on any network that supports smart contracts. But to argue that this allows one to conclude the following is absurd:
“Contrary to popular belief, the primary advantage of blockchains is neither programmability, nor automation, nor efficiency. These properties can often be more easily achieved with centralized databases. The innovation of public permissionless blockchains lies in governance.”
Any software can be rewritten to add almost any functionality, although trying to rewrite software written for mainframes to cover blockchain probably will not leave much of the previous functional code. However, the design principles of embedding data schema and data rules into the asset are fundamentally different, and the reason why there is this idea that smart contracts could drive automation is because the asset “knows” what it needs to do. Sorry, EU Commission, this is really wrong, and you completely miss the picture here.
“While most FMI environments allow for simple programmability (process engines and logic trees), this is generally limited to the context of one asset type. Composability and atomicity are often lacking because different assets are not present on the same ledger.”
No, the token is a function of a smart contract. Hence, the asset carries state and business logic, and that is totally absent as a business concept in traditional finance environments. If they don’t get this, the entire analysis is off.
Traditional finance relies on external systems to enforce business rules (e.g., custody systems, compliance checks). In contrast, blockchain tokens have these rules built into the asset itself. That’s what makes this interesting, different, innovative and the reason why anyone cares.
Embedding logic in tokens reduces reliance on intermediaries and enables automation at the asset level. This is not merely a technical improvement but a paradigm shift.
“While dominant messaging standards and interfaces provide some degree of interoperability, this is generally application-specific and confined to simple transactions. Composability in the context of DeFi refers to a more flexible Lego pieces approach, where smart contract-based financial protocols and assets can be reused within other protocols.”
What’s the application? If I say Ethereum vs. Ripple, then I have the same issue, and composability does not equal interoperability in our typical understanding. This is because the actual design and configuration of each smart contract needs to be tested. If I send a SWIFT-compliant message to someone who says they adhere to the standard, it has a higher chance of being successfully and correctly processed than saying I sent a transaction to a given smart contract and hoped for the best. A few pages later, they acknowledge this by saying “true composability and atomicity only function effectively on a single ledger”—but then both statements can’t be valid without this qualification.
“Interoperability” in blockchain comes from the shared execution environment (e.g., Ethereum's EVM), allowing tokens to interact seamlessly with other smart contracts and protocols.
“[W]hen users frequently use a block explorer for a specific address, permit a website to access the active address via their browser extension wallet, or depend on an external RPC provider to conduct transactions or query the network, they enable these entities to compile profiles. These profiles may combine IP addresses and cookie data with blockchain addresses and transactions and include other information sources, like blockchain-based identity claims, web3 domain names, web3 social media activity, or even metaverse movement patterns. With ever-increasing data, more advanced algorithms, and diminishing computational constraints, privacy is likely to further erode over time.”
RPC is a critical protocol in blockchain, enabling external clients (wallets, dApps, developers) to interact with blockchain nodes. While it simplifies blockchain interactions, reliance on centralized RPC providers raises privacy and decentralization concerns. Running your own node or using decentralized RPC networks can help mitigate these risks.
Luckily we have the EU for that since collecting personal data (e.g., names, IP addresses, or activity patterns) this way could conflict with the General Data Protection Regulation (GDPR) if done improperly. GDPR applies when personal data of individuals in the European Economic Area (EEA) is collected, processed, or stored. Many RPC providers do not explicitly disclose their data collection practices, potentially violating Article 13 of GDPR. GDPR requires a lawful basis to process personal data:
Consent: The user must explicitly agree to the data collection.
Legitimate Interest: The provider must demonstrate a compelling reason for data processing.
Legal Obligation: The data collection must comply with a specific regulation.
If RPC providers collect personal data without a valid basis, they risk violating GDPR. How about some investigation here? Just a thought.
“Similarly, the node must choose the order of the transactions in each block. Note that in a decentralized network, there is no universal agreement on the sequence in which the transactions must be included. The order in which one node receives the transaction messages may be entirely different from the order in which another node receives the transaction messages. So, within the constraints of cryptographic legitimacy, the consensus-relevant nodes that propose a block may choose the transactions to be included and decide on the order in which they are executed.”
That depends. Ethereum uses nonces to enforce the order of a user's transactions, which means the user determines the sequence of their own transactions. This is an important distinction from the flexibility block proposers have in deciding which transactions to include in a block and in what order they execute those transactions relative to others. However, proposers can reorder transactions between different accounts to maximize fees (e.g., by prioritizing transactions with higher gas prices). Ethereum’s nonce mechanism prevents reordering or tampering with transaction order by validators, so some of the concerns in the paper are not applicable universally.
“PoS generally has stronger finality properties than PoW, typically asserting economic finality, a concept that is comparable to the finality guarantees in traditional finance and adequate for most applications, including financial services.”
"Economic finality" is a term that is not typically found in traditional financial or legal literature. It appears to have originated as part of the cryptocurrency and blockchain discourse to describe guarantees of transaction irreversibility in economic terms. In traditional banking and finance, finality is discussed using well-established legal and operational concepts, such as settlement finality and legal finality, rather than "economic finality." In other words, economic finality is not really a thing, hm.
They then have a very confusing text in Note 7 (unfortunately, the paper has no page numbers—what is that about, EU Commission?) about forks, trying to distinguish between different types of forks based on the nature of the rule change and how Consensus-Relevant Resources (CRRs) (e.g., computational power, staked tokens, or validator support) are distributed. I can’t understand what they are talking about, so here is some help to explain this in human-readable format:
Soft Fork: Introduces stricter rules. The chain converges if most participants adopt the new rules, but a split can occur if many reject them. Example: Ethereum vs. Ethereum Classic (soft fork turned into a split).
Hard Fork: Introduces more permissive rules. The chain converges if most participants adopt the new rules, but a split can occur if many stick to the old rules. Example: Bitcoin vs. Bitcoin Cash (hard fork split over block size).
Forced Fork: Introduces incompatible rules, always resulting in a split.
The problem with these terms is that they try to describe both an outcome and the path it took to get there, which makes them unsuitable for clearly describing events. This is pseudo-science or crypto.
Take, for example, the Ethereum Hard Fork after the DAO hack (2016): The original chain continued as Ethereum Classic (ETC), and the forked chain became the current Ethereum (ETH). This could arguably be seen as a forced fork: The two chains became incompatible because they diverged fundamentally on how to handle the hack. However, some classify it as a hard fork because the rules could theoretically have been agreed upon if all participants aligned.
Take another example: Bitcoin and Bitcoin Cash Fork (2017). There were disagreements over block size limits (scaling Bitcoin). One faction implemented a larger block size (Bitcoin Cash), while the original chain retained smaller blocks (Bitcoin). Although it’s commonly described as a hard fork, it could also be framed as a forced fork: the two rule sets (block size limits) are fundamentally incompatible.
The funny fact is, these definitions are such that it’s hard to say which term applies. The framework doesn't provide clear criteria for when a fork qualifies as one type versus another. This framework is flawed and should not be propagated without critical reflection. The three terms—soft fork, hard fork, forced fork—fail to predict outcomes or explain the processes leading to a split. They oversimplify complex social, technical, and economic dynamics into rigid categories. And they fail to capture the nuance that fork outcomes are contextual and can be temporary.
They then write a lot about scaling and privacy, but this reads strangely to me because it characterizes pseudonymity as a positive aspect. They state that there is no law mandating total public transparency, and:
“While the risk of illicit activity, money laundering, and terror financing is real, it must be acknowledged that there are also legitimate reasons for the demand for privacy. In what follows, we explore some of the privacy-enhancing protocols and discuss the tightrope walk between the two extreme scenarios with either complete privacy or none at all.”
But that is not what follows, because the privacy-enhancing methods they describe would typically be considered obfuscation tools. They mention EY’s Nightfall, an Optimistic Zero-Knowledge (ZK) Roll-Up protocol. EY has publicly stated that it does not retain ownership or responsibility for the code, as it is released under the CC0 1.0 Universal (Public Domain Dedication) license. However, using this tool—depending on how it’s implemented—could facilitate tax evasion and similar issues.
Many blockchain solutions lack built-in tools for selective transparency. Current systems often choose between:
Full transparency (e.g., Bitcoin).
Full privacy (e.g., Monero).
Building selective transparency into blockchain protocols requires complex upgrades, and this is the real issue. The paper seems surprisingly ignorant of these challenges. They mention partial privacy twice, more as a side comment, and emphasize putting the user in control:
"The proposal allows for partial privacy, where a user would not be required to reveal their entire transaction history to the general public but can disclose their transaction history selectively with authorized parties."
However, it’s unclear who "the user" is in this context. Is it the investor, the wallet provider, or another intermediary? If it’s the investor who decides what to disclose, this approach would not align with AML compliance requirements. Sanction screening and financial transparency cannot depend solely on the discretion of the individual investor to select transactions for review as they see fit.
Privacy tools like Nightfall enable full privacy but offer no built-in mechanisms for regulators or tax authorities to selectively access transaction details. This creates a clear tension between:
Legitimate privacy needs (e.g., protecting sensitive financial information).
Regulatory compliance (e.g., ensuring traceability for oversight).
That said, I’m not sure anyone is actively using Nightfall. So perhaps this concern is more theoretical for now. But shout out to their marketing team—this project name would make an excellent title for the next James Bond movie.
“Before we analyze the solution space, it is important to understand that MEV [Maximal Extractable Value] might be less problematic than it may appear at first glance. First, not all MEV is harmful. Creating additional incentives for arbitrage between various exchanges or for the timely liquidation of unhealthy collateralized positions is in the best interest of the platform and its participants. Thus, it is an option to embrace beneficial MEV, while trying to mitigate harmful MEV on the application’s smart contract or user interface level, i.e., with slippage limits or batch auctions limits on smart contract-based exchanges.
That is a severe oversimplification and, in its assessment, shocking. Incentivizing arbitrage or timely liquidations can improve market efficiency and ensure the platform functions as intended. However, this would require that MEV extraction in these cases does not create unfair advantages or harm users indirectly—for example, by increasing transaction costs or introducing systemic inefficiencies.
The suggestion that harmful MEV can be mitigated through slippage limits or batch auctions is overly simplistic and fails to address systemic issues, such as validator incentives to reorder transactions for profit. Moreover, harmful MEV often exploits users who are unaware of these risks, particularly those engaging in DeFi without understanding the mechanics of front-running.
A bank that front-runs client trades may create some "benefits," such as increased liquidity or higher profits. However, such behavior is universally condemned and deemed unacceptable in any other market context that the EU Commission is concerned with. Arguing that such practices improve market efficiency would be indefensible elsewhere—why should it be tolerated in blockchain?
Let me demo this:
“First, not all MEV Market Abuse is harmful. Creating additional incentives for arbitrage between various exchanges or for the timely liquidation of unhealthy collateralized positions is in the best interest of the platform and its participants.”
In my opinion, this statement needs to be corrected. It undermines fairness, the rule of law, and trust in decentralized financial systems.
“Similarly, many FMI [Financial Market Infrastructure] activities would most likely operate on L2 and only use L1 for dispute resolution and to ensure broader composability where necessary. [..] As such, MEV is not necessarily a significant issue within a regulated FMI context.”
I am shocked (again). While FMIs may use L2 solutions to improve scalability, MEV opportunities remain because validators or sequencers on L2 have the same ability to reorder, censor, or prioritize transactions within their local context. L2 systems like Arbitrum, Optimism, or even private networks don’t inherently eliminate MEV; they localize it to their ecosystem.
MEV is not exclusive to L1 blockchains; it exists wherever there is transaction sequencing, including on L2. In fact, the centralized nature of many L2 sequencers could exacerbate MEV risks rather than mitigate them.
Even in a regulated FMI context, MEV creates opportunities for market manipulation, unfair transaction ordering, and extraction of value at the expense of other participants. FMIs are designed to ensure fairness and transparency, yet MEV directly undermines these principles. Regulation may provide oversight, but it does not inherently address the technical vulnerabilities that enable MEV.
To claim that MEV is "not significant" in this context is not only technically naïve but also dangerous, as it fails to recognize the risks MEV poses to the very foundations of fairness in financial market infrastructures.
And even if it were true—which it isn’t—that L2 systems are free of MEV risks, how can the EU Commission argue we should turn a blind eye to practices that would be considered illegal in regulated financial activities? This would be tantamount to declaring ethical bankruptcy and, legally speaking, would create an avenue to circumvent effective regulation and supervision. If anyone could absolve responsibility for relying on such inputs, the door would be open to systemic abuse.
Take this to an extreme: imagine justifying imported goods produced by child labor abroad, arguing that their production is a concern but "not necessarily a significant issue" in the local context where they are sold. Can this reasoning be right? I hope not.
“As highlighted by Nabilou (2022), finality is mainly a legal concept. He argues that traditional FMIs cannot guarantee strict operational finality either, and instead rely on a concept he coins «legal finality».”
First of all, who is Nabilou? Is this author the preeminent authority on assessing finality in the context of FMIs? I would say no. Picking random quotes like this does not demonstrate scientific rigor.
Secondly, the author did not coin the term legal finality. I would recommend the EU Commission read up on Herstatt risk, concerning a privately owned bank from Cologne that went bankrupt in the 1970s. Legal finality arose as a critical concept to address exactly these kinds of risks.
From reading Nabilou's work, it’s clear that his argument does not position legal finality as a flaw of traditional FMIs, as the EU Commission portrays it, but rather as a necessary construct to manage operational and systemic risks. Absolutely. Nabilou emphasizes that even conventional systems cannot guarantee 100% operational finality, and therefore legal finality becomes an essential layer of certainty in financial systems.
Here again, I would advise the EU Commission to revisit the justification for its own Settlement Finality Directive and how it enables the ECB to accept cross-border collateral despite the lack of harmonized property laws across member states.
Reading this in an official publication from the EU Commission is deeply concerning. I’m sorry, but this is shocking, and it’s alarming that this kind of misunderstanding slipped through their editorial process.
And it goes on and on with nonsense:
“Ideally, a blockchain should never experience any issues that affect its liveness, and a truly permissionless and decentralized blockchain is arguably among the most resilient systems in existence.”
The statement reflects an idealistic view of blockchain systems that ignores the inherent trade-offs and real-world challenges they face. While blockchains do offer unique resilience properties, they are not immune to liveness issues or operational failures. Recovery from such failures is often slow and complex, particularly in truly decentralized networks. And their design without documentation, clear responsibilities or implementation standards makes it impossible to manage this risk right and comply with regulatory expectations.
And I stopped reading after a while because the authors pontificate about complex issues they clearly do not understand. At the end, they present three policy recommendations:
Public permissionless blockchains “promote competition and can help mitigate monopolistic market structures and the creation of isolated silos.”
Regulation and blockchains: “does not imply the absence of regulation. While it is true that regulation – by definition – cannot be enforced on the public permissionless blockchain itself, intervention at the blockchain level may not be necessary.”
Interoperability: “can foster interoperability. Even in the presence of regulatory enclaves, or use-case-specific L2s, a public permissionless blockchain can serve as a neutral interoperability layer, laying the groundwork for the next logical step in open finance.”
These statements are not supported by any objective evidence. They rely on implicit assumptions such as the one mentioned at the beginning of the paper: “The functional scope of a blockchain closely mirrors that of a traditional database.”
Blockchain’s very low processing depth and lack of fundamental business logic make it unsuitable for banking or running any regulated business activity. The technology is optimized for a specific use case—censorship resistance—but its current operating model is fundamentally incompatible with banking or regulated financial activities.
A New Approach
But reading this paper wore me down, and so I will explain very soon.
This is such an interesting and critical topic that it demands a new whitepaper after Genesis Story—one that deals with smart contracts, data oracles, and proposes a solution to create a secure and verifiable connection between the real world and blockchain that is trust-minimized and cryptographically verifiable.
The oracle problem, borrowing from the EU Commission, is not necessarily a significant issue—if approached with the right technical and conceptual frameworks.