The promise of crypto lies in disintermediation, publicly verifiable systems, and credible neutrality — the foundations of an open economic system that is accessible to anyone regardless of geography, identity or beliefs.

Credible neutrality is one of the most important concepts in the industry and it took several years for the community to settle on a term that captures this ethos.

Vitalik has a rule of thumb for what it means:

Credible neutrality. Essentially, a mechanism is credibly neutral if just by looking at the mechanism’s design, it is easy to see that the mechanism does not discriminate for or against any specific people. The mechanism treats everyone fairly, to the extent that it’s possible to treat people fairly in a world where everyone’s capabilities and needs are so different.

Crucially, credibility matters as much as neutrality itself. A system must not only be neutral in design, but also provably so to its users. Neutrality must be backed by social legitimacy and a technical means to achieve it.

This essay will not argue that credible neutrality should be abandoned. Rather, we examine how practical security pressures are reshaping how neutrality may be implemented, especially for institutions who may adopt rollups as a technology stack.

Evolution of Credible Neutrality

The phrase, credible neutrality, originates from the Ethereum community and it is often applied retrospectively to Bitcoin.

Bitcoin laid much of the groundwork for what is now described as credible neutrality. It was the first to implement a set of publicly verifiable consensus rules that self-enforce the network’s integrity without a trusted third party or mediator.

Collectively, the network enforces:

• The 21 million supply cap,

• The issuance schedule for new bitcoins,

• Rules governing transaction validity,

• A total ordering of all confirmed transactions,

Going further, the chain advances through an open competition among miners to produce new blocks and the competition is based on solving computationally difficult puzzles. The only advantages available to a miner are network latency, hardware efficiency, capital investment to set up a mining farm, and the ongoing operational cost to run it. There is no discretionary authority who can bypass the competition.

Attempts to violate consensus rules such as including invalid transactions or producing blocks without participating in the competition are simply ignored by the network at large.

Equally important are the social foundations of neutrality.

Bitcoin’s founder Satoshi Nakamoto stepped away early in the project’s development. He left the community to steward the project’s future. The absence of a central authority has helped prevent coordination around discretionary rule changes. Any attempt to change the rules is often heavily scrutinised and must overcome the toxicity of Bitcoin maximalists who act as a ‘swarm of cyber hornets’.

Taken together, these technical and social dynamics help explain why Bitcoin is widely regarded as a credibly neutral system. To understand how neutrality manifests in practice, however, it is worth examining one of the most critical mechanisms: transaction ordering.

Transaction Ordering and the OP_RETURN Wars

This brings us to arguably one of the most important mechanisms underpinning credible neutrality in blockchain networks:

• The transaction ordering policy and the question of ‘censorship’.

At first glance, Bitcoin is often assumed to embody strict neutrality. The common view is that all transactions are treated equally, so much so, that even sanctioned actors like North Korea prefer to keep their holdings in BTC over all other crypto assets.

Yet this assumption on neutrality is not necessarily true.

There is a long-running and ongoing conflict in the Bitcoin community called the OP_RETURN wars. The debate focuses on what type of data should be permitted within transaction payloads:

OP_RETURN. The signer can store arbitrary bytes in the transaction payload. The data must be sent alongside the transaction and the new block, but it is not kept in the network’s active state (UTXO set). It contributes toward the ~4 MB limit of a block.

The debate is nearly as old as Bitcoin itself, but in recent years, it has re-emerged due to the popularity of Ordinals and a single jpeg of a ‘bitcoin wizard’ filling an entire ~4MB block.

This raises the question on what it means for a transaction ordering policy to be credibly neutral. Historically, it has relied on the following rule of thumb:

• Fee market neutrality. A transaction should be ordered for execution based solely on whether it pays a sufficient fee at the time of inclusion.

Practically, this means block builders evaluate whether the fee compensates for execution and block usage without judging the transaction’s content or intent.

The current debate is often framed as a divide between Bitcoin Core developers and the Knots community. Broadly speaking:

• Bitcoin Core developers tend to favour allowing the fee market to regulate transaction content without explicit filtering mechanisms.

• Knots proponents characterise OP_RETURN usage as spam that undermines node decentralisation and thus filtering can help preserve neutrality of value transfers into the long-term.

Regardless of where one stands, the dispute is fundamentally about credible neutrality:

• Should any transaction be permitted as long as the sender is willing to pay the market price for blockspace?

• Should the network prioritise financial transactions above all else and scrutinise the intent behind certain payloads?

The tension between relying on an open fee market to enforce neutrality or whether content filtering can be justified for the greater good is not only a debate in Bitcoin. As we will see, it is a prominent debate across the blockchain ecosystem more broadly.

Ethereum’s Credible Neutrality in the Face of OFAC Sanctions

Ethereum was born with a similar ethos to Bitcoin. It was envisioned to be a world computer running unstoppable code without central control.

Admittedly, there was a blip in Ethereum’s credible neutrality in the early days, as the community coordinated a hard fork to reverse the effects of TheDAO hack and return funds to affected participants. It is the only occasion where the community as a whole interfered with the system’s operation.

Over time, a stronger cultural norm emerged within the Ethereum community. Network rules should not be changed in response to a bug at the smart contract layer. Intervention by core developers is only appropriate for fundamental vulnerabilities in the blockchain protocol.

This cultural norm was first tested a year later with the Parity Wallet hack in 2017. More than 150k ETH was frozen due to devops199 exploiting a bug in the implementation of a multisig. Parity, at the time, was one of the two core development teams for Ethereum. The hack was not reversed, which upheld credible neutrality, but it was arguably one of several contributing factors that led to the departure of Parity as a core developer.

In my view, the real test of credible neutrality in Ethereum was the network’s response to the Tornado Cash sanctions. In a nutshell, the US Government sanctioned the Tornado cash smart contracts. This means anyone interacting with or facilitating transactions involving them could potentially face violations of US sanctions law and significant legal consequences.

Despite regulatory pressure, Ethereum’s proof of stake protocol did not censor transactions or alter the consensus rules, even though a majority of stakers and some infrastructure providers compiled with sanctions. The network continued to process Tornado Cash related transactions, albeit with a short delay.

Looking back, this was the right decision by the Ethereum community as a recent court ruling declared that an immutable smart contract may not qualify as sanctionable property and the sanction was later lifted by the US Government.

Rollups Pursue Ethereum’s Path

Rollups follow Ethereum’s path in embracing credible neutrality. Some argue that a centralised sequencer cannot be credibly neutral — a question we will return to shortly.

If we focus specifically on the sequencing layer, then the case for credible neutrality can be even stronger in some respects than Ethereum. A sequencer’s primary role is to collect transactions as data blobs, order them, and publish them to Ethereum. While sequencers typically verify transaction validity and confirm that signers can cover fees, even this is not strictly required at the protocol level.

In principle, a sequencer could publish all collected data blobs, including invalid transactions. The rollup smart contracts will simply ignore those that fail to execute. The trade-off is economic as the sequencer will bear the cost of posting invalid data without reimbursement.

A centralized sequencer or several acting in concert can censor transactions by withholding data publication. Many rollups mitigate this risk through an escape hatch mechanism that allows users to transact or withdraw funds if the system becomes unavailable. In practice, these mechanisms help preserve credible neutrality by enabling users to bypass the sequencer if their transactions are not included.

However, as we will see, the sequencer’s ability to withhold data and not order it for execution can shift systems away from strict credible neutrality towards discretionary security enforcement.

Emerging Trend To Pursue Security-First Neutrality over Credible Neutrality

We are increasingly witnessing a shift in the Overton window as some projects move away from strict adherence to credible neutrality and toward what might be described as security-first neutrality:

Security-first neutrality. Preserves the goal of impartial infrastructure, but prioritises protecting user funds when credible threats arise, even if that requires selective intervention.

There are several historical precedents which suggest that a security-first neutrality paradigm is often viewed as desirable by users and projects.

Ethereum’s response during TheDAO hack was the first instance of security-first neutrality. Other events include Binance halting their smart chain to reduce impact of a cross-bridge hack, Berachain’s emergency hard-fork to freeze hacker funds and SUI working with their validators to freeze hacker funds.

Additionally, there are proposals which have not been realised but reflect similar instincts. For example, Changpeng Zhao (CZ) once floated the idea of rolling back Bitcoin’s blockchain to rescue 7,000 BTC. Meanwhile, Optimism’s documentation presents an approach to fork Ethereum L1 and rescue funds in the event that Optimism’s core blockchain protocol was hacked.

Among these cases, a common theme emerges that developers may be forced to intervene if the hack represents an existential threat to the blockchain ecosystem at large.

Filtering Transactions At The Sequencing Layer

Returning to the issue of centralised sequencers and their ability to selectively withhold transaction data, there is a growing trend for a new category of infrastructure that focuses on security-first neutrality.

The new infrastructure empowers the sequencing layers to evaluate transactions for potential misuse before deciding whether to include them in the final ordering.

One early example is Flashbot’s revert protection. It simulates transactions before inclusion and will drop valid transactions that can pay a fee, but the execution has failed for any reason. The benefit is that users are no longer charged for failed transactions. A few years ago, revert protection was made available as an optional integration at the RPC layer but it can now be incorporated at the sequencing layer for rollups. It is interesting that Unichain offers revert protection, but it was not enabled on Base.

More recent offerings go beyond revert protection and focus explicitly on exploit prevention. This includes products like STOP by Blocksec, Forta Firewall by Forta, Hexagate by Chainalysis. They rely on machine learning and other techniques to flag whether a transaction is attempting to exploit a smart contract. Another startup, called Credible Layer by Phylax allows projects to explicitly define a list of invariants which is used by the sequencer to block any transactions that violate the invariants.

Transaction Filtering Is Not Free and Has Some Complications

The appeal for transaction filtering is clear from a security perspective. Early detection can slow or halt exploits, alert affected projects, and provide time to coordinate responses that protect user funds. Yet this capability also shifts sequencers closer to an intermediary with discretion rather than neutral ordering infrastructure.

However, transaction filtering is not without costs and complications:

• Liability. Questions quickly arise around responsibility if filtering fails to stop an exploit. Does liability fall on the sequencer, the filtering provider, or neither if the service is framed as best-effort?

• Facilitating upgrades. Many attacks can be addressed by projects updating their smart contracts. However, when mitigation requires upgrading the underlying blockchain itself, like replacing an immutable smart contract, the task can place significant pressure on core developers and the broader ecosystem who will need to update node software within a short period of time.

• Bypassing filters. Attackers often test exploits on public (and private) testnets before deploying them on mainnet. If filtering APIs are accessible, adversaries may probe them with test transactions to learn what is blocked and how to work around its defences. Probes can provide APIs with useful information and notice of an upcoming attack, but distinguishing signal from noise, at scale, can be challenging.

• Scope creep. What begins as narrowly defined exploit prevention can gradually expand. The narrative of protecting users may justify broader transaction screening, potentially moving from technical exploit detection toward behavioural or activity-based filtering, raising concerns on credible neutrality.

• False-positives. No detection system is perfect. Legitimate transactions may be incorrectly flagged or delayed. In fast-moving DeFi environments, delays can have real financial consequences. For example, if a user is prevented from topping up their collateral before liquidation, then they’ll lose funds without any recourse.

• Latency. Transaction simulation, analysis and filtering introduces additional processing overhead. As rollups and other blockchain networks push towards ever-lower latency transactions such as less than 100 ms, and hopefully 10 ms, then even a small increase due to filtering efforts will eventually become material and have an impact.

• Appeals. In cases of false positives, users must identify the appropriate party and request that the transaction be unblocked. This may require additional human resources for the entities running the sequencing layer or alternatively force users to rely on the filtering provider to resolve the issue.

There are many cases where teams can remedy issues by updating smart contracts directly.

For other cases, where the core developers must be involved to update the core blockchain protocol, we need to consider proportionality. For example, it does not necessarily make sense for hundreds of infrastructure providers to upgrade node software to rescue funds from a smart contract holding less than $100k in TVL.

Unfortunately, this is the kind of judgement core developers may be forced to make if they are expected to intervene at the smart contract layer. While the promise of security-first neutrality may be appealing to users, its practical implementation can be challenging for core developers, particularly as ecosystems grow in scale and complexity.

An interesting research area is to evaluate all previous exploits and determine whether transaction filtering could have prevented it alongside the sequence of events needed to fix the exploit.

Institutions Will Adopt Security-First Neutrality

The Overton window is clearly shifting.

Credibly neutral base layers like Bitcoin and Ethereum will likely remain as foundational settlement infrastructure, but institutions adopting rollups as a technology stack may prioritise security-first neutrality for their own execution environments.

They will likely implement preventative security like transaction filters and reactionary security measures like security councils to recover funds (when possible). The motivations are not only regulatory or reputational, but necessary to earn the trust of users who may deposit billions of dollars into their system.

This reality is OK.

Practically speaking, we suspect that transaction filtering will only prevent a subset of exploits, like freezing user funds within a vulnerable smart contract until the project can deploy a fix. Direct intervention by network developers will remain reserved for high-impact incidents.

The primary challenge in the coming years will be preventing scope creep where transaction filtering that is implemented to stop heists is later expanded to discriminate against honest users. Credible neutrality is still important, even if policies that advocate for developer intervention to protect user funds is prioritised from time to time.

If nothing else, users will at least save on fees from failed transactions, a significant UX improvement.

The industry is coming to grips with Vitalik’s new post on rollups which argues that the original framing of the rollup-centric roadmap needs updating as scaling Ethereum L1 becomes an increasing priority.

The response to his tweet is interesting.

Rollups are making counterarguments while others are taking “victory laps” that they were “right” that “rollups were doomed to fail”.

Yet, I feel nearly all responses are missing the point of his tweet.

His message is not that rollups have failed, in fact, it is the opposite. Rollups that have differentiated themselves relative to Ethereum have succeeded hugely, but this is not what was anticipated in the initial vision.

To understand why, let’s dive down memory lane on how rollups came to be, how rollups have evolved over the years, why achieving Stage 2 security is not necessarily an immediate priority, and the type of product market fit that rollups have found.

We will see that rollups have succeeded, but not as Ethereum shards extending blockspace. Instead, rollups have succeeded as independent economic ecosystems that seek to offer best-in-class security when accessing assets (and liquidity) on Ethereum.

The long-term success of rollups depends on a highly scalable Ethereum L1 that remains the primary source of assets and liquidity.

Quick dive into the history of rollups

Back in 2016, Ethereum adopted the same philosophy of Bitcoin, that a home computer should have the capability to independently verify the entire chain from genesis.

There are many good reasons to take this philosophy approach. It prioritises decentralisation as a core value, protects the chain from hostile takeover, and helps spot bugs/exploits immediately.

At the same time, it also concludes that Ethereum will never achieve 1,000 tps with low fees, and it’ll be impossible for the world’s transactions to be processed by a single chain.

Back then, there were two scalability approaches under consideration:

• Sharding. Partition the blockchain into different processing units, where each unit only processes a subset of transactions.

• Off-chain solutions. Take transactions “off'“ Ethereum, process them elsewhere, and bring the result back to Ethereum.

Proposed solutions for Sharding often replicated how it works in classical database theory. However, they were Frankenstein solutions, monstrous, and in many ways perceived to be impossible to implement at scale, simply due to their complexity.

Off-chain solutions were often very simple to reason about and implement. I spent most of my own time working on State Channels. However, channels only work for a small set of parties and were not applicable for 90% of applications. This became obvious to me after trying to build a battleship game and discovering it was not a real solution to the problem.

Then, in 2017, there was a scalability breakthrough thanks to Joseph Poon and Vitalik Buterin. They introduced the concept of Plasma which effectively combines the concepts of sharding and off-chain solutions.

Plasma failed, but eventually evolved into the rollup-centric roadmap from 2019 onwards.

Rollups, as a Sharding Solution, Could Have Same Security as Ethereum.

Rollups, from a technology perspective, moved the execution of transactions off Ethereum (like off-chain systems) while fragmenting transactions according to the relevant smart contracts (like sharding).

It was generally assumed that rollups could replicate the same, if not better, security guarantees offered by sharding protocols. If this was accomplished, then rollups could effectively act as a direct extension of Ethereum. This led to the following:

• Multiple teams building their own version of a rollup, effectively a shard, with the desire that at least one team gets it right.

• L2Beat emerging as a referee to hold the teams accountable that they were indeed building rollups according to the initial vision of extending Ethereum’s blockspace (securely).

Over the years, the community agreed to a framework on how to evaluate whether a rollup was on the path to achieving the goal of becoming a true extension of Ethereum.

Out of all the teams that attempted to build a rollup, there are only a few managed to achieve Stage 1 status and build an ecosystem that is worthwhile for users to transact on. Of course, this includes Arbitrum, a team I decided to join a few years ago.

Desirability of Stage 2 and Frustration To Achieve the Rollup-Centric Vision

The primary difference between Stage 1 and Stage 2 is whether there is a security council with the authority to immediately upgrade the chain:

• Stage 2. Security council is severely restricted to only handle soundness errors that are detectable on-chain (i.e., different valid proofs for the same checkpoint) or simply no security council.

A rollup is classified as Stage 2 if there is no longer a trusted committee with the ability to perform instantaneous upgrades.

The community is split on whether this is desirable for users and operators.

I’m in the camp that it is overall bad for users if the security council is removed. It limits security to reactionary measures and stops the team from fixing known exploits quickly before they become serious risks. That is a choice that Ethereum makes, but rollups don’t need to make the same choice.

Another point, mentioned in Vitalik’s original tweet, is that enterprises want to maintain a level of control over the system. The legal system, and the consequences of removing safety wheels, is part of their threat model too.

Of course, this rationale is at odds with the original rollup-centric vision.

Staying at Stage 1 means the rollup will not be a fully trustless system as there is an additional trust dependency beyond just Ethereum.

If a rollup wants to follow the ideology behind the rollup-centric vision and truly be an extension of Ethereum, then it must achieve Stage 2 status by nerfing the security council or removing it altogether.

Rollup Product Market Fit at Odds With the Original Vision for Rollups.

The drift on expectations compared to reality has to do with the type of product market fit that rollups have found.

The product fit is not necessarily acting as a strict extension of Ethereum, but empowering operators to embrace a Web2 architecture with all the benefits of Web3.

Large institutions like Coinbase, Robinhood, and others, want to distribute services to their customers, and rollups are emerging as a compelling technology stack for this purpose.

Every rollup project has a strategy focused on institutions:

• Customisable Arbitrum chains,

• Optimism’s Superchain,

• ZkSync’s “bank chain” motto.

This is not surprising as there are many reasons why institutions will want to adopt rollups:

• Control over the user experience,

• Add functionality that doesn’t exist on Ethereum,

• Experiment with different MEV-aware architectures,

• Capture value from their own distribution channels.

Most importantly, rollups are economic actors. They compete to attract users, developers and projects, seeking to maximise the utility and reach of their own ecosystems.

This is very different behaviour from what we would expect of Ethereum shards. Rather than passive extensions of L1 blockspace, rollups are competitive execution environments seeking access to Ethereum’s liquidity.

Competition drives experimentation, differentiation, and a better experience for users.

This brings us back to the security framework managed by L2Beat.

Stage 1, to date, already offers stronger user (and operator) protections than typical Web2 infrastructure while still allowing the operator to respond quickly to critical security incidents:

• Users do not necessarily have to trust the operator on a day-to-day basis alongside an escape hatch to withdraw from the system if issues do arise.

• Operators can rely on the technology stack to protect billions of dollars with the ability to perform emergency upgrades if zero-day exploits are discovered.

There is a risk that the security council is compromised and they steal all funds in the rollup.

With that in mind, achieving Stage 1 is good enough for many operators. The benefit of becoming a Stage 2 rollup is not strictly superior as it depends on technical maturity, governance needs, and regulatory context.

Scaling Ethereum L1 is a MUST for Rollups To Win

Let’s assume that rollups are indeed an ideal technology stack for companies to adopt, build products on, and rely upon to distribute services to their customers.

There is still a missing piece that all companies who adopt rollups will depend on:

• An Ethereum L1 that scales to become the primary source of assets and liquidity on earth.

Why?

Take a moment to think, fundamentally, why rollups are useful:

• Best-in-class access to liquidity. Rollups allow the operator to access liquidity on Ethereum and for the assets on Ethereum to be maximally protected when they are transacted with on the rollup.

If Ethereum fails to scale, then there will be no assets on the chain, and thus there is no point to deploy rollups on Ethereum.

The success of rollups depends a scalable Ethereum L1.

In fact, it goes a bit further than that, we should expect to see rollups deploy bridges to several networks, like the Base-Solana bridge, as rollups seek access to liquidity on all public venues.

Ethereum should remain the primary venue for liquidity and the anchor that secures the rollup for users & operators.

In hindsight, one of Ethereum’s biggest strategic mistakes may have been inheriting Bitcoin’s scaling conservatism rather than anchoring scalability to real-world conditions, like the yearly increase in hardware and bandwidth resources available.

I believe this philosophy is actively being dropped by the community as everyone is changing their minds on what it means for Ethereum to scale.

Ironically, I was a “big blocker” during the Bitcoin block size wars, but also fell prey to believing Ethereum couldn’t scale beyond what it does today in the name of decentralization.

Really? What if Ethereum Scales Infinitely? Rollups Should Die?

Let’s pretend Ethereum infinitely scales and transaction fees are so cheap that anyone can transact.

In this world, do you believe that cryptocurrency exchanges like Coinbase, Binance or Kraken will disappear?

Most people, I’d assume, will answer no.

Why? because exchanges offer functionality and services that are difficult to replicate on Ethereum.

The same is true for rollups.

This brings us back to Vitalik’s original tweet.

Rollups need to differentiate on functionality. Rollups shouldn’t simply be boring clones of the EVM. Boring clones will die off, but rollups that offer fundamentally different functionality will thrive.

Rollups will increasingly compete as economic ecosystems. They will continue to experiment with execution environments, MEV-aware designs, user acquisition strategies, and ultimately capture value for the wider ecosystem.

Ethereum scaling and rollup differentiation are complementary, not competing strategies.

Rollups ultimately succeed when Ethereum L1 succeeds because it is the primary source of assets, liquidity, and security anchoring.

Vitalik’s tweet reflects an ecosystem recalibration rather than a retreat from the rollup-centric roadmap. The time to scale Ethereum L1 has arrived and we should approach it with confidence rather than hesitation.

DAOs are probably one of the most controversial topics in crypto.

So much so, when I asked on Twitter why DAOs have failed, I was overwhelmed with various takes on why:

• Delegates not the same as full time board members,

• Soviet Union vibes, everyone owns something, nobody owns it, and nobody has a direct interest to maintain or improve its condition,

• People vote for their own short term interest at the cost of long term success,

• People lack the expertise to make educated decisions across multiple subject matters,

• DAOs, throughout history, only worked with a very small group. Large groups centralised with leadership & hierarchy.

• Handing power to people who don’t know what they are doing

Others commented that DAOs have not failed. DAOs will simply become blockchain-oriented responsible entities (BORGs) and other legal structures like LLCs. There is a long tweet that summarises many of the apparent issues in DAOs.

After two years immersed in DAO governance at Arbitrum, I want to reflect on what’s working, what isn’t and where we go next. To accomplish this, I have put together several articles:

• Why DAOs are interesting

  • From Rough Consensus to Autonomous Execution: How I Learned to Appreciate DAOs

• What is a DAO

  • DAOs: Stakeholders, Autonomy, and Organisational Design

• Proposal Process in DAOs

  • DAO Politics: Holistic Challenges in the Proposal Process

• Towards More Effective Governance

  • Learning From Failures to Build Better DAOs

• Moral and Ethical Issues

  • Vote Buying as a Service, LobbyFi and DarkDAOs

Let’s take this opportunity to provide a summary for the articles, but I do recommend to take the time to read them.

The Core Problem is Governance. Every protocol has two layers:

• Operational component that runs 99.9% of the time,

• Governance backend that can change the live system.

Regardless if the system is Bitcoin, Ethereum, another L1, a rollup, or even a smart contract on a public blockchain, it always has these two layers.

Governance manifests itself when a group of stakeholders need to make a decision that changes the system’s rules or push the ecosystem forward. Even immutability — often seen as the absence of governance — is itself a governance decision to restrict any future changes.

Historically, in networks like Bitcoin or Ethereum, governance has been implemented through rough consensus. An intentionally ambiguous process with no single leader. Influence is hard to measure and who has influence depends on the issue at hand. The ambiguity has evolved over the years to fend against hostile takeovers of the system.

DAOs take the polar opposite approach.

There is an voting system explicitly defines voters, distribution of voting power, and exactly what is governed. The DAO operates through a transparent proposal process that allows anyone to submit ideas, initiate discussion, and trigger a measurable vote.

The very concept of a hostile takeover is ambiguous. As long as a proposal passes the on-chain voting protocol, then it can still be considered valid, even if it passes due to an actor acquiring overwhelming voting power.

Over time, DAOs have expanded influence beyond software to managing treasuries, deciding organisational hierarchies, and having authority over legal entities. The software works as intended, but problems arise in the human realm, as the proposal process must handle conflicting interests amongst hundreds of actors.

This leads to a whole host of problems including:

• Rigid proposals that can’t adapt to reality,

• Swarms of vendors seeking funding,

• Overpaying for services,

• Committees that don’t coordinate,

• Voter apathy from excessive volume,

• Excessive lobbying,

• Lack of accountability from proposers.

Many of the problems arise not out of malice, but from good intentions by the parties involved. For example, proposals are rigid so authors can be held accountable, but the same rigidity also makes execution harder and less effective.

The immediate solution is to step back, understand the source of the problems, and reset expectations in DAO governance:

• Governance should be rare. Proposals should be deliberate, strategic, and large in scale. They should earn attention from voters because they matter and not because it exists in the pipeline.

• Governance is expensive. It takes time and resources. Everyone must come together to review the proposal, discuss it, and vote on it. A scarce resource that should be respected and a culture should emerge that discourages low-quality proposals that do not meet an exceedingly high bar.

• Governance needs trusted teams. DAOs need full-time actors whose job is to execute the DAO’s will. Not vendors or contractors, but teams who ultimately depend on the ecosystem’s long-term success. They should be empowered to make decisions, hire and terminate vendors, and execute initiatives on behalf of the DAO.

• Governance is not for everyone. Most people should not be involved in proposals or governance. Their involvement should begin after a proposal has passed and it is time to find the talent with the appropriate skills to carry out the work. Traditional processes like recruitment, outreach, and onboarding still work. Use them.

• Governance is serious business. Toxicity and status games drive away good contributors who do not want to get involved in the politics. A healthy DAO culture must make this behaviour unacceptable and stomp it out in an unforgivable manner. Otherwise, it undermines the legitimacy and authority of the DAO itself.

Good governance is what makes large organisations and ecosystems successful. DAOs are one way to implement it. The final organisational structure must serve the people, the system, and what is being governed, regardless of any constraints that ideological advocates may wish to place on it.

People will remember governance systems that leave a real impact on the world and make everyone wealthier as a result. They won’t remember systems that failed because they clung to ideals that didn’t work in practice and did not attract those who want to build.

I am grateful to my colleagues at the Arbitrum Foundation like Andreea, Raam, Cliff and Mateusz, who have spent countless hours and even more brain cycles working with me to improve the ArbitrumDAO.

All views expressed here are my own and not representative of my employer. They are just personal musings and strong opinions, weakly held.

There is no silver bullet for fixing DAO governance.

It is the realm of people problems, not technical problems. And people problems are really hard to solve for.

Still, there are promising directions worth exploring, based on heuristics and lessons from real-world experimentation. None of these ideas are guaranteed to work, but they are worth trying as we search for the next steps in evolving DAO governance into something more effective.

We’ll first explore a set of protocol goals that we may want to strive for in the design of a DAO. Then, the discussion will focus on how the goals can be applied to the ArbitrumDAO. Of course, the discussion is applicable to other ecosystems tackling similar issues.

Considerations for Operating a DAO

Running a DAO is not just about voting — it is about making decisions, executing them, and ensuring accountability.

This process starts with a clearly defined voting system, a collection of voters, and a governance surface that outlines what the DAO controls. The voting population should reflect those with a long-term interest in the DAO.

The output of the voting system is a proposal which includes a set of actions that need to be carried out once approved by the collective. All participants should embrace a culture of collective responsibility: disagree and commit once a proposal has passed.

Yet, governance is costly.

Governance demands time, attention, and coordination. It takes time for everyone to come together, read a proposal, discuss with each other, and eventually make a decision on whether it should be approved. As such, only proposals that can truly entice everyone’s attention should go through this process.

Put another way, governance must be minimal for it to be effective and the entire process should be reserved for matters of great significance.

The DAO can approve actions, but it needs a team to carry them out. This requires two things:

• Trusted Teams. The DAO should have a set of dedicated teams who are capable of executing the work.

• Decision-Making Body. An agile decision-making body should be empowered to handle post-approval proposals and oversee their implementation.

The team and decision-making body can work together to iterate on the operational details of a proposal as long as it remains in the spirit of what was approved by the DAO. This is in line with governance minimalism as the proposal can focus on desirable outcomes and trusted teams work out the finer details as more information becomes available.

Finally, DAOs and governance in general, must be resilient to capture. In the sense that no actor can push self-serving proposals through the process or block the process entirely. Governance only matters if decisions are executed as promised. To that end, DAOs need clear structure to ensure accountability and follow through.

Protocol Goals for DAOs

Here is an incomplete list of goals that are important for DAOs and effective governance in general:

Autonomous Execution. Token holders should be able to directly enforce their collective will over the systems and resources the DAO governs.

Governance surface. The DAO should define what it has control over and its authority should be clearly defined.

Multi-Stakeholder Participation. Relevant stakeholders should have both the incentive and means to participate in governance. The influence of a stakeholder on the decision-making process should be measurable and the governance system should reflect all stakeholders.

Optimistic Decision-Making. A decision-making process that allows decisions to be made swiftly on behalf of token holders while still upholding the DAO’s right to veto or override any such action.

Flexible, Accountable and Trackable Proposals. An organisational layer that makes approved proposals easy to review, track, and hold accountable. This structure should allow proposals to be flexible in execution as long as the outcomes remain aligned with what was promised to the DAO.

Governance Minimisation. The decision-making process should be invoked infrequently, or only when needed, to make decisions that may impact all stakeholders in the ecosystem.

Resistance to Capture. It should be difficult for a single party to capture the entire decision-making process in the DAO, and if it occurs, there should be a mechanism available to deter and veto it.

Let’s explore whether any of these goals have been met, and if not, consider how they might be achieved.

Autonomous Execution

To date, the ArbitrumDAO has focused on Autonomous Execution, and in my view, they have done an overall good job at achieving the goal.

The suite of governance smart contracts control the treasury and has the power to upgrade the smart contracts. Beyond emergency and non-emergency patches to the codebase, as entrusted to the security council, all upgrades are approved via the proposal process in the DAO.

There is still an argument on whether security councils undermine autonomous execution and I have written about this previously. My short answer is no. Security councils are absolutely necessary, and in some ways I hope they never disappear.

When it comes to governing legal entities, the ArbitrumDAO generally reigns supreme with ultimate control. Token holders can replace directors of the Arbitrum Foundation, they must elect the AGV Council on an annual basis, and similarly so for the OpCo as well. There is an interesting debate about the long-term viability of Foundations which you can read here.

Governance Surface

Autonomous execution is only meaningful if the DAO’s authority is clearly defined. Governance surface determines what the DAO actually controls and to what extent.

This is where programming and law diverge in how they define control. In software, control is explicitly and precisely defined with little room for ambiguity. In contrast, the legal realm operates through legalese, a language designed for broad coverage and crafted to anticipate future developments and address unforeseen circumstances.

DAOs must navigate the tension between precision and broad coverage by leveraging both approaches to define control.

Ideally, a proposal should clearly state what the DAO will control if the vote passes. Examples of control includes the authority to claw back funds, authority to replace the team, execute on-chain actions or change configuration details such as extending a proposal’s term.

In practice, it has been easier to express the intention of control in the text and the final details are handled after the proposal has passed. For example, writing the smart contract code or preparing relevant legal documents like service level agreements or bylaws.

Interpretation issues do arise from time to time as proposal authors are not well-versed in defining governance surface of control mechanisms. This is why there must be an empowered body on behalf of the DAO that can act as an authority to interpret what the DAO has voted on. If there is a dispute between this body and the authors, then the matter should be brought forth to the DAO to adjudicate on.

One issue that does arise is scope creep after a proposal has passed. Voters may demand changes or add new conditions not originally included in the approved scope. While these demands are sometimes well-intentioned, they can create uncertainty and shift power towards micromanagement. There is no right answer on how to deal with this situation and generally should be evaluated on a case-by-case basis.

Governance Minimalism to Fix DAO Participation

The ArbitrumDAO is already remarkable in one respect: there are numerous occasions where over 70% of explicitly delegated tokens consistently participate in votes. This demonstrates that engaged stakeholders are actively involved in its governance.

However, given the size and diversity of the ecosystem, many key contributors including application builders, DeFi protocols, gaming teams, Orbit chains, and others who are building on top of Arbitrum, are missing in action. This has led to some issues around quorum thresholds as the total supply of votable tokens continues to increase every month.

The issue of multi-stakeholder participation in the ArbitrumDAO is not related to token distribution. The problem is accessibility, awareness, and perceived value of actually participating. Fixing this requires resetting expectations in the DAO, especially around the type of proposals that are brought forward and the overall volume of governance activity.

There are three key metrics for evaluating participation in the DAO:

• Voting participation. Growth in the quantity of delegated tokens and the total number of votes cast per proposal.

• Stakeholder Engagement. Total stakeholders consistently kept informed about proposals alongside efforts to collect feedback when relevant.

• Execution Alignment. Presence of aligned teams actively executing DAO-approved proposals on behalf of the team.

Let’s consider voting participation and stakeholder engagement. The first step is personal outreach. They should be invited to participate in governance. There should be one-to-one teach-ons to walk the stakeholder through how the DAO works, why they should care for it, and how to get involved. At a minimum, the goal should be to encourage delegation of tokens, and ideally, active voting.

We must also respect that not every stakeholder wants to engage in the public. Some prefer private discussions. That is perfectly fine. We should embrace different modes of communication as long as all relevant stakeholders can remain informed and have an opportunity to provide constructive feedback. The goal is to meet stakeholders where they are and not force them into a specific mode of engagement.

It may be the case that a trusted team, like the OpCo or Arbitrum Foundation, acts as a point of contact to gather feedback, facilitate private conversations, and integrate stakeholder input into a proposal. Additionally, they can produce executive summaries, host debriefing calls, and support stakeholders in understanding key details.

To avoid voter apathy and fatigue, the DAO should only process a handful of proposals at any given time. We should work towards absolute minimal governance activity and consider it exceedingly expensive to invoke. A proposal should only go through the process if it is indeed truly significant and the proposal’s impact can truly entice the interest of relevant stakeholders.

Additionally, toxicity is one of the fastest ways to drive away participation, and the DAO should adopt a zero tolerance approach towards bad-faith actors, hostile behaviour, or agents who actively seek to bring conflict into the public arena outside of the DAO. A maximum politeness policy should be the cultural norm, conflicts should be resolved amongst active participants in the DAO, and wealth creation games should always be prioritised over status games.

Finally, participation is not limited to voting, but executing the DAO’s will. Teams entrusted to execute on proposals should have proper alignment with the ecosystem. They should care more about the long-term success of the ecosystem over their own short-term interests.

If a team’s survival depends on a proposal moving forward, it creates a perverse incentive to keep a failing initiative alive rather than acknowledge when it should be shut down. This is primarily why we should no longer entertain vendor-specific proposals.

The Arbitrum Ecosystem is exceedingly lucky.

There are five teams, with 3 teams organically emerging from the DAO, who are willing to execute on proposals on behalf of the DAO. This includes Offchain Labs, Arbitrum Foundation, Entropy Advisors, Arbitrum Gaming Ventures (prev. Gaming Catalyst Program), and the Operations Company (OpCo).

If the ArbitrumDAO is successful, and the Arbitrum ecosystem is successful, then ultimately these companies will also be successful. We should take advantage of them to do more work on behalf of the DAO.

Optimistic Governance and Flexible Proposals

The solution sounds obvious once it is stated: complement the waterfall model with an agile methodology to enable iterating on the proposal as more information becomes available.

In practice, this requires a secondary governance mechanism to be implemented to quickly approve changes as long as they remain within the spirit of what the DAO approved.

The second governance mechanism can take many forms:

• Legal entity for oversight alongside a service-level agreement,

• DAO-elected committee empowered to approve deviations,

• Optimistic model where the author publicly proposes changes and proceeds unless an explicit community-wide vote vetoes the decision.

In the ArbitrumDAO, the second governance body mechanism is expected to be fulfilled by the Oversight Committee (OAT) and the Operations Company (OpCo).

The OpCo should maintain a dedicated team to monitor the implementation of approved proposals, follow all workstreams, and hold accountable the proposal’s progress. If a proposal requires a pivot or adjustment, the OAT can review and approve those changes on behalf of the DAO.

With the above in mind, proposals should no longer be rigid or read like a cooking recipe. They should be goal-oriented with an initial plan on how to achieve the goal. The plan should be expected to change over time as the team iterates and the governing body can validate changes to ensure the proposal remains aligned with the DAO’s priorities.

Finally, proposals should not be tied to specific vendors. Instead, the outcome of a proposal should be owned by a trusted team accountable to the DAO. That team should manage procurement, select and onboard service providers, and terminate them as needed. It should not require a return to the DAO proposal process to remove service providers and the public dispute that entails.

Resistance to Capture

There are three key components that every DAO must focus on to prevent capture:

• Defending the integrity of the DAO’s voting system,

• Enforcing control and autonomy when executing the DAO’s will,

• Mitigating operational risk by eliminating single points of failure.

In regards to defending the integrity of the DAO’s voting system, a core pillar of governance is enabling stakeholders to express their views while ensuring no single actor’s voice carries disproportionate weight relative to their expected influence.

The principle is not so different from how proof of stake or proof of work protocols operate. In those systems, a validator with a certain percentage of voting power is expected to have an equivalent percentage of influence over the network.

DAOs should strive for the same standard.

Voting power is intentionally measurable through the voting system and directly reflects a participant’s influence in the decision-making process. This is why it is critical to encourage token holders, especially large ones, to actively participate in governance. The governance platform should accurately represent the views of all stakeholders in the ecosystem.

Capture is not just about pushing proposals through the process, but the ability to oscillate the decision-making process and block any progress.

Governance only works when there are conflicting views that generally all agree on the same direction, forcing compromising, negotiation, and rethinking approaches that people will eventually approve of. If we end up in a world with extremely divergent views, then no progress is made, or worse, the community splits. Effectively the same impact as capturing the DAO.

Influential bodies may emerge who can exert soft power over governance, even without holding significant voting power. This is why onboarding token holders to actively participate in governance and improving the distribution of hard power through voting is essential. Broadening participation helps dilute influence of any single entity and reinforces the legitimacy of the process.

There is an academic paper that studies decentralization in voting blocks for a DAO and the ArbitrumDAO ranks fairly well on this front.

In regards to enforcing control and autonomy of the DAO, capture is often discussed in the context of decision-making. This includes attempts to weaken the DAO’s control to approve software upgrades, transfer treasury assets, or exert authority over legal entities acting on its behalf.

However, there is a second, less obvious form of capture that occurs at the execution stage of a proposal. Even if a proposal has passed through the legitimate governance process, the DAO may lack mechanisms to ensure that the work is carried out as promised. This can lead to de facto capture – not through overt influence, but through neglect, lack of follow up and insufficient accountability.

This tends to happen as DAOs are overly focused on a proposal before it passes, but then overlooks its execution due to more immediate and pressing priorities that arise later. Ensuring follow-through is not a problem that technology alone can solve. It requires optimistic governance and trusted teams to keep track of proposals, uphold promises and the rules, and if needed, seek recourse via the legal system on behalf of the DAO.

Finally, the whole premise of DAOs and blockchains in general, is to avoid single points of failure and build resilient systems. Put simply, the risk of operational capture. This is why I find the emergence of an ecosystem of firms and companies working on behalf of the DAO so promising.

The idea that a multitude of companies can work for the DAO first struck me around the time that Plurality Labs received a grant from the ArbitrumDAO (July 2023). It sparked a strange but exciting thought experiment:

• What if a DAO doesn’t just fund isolated vendors, but instead supports a group of independent companies?

• Each focused on a different domain with its own leadership and yet all aligned working towards the same shared mission?

• Would that resemble the departments of a traditional organisation? Or is it something entirely new that is decentralised, adaptive and emergent?

In the ArbitrumDAO, it has taken a few years, but it has organically emerged. The DAO has bootstrapped three organisations including Entropy Advisors, Arbitrum Gaming Ventures, and Arbitrum’s Operation Company (OpCo). All teams, including the ideas for the organisations, came from participants in the DAO. So, the ArbitrumDAO has proven, this can be done.

I do believe there should be no playbook on how to establish an organisation that works for the DAO. After all, an organisation needs to be funded, which can cost hundreds of thousands of dollars, if not millions. The organisation should arise naturally within the compounds of the DAO and everyone should reach a rough consensus that it is indeed a viable thing to do.

Conclusion and takeaways

I’d like to take this opportunity to put together a list of heuristics that can help guide DAOs towards more effective governance based on everything we have discussed:

• Governance Design and Boundaries

  • Decide the surface of governance and what the DAO should control,

  • Proposals should be goal-oriented, flexible and trackable, not rigid or recipe-like.

  • Optimistic governance enables agility and adaptation during execution,

  • DAO Governance is expensive – minimalism is a feature, not a flaw.

• Organisational Execution

  • Trusted teams, not vendors, should pursue proposals,

  • Vendors should be hirable/removable without DAO-wide votes,

  • Focus on strategic outcomes and not vendor pitches,

  • DAO should not be deciding on operational details,

  • Councils are easy to create, but often slow to move – effectiveness depends on members and not the structure,

  • Traditional recruitment processes and active outreach work wonders,

• Voter participation

  • Embrace large token holders and focus on complete representation of stakeholders,

  • Engage voters where they are, even if it is outside public forums.

  • Voters should participate due to self-interest, not incentives or compensation.

  • Participation should be lightweight, predictable, and worth a delegate’s time.

  • Respecting some stakeholders prefer private discussion and that is ok.

  • Produce executive summaries, regular calls, and keep voters up to date in a way that informs, but does not sway decision-making.

• Culture and Resilience

  • Maximum politeness and resolve conflicts within the DAO,

  • Wealth creation games over status games,

  • Accountability is critical in all aspects of the DAO,

  • Foster an ecosystem of firms who care just as much, or more so, than the project’s founders.

  • Dedicated teams will emerge organically, support and fund them when the moment is right.

One final thought – an ecosystem is truly successful when it can outlive its original creators and founding organisations. When it can reach escape velocity and become self-sustaining. At that point, the genie is out of the bottle. The role of governance, and of DAOs more broadly, is not to stop that from happening, but to ensure that once the genie escapes, it can remain accountable, aligned, and hopefully manageable.

The heart of every DAO is a public proposal process which invites anyone to participate in, encourages negotiation, and a community-wide vote to decide whether a proposal should move forward.

We’ll explore several key issues that arise in the proposal process: lobbying and coercion, competitors and frameworks, rigid proposals that lead to inaction, and voter apathy driven by the sheer volume of proposals – all of which fall under what is often called “DAO politics”.

This is not an exhaustive list, but I believe understanding these challenges is essential before we can design solutions for more effective governance.

Navigating Proposal Process and Preference for Frameworks

While the proposal process can generate valuable ideas and attract contributors, its open and public nature also creates friction. As we will see, authors may face a swarm of competitors or opposition before their work can advance. At the same time, in order to appease all parties, DAOs will lean towards frameworks that share the work amongst everyone as opposed to making opinionated bets.

Navigating Among Too Many Chefs

A well-meaning proposal can attract tens or even hundreds of comments from delegates, each with their own suggestions, critiques, and conflicting priorities:

• Delegates might question the scope,

  • “Why target this user group?”

• Demand greater DAO participation,

  • Why not include other contributors?

• Suggest entirely new directions.

  • Why not pivot the proposal and apply the same skills to a different problem?

The entire process can quickly become a minefield for the author to navigate and usually ends in one of three ways:

• Navigated successfully. The author manages to navigate the politics involved in pushing a proposal through the DAO, it is approved by delegates, and they can then execute the work on behalf of the DAO.

• Abandon proposal. An author may struggle to navigate the contradictory feedback and fail to gain a sense of whether delegates will support the proposal. It is not uncommon for the author to eventually abandon the proposal even if it is overall a good idea that is likely to pass.

• Ultimatum dynamics. An author may reach a breaking point after attempting to negotiate with the host of delegates and simply offer an ultimatum: "either accept the proposal as-is or reject it”.

The fundamental issue is that a proposal author is forced to navigate a fragmented and often uncoordinated group of delegates rather than negotiating with a single counterparty.

Even if an author navigates the process successfully, it does not imply the final proposal is optimal for execution. A proposal that survives the process often undergoes significant revisions which can improve it, but also introduce compromises and complications that hinder its long-term success. In ultimatum cases, delegates may approve flawed or overpriced proposals simply to ensure there is progress in the DAO.

This dynamic becomes especially concerning when the DAO controls a large treasury. A single proposal that overcharges the DAO can easily be overlooked. Also, and potentially more concerning, delegates bear no direct costs to them and the impact on the DAO’s treasury as a whole appears negligible in the short term. If the problem is left unchecked, this pattern can lead to inefficient spending and accelerate the depletion of the treasury.

Competitors and Frameworks

The public forum, in some ways, serves as a natural discovery mechanism for identifying service providers interested in offering a particular solution.

For example, let’s assume a service provider publishes a proposal to the DAO that offers their services in exchange for a fee. A competitor sees the opportunity, quickly assembles a similar pitch, and submits a competing proposal. As a result, multiple proposals addressing the same problem often appear on the forum in quick succession.

On a positive side, this shows that service providers are actively engaging with DAOs and looking for opportunities. The DAO attracts interest without needing a formal request for proposals process as long as one service provider is willing to pull the trigger.

The downside is the swarm effect.

Once multiple competitors are involved, the path of least resistance often shifts from evaluating and selecting the best proposal to establishing a broader framework where all participants can benefit financially. Because this process unfolds in public, it also becomes socially difficult to reject some proposals outright, even when, in a traditional procurement setting, only a handful of providers might be chosen.

On top of all this, there is a prevailing ideology in DAOs that resources should be shared equally amongst all who apply. Swarms of competing vendors often reinforce this mindset as it increases their chance of inclusion. But this approach is problematic as resources, like funding and team capacity, are limited. It also encourages political maneuvering to appease everyone rather than focusing on solving the actual problem.

Lesson: True equality isn’t what most people really want. What they value more is fairness, the sense that everyone has a chance, outcomes are based on merit, and the rules apply equally to all.

Vendor Specific Proposals and Not Strategic Goals

It is common for proposals to be written in a way that only the author is positioned to carry out the work. From the author’s perspective, this is rational. Avoid competition, keep delegates focused, and present themselves as the only option.

Interestingly, at times, authors may even apply social and emotional pressure on delegates to justify the funding. After all, the author went through the effort to write the proposal, navigate the DAO’s proposal process, negotiated with all the delegates, so it should be funded.

In my view, it is problematic for the DAO to facilitate vendor-specific proposals. It prevents the DAO from running a more deliberate and competitive procurement process which not only helps find a good team, but also leads to competitive pricing to complete the job. Tying a proposal to a specific vendor also has a lock-in effect that makes it difficult to terminate the service as it often requires a community-wide vote and the public process that entails.

The final, and perhaps biggest issue, is that vendor-specific proposals put the DAO in a reactive position. Many delegates are still new to the reality that an avalanche of vendors want to sell their services. When a polished offer shows up, it feels novel and there is an instinct to make it work, even when the service is not necessary. There is still a large degree of innocence amongst the community on the persistent lobbying by vendors in order to win business deals.

Rigid Proposals, Accountability and Too Much Control

In practice, delegates are expected to track the progress of approved proposals and ensure that authors deliver on what was promised. Especially when those same authors return with follow-up proposals that request further funding to continue the work.

This brings up a broader challenge: accountability.

When reviewing a proposal, a delegate must assess not only how to improve the idea, but also how the author will be held accountable for delivering the final outcome.

In the simplest case:

• Is there a clear and objective way to determine whether the proposal was successful?

To answer this, delegates will often request a list of ‘key performance indicators’ (KPIs) and/or ‘objectives and key results’ (OKRs) to help define what success looks like after the proposal is executed.

For example, if a proposal seeks funding to run an accelerator for 30 early-stage startups, a KPI might specify that at least five of those projects should graduate and go on to raise a Series A from top-tier venture capital firms.

In the harder case:

• Did the author actually do what they said they would?

The question often leads to proposals resembling cooking recipes: a list of ingredients, set of instructions, and the final outcome. Proposals become rigid and authors are expected to follow the plan exactly as defined.

The motivation for delegates to advocate for a rigid structure is understandable. It makes it easier to estimate costs and verify whether the work was delivered as promised. However, the need for a rigid structure can backfire.

More often than not, authors will discover a better approach or want to course correct while executing the proposal, especially if any unforeseen circumstances materialise which happens quite often. However, any deviation from the approved plan typically requires a follow-up community-wide vote. This is a herculean effort in its own right and may delay the proposal’s execution by at least 2 weeks, if not months.

As a result, even when changes would clearly benefit all parties, authors often stick to the original plan simply because that is what was approved. The system rewards strict adherence over iterative improvements.

The fundamental problem is that the DAO proposal process follows a waterfall model when in reality most organisations may agree upon an initial plan, but follow an agile methodology to quickly iterate on the plan as new information becomes available.

Voter Apathy, Too Much Volume and Repetitive Work

One of the common mistakes DAOs make — like many new systems — is over optimising for participation. They design incentives to attract more contributors, more voters, more proposals, and aim for maximum engagement from everyone all the time.

But this overlooks a simple constraint: delegates have limited time.

In reality, most delegates can only meaningfully process a handful of proposals per month. Yet, when there are four or more proposals per week, each requiring time to read, understand, assess, and to vote on, it is no surprise that delegates are overwhelmed simply by volume alone.

Worse still, if multiple proposals are passed weekly, the DAO ends up with tens or even hundreds of active work streams running simultaneously. This isn’t necessarily a bad thing if the organisational structure exists to manage that level of throughput. But in most cases, it cannot. And work begins to fall through the cracks. Not because anyone is incompetent or avoiding work, but simply there isn't enough capacity to keep up.

When it comes to reviewing proposals, delegate incentive programs have appeared that financially compensate delegates to vote, leave comments, and engage publicly.

While some feedback is thoughtful and genuinely valuable — as the program intends — these incentives can also distort the conversation and encourage spam-like behaviour. In some cases, delegates leave superficial comments in order to tick the box required for rewards. Going further, some feedback even appears to be AI generated. Both contribute little to the actual discussion.

On the topic of feedback, public discourse is not ideal if a delegate wants to share criticism of the proposal. Even the slightest public criticism can damage the relationship between a delegate and a proposal author. As a result, delegates tend to offer feedback privately to avoid public shaming or reputational fallout. This creates a disconnect, where public discussion appears positive, while private sentiment among delegates may be far more critical.

This probably reveals a deeper truth that governance needs to adapt to how delegates prefer to give feedback, even if that doesn’t always happen through public discourse.

Social Pressure, Private Voting, and Delegate Transparency

DAO governance often involves tensions between authors of a proposal and delegates who vote on the proposal.

Proposal authors often lobby delegates to support their initiative. Because voting is public, delegates who oppose a proposal risk burning social capital, especially if they plan to bring forward their own proposal in the future.

Some degree of lobbying is healthy within a decision making framework and it should be encouraged. But problems arise when lobbying distorts incentives. If a coercer can force delegates to prioritise short-term relationships or their own reputation over long-term interests of the DAO, then it may result in non-optimal outcome and represent a potential takeover of governance.

Private voting can help mitigate this and reduce social pressure. Delegates can publicly commit to a position, but privately vote according to their own judgement. However, privacy only goes so far. If a coercer can observe the voter as they cast their vote or if a voter can prove how they voted afterwards, then the pressure may still remain.

Unfortunately, private voting introduces inherent trade-offs that make it difficult to adopt in DAOs.

One major issue is delegation. In most DAOs, token holders delegate their voting power to others. But if votes are private, delegators lose the ability to verify how their delegates voted and whether those votes align with their own preferences. Selective disclosures, where the voter can reveal their votes to delegators and not others, can help address this issue. But it comes with its own attack surfaces (e.g., poisoning attacks) and remains largely unexplored in the context of DAOs.

A second issue is autonomy. Most private voting systems rely on one or more external tallying authorities to complete the cryptographic tallying process and publish the final result. This is because a smart contract cannot securely hold or use private keys. Dependency on a tallying authority undermines the DAO’s autonomy. If the tallying authority goes offline, for whatever reason, then the voting process halts and the DAO loses the ability to guarantee liveness and enforce outcomes on-chain.

Summary

The proposal process invites public participation, negotiation, and relies on community-wide voting to make decisions. While the structure aims to be inclusive and transparent, it also introduces significant political, operational and social challenges often referred to as “DAO politics.”

This article examines key friction points that emerge within the process:

• An overwhelming volume of proposals,

• A minefield of contradictory feedback for authors,

• Lobbying and social pressure on voters,

• Swarm of competing vendors and vendor-driven proposals,

• Rigid proposals that read like cooking recipes,

• Private voting is difficult to implement and not a silver bullet.

In many cases, the frictions arise not because parties are malice, but because they are well-intentioned.

Proposal authors want to be fairly compensated for carrying out work for the DAO, vendors do not want to lose out to their competitors, voters want to ensure everyone is accountable to what they promise the DAO, and the transparent nature of the system encourages engagement from all parties including those who lack context but genuinely want to help out.

The voting infrastructure works as intended. The real challenge is human.

A core challenge is assigning trust and who can be relied upon to carry out the DAO’s will. When each proposal comes from a new, unvetted team, and voters must perform diligence every time, then it is no surprise that voters are overwhelmed, vendors flood the process, and authors face contradictory feedback.

To address this, DAOs need to establish a middle ground, where trusted teams or bodies are empowered to act on the DAO’s behalf. These entities can take responsibility for executing proposals, overseeing vendors including hiring and terminating them, and making decisions that are in alignment with the intention of an approved proposal.

By doing so, DAOs can move beyond rigid processes and towards more agile, accountable execution, without sacrificing the core value that is important: autonomy, control, and the supreme decision maker.

There are some solutions based on the above that we explore in the next article — Learning From Failures to Build Better DAOs.

DAOs enable collective decision making on a global scale. It is designed to be publicly verifiable and offer transparency in real-time. These systems enable participants not only to coordinate decisions, but also to autonomously enforce them through on-chain execution.

At the heart of every DAO: a list of voters, a distribution of voting power, a voting system to tally the votes and a means to execute the will of voters.

People deploy DAOs to coordinate around a shared purpose. They can organise ad-hoc efforts like purchasing a copy of the US constitution, coordinate the treasury and decisions made by investor syndicates, or govern an entire ecosystem from the software to the organisational structure.

Let’s take this opportunity to explore the D, A, and O in DAO to better understand the principles behind it.

“D” in DAO — Targeting Stakeholders

A fundamental problem to solve in governance, regardless of DAOs or traditional systems, is distributing power to the right people. Those who are aligned with the mission, care about the system, and have meaningful skin-in-the-game for its long-term success.

This should happen naturally.

In corporate governance, a founder typically starts out with 100% ownership in the venture. Over time, through hiring, fundraising, and strategic partnerships, they gradually distribute ownership and influence to others who become aligned with the broader mission. Eventually, a company may go public, allowing an even wider set of stakeholders to gain a degree of influence.

In Bitcoin’s early years, Satoshi Nakamoto held all meaningful authority. Even after stepping back, Satoshi retained enough legitimacy to appoint a successor by naming Gavin Andresen as the lead maintainer. Over time, the mechanism of rough consensus took hold, and the Bitcoin Core project collectively established their own governance norms, determining who should have commit access and the ambiguous (alongside notoriously difficult) process for upgrading the network.

In the DAO world, the path of least resistance for distributing power is to issue a governance token. This is typical of DAOs that govern entire ecosystems. The intention is to allocate tokens to individuals aligned with the mission and motivated to participate from the outset.

Tokens may be distributed through mechanisms such as private fundraising, initial coin offerings (ICOs), and airdrops. In some cases, tokens are directly allocated to specific stakeholders, such as in proof-of-personhood systems or DAOs with defined membership, like an angel syndicate.

Depending on whether membership of the DAO is permissionless or restricted, tokens can also be made publicly available for others to acquire which allows them to gain alignment and the right to influence the decision making process.

Tokenisation lets us define voter eligibility based on ownership and typically compute voting power proportionally to token holdings. Many DAOs also support delegation which allows passive holders to outsource their votes to more engaged or knowledgeable participants.

To date, even if tokens are well-distributed, there is no guarantee that the people who should participate actually do. And sometimes, ideological proponents of public governance, actively discourage them from doing so.

For example, when a16z — Uniswap’s largest backer — votes against a proposal, it triggers backlash that a16z controls the Uniswap DAO.

This framing is misguided.

The voting system is working as intended.

Fairness is defined as voting power aligning with token ownership. The real issue isn’t that a16z can sway the outcome of a vote, it is that more large holders do not participate. Rather than discouraging major stakeholders from participating in the name of decentralisation, we should focus on encouraging broader participation across the board.

To summarise, the fundamental problem facing the D in DAO is ensuring the right stakeholders are actively participating in governance.

“A” in DAO — Autonomous and Control

The “A” in DAO — Autonomous — refers to the ease with which a DAO can exercise its authority and enforce outcomes based on decisions made by voters.

As we discussed previously, DAOs are typically deployed to govern a suite of smart contracts. This includes upgrading the smart contract code or invoking functions in the smart contracts to perform certain actions. For example, spending from the treasury, changing a configuration, or replacing privileged actors in the system.

The first example was TheDAO which launched in 2016. It was designed to serve as a decentralised governing body for a shared treasury. Token holders were expected to collectively review proposals and decide whether capital should be allocated. If the investments were successful, the returns could flow back to TheDAO’s token holders.

TheDAO raised 11.5 million ETH — roughly 15% of all ETH in circulation at the time — valued between $50 million to $150 million depending on the ETH price.

As history remembers, TheDAO ultimately blew up due to a reentrancy bug, but the concept has only grown stronger since.

Today, several major DAOs — including ENS, Arbitrum, Lido, Maker, AAVE — continue to pursue this original vision of decentralised governance. In fact, according to DeepDAO, DAOs across the ecosystem collectively manage approximately $15bn in assets. The autonomous aspect of a DAO in relation to governing smart contracts works as intended.

Of course, the story of autonomy does not end with smart contracts.

DAOs are no longer limited to controlling code. They are increasingly asserting authority over organisational hierarchies and even legal entities. To support this broader scope, new entities — often referred to as BORG-style entities — have emerged. These include efforts like Wyoming DAO LLC which attempt to provide legal clarity by recognising DAO votes as binding within a formal legal framework.

Unlike smart contracts, where control and authority are transparent and verifiable on-chain, applying the same level of clarity to the legal domain is more complex. It will take much longer for courts and legal systems to fully recognise DAO autonomy over real-world entities. It is not just about defining and structuring control, but that control being recognised and enforceable in legal adjudication.

“O” in DAO - Hierarchy via Popular Vote

A DAO is fundamentally a voting system that can govern a treasury that can be used to fund an organisational hierarchy.

Anyone can submit a proposal to:

• Hire individuals or a team,

• Form a committee,

• Onboard service providers,

• Form a new legal entity.

Voters are expected to review proposals, provide feedback, and cast a vote with their final decision.

This leads to a core, and often debated, principle of DAOs:

• A community-wide vote must approve the compensation for a contributor or service provider.

The real-world equivalent of this situation is gathering all the villagers to a town square, presenting a proposal for some work, and asking everyone to vote on whether it should move forward at the proposed cost.

Many proposals do succeed through this process, leading to the hiring of individuals, teams, or service providers. But most people quickly realise this isn’t an effective approach to evaluate proposals, negotiate terms, or hold proposal authors accountable over the long term.

It soon becomes clear that a more structured organisation is needed to operationalise the DAO.

A common solution is to form committees to support procurement and coordinate specific initiatives. Committees are a popular model because they often function as consultancy-style arrangements:

• Contributors can retain their full-time job while earning compensation for their work in the DAO in a side-gig capacity.

• Service providers can participate as committee members and add an additional revenue stream for their business.

This approach helps bootstrap the DAO’s operational ability with people who can be onboarded quickly and start contributing immediately. Additionally, it is a means to instantiate optimistic governance, where people can make certain decisions on behalf of the DAO, while the wider DAO retains its ability to recall them.

However, DAOs become over-reliant on committees. It is not uncommon to see more than ten committees, each focused on different initiatives, with their own custom processes and contact points.

This leads to a range of issues:

• Recruitment problems. How to attract and onboard talented people beyond those who are willing to lurk a governance forum,

• Activity gaps. Contributors with a full-time job will prioritise their duties over their DAO responsibilities,

• Role confusion. Service providers who typically adhere to a fixed scope of work are now making strategic decisions,

• Synchronisation issues. All committees have their own communication and information flows – leading to potential silos.

• Loss of information. Knowledge related to the initiative may not be preserved due to the ad-hoc nature of its membership and the cost to retain information beyond a committee’s remit.

There is also a recurring social tension: the perception of grifting.

Some proposals are seen as overcharging the DAO for the services offered. There are certainly cases where this may be true, but I am cautious about making that judgement lightly. When everything is public and compensation is determined through a community-wide vote, we shouldn’t be surprised (or upset) as people navigate that system to find work. The nature of compensation is inherently subjective and it often becomes contentious when made public.

The main issue with the committee approach isn’t the structure, but the fact that membership is often by people scattered across the ecosystem and lacking a central touch point. People are willing, and want to get involved, but it is often lacking a core team or members who steward the committee’s direction.

With the above in mind, the next natural step in building a more structured organisation for the DAO is the creation of a legal entity:

• Job security for contributors,

• Hire full-time staff via a traditional recruitment process,

• Synchronise team under a common leadership,

• Negotiate terms with service providers.

This often leads to jokes that DAOs are simply relearning everything that led to theory on firms. It also invites criticism that the DAO’s organisational structure is becoming increasingly centralised and at odds with the original vision of decentralisation.

There might be some truth to these critiques, but we should recognise that every community has the right to organise itself according to its own needs and values.

Take Ethereum’s early evolution, for example: The Ethereum Foundation led protocol research, Consensys acted as a venture studio to incubate startups, and other companies like Parity played key roles in the ecosystem. It progressively decentralised across different companies and firms.

Every ecosystem is different.

The goal should be to organise in ways that solve the problem at hand and anchored in shared values, but not constrained by rigid ideology.

Summary

The easiest part of building a DAO is implementing the on-chain voting protocol and designing the membership token. These technical components are well understood and straightforward to deploy.

The hardest challenges, however, are fundamentally human. They involve ensuring that aligned stakeholders are actively participating, that contributors are organised in a way that supports the long-term success of the DAO, and that the DAO’s authority is respected in legal disputes across jurisdictions.

In many ways, DAOs serve as a microcosm of real-world organisational dynamics as it showcases how people coordinate, distribute power, and build institutions from the ground up. The progression from individuals to committees to fully formed legal entities often mirrors the very problems that gave rise to the theory of the firm.

Yet despite these parallels, DAOs introduce fundamentally different constraints. Their global reach and radical transparency creates unique challenges. Recruitment often occurs through public elections, negotiations play out in real-time and in full view of the public as proposals move through the governance process, and participants frequently weigh short-term incentives against long-term interests.

We explore these dynamics further in the next article — so dive in and learn more about DAO Politics: Holistic Challenges in the Proposal Process!

However, just three days into the role, everything changed.

Blockworks ignited a fire in the DAO that quickly consumed the mindshare on the forum and twitter. It eventually led to delegates rejecting AIP-1 that was supposed to fund the Arbitrum Foundation and establish the entire DAO’s governance framework.

It was a full-blown governance crisis and certainly a memorable introduction to the world of DAOs.

In the aftermath, I volunteered as tribute to take on the task of governance and help set the DAO up for long-term success.

But as an academic at heart, I kept circling back to some fundamental questions:

• Why do we have a DAO?

• Why should anyone — including myself — care?

• Is it interesting or novel in any meaningful way?

Finding answers to these questions was not easy.

I had somehow gone from solving technical problems to navigating people problems. Many ex-colleagues questioned what I was doing with my time.

Over time, I’ve found my own answers to these questions.

This short post is my attempt to articulate the rationale behind why I believe DAOs are important tools for governance despite the many challenges they face.

The same individuals who sparked that controversy are now working full-time for the ArbitrumDAO via Entropy Advisors. Remarkable to witness someone quit their job and join forces with us because they also believe in Arbitrum’s digital sovereign nation vision.

Story: Governing Open Source Software

The story begins with publicly available software.

It is common for developers to make their code available on Github with the intention to allow anyone to:

• Read the code,

• Understand the code,

• Deploy a local instance of the software.

Anyone can modify the code and submit their patch upstream to the main project’s Github via a pull request.

This raises an important question:

• How should publicly available code be governed?

Someone must be responsible for reviewing a pull request and deciding whether a patch should be merged into the main codebase.

Nearly all open source projects start off with a small team of developers. But as a project grows in significance, a governance process must be established to allocate responsibility and accountability. This is commonly formalised through a file called CODEOWNERS.

CODEOWNERS defines who is responsible for which parts of the code base including specific directories. This makes it easy to identify the decision makers for any given section of the project. They should review the pull request, leave comments, and decide whether the code should be merged.

In some projects, especially for politically sensitive ones like Bitcoin or Ethereum, decision making is still heavily guided by social consensus. Code owners often see their role not as gatekeepers, but as reviewers who ensure that changes reflect the broader community’s intent.

Bitcoin Core’s decision to rename CODEOWNERS to REVIEWERS reflects this philosophy and more accurately reflects the role of code maintainers. The reviewers file was eventually removed because of complaints that the notifications were very annoying for reviewers, lol.

Keep in mind though — even if a patch is merged into the main codebase, that doesn’t guarantee the code will be used in production.

Only One Meaningful Deployment of the Software?

In the land of crypto, it is often the case that there is only one meaningful deployment of the software.

Anyone can download the code, run a local copy, and send transactions, but it isn’t meaningful beyond acting as a test network.

Launching a meaningful deployment of the software takes a Herculean effort to gain traction and sustain relevance over time. That’s why there’s only one Bitcoin, one Ethereum, one Arbitrum One, one OP Mainnet, one Solana, and one Avalanche.

There are times when the same software is used to deploy an entirely new network and the code is designed to make this easy to do. This is fundamental to the rollup-centric roadmap, the forking of blockchains, and the launch of new L1 blockchains.

Yet, despite sharing a common codebase at inception, each deployment tends to evolve independently. Over time, the code that underpins the live instance often diverges based on the unique need and priorities surrounding its ecosystem.

Blockchain Governance And Consensus Rules

Of course, going back to the problem of governance, this brings up one of the most important questions in blockchains:

• How is the live deployment of the software governed?

There are many components of a blockchain network that requires some form of governance and decisions to be made including:

• What version of the code should be used?

• What is the genesis block?

• What is the software’s configuration settings?

This is often referred to as the consensus rules for a blockchain network. All users must reach consensus on the same shared set of rules and users will run software that they believe faithfully enforces those rules. If different versions of the software implements conflicting interpretations, then this can cause a fork and users will end up on divergent views of the blockchain.

In the context of rollups, however, the model is slightly different. Users are not responsible for enforcing the consensus rules. Instead, it is the responsibility of a smart contract suite, commonly referred to as a validating bridge, which holds all user deposits. What matters in rollups is the state transition function which dictates access control, the validity of transactions, and how users can safely exit during an emergency.

In both cases, whether blockchains or rollups, we still need a process to collectively decide what rules should be enforced. This brings us to the challenge of governing systems that may secure billions, if not trillions, of dollars in assets.

As we will see, it is far from a straightforward problem to solve.

Towards Decentralised Governance

The philosophy of progressive decentralisation encourages projects to gradually transition control from a single authority (like the founding team) to the wider community as a network grows in importance.

There are many reasons a founding team may choose to step back and relinquish control: from limiting legal liability to recognising that their influence has waned as others in the community step up to lead key work-streams.

After all, Satoshi Nakamoto was fearful that Bitcoin usage with Wikileaks could be destructive. He described it as kicking the hornet’s nest and the swarm was headed for him. He stopped posting on the forum within a few days after those messages.

In many cases, the explicit goal is to build a system that can thrive beyond the founding team’s remit and can take on a life of its own into the long-term, hopefully for the next hundred years or more.

To date, there are two approaches to enable the community to take the reigns on governance:

• Rough consensus. Everyone signals they want to upgrade and this activates a flag day.

• Explicit voting. Participants cast a vote and the outcome is determined by the final tally.

Interestingly, both approaches, are opposite ends of the spectrum, as one embraces ambiguity and informal agreement while the the other depends on a formal and measurable consensus that seeks explicit confirmation.

Let’s take this opportunity to explore all three approaches to better understand the rationale that has led to the rise of decentralised governance including why DAOs are interesting.

Single Authority & Single Point of Failure

All projects begin with a single authority who coordinates the upgrade of the network.

The reasons are straightforward: only the core team understands the code base, the community is small with limited stake, and there is a need for rapid iteration to address bugs and add features.

This was true for Bitcoin too.

It was common for Satoshi Nakamoto to announce a software upgrade and inform node operators that they should upgrade in a timely manner. This was communicated on the mailing list, the bitcointalk forum, and the relevant IRC channels.

However, eventually when a blockchain network reaches a certain size and significance, the community needs to decide how it should be governed into the long-term.

Why is this necessary?

• The common answer —because decentralisation—is often invoked, though the term is frequently overloaded and imprecise.

In my opinion, it is important to eliminate single points of failure in decision-making and to ensure all stakeholders who depend on the network’s success have a voice in deciding how the live system develops overtime.

At some point, the live deployment of the software should become bigger than the core team and this is essential for long-term resilience of the system.

Rough Consensus & Hot Potato

One approach to governing a blockchain project is rough consensus. It has become the de facto standard in Bitcoin near the end of Satoshi Nakamoto’s term and certainly by the time he handed control to Gavin Andresen.

This model gained prominence during the Bitcoin Block Size War, where it served as a key defence to fend against hostile governance takeovers. It also played central role in Ethereum’s response to TheDAO hack, when the Geth client offered users a choice: upgrade to the hard fork chain or continue running the original chain containing the stolen funds.

But what is rough consensus?

It is a decision making process in which no single party can (or wants to) single-handedly dictate the software version used for the live deployment of the network. Instead, each party independently signals a willingness to upgrade, a flag day is set, and each party is expected to upgrade their software by that date.

The entire process resembles a game of hot potato — no one wants to be seen as initiating the upgrade, but everyone wants to agree that the upgrade should happen. When the potato falls into their hands, they can issue their signal before passing the potato onwards.

The greatest challenge, and some would argue, the greatest strength of rough consensus, is the ambiguity around how to assess the relevance or weight of a given signal.

For example, during the Block Size War, numerous Bitcoin companies expressed support for the upgrade, but the signal lacked overwhelming influence and ultimately failed to push the desired upgrade on Bitcoin.

This ambiguity is intentional.

It serves as a defence against hostile governance takeovers. By keeping it unclear who is making the final decision, participants maintain plausible deniability and are under no obligation to upgrade. In this sense, it makes the upgrade difficult to exercise, by design.

This reflects a broader expectation: reaching global consensus to change the system should be rare and it should become increasingly more difficult as time goes by.

Voting Systems and Self-Enforcing Autonomy

A voting system represents the opposite end of the spectrum from rough consensus. It favours explicit rules, formal procedures, and measurable outcomes over ambiguity and informal agreement.

The system has a predefined list of eligible voters and each voter is assigned an explicit voting weight. Voters are required to cast their vote within a specified time window and the final tally determines the community’s decision.

We say the voting system is autonomous when it operates entirely on a public blockchain and it has the authority to unilaterally enforce software upgrades.

There are several autonomous voting systems that are already live:

• Ethereum’s proof of stake protocol allows validators to vote in real time to adjust the block gas limit, directly influencing network parameters.

• Tezos, known as a ‘self-amending’ blockchain, enables token holders to vote on protocol upgrades focused on economic rules,

• The Cosmos SDK includes a governance module that allows token holders to propose and vote on software upgrades affecting a specific chain.

And most relevant for this discussion: DAOs on Ethereum. These organisations can coordinate proposals, assign voting rights to token holders, and self-enforce upgrades to the smart contracts they govern. All on-chain without relying on external actors.

It can be argued that all the examples above — from Ethereum’s proof of stake protocol to governance systems built around on-chain voting — fall under the broad definition of a Decentralised Autonomous Organisation (DAO).

What unites them is a critical ingredient: a defined set of voters can decide an upgrade should occur and the software itself enforces that decision.

In this model, authority is not merely a signal, but it is automatically executed through the code.

Which Approach Is Superior?

Both rough consensus and on-chain voting are mechanisms to measure the community’s intent to upgrade the software.

It is not necessarily the case that one approach is inherently better than the other. The key difference lies in the source of control for executing changes and there is a nuance in this distinction.

We can broadly categorise two sources of control:

• Social consensus with off-chain enforcement.

  • Upgrades happen when all participants voluntarily choose to run new software.

  • Control is ultimately held by the individuals or entities running the nodes.

• On-chain authority with autonomous execution.

  • Upgrades are encoded as permissible actions within the protocol itself.

  • Control is enforced by the software based on pre-defined rules and vote outcomes.

It just so happens that:

• Rough consensus aligns naturally with social consensus with off-chain enforcement,

• On-chain voting only really works when used to upgrade components that do not rely on off-chain coordination such as smart contracts on public blockchains.

This is why DAOs have found product market fit. The voting system not only records intent, but it can also directly enforce the upgrade of a suite of smart contract ensuring the agreed changes are executed.

ArbitrumDAO. The voting system can unilaterally upgrade the smart contracts that hold all funds in Arbitrum One. It is the smart contracts that are responsible for enforcing the rules and they will ignore any off-chain actor who is not running the correct version of the software.

This brings us to one of the most important takeaways for decentralised governance systems:

• Social consensus ultimately overrides on-chain authority.

No matter how autonomous or trust-minimized a system claims to be, if a devastating vulnerability emerges in a suite of smart contracts, then the last-resort option is to hard-fork the underlying public blockchain.

Interestingly, the Optimism documentation outlines an approach to entice Ethereum validators to soft-fork the L1 in order to unfreeze fends held in the bridge in the event of a critical failure. This proposal sparked significant controversy at the time including a blog post by Vitalik Buterin to caution against overloading Ethereum’s social consensus.

Are DAOs actually interesting?

Yes — they are interesting and very useful.

To summarise why:

• Relinquish control. DAOs offer a practical mechanism for founders to step back and transfer authority to stakeholders who are better positioned to govern the project over the long term. This enables a more sustainable and decentralised model of stewardship as the ecosystem matures.

• Specific domain. DAOs are designed to govern a specific domain — typically a suite of smart contracts — and they do so with clear, enforceable authority. This form of governance can operate autonomously on a public blockchain and remains independent of broader social consensus.

• Explicit nature. The on-chain voting system makes clear whose opinions count in an upgrade and how much influence each participant has. In many cases, voting power is proportional to token ownership, with weight measured by the number of tokens held. However, this isn’t a requirement, as alternative models can be explored such as proof-of-personhood with one-person-one-vote, are increasingly explored.

• Beyond software. Many DAOs have expanded their scope beyond just governing software deployments. They now manage ecosystem treasuries, establish organisational hierarchies through popular vote, and even exercise authority over legal entities, such as BORGs (Blockchain-Oriented Responsible Governance structures).

DAOs are far from perfect, but they remain one of the most promising tools we have for coordinating governance over a suite of smart contracts.

That said, they still have many problems.

A recent twitter thread has captured a range of opinions on why DAOs have “failed” to date. In my view, the biggest issue is perception: DAOs are often seen as toxic or adversarial environments which discourages thoughtful and sustained participation. This ends up with an adverse selection problem as valuable stakeholders who should be involved simply avoid it.

To be fair, many of these problems stem from the expanded scope that DAOs have taken on beyond governing software upgrades. They have budgets, organisational structures, and community politics, each introducing their own set of political and coordination problems.

Yet, even if DAOs simply focused on software upgrades, governance would still be far from straightforward. As the Bitcoin Block Size War made clear, even changing a simple configuration can become deeply controversial when the stakes are high.

I believe this can be fixed, but to do so, we need to acknowledge the problems and potential ways to solve for them. I have covered some of this in a recent talk and I hope to write more soon. 😋

Several years ago, I studied how smart contracts can enable bribery of miners to undermine Nakamoto Consensus. More recently, researchers have proposed DarkDAOs (alongside proof of concept implementations) that allow tokenholders to sell their votes to the highest bidder in a privacy preserving and trustless manner.

I assumed that vote-buying-as-a-service was still within the realm of academic interest and it was not likely to emerge any time soon.

I was wrong.

Crypto is funny sometimes. If something is technically possible, regardless of its morality, then sooner or later, a team will raise VC funds and deploy it at scale.

Let’s take this opportunity to cover some background on DAOs which includes voters, the voting system, and delegation before diving into the main topic.

Decentralised Autonomous Organisation (DAO)

The primary aim of a DAO is to bring together a group of stakeholders who are united by a common objective and empower them to work as a collective to tackle it.

The core function of a DAO is decision making — empowering the community to collaboratively make choices they believe will achieve their long-term objectives.

DAOs tend to have an open forum for communication amongst the community. Stakeholders include token holders, contributors, full-time employees, vendors, and anyone interested in joining the collective effort.

A large focus for a DAO is the passage of proposals. Anyone can propose a proposal, there is a feedback loop to revise the proposal, and eventually the proposal can be voted on by the DAO to decide whether to approve or reject it. If a proposal passes, then the community should execute on it, carrying out the necessary and agreed actions.

Any community with actionable decisions that require collective voting can form a DAO to coordinate the decision making process. Several examples include venture initiatives (buying the US constitution), ecosystem growth (ArbitrumDAO) and social (football fans).

Voters & Voting Weight

Collective decision making in DAOs relies on a voting protocol and voters who will cast their vote.

Voters are identified through their possession of tokens which confirms their eligibility to vote and their voting power.

There are several variants, but the most popular include:

• Token-weighted. Voters must hold specific tokens and it is typical that 1 token represents 1 vote.

  • The ARB token represents voting power in the ArbitrumDAO.

• Proof of personhood. A voter’s identity is verified by a third party identity service and they are linked to a token (like an NFT) that represents their voting rights.

  • Citizen’s house in Optimism. Citizens must prove their personhood to the OP Foundation before they are permitted to join.

This article is focused on token-weighted voting, but the principles discussed are applicable to any system that ultimately authenticates voters and determines voting power via possession of tokens.

Voting System

A voting smart contract can be implemented to enable collective decision making. If a proposal is passed by the DAO, then the smart contracts should have direct access to an on-chain treasury or the authority to upgrade the system. This ensures all actions authorised by the DAO are performed transparently and autonomously without the need for centralised control.

Voting privacy. All votes and the running tally are public. To date, it has proven difficult to implement private voting without the introduction of an off-chain tallying authority.

Proposals fall into a few key categories:

• Funding request. Request funds from the on-chain treasury to run an initiative on behalf of the DAO.

• Software upgrade. Proposals with bytecode that will update the on-chain smart contracts for the project.

• Informational. Seek consensus on specific pieces of information relevant to the DAO. Agreements are important for governance and operation of the DAO, but they may not always result in a meaningful on-chain action.

Of course, all DAOs are not the same and the final implementation of the voting protocol may significantly differ to what is described above. The main premise is that on-chain smart contracts can enforce the voting protocol and ultimately govern the treasury and project’s code.

Popular implementations include the OpenZeppelin contracts and Aragon voting suite. As well, two popular user interfaces include Tally and Agora.

Delegation & Delegates

Voter apathy is common in all voting systems, stemming from various reasons such as a lack of time to review proposals, prioritising other tasks, or simply lack of interest to participate.

Delegation is one solution to combat this issue. It allows a token holder to assign their voting power to a voter who can vote on their behalf. The practice is widespread. For example, in the ArbitrumDAO, about ~9,311 accounts have delegated their voting power to L2Beat who have amassed over ~18 million votes.

We call voters like L2Beat, delegates, as their voting power is largely derived from other tokenholders.

The current system, in many DAOs, only allow a token holder to delegate to a single delegate. However, a potential future enhancement could enable token holders to delegate to multiple delegates based on their expertise and the specific nature of the proposal. For example, a voter may delegate to L2Beat for technical matters and Coinflip for decisions concerning the ecosystem.

Stepping back — DAOs implement a form of liquid democracy — as token holders can decide to cast their vote (direct democracy) or delegate their voting power to others (representative democracy) while retaining the right to reclaim their voting power at any time.

Note, delegation was apparently implemented because of high gas fees on Ethereum, and not necessarily due to voter apathy.

Voter & Delegate Incentives

This brings us to financial incentives for token holders and delegates.

Why should a token holder participate as a voter?

The motivation for a token holder to participate hinges on the nature of the DAO. Generally, the financial incentives of the token holder should align with the DAO’s long-term goals. If the DAO is successful, then so are the token holders, as their success is mutually dependent.

Is it advisable for a token holder to delegate their vote?

For token holders, who lack the time or expertise to participate in governance, then it should be in their interest to delegate their vote to someone, who in their view, possesses the necessary skills and knowledge to assess proposals and vote with the DAO’s long-term prosperity in mind.

Why do delegates participate, especially if they are not token holders?

Delegates might participate for several reasons: gain influence and power within the DAO, curiosity and interest to participate in such an open governance forum, and potential financial benefits such as receiving a monthly stipend or rewards from successful proposals.

In the answers above I deliberately used “should be” because these assertions are not definitively proven; they rely on conventional wisdom, empirical observations and a little bit of wishful thinking.

Looking ahead, we will discuss how vote-buying-as-a-service can disrupt the existing incentive structures for participants.

Additionally, I believe there is a fundamental issue with delegates who lack skin in the game, i.e., delegates with no token holdings, as there is no direct consequences for their voting decisions and I’d argue this results in a laissez-faire attitude for financial aspects of a proposal. This is a blog for another day 😊

An in-depth study of incentives for participation using empirical evidence from DAOs would be very interesting.

LobbyFi - Vote Buying as a Service

Vote buying as a service has emerged in the world of DAOs.

LobbyFi, a venture funded startup, has deployed a suite of smart contracts designed to facilitate vote buying for any DAO proposal.

It is straight forward to use too.

Any token holder can delegate their coins to the smart contract and the votes will be sold to the highest bidder for any DAO proposal.

Lobbyfi has acquired ~20 million votes from a single large token holder to explore the idea of democratising lobbying within the ArbitrumDAO.

Types of Vote Buying

We use LobbyFi as the example since they have a live service, but generally speaking, any vote-buying-as-a-service will likely offer the ability to participate in an auction or to instantly buy the votes.

Auctions. The vote buying smart contract can run an auction to allow anyone to bid and purchase the votes. In the case of LobbyFi, vote buyers can place a bid for options like FOR or AGAINST. Multiple vote buyers can work together as all bids are accumulative. For example, 3 people may bid ‘FOR’ and 2 people bid ‘AGAINST’.

The auction will remain live until a predetermined deadline and after this point the smart contract will cast a vote for the option that has attracted the highest total bids. Funds from the winning bid are distributed among the token holders (who sold their vote) while losing bids are returned to the bidders.

Additionally, a reserve price can be set to establish a minimum bid, ensuring there is a financial cost to win the auction.

Instant Buy. A fixed price can be set to purchase the votes. If the buyer pays the price, then the smart contract will instantly cast the intended vote. Unlike the auction mechanism, price discovery relies on a third party like LobbyFi to decide what the price should be.

To date, LobbyFi has published the rationale behind the fixed price for an instant buy option. There are several potential methodologies for computing the fixed price depending on the proposal at hand.

Keep in mind, a proposal may have multiple possible options beyond simply ‘for’ or ‘against’, which is reflected in LobbyFi’s implementation too.

Quick Look at LobbyFi Data

LobbyFi has been operational in the ArbitrumDAO since July 2024 and votes could be purchased for ~75 proposals including when voting power dropped from ~800k to ~92k ARB for 2 proposals.

First 7 months (July to January):

• ~800k votes for sale in ~67 proposals,

• 17 successful auctions,

  • Highest winning bid of 0.003 ETH (~$8),

  • Majority winning bids at 0.001 ETH (~$3),

• 21 successful instant buys,

  • Largest buy at 0.1 ETH ($300) for Questbook Domain Elections [1,2].

  • Vote for “New Protocols and Ideas allocator” failed as LobbyFi did not encrypt the vote in line with Snapshot’s shielded voting.

  • Vote for “Dev Tooling on One and Stylus allocator” succeeded and it was cast for andreiv.

  • All other instant buys purchased at 0.001 ETH ($3) or below.

Past month (February):

• ~21m votes for sale in ~6 proposals,

• 3 successful auctions

  • Winning bids of 0.002 ETH, 0.005 ETH, 0.0064 ETH (~$15),

  • More competitive with ~9 bids in latest auction.

• No successful instant buys

  • Reason: Significantly higher purchase price at 18.85 ETH, 1.7 ETH, 7.5 ETH, 2.5 ETH, 0.5 ETH.

There are other notable observations.

• Instant Buy Pricing Experiments. LobbyFi has experimented with setting the instant buy price as consistently 0.1 ETH, then a mixture of values from 0.00001 ETH to 0.1 ETH, and then more recently with significantly larger values like 18.85 ETH.

• No Reserve Price Until Recently. Nearly all auctions have had a negligible reserve price, although since receiving a 20m delegation, the reserve price is now being set. For example, a recent auction, with several bids, failed as the reserve price was set at 1.35 ETH.

  • Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program - Season 3.

• Inconsistent Instant Buy Pricing. The DAO ran an election for each ARDC member (at the same time) and the instant buy option was different for one election.

  • Supervisory Council - 0.001 ETH,

  • Risk Member - 0.001 ETH,

  • Security Member - 0.00001 ETH,

  • Research Election - 0.001 ETH,

• One Lucky Buyer. 1 person was consistently buying ~800k votes between October and December for 0.001 ETH ($3) for each proposal.

  • 0xf568a8DeDe42a85372bD3adfC450022Eb40C094E

• No Impact (Yet). LobbyFi has not swung the final result for any DAO proposal.

LobbyFi appears to still be in its infancy.

It is experimenting with different parameters around Instant Buy and the Auction’s reserve price. They are still fixing bugs that prevented votes from being cast properly which has happened on several occasions for shielded voting on Snapshot.

Vote buying is not yet competitive and nearly all proposals (except two) failed to garner more than $20 from buyers per proposal.

Over the coming months, I’d expect to see a change in participation on LobbyFi. They have acquired ~20 million votes and they are the largest delegate in the ArbitrumDAO. This voting power can potentially swing the result of a proposal and we should not be surprised to see this happen soon.

I took time to scrape the LobbyFi data to glean the above information. There may be mistakes and it may also be incomplete. If you find any missing or incorrect data, please do let me know!

Evaluating Payoffs for Vote Buying

Although implementing vote-buying-as-a-service is indeed feasible, it is still worth assessing whether there is a positive payoff for parties to engage in the activity with non-trivial funds.

We will make the following assumption:

• Swing vote only. A party will only participate and buy votes via the service if it will swing the outcome of the vote in the buyer’s favour and achieve the desired result.

The motivation for the assumption is simple. If buying the vote does not impact the final tally, then there is no financial incentive for any party to purchase the vote as the end-result will be the same. This is the case in DAOs as the running tally is public and the buyer can objectively evaluate whether the purchase will make a meaningful impact.

If the vote is private (like shielded voting), then the swing vote only assumption does not necessarily hold. The buyer will need to determine whether it is worth ‘taking the risk’ to purchase the vote.

With the above in mind, we’ll will use this opportunity to assess who benefits from a proposal and which parties are likely to participate in vote buying.

Case 1: Proposal with no financial benefit to any party.

For example, the proposal may focus on a software upgrade to the wider project and there is no movement of funds from the treasury.

There is no risk-free or positive payoff for a party to purchase the vote.

There may still be reasons for a party to buy a vote for other indirect benefits, but generally, it will cost them financially to purchase the votes and the funds will not be recouped from the proposal.

Case 2: Proposal only financially benefits a single party.

For example, the proposal will pay a single party $$ to run a service for the DAO.

It is “risk-free” for the single party to purchase votes, swing the vote, and guarantee the proposal passes. The reason is that they can recoup the cost of purchasing the vote from the payment received through the proposal.

If the party stands to receive X from the proposal, then may be willing to spend up to Y (where Y < X) to ensure it passes, resulting in a net profit of (X-Y).

Conversely, others have no financial incentive to buy the votes and take the opposite position against the proposal as there is no positive payoff. If someone were to spend Y and reject it, they would incur a strict loss of Y, as there is no way to recoup the cost.

This suggests that auctions are ineffective for proposals that primarily benefit a single party as there is no natural counterparty to bid against them. An instant buy option can be priced strategically to attract the only party with a financial incentive to purchase it.

Case 3: Proposal benefits at least 1 out of N parties.

For example, the proposal may offer a grant to a single service provider, but the DAO can only pick 1 out of 5 service providers to receive the funds and carry out the work.

There is a financial incentive for all five service providers to purchase votes and sway the final decision in their favour. For example, if there is an auction to purchase the votes, then all five parties might be willing to pay up to X, where X represents the total payout the winner will receive.

In the case of LobbyFi, only the winner of the auction will pay, meaning there is no negative financial outcome for any participant assuming they only vote for themselves.

We oversimplify the statement that a buyer may be willing to pay up to X assuming they receive X from the proposal. There will be a cost ε that party may need to pay to execute the proposal and as such they may only be willing to pay up to X - ε.

Why Will Token Holders Delegate to the Service?

Conventional wisdom for DAOs is that a token holder’s financial interest should be tied to the DAO’s success and they should be inclined to support delegates who will actively vote and make good decisions on their behalf.

Vote-buying-as-a-service challenges conventional wisdom. There is now an “opportunity” for token holders to earn “yield” by selling their votes to the highest bidder.

There are a few cases when it might make sense for a token holder to earn a yield by selling their vote:

• Short-term holder. Impact of a decision made by the DAO may not be felt for months or even years later. By that time, the party may no longer hold the tokens.

• Apathetic holder. Token holder does not believe that decisions by the DAO will have an impact on the long term and they can make a short-term profit by renting their votes.

• Mutually beneficial. Token holder has no interest in the proposal, but buyer has a strong financial interest, so buying the token holder’s vote can financially benefit both parties.

• Better decision making. The token holder may not be convinced the delegates are good at making decisions and the act of selling their votes may lead to better decision making.

Additionally, there is a concept known as quadratic voting, where a voter can purchase votes and the price of every vote goes up quadratically in cost. It allows a voter to demonstrate the intensity of their preference and potentially leads to more requitable outcomes for minorities.

However, the model of vote-buying-as-a-service does not align with this framework, as it allows votes to be purchased at much lower costs.

With the above in mind, vote buying seems like a Tragedy of the Commons, where token holders pursue their own self-interest for short term gains over working as a collective — particularly if they believe their voting power has minimum impact and isn’t crucial in determining the outcome of a vote.

Is Vote Buying an Attack on Governance?

The immediate reaction from many people will be that vote-buying-as-a-service is an attack on governance and must be stopped at all costs.

However, before labelling it an “attack”, we must first define how the voting system is intended to work and whether vote buying undermines or violates it.

In traditional voting systems (e.g., government elections), the principle is “one person one vote.” Vote buying is considered an attack because it allows individuals to purchase additional votes and cast more than their single allocated vote.

In token-weighted voting, the key principle is “one token one vote”. Since each token has financial value, voting power is tied to capital. For instance, if a token is priced at $1 and a person buys 100 tokens, then they acquire $100 in voting power.

A DAO’s voting integrity should reflect the capital cost of all votable tokens at the time of the vote. This principle ensures the security of a DAO can be quantified financially.

ArbitrumDAO Case Study. Around ~210m votes were cast for the BoLD proposal and it remains the proposal with the most voting activity to date. To dominate the voting protocol and ensure victory in every vote, an attacker will need to secure more than 50% of all active votes, which amounts to just over ~210m votes. With the token priced at ~40 cents, an attack needs to spend more than $84m to acquire the necessary votes.

Vote-buying-as-a-service, along with other methods of renting voting power, alters the intended security model.

If an attacker can temporarily rent the same amount of voting power for lower cost, say $1 for every $100 worth of votes, the perceived financial security of the DAO is undermined.

Instead of governance security being tied to the capital cost to acquire votes, it becomes dependent on the cost and availability of renting votes.

This is not indifferent to proof of work blockchains whose security can also be undermined by renting hash-rate. Many networks like Bitcoin are secure against rental attacks simply because it is infeasible to rent the quantity of hash rate to attack the network. Others, like Ethereum Classic, were not as lucky.

Returning to the question: Is vote-buying an attack on the voting system?

Yes, it is.

Yet, following our discussion, one could also argue that delegation itself is an attack — since delegates receive voting power for free from token holders.

For a voting system that includes delegation, we must recognise a third security attribute:

• One token, one vote (Measurable)

• Voting power represents the capital cost of tokens (Measurable)

• Intentionality of delegation (Subjective)

The first two attributes are objective and measurable, while intention of delegation is subjective.

We may argue that a secure system relies on token holders delegating to voters who are likely to make wise decisions, but this cannot be enforced by the smart contracts without substantial changes like creating a curated and centrally approved list of delegates who are the only parties allowed to vote.

Security will ultimately rely on choices made by token holders in regards to delegations, but it can only be influenced via the social layer of a DAO.

At this point, we must acknowledge that token holders will sell their voting power to others. This can be facilitated through vote-buying-as-a-service, lending markets, DarkDAOs, or even ‘kick-backs’ to delegators based on earnings from the DAO.

Even if smart contracts disabled delegation, it can be implemented using TEEs via DarkDAOs, which is even more problematic as it removes transparency and makes it more difficult to detect vote buying.

Let me be clear — renting voting power poses a real threat to DAO governance and voting — it undermines the financial cost to acquire votes and, in my view, does not lead to the collective making better decisions.

If this practice becomes widespread, we may need to treat it like Miner Extractable Value (MEV) with a deliberate strategy to minimise any advantage of vote buying and to increase the cost of renting voting power to swing a vote’s outcome.

Of course, we may get lucky, as Bitcoin did, where the amount of rentable voting power remains negligible. So the threat always exists in theory, but it practically unexploitable. However, we should not assume we will be as fortunate.

Can DAOs Defend Against Vote Buying?

We have concluded that vote buying, in general, should be considered an attack as it lowers the capital cost required to swing the outcome of a vote and potentially overwhelm a DAO’s voting system.

There are a few approaches on how we may defend against it, but honestly, none of them are that satisfactory.

Social approach. All funds are sent to a trusted third party (TTP) in the DAO for every proposal.

The motivation is to allow the trusted third party to review the votes, and if vote renting is detected and it was sufficient to swing the vote, then the funds should be returned to the DAO.

Governance committee. A committee is installed in the governance smart contracts with the authority to delay the passage of a proposal and, if necessary, veto it.

The power to delay the passage of a proposal can permit time to investigate the voting results and detect if a vote rental service was used to swing the votes. Enabling the committee to veto the proposal and effectively cancel it can protect the DAO while acting as a deterrent against the use of vote buying. Membership can begin small (~3 members) and eventually evolve into a collection of parties who act as a ‘check’ on the results of token-weighted voting.

Negate approach. A smart contract, with the same voting power as the rental service, will wait until the rental service casts its vote and then automatically vote against it.

This is probably the most decentralised approach and does not rely on any changes to the voting system.

However, it requires matching the voting power of the attack and introduces timing challenges between the attacker and defender (i.e., latency games). For example, if the attacker sends their vote transaction for inclusion in the same block in which the voting period ends, then the defender may not see the transaction and thus react in time.

Additionally, it may increase Quorum for a vote and inadvertently facilitate the approval of less popular proposals that garnered more “for” than “against” votes but lack sufficient overall votes and participation from the DAO.

The primary issue is that attacks only get better.

If a defence is put in place to detect and counteract transparent vote buying, it could accelerate the development of DarkDAOs — enabling the selling of votes in a privacy preserving and trustless manner. We should assume that DarkDAOs will eventually emerge if vote-buying as an activity really takes off.

Final Thoughts

Vote-buying-as-a-service, along with other forms of renting votes, is likely here to stay.

Current data suggests that renting voting power has not yet had a detrimental impact in the ArbitrumDAO nor has it decisively influenced the outcome of any votes.

I remain hopeful that vote buying will not gain popularity and it will gradually fade into irrelevance.

However, as is often the case in the crypto world, we cannot simply hope for something to disappear, especially when the financial incentives for buying votes favor the attacker over the defender. It is profitable for attackers to buy votes, and when there is profit, there is action.

We, the DAO community as a whole, need to start discussing how governance should evolve beyond token-weighted voting with more robust checks and balances. This may require introducing some level of centralisation with gatekeepers, but I believe this could be a more effective approach than passively allowing governance attacks to happen.

Additionally, the ArbitrumDAO’s Code of Conduct clearly states that severe cases of self-voting or failure to disclose conflicts of interests can lead to remove of DAO positions:

“However, as explained further below, a delegate that repeatedly fails to disclose a conflict of interest before self-voting or if a single instance is deemed to be severe, they risk being removed from the Delegate Incentive Program or a DAO-elected position.”

It should also be socially unacceptable to purchase votes and we should treat vote buying as severe misconduct. In fact, we should go further than what the code of conduct requires, and outright ban individuals from the DAO who are discovered to be buying votes for their own personal gain.

Of course, these are only my thoughts.

I remain open minded and convincible that allowing folks to sell their votes to the highest bidder or for people to rent votes from others, in general, can lead to overall better decision making. Lobbying does exist and it is very real in any governance system.

Should we actually embrace it? Or fight against it? I’m leaning on the latter, but open to the former.

There are many good reasons why developers will make this decision:

• Real-time audits,

• Proof of solvency by default,

• Custody of user funds is optional,

• 1 honest party can protect the entire system

Most importantly, all design and implementation efforts for rollups are focused on protecting the user, their funds, and all their interactions, from a potentially unknown and powerful system operator.

Even in the event that the entire system goes offline, a user is empowered to single-handedly recover their funds.

If rollups can gain wide-spread deployment as a tech stack, then we may have the ability to breakdown the barriers of trust and enable anyone in the global community to financially interact with each other, swooping in a new era of global e-commerce, remote hiring and frictionless provision of services.

There is truly a lot on the line to get a rollup implementation done right.

What About The Multisig?

Hold on stonecoldpat.

That all sounds good, but at the end of the day, there is a multisig underpinning the entire system. If the signers are compromised, or malicious, then they can simply steal all the funds.

So who cares about the rollup?

~ Somewhere on CT

It is true that all rollups (today) have a multisig with the authority to upgrade the underlying smart contracts, but as we will see, it is a reactionary mechanism for protecting user funds and it is part of a wider system architecture.

Security Council’s Responsibility

A multisig is a technical term for a system that requires multiple signers to authorise an action. For example, K of N signers must produce a digital signature before a transfer can be approved.

In the context of rollups, the multisig is often called the Security Council and the signers are entrusted with the power to upgrade all relevant smart contracts.

Let’s consider the security council in Arbitrum (since I am exceedingly familiar with it) to understand what type of responsibilities a council may take on:

• Veto. Cancel a proposal passed by the Arbitrum DAO if the Security Council believes it violates the Arbitrum Constitution and potentially harms the Arbitrum ecosystem. For example, cancel a proposal that was passed due to an attack on governance.

• Maintenance. Upgrade the Arbitrum smart contract suite for minor changes that do not justify invoking the Arbitrum DAO process. For example, change a configuration setting that impacts how transaction fees are charged to users.

• Emergency events. Respond swiftly during an emergency and upgrade the smart contracts if they believe user funds are at imminent risk.

Of course, above all, the security council‘s primary duty is to tackle emergency events and act swiftly to protect user funds.

Acting as a security council member is a very much a trusted role.

Signers are trusted to react quickly, trusted to upgrade the smart contracts if an emergency strikes, and trusted to do their utmost to protect the safety of funds held by the smart contracts.

Picking The Right Multisig Threshold

There are two important choices that need to be taken into account when deciding to set up a Security Council:

• How many signers are on the multisig?

• How many signers are required to approve an action?

It may appear at first to be a trivial problem, after all it is just two numbers, but there is a balancing act that must be considered:

• Safety violation: K members may collude to change the smart contracts and steal user funds.

• Liveness violation: N-K+1 members collude to prevent any change to the smart contracts, especially problematic if a critical vulnerability is discovered.

The difficulty is to pick a threshold that upholds the safety of funds during times of peace, but enabling swift action during an emergency when user funds are under threat.

Let’s consider a concrete example. Let’s say the threshold is set to 9/10, where 9 signers must collectively sign a message. This is a significant safety threshold as 9 signers must be compromised to steal the funds. However, the downside is that any two signers can prevent the authorisation of any action during an emergency. For example, if two signers are on a transatlantic flight, then the Security Council is rendered unable to perform their duty.

Of course, if the safety threshold is low, let’s say 2/10 signers, then it only takes any two signers to collude (or be compromised) for user funds to be stolen.

Picking the appropriate threshold is a more a social than a technical problem and I’d argue it is more of an art than a science. Security largely depends on the perceived integrity of individual signers. As we will see shortly, there are methods to reduce trust in the multisig, but that will come with its own set of tradeoffs.

Security Council’s Membership

Most rollups have an anonymous set of signers in their security council. We suspect this may be due to:

• The rollup’s stage of development,

• Caution around protecting members from a $5 wrench attack,

• Perception that anonymity is the best option for protecting user funds.

On the other hand, there are three rollup projects who have publicly declared the membership of their security council:

• Arbitrum. Signers are publicly elected and the current list is available on Tally. Only three signers are associated with the Arbitrum project (two from Offchain Labs, one from the Arbitrum Foundation),

• Base. It is a 2/2 multisig that relies on the output of two different multisigs, one controlled by Base and the second controlled by Optimism.

• Polygon ZkEVM. Not yet implemented, but they have announced intent to upgrade their multisig to 10/13 which includes two members from Polygon Labs alongside one advisor to Polygon Labs.

• ZkSync Lite. It should not be confused with ZkSync Era, but its security council is publicly announced and it includes no direct affiliates from the rollup project (except for investors in ZKSync).

In Arbitrum and hopefully soon on Polygon, only a few signers are directly affiliated with the rollup project and the number is small enough to ensure that affiliates cannot collude to prevent an action taken by the security council (liveness violation). In ZkSync Lite, outside of investors in ZkSync, they have focused on appointing signers who are independent of the project.

In all cases, there is a strong emphasis to onboard signers who are not directly affiliated with the project.

Yet, there appears to be a lack of consensus on what makes a good multisig which brings us to several design questions:

• Should anonymous members be allowed?

• Should members be geographically diverse?

• Should members be individuals or companies?

• Should members be appointed or elected?

• How many members from the same company (or country) should be allowed?

• Is there a minimum size and threshold that is considered appropriate?

The general rule of thumb should be to pick members of high integrity so the public can have confidence that the system will be kept safe. At least, that is what I believe most projects are likely doing, even if it is not always publicly verifiable.

p.s. Six members of the Arbitrum security council are currently pre-appointed, but they will be replaced in the March election.

Curtailing Council’s Authority

So far, we have only considered a security council with the authority to instantly upgrade the smart contract, but there are methods to curtail the council’s power:

• Time delay. All actions authorised by the security council will only be executed and take effect after time T has passed.

• Pause-only. Native bridge holding all the assets can be frozen by the security council. This may pause the ability to:

  • Pass messages from L2 to L1 (i.e., withdrawals),

  • Finalise the ordering of pending transactions,

  • Finalise new checkpoints / attestations,

  • Accept new rollup data (i.e., pending transactions).

• Removed. Abandon the security council and rely on another governance mechanism (like a DAO) to approve upgrades.

Of course, there is a trade-off to curtailing the security council’s ability to swiftly act and whether they can effectively respond to an emergency event that threatens user funds.

In the case that a vulnerability is privately disclosed to the security council, but it is not yet actively being used, then the security council may have the option to upgrade the smart contracts and fix the bug. By including a time delay to the upgrade, it increases the risk that an attacker can study the publicly disclosed upgrade, find the exploit, and then use it.

For example, CVE-2018-17144 in Bitcoin was initially advertised as a DDoS bug while trying to hide the more serious coin inflation vulnerability. Upgrade speed was of the essence to prevent its exploitation.

Evaluating Pause-Only as a First-Line Defence

Let’s consider potential scenarios where a vulnerability is actively being exploited by an attacker:

• Malicious L2 → L1 message. An attacker can craft any arbitrary message that originates from a smart contract on the rollup and forward the message via the native bridge to smart contracts on Ethereum.

• Invalid State Transitions. An attacker can execute transactions on the rollup that break the state transition function rules and it should normally be considered invalid.

• Withdrawal exploit. An attacker can withdraw funds from the native bridge by only issuing transactions on Ethereum (the layer-1).

In all three cases, a time delay simply permits an attacker additional time to continue stealing the funds and reduces the window of opportunity for the security council to defend the system. The time-delay functionality is prohibitive to defending against active exploits and should only be used for routine maintenance / non time critical tasks.

We will only evaluate the ability to pause the system and the degree in which the system can be paused.

In the case of a malicious L2 → L1 message, the pause functionality can mitigate the attack without interfering with transaction activity. The security council should pause message delivery and/or the ability to finalise new checkpoints. There is an argument that L2 → L1 messages should have a time delay before they are executed to permit time for the security council to detect bug and react to the emergency event.

Defending against invalid state transitions is trickier as transaction finality has different tiers in a rollup. If we only consider transactions on the rollup and not any side-effects, then the best defence for the security council is to halt the ability for checkpoint finalising, but continue to allow pending transactions to be ordered. This can permit time for the bug to be fixed, checkpoint finalisation reactivated, and for the invalid transactions to simply be ignored.

However, if transaction activity on the rollup is not turned off, then the user experience will be messy and the rollup may appear in a state of havoc until the client software is upgraded.

This brings us to next scenario. How should the security council react if we consider how the invalid transactions on a rollup may impact other systems that observe it. The best line of defence is to either freeze the ability for the native bridge to finalise the ordering of transactions or to turn off the Sequencer altogether.

This is because some systems, like fast bridges that move funds from one rollup to another rollup, may authorise funds to be transferred once they believe that a rollup’s transaction (including the invalid transaction) is ordered for execution. In this example, it may allow an attacker to exploit a DeFi protocol on the rollup and then quickly escape with the funds by moving it to another rollup via a fast bridge.

By the time the security council can fix the bug and revert the invalid transactions, the damage may already be done. Either the DeFi protocol or the LPs in the fast bridge may bear the losses from the attack.

Finally, if the vulnerability allows the attacker to withdraw funds directly from the native bridge, similar to the Nomad Hack, then the security council may be powerless to stop it.

There is a final overarching issue with the pause-only approach. We must assume there is a wider governance system that can approve the upgrade and reactivate the rollup. If we assume the governance system is a DAO with an on-chain voting system that runs on the rollup, then there are tricky implementation issues that arise.

For example, if the L2 → L1 message bridge is paused, then the DAO’s voting result cannot be passed from the rollup to the native bridge living on Ethereum. An alternative method for the DAO to send its approval and execute the upgrade must be implemented.

Phasing Out Security Council

Some in the community believe that Security Councils should be phased out, but from my perspective, two issues arise:

• False sense of security. An attacker with knowledge of an exploit will wait until the security council is phased out before performing the attack. This undermines our ability to gain confidence in the system’s security with the passage of time.

• Limited recovery options. Without a security council, there is little the community can do to fight back against an attacker. The only option available is to pursue a parallel white-hat hack and hopefully recover any remaining funds.

I’d argue that security councils will always be needed, but the authority that is entrusted with them should be gradually curtailed.

With that in mind, the design question should be:

How can we enable a security council to pause the system with minimal impact on users while allowing the wider community’s input on deciding how to fix the bug and reactivate the system?

Put another way, we need an implementation that truly allows the community to step in and recover the situation before curtailing the security council’s power to pause-only.

In layer-1 blockchain land, the community does have direct input by using a user activated fork, but that approach is not applicable for smart contracts on Ethereum (like a rollup) without forking the entirety of Ethereum. There may be cases when the Ethereum community will collectively decide to save a rollup, just like TheDAO in 2016, but a rollup project should NEVER depend or expect such an outcome.

Another interesting idea along these lines is to implement an Ethereum Supreme Court to decide upon smart contract upgrades and enable a mechanism that looks similar to a user activated fork.

As mentioned already, if the rollup entrusts its security with a DAO, then there should be an implementation that allows the DAO to cast votes directly on Ethereum. This is very tricky, especially if the voting protocol lives on the rollup.

As a final note, I do believe that a comprehensive review on the type of situations that may warrant a response from the security council is required to help aid the discussion around their necessity.

Why Care About The Rollup If There Is A Multisig?

We have spent a considerable amount of time understanding the responsibility, design and need for a security council, but it is important to get back to this article’s original question:

• Is a Rollup Just a Multisig?

The answer is no.

To help understand why it is best to take a step back and understand what a blockchain system is really trying to do.

A blockchain protocol is a tool that allows a user to compute a copy of the database and have confidence that they have the same database as everyone else.

With that in mind, there are two components to any blockchain system:

• Blockchain Protocol. A combination of software, cryptography, and distributed systems, that enables anyone to have confidence in the integrity of the database.

• Governance System. A coordination mechanism that allows all interested parties to collectively work together and agree to change the blockchain protocol.

The goal of any blockchain system, including rollups, is to ensure the blockchain protocol is always running with exceedingly reliable uptime of 99.9999%. There should be little to no interference from a trusted system operator on the day-to-day running of the system. It should be the software, cryptography, and distributed systems, that is ultimately responsible for protecting the user’s balance, the smart contract code and state.

There are times when the blockchain protocol needs to be changed for the betterment of the users. The community may want to fix a configuration issue, add a new feature, or react to a critical vulnerability that threatens the system’s integrity. This will require human intervention and it should only be invoked 0.0001% of the time.

The governance system is responsible for enabling human intervention and over the years several approaches have emerged:

• Centralised party. A single party can single-handedly decide how to upgrade the system (many projects, including Bitcoin, starts out this way).

• Rough consensus. An economic majority of participants signal their intent that they are ready to deploy the upgrade, a flag day is decided, and then the upgrade executes on the flag day (Bitcoin/Ethereum).

• Voting protocol. All parties participate in an election and explicitly cast a vote on whether the upgrade should be approved.

• None. The smart contract can be immutable and the system can never be changed.

Alongside the above, the community may decide to appoint a security council as an additional and complementary option to governance, to be used when an emergency strikes and swift action is required.

Security councils do not prevent attacks. It is a reactionary mechanism that works alongside governance for when the blockchain protocol is vulnerable to an attack that threatens user funds or the system’s reliability/performance.

Last words

All discussion around blockchain protocols, governance and security councils is critically important. The existence of this discussion is what makes cryptocurrency so special.

It is a wonderful example of Trust Engineering

An engineering discipline that focuses on identifying, measuring, and reducing/eliminating trusted elements in a system.

In cryptocurrencies, we focus on building systems that not only protect users from an all powerful system operator, but for the system to run reliably (and safely) in the most adversarial conditions possible.

This is why it is healthy for community members to remain skeptical on the merits of a security council and that is OK, but the onus is on them to come up with better solutions that can protect user funds in a reactionary manner during an emergency event.

I hope this article makes it clear why security councils can be useful, they are somewhat necessary today, but also just a small part of the wider architecture of a smart contract system. :)

Thanks to terence.eth for reviewing

Maximal extractable value: The maximum amount of value an agent can extract by including, excluding, or changing the order of transactions during the block production process

To put it more clearly, the concept of Miner Extractable Value (MEV) refers to a scenario in which an agent examines a user’s recent transaction, devises a strategy to generate profit from it, and subsequently implements that strategy to seize any potential earnings.

More often than not, an agent who successfully captures MEV will do so at the expense of another party. It may be the user issuing a transaction or a passive agent in a DeFi protocol.

The very simple act of making money by interfering with the execution of a pending transaction has huge ramifications for users, DeFi Protocols, and the underlying blockchain network.

We’ll present some background information about MEV before diving into the core discussion — what is the morality of MEV? Both in the context of agents that exploit MEV and actors who attempt to defend against it.

Agents within the MEV Game

In addition to users seeking to engage with a smart contract, there are two other crucial roles deeply intertwined with the concept of MEV:

• Searcher. An agent who finds an opportunity to make profit from a user’s transaction, creates a bundle of transactions to exploit it, and proposes the bundle to the proposer.

• Proposer. An agent with the authority to decide the ordering of transactions.

A searcher can be a trading firm with extensive expertise or a hobbyist coding in their bedroom.

Being a searcher is a permissionless role.

The only obstacle is the searcher’s ability to find alpha, build a competitive MEV bot, and exploit the opportunities. Access to capital helps, but it is not yet a significant obstacle.

On the flip side, a proposer wields the power to determine the sequence of transactions and, consequently, the outcome of their execution. This pivotal role can be filled by various entities, including Miners (in proof of work systems), Stakers (in proof of stake systems), or Sequencers (in rollups).

While the pool of proposers is typically restricted, it can be open access.

There exist compelling reasons for imposing limits on who can take on the role of a proposer:

1. Consensus Protocol: Many blockchain systems necessitate proposers' involvement in a round-based protocol, requiring cooperation from a majority (or supermajority) of them in each round. Coordinating communication among all N participants often proves to be a bottleneck.

2. Transaction Routing: Users must have a reliable means to transmit their transactions to the proposer. This can be achieved by forwarding transactions to a public memory pool or directly to the designated proposer.

3. Verifiable Integrity: The broader community may seek an objective metric to verify that all proposers are working together as a collective to decide the order of transactions and that they are always extending the latest ordering. For instance, the network may implement a fork-choice rule where a proposer builds on top of the heaviest chain (stake/work).

4. Risk of MEV: In some blockchain systems, particularly most rollups today, proposers are entrusted with the responsibility of not exploiting MEV opportunities. Hence, it's crucial for the community to have the authority to decide whom they trust.

In simpler terms, there must be a mechanism that allows a user to verify, in an independent manner, whether a proposer holders the authority to decide the ordering of recent transactions. Without this assurance, malicious actors could flood the system with bogus transaction orderings, leaving users unable to discern the truth.

To keep the explanation of agents simple, we incorporate the role of a builder into the proposer, and assume a proposer will both build a block and have the authority to publish it.

Interplay and Relationship of Agents

A large focus of MEV research is understanding the interplay between searchers and proposers. Furthermore, it's essential to establish whether these roles can be fulfilled by the same entity or if they necessitate distinct agents:

• Same agent. The searcher can be a proposer in the system,

• Separate agents. There are one (or more) searchers who are not proposers and they are all competing to influence the proposer.

Put another way, it is important to identify whether a searcher can have full and undisputed control of the transaction ordering policy. If the searcher is also the proposer, then it can potentially grant the searcher added power to observe the tactics employed by other searchers, enabling them to potentially steal opportunities from more competitive searchers.

On the other hand, if searchers cannot be proposers or collude with proposers, then it allows us to assume an environment where searchers must compete against each other. Their goal is to sway the proposer and persuade them to order a list of transactions according to the winning searcher's preference.

Outsourcing vs. Monopoly in MEV Profit Maximisation: There is an interesting debate whether it is more lucrative for a proposer to subcontract the task of identifying and capitalising on MEV to an open marketplace of searchers or if they should instead aim to consolidate the opportunity through a monopolistic approach.

We will assume that a proposer will act as an honest party and stick to their promised transaction ordering policy. Additionally, that searchers and proposers are always separate agents.

Our focus is understanding the strategy used by a searcher to influence the ordering policy of a proposer and hopefully beat all other competitors to the same opportunity.

Transaction Ordering Policy

The pursuit, and defence, of MEV focuses on the searcher’s ability to influence a single component of the blockchain system:

• Transaction ordering policy. Given a list of pending user transactions, which ordering algorithm is applied to output the final list of ordered transactions (i.e., a confirmed block).

A blockchain system can implement a variety of ordering policies and its goal is to offer fairness to all users who may want to transact.

This prompts the inquiry: What is the definition of fairness?

• Should users all pay the same fee and transactions are ordered on a first-come-first-serve basis?

• Should users pay a fee according to the transaction’s priority and all transactions are ordered based on the fee paid?

Both cases follow the general principle that a user can transact as long as they have the capability to pay. It does not dictate the user’s transaction will have a promised position in the total ordering, only that it will eventually be ordered for execution in a timely manner.

This concept of fairness, which underpins why a blockchain network is censorship-resistant, is interesting.

It outlines that a user’s ability to transact should only depend on their ability to pay, and they are not discriminated based on their geographical location, identity, gender, or belief-system. It originates from the realm of Bitcoin and it can easily be applied as the network only supports payments.

However, the ability to guarantee the inclusion of a transaction falls short when we attempt to understand fairness within a smart-contract enabled system. For a network like Ethereum, we must broaden the scope of fairness beyond transaction inclusion in the global ordering. It should also consider the intent of a user who signed the transaction and whether the user’s desired outcome was achieved after the transaction was executed.

Recognising the Vital Role of User Intent in Fairness. Users gauge fairness, not only on the ability to include a transaction in a timely manner, but by evaluating the actual outcome of their transaction and whether it aligns with their initial expectations when they signed the transaction.

This can lead to a new, and interesting, definition for what we mean by censorship-resistance:

• Weak censorship resistance. A user can always order a transaction for execution as long as they are willing to pay the appropriate fee for it.

• Strong censorship resistance. A user can force the intended outcome of their transaction and again they only need to pay an appropriate fee.

Keep this in mind, as it will become important when we understand how MEV can be leveraged to interfere with a user’s transaction and force it to fail its execution. Thus, even though a user’s transaction can be forcefully included in the total ordering, the user’s desired outcome (intent) cannot be achieved.

It appears, to the best of our knowledge, that a ordering policy must prevent searchers having the ability to selectively interfere with a user’s transaction, if we want to build a system with strong censorship-resistance. This remains an open research problem.

The enablement of OFAC sanctions via Relays is actively testing whether a blockchain network can continue to treat users fairly based on their ability to pay for transaction inclusion.

Enablement of MEV

To delve deeper into the technical aspects of Miner Extractable Value (MEV), we must examine the following:

1. Locating MEV opportunities: Understanding how a searcher can discover a user's recent transaction within the blockchain system.

2. Execution Environment: Examining the technical environment in which all transactions are executed.

3. Exploitation Strategies: Investigating the various strategies that a searcher can employ to exploit MEV opportunities, such as transaction reordering, front-running, and arbitrage.

4. Influencing Ordering: Exploring how a searcher can influence the proposer to prioritise the inclusion of their MEV-related transactions.

Once we've established a firm grasp of these fundamental components, we can proceed to evaluate the ethical implications and moral considerations surrounding MEV.

Locating MEV Opportunities

A searcher needs access to recent user transactions to find new MEV and money-making opportunities.

There are two approaches for finding transactions:

• Gossip protocol. A user submits their transaction to the peer to peer network and the transaction is propagated to all nodes within a very quick time frame (<1 seconds).

• Proposer feed. Proposer publishes pending and/or recently ordered transactions.

The majority of users send their transactions on the gossip protocol with the hope that a proposer will discover their transaction and include it in their block. At the same time, anyone including searchers, can join the gossip protocol and listen for pending transactions.

It has led to ‘Dark Forest’ nickname as it is almost guaranteed that a searcher will find a user’s transaction and interfere with its execution if there is a money-making opportunity. For example, in the Dark Forest post, the authors failed to recover at risk funds as a searcher discovered their transaction, evaluated it, and collected the funds for themselves.

To date, the only way to defeat the dark forest is to avoid sending a transaction to the peer to peer network. In a subsequent post, the authors Escaped the Dark Forest by sending their transaction directly to an Ethereum miner. This, alongside other instances, eventually led to the Flashbot offering a direct transaction feature which allows a user to send their transaction directly to a trusted miner (as a service).

There is still a risk that MEV bots can exploit a direct transaction if the blockchain experiences a re-org and the user’s transaction is temporarily unconfirmed and placed in the memory pool. However, re-org events are relatively rare in proof of stake Ethereum compared to 7% of all blocks in PoW Ethereum.

The same risk does not apply on rollups (as implemented today). Almost all transactions are direct transactions as users have a direct communication connection to the Proposer (Sequencer). There is little to no opportunity for a searcher to eavesdrop on the channel and it significantly increases the difficulty to exploit MEV opportunities for pending transactions.

This has led to a perception that rollups have defeated the searchers. To date, any success has hinged on the trustworthiness of Proposers not exploit MEV for their own gain. Of course, this is not the entire story, and searchers can still find MEV opportunities.

In rollups, thanks to direct transactions, searchers have shifted their focus to locating recently confirmed transactions in the hope to find arbitrage-like opportunities.

For example, in Arbitrum, the Proposer maintains a feed that publishes recently ordered transactions. It is published every 250 milliseconds, primarily to assist infrastructure providers such as Infura and Etherscan in obtaining the most up-to-date data. This allows a user to send a transaction to the Sequencer and then check its status on Etherscan. Additionally, it allows anyone to run an Arbitrum node with Sequencer confirmed state.

Regrettably, MEV bots discovered this feed. A searcher will connect to the feed and exploit arbitrage-like opportunities from recently ordered transactions.

Any information about transactions can enable MEV. Most discourse about MEV focuses on the ability for searchers to locate and interfere with the execution of pending transactions. However, even if the Proposer is completely trusted not to allow searchers to locate pending transactions, there's still the potential for searchers to utilize any information made available by the Proposer.

Shared Database State

Every blockchain system operates as a finite state machine and in this context there's a state transition function (STF) that takes:

• Latest database state,

• User's input.

Upon execution, the STF will output a new state of the database. We can summarise it as the following:

• STF(database_state, user’s input) = new_database_state

When a user initiates a transaction, they target a specific state transition function along with their input. It's important to note the transaction doesn't commit to the current database state; the latest database state is only known when the execution occurs.

In a blockchain system, the state transition function includes many components that may impact an update to the database.

To keep it simple, it is most notably defined by a virtual machine like the EVM, WASM, MIPS, or Cairo. Going a bit further, when a developer deploys a smart contract onto the virtual machine, they are locking an entry of the database for exclusive use by the smart contract. The database entry can only be updated when the smart contract executes on it.

A smart contract defines write access to a specific database entry.

So, when a user initiates a transaction and targets a smart contract, they are intending to update a specific entry in the database or any database entries that smart contract has write access too. Because the smart contract defines write access, it can define who is allowed to perform that action.

In the majority of cases, a smart contract operates with an inclusive policy, permitting anyone to execute it as long as they meet certain predefined criteria. Unless the smart contract function serves an administrative purpose, the criteria will not depend on the identity of the transaction initiator but are rather employed to uphold the rules governing the smart contract. For example, checking the user has a sufficient balance of token X before performing a swap of Token X → Token Y.

In summary, we must take into account two key aspects of a transaction:

1. Non-Commitment to Output: When a user signs a transaction, they aren't locked into a specific execution outcome. Their signature covers the inputs and the target smart contract but doesn't dictate the exact execution.

2. Smart Contract Preconditions: Smart contracts establish conditions that must be met for a successful execution. These conditions often revolve around enforcing protocol rules (such as swap logic) rather than the identity of the caller.

Both components are necessary to facilitate users to issue transactions at the same time and to deal with race conditions. Otherwise, as we saw with the launch of swaps on Cardano a few years back, it can lead horrendous usability issues.

At the same time, it leads to the enablement of MEV on any smart contract platform as it allows a bot to interfere with the execution of a user’s transaction and potentially generate a profit by doing so.

Transaction Bundles and Interference Methods

Thanks to the public nature of:

• User transactions,

• Shared database state.

A searcher can simulate pending transactions and have full insight into future database states. Their task is to simulate transactions and determine whether there is a future database state that is profitable for them. If so, then they should strive to make the future database state occur and capture the profit opportunity.

Once they find a pending transaction that is profitable for them, then the searcher can execute one of two strategies:

• Do not interfere. Allow the user’s transaction to execute as expected and the searcher will follow up with their own transaction that takes advantage of the resultant database state.

• Do interfere. A searcher must issue transactions that set up the ideal conditions before the user’s transaction is executed.

The do not interfere approach is straight-forward. The searcher has essentially pre-computed what the database will look like after the user’s transaction is executed and they can issue a transaction that execute after the fact and capture the resultant profit. As an example, a searcher may chase an arbitrage opportunity by back-running a user’s transaction.

The do interfere approach requires the searcher to issue transactions and aim for their transactions to ordered before the user’s transaction. This will impact the execution of the user’s transaction and hopefully result in a desired database state that is profitable for the searcher.

Two examples of interference include:

• Sandwiching. A searcher will issue two transactions that surround a user’s transaction. It will interfere with the user’s transaction execution in order to collect a profit.

• Front-running. A searcher will copy the user’s transaction and get it executed before them. It allows the searcher to steal the profit opportunity before the user.

For the do interfere approach to work, it needs to make assumptions about the transaction execution model. As mentioned previously, we assume a user’s transaction has no fixed outcome at the time of signing and its final execution is dependent on the shared database state.

Thanks to the execution model, and the fact that a user can define a set of pre/post conditions that must be satisfied before the transaction to successfully execute, it can be argued that a user defines a range of acceptable outcomes, even if it may be used against them by searchers looking for an opportunity to capture profit.

The idea that a user has the authority to approve a range of acceptable outcomes is important when evaluating the morals of MEV.

Influencing How a Proposer Prioritises Transaction Ordering

This brings us to the final piece for enabling MEV — understanding how a searcher can convince the proposer to prioritise their bundle of transactions at a specific position in the total ordering.

The approach taken depends on the ordering policy implemented by the Proposer, but it generally falls into two categories:

• Priority Auction. A searcher must pay a bid that is higher than all other searchers.

• Latency Games. A searcher must send their transaction (that pays an appropriate fee) to the proposer before all other searchers.

Put another way, we need to consider the competition amongst searchers, how they can outcompete each other and which approach has the ability to enable an open-market of searchers to participate on a level-playing field.

Thanks to the public nature of a gossip protocol and the fee market auction mechanism on Ethereum, a new phenomenon emerged as the community became aware of MEV and it led to significant network congestion.

In the Dark Forest, if a single searcher finds an MEV opportunity, then it is very likely that other searchers will find it as well. Only one searcher can win the MEV opportunity and as a result it leads to a very competitive bidding war called a priority gas auction.

In a priority gas auction, a searcher wants to pay the minimum necessary bid that is higher than all competitors while maximising their profit. They must monitor the current sets of bids (in the memory pool) and issue a new transaction with a higher bid. All new transactions should replace their previous transaction.

Competitors repeat the above process and it results in significant spam hitting the peer to peer network. For example, in the above chart, we can count at least 100 transactions within a 12 second window. Additionally, only one transaction can succeed and capture the MEV opportunity. All competing transactions are still included in a block and will likely fail to execute. Wasting both bandwidth and blockspace.

Flashbots emerged with a solution to alleviate the issues associated with priority gas auctions.

Flashbot’s solution: Take the priority auction protocol for picking the winner and move it off-chain.

All searchers were encouraged to submit bundles to a Relay run by Flashbots. It was up to the Relay to pick the winning bid and forward it to the proposer. All failed bids were discarded by the Relay.

This paved the way for the development of the proposer-builder separation (BPS) framework, a concept that distinguishes between the block builder who orders transaction for a block and the block proposer who is endowed with the authority to decide the final content of a block.

The separation of roles fosters an open marketplace for builders, as well as searchers, to collaborative create profitable blocks while sharing a portion of the profit with the proposer via a priority auction. The primary goal is to ensure no single party can take all profit generated by MEV opportunities.

The process for convincing a proposer is very different for a layer-1 blockchain like Ethereum compared to a rollup like Arbitrum.

Ethereum has ~800k validators, a public memory pool, and the process of picking the validator to become the next proposer depends on a random beacon. Whereas, Arbitrum only has a single Sequencer (Proposer) who has a private memory pool, easily identifiable and users can have a direct connection with them.

The rollup environment impacts how a searcher may attempt to influence the proposer as they no longer have access to pending directions and there is only one (or a few) parties to convince.

As mentioned previously, a searcher can:

• Listen to the Sequencer feed,

• Find recently ordered transactions,

• Leverage back-running strategies to capture MEV opportunities.

A searcher can increase their chance of winning the competition a profit if they are the first bot to learn about the MEV opportunity and they have the fastest connection to the proposer. Put another way, without a priority auction, the only way for a searcher to win is to compete in a latency game.

Searchers discovered, upon studying the Sequencer feed policy, that the feed will randomly prioritise a different web-socket connection to receive the transaction first.

The best strategy was to simply open as many connections as possible and receive the transaction first by winning the connection lottery. This led to >150k connections to the Arbitrum Sequencer.

The excess connections were a waste of resources, a potential denial of service attack on the Arbitrum Sequencer, and only beneficial to searchers who can successfully compete in a latency game.

Timeboost proposal. Combines first-come-first-serve with priority auctions. The majority of transactions can be ordered according to FCFS, but searchers have an opportunity to participate in a priority auction for back-running opportunities. Thus, it removes any latency advantage while still allowing users to enjoy a FCFS ordering policy.

Morality of MEV

All eco-systems need to grapple with the following question:

Surprisingly, there is no straight-forward answer, yet many in the technical community have a binary opinion on the topic.

There are two schools of thought around the exploitation and prevention of MEV:

• Anti-MEV camp. MEV as harmful. It is akin to throwing a user to the degen wolves and allowing them to be maximally exploited. We should do all we can to prevent its exploitation.

• Pro-MEV camp. MEV is good. It provides a financial incentive for searchers to perform actions that ultimately benefit the user experience and stabilities the marketplace. Even more, MEV exploitation is inevitable and we should do all we can to embrace it.

There are some easily identifiable factors contributing to the binary-like opinions within the community. More often than not, the perspective is rooted in anecdotal evidence and personal experience within the financial sector.

Some argue that the prevalence of high frequency trading in the traditional finance system tends to disadvantage smaller traders while favouring large trading firms who have the resources (and permissions) to execute their trades more quickly. Plus, it leads to users performing the trade to get the worse deal while allowing large firms to profit from it.

In contrast, others view the exploitation of MEV inevitable due to the open and permissionless nature of blockchain systems. It is an inherit aspect of how the system operates, and arguably, the stability of a blockchain system depends on our ability to maximise extract while sharing its profits to all participants.

Evaluating how MEV impacts a Blockchain System

To understand whether MEV is morally justifiable, we should evaluate how it impacts the fair reward assumption of layer-1 blockchain systems and whether it negatively impacts the intent of a user’s transaction.

Fair Reward for All Proposers

A core property for a layer-1 blockchain, like Bitcoin and Ethereum, is that all proposers make approximately the same reward for producing blocks on behalf of the network.

The motivation to offer a fair reward for all proposers has two key aspects that underpin the security and reliability of a blockchain system.

• Keep the proposer set decentralised. Firstly, it aims to prevent a single proposer from growing disproportionately larger than all other proposers over time, which could potentially enable them to accumulate enough capital to execute a 51% attack.

• Financial incentive to follow the longest chain. Secondly, it creates a financial incentive for all proposers to consistently extend the longest chain. If a block’s reward significantly surpasses the next block, then there is a risk that a proposer might be incentivised to re-org the chain’s tip, resulting in instability for users.

In the Ethereum community, the above insight has led to proposer-builder separation (PBS) as a method to democratize the profits of MEV. Put another way, the focus of embracing MEV is to fairly share the rewards across all Proposers, and ultimately protect the network’s decentralization and reliability.

Conversely, the requirement to offer a fair reward to all proposers is different in a rollup ecosystem, primarily because of the divergent underlying trust assumptions.

In a layer-1 blockchain, such as Ethereum, the trust assumption rests on a majority of proposers acting honestly to maintain the system’s integrity. It should optimise for a vast network of diverse participants and rewarding them for their uptime.

In a rollup, the trust requirement is far more modest:

• Safety. One honest party to safeguard the system’s integrity.

• Liveness. Any user can submit their transaction using the on-chain forced inclusion mechanism.

Of course, the forced inclusion mechanism should be a last-resort option that can be used by the user (I am not a fan of based-rollups).

Nearly all users depend on the appointed Proposer to decide the ordering of transactions and to offer a soft confirmation about how their transaction will eventually execute. Soft confirmations can be upheld by a single proposer, or multiple proposers working together. You can read this article to learn more about the different tiers of transaction finality in a rollup.

Decentralized Sequencing. Some rollups may seek a stronger trust assumption, like an honest majority, if they want to guarantee uptime of soft-confirmations amongst a committee (or set) of Proposers. It is not a strict requirement for a rollup and various options are still being explored by the community.

The important takeaway is that a rollup does not necessarily need to guarantee the uptime for hundreds of thousands of participants or to maximise the decentralisation of participants. The priority is to ensure the system is openly accessible and a single honest party can step in at the right time to protect it.

Thus, there is a weaker need to embrace MEV and offer a fair reward for all proposers of a rollup, especially if there is only one proposer. The question to embrace MEV is not for security of the system, but whether it is in the proposer’s best interest to leave money on the table or to capture some profit from an additional revenue stream.

It remains an open research question, but empirical evidence that most rollups today have successfully operated with a single Sequencer while not embracing MEV, suggests this conclusion.

Interference of a User’s Transaction

Another facet to consider when evaluating the morality of MEV is to understand the potential influence, whether positively or negatively, that a searcher’s transaction bundle can exert on the execution of a user’s transaction.

We argue that only focusing on how it impacts the intent of a user’s transaction is overly limited.

An evaluation should encompass a broader perspective that takes into account ramifications on agents within a DeFi protocol, as well as its capacity to contribute to the synchronous operations of DeFi protocols.

Let’s take this opportunity to consider specific examples of transaction bundling and whether it can be justified as a moral activity.

Front-running

The strategy is often associated with a searcher evaluating a user’s transaction, copying its content, and stealing the user’s opportunity.

• Negative — Guaranteed Tx Delivery

  • Near’s Rainbow Bridge took advantage of MEV bots to guarantee transaction delivery for their fraud proofs. This helps to protect the integrity of a DeFi protocol and ultimately protects users.

• Negative — Censorship issues

  • Front-running can enable censorship as the searcher forces the user’s transaction to fail.

  • This was witnessed when Vitalik was attempting to “dump” SHIBA tokens and MEV bots interfered with his trades to prevent his ability to sell the tokens.

  • Vitalik was forced to migrate to CoW Swap and send this transactions directly to the proposers (miners).

• Positive — Cannot recover exposed funds

  • In the Dark Forest example, the MEV bot was able to steal the funds while the user tried to recover it from an exposed/broken smart contract.

Sandwiching

The strategy is often associated with a searcher changing the exchange rate before and after a user’s trade.

• Negative — Worst exchange rate

  • There are many instances of sandwiching where a user ultimately ends up with the worst exchange rate when performing their swap. This is because the searcher moves the price not the user’s favour, the user’s swap executes, and then the searcher moves the price back.

  • The searcher benefits by creating an arbitrage-opportunity and collects any positive slippage that the user may have received. There are arguments that sandwiching can be beneficial for routing trades, but most discourse focuses on the immediate negative experience for the user.

• Positive — Best exchange rate (Positive).

  • Just In Time Liquidity (JIT) entails the searcher strategically injecting concentrated liquidity just before the user's swap and subsequently withdrawing it immediately after the swap.

  • This allows the user to secure a more favourable exchange rate when performing their swap while the searcher earns the bulk of the fees for facilitating the swap.

  • Passive liquidity providers (LPs) may find themselves at a disadvantage, as they receive minimal to no fees since it's the searcher's liquidity, not theirs, that is utilised to execute the swap.

Unfortunately, it was recently discovered in the wild that both sandwich strategies can be combined and results in the worse of both worlds. The user will receive the worst exchange rate and allows the searcher to obtain most of the fees for facilitating the swap. Thus, both the user and passive LPs lose out.

Back-running

The strategy is often associated with a searcher chasing an arbitrage-like opportunity.

• Arbitrage-like opportunities (Positive).

  • The most common case for backrunning, to the best of my knowledge, is when a searcher wants to arbitrage the exchange rate after a large swap performed by the user.

  • This is beneficial to the synchronicity of DeFi Protocols as it keeps the price of tokens in sync and ultimately for the user as they are always paying the market rate when exchanging for a token.

I cannot recall any back-running strategies that have a negative impact on a user or DeFI protocol. If you can think of any, please leave it in the comments!

Objective Assessment with Subjective Judgements is Required

There is an increasing need for an enhanced methodology to gauge the impact of MEV.

This methodology should encompass:

• Transaction bundle strategy,

• Application-specific effects,

• Profitability for agents it benefits,

• Potential losses for agents that do not benefit,

• Frequency of occurrence.

With objective metrics as the above, the community can then make a value-judgement on its morality. For example, if we consider Just in Time liquidity, it provides users with a better exchange rate for tail-end assets, and if it represents <1% of all trades, then it could be a justifiable MEV strategy to allow as the benefits outweigh the risks.

To the best of my knowledge, the above type of analysis is completely missing in the discourse of MEV. The on-chain data is available, but the data set is not yet easily accessible for the above analysis.

There is a discussion to be had in the community on how to strike the balance between supporting MEV activities while maintaining fairness in the ecosystem, where fairness should be explicitly defined,

Enforcing Subjectiveness?

The discourse surrounding the acceptance of morally justifiable forms of MEV prompts a fundamental inquiry:

In the context of a layer-1 blockchain like Ethereum, there is no central authority empowered to impose subjective judgements. The responsibility for determining whether certain types of MEV should be excluded falls upon individual proposers or builders. However, such exclusions are often impractical without coordinated collective action.

Furthermore, given the community’s commitment to preserving credible neutrality and upholding the principles of decentralisation to safeguard the right to transact, enforcing any form of subjective judgement on a network like Ethereum is highly unlikely. Even the OFAC sanctions enforcement ultimately failed to garner 100% support.

Now, when we shift our focus to a layer-2 rollup solution, we encounter a different scenario.

Here, a single entity, the Proposer, possesses the authority to enforce subjective judgements regarding soft-confirmations they may choose to provide for transactions. For instance, in most rollup implementations, trust is placed in the Proposer not to exploit their privileged position for additional rewards through the manipulation of MEV opportunities. However, it's conceivable that in the future, a Proposer might opt to restrict specific forms of MEV — at least to the best of their ability to do so.

This raises the question on the practicality to enforce subjectiveness and leads to an interesting research problem:

Facilitate soft-confirmations for selective MEV. Evaluate the effectiveness for a Sequencer to inspect transactions in real-time, determine the MEV strategy deployed and decide whether they should be rejected, without impacting the overall user experience or increasing the system’s latency for soft finality.

Put another way, if there is an objective methodology for evaluating the impact of MEV and a subjective framework for deciding which MEV should be tolerated, how practical is it for a rollup’s Sequencer to enforce it.

Credible neutrality above all else?

As we delve into the ethical considerations of MEV and the potential justification for restricting certain forms of it, a broader moral dilemma emerges—one that revolves around the potential for these judgements to inadvertently foster censorship.

There is a legitimate fear that the freedom of users to transact can be eroded over time as certain transactions are seen as morally unjust by the operators of the system. It may start off with transactions that do directly harm the user, but eventually lead to the censorship of other forms of transactions simply because the technology now exists to enable it.

I strongly believe that a layer-1 blockchain like Ethereum must remain credibly neutral at all costs. Not only to protect the right to transact, but also protect all rollups that build on top of it. It is a pre-requisite to guarantee that Ethereum can be the root of trust and the platform for protecting user' funds that are locked into an off-chain system.

On the other hand, there is a potential for Proposers in a rollup-like system to implement real-time transaction filtering and forego credible neutrality.

This avenue of research is likely to be pursued regardless of our opinions on the importance of credible neutrality. It is imperative for our community to proactively engage with it and understand the extent to which it can be practically implemented.

It is true that embracing the practicality of transaction filtering may inadvertently lead to a system that erodes the freedom of users to transact.

This is why our community must work in parallel on another research stream that focuses on ordering protocols that tie the hands of the proposer, preventing their ability to filter specific transactions, and ultimately protect the user’s right to transact.

Can’t be evil by default. In my view, the end-game is to build a rollup where the Proposer cannot be evil as opposed to simply promising that they won’t be evil.

Assuming the community decides to implement protocols that tie the hands of the proposer, then there is a legitimate fear that MEV must be embraced by default. I hold the view that this is not necessarily the case.

For example, the Time-boost proposal is an example that combines:

• First come first serve ordering,

• Ordering agreement by committee,

• Enable back-running via micro-auctions.

It allows a rollup to embrace back-running strategies, something that is generally considered morally just, while making it difficult to sandwich a user’s transaction without direct access to the user.

Without transaction filtering, the trade-off is that an ordering protocol may discourage entire categories of MEV strategies, but this may be necessary to help protect the freedom of users to transact.

Of course, on the flip side, perhaps a rollup should not try to prevent MEV opportunities at all and embrace MEV in its entirety. Allow the marketplace to reach some equilibrium around the profits generated by MEV by enabling an open-market of searchers to participate. Anything can happen!

There is no right answer on whether to prevent or embrace MEV.

Thankfully, rollups as a technology stack, offer us the freedom to experiment with all of the above, and find the solution that best protects the interest of all parties involved including the transacting user, agents in DeFi protocols, and the participants in the underlying protocol.

I attended a trip organised by Borderless Africa alongside a small cohort including Yoseph Ayele, Songyi Lee, Jeff Coleman, Ye Zhang, Kartik Talwar and Jacob Willemsma.

The trip was split between Kenya and Nigeria across ~9 days.

In each country:

• General meet-up for Q&A and Panel Discussion,

• Intimate circle discussions led by locals,

• Developer educational workshops.

Alongside the meet-ups, we had the opportunity to meet with founders and well-known contributors.

This article represents my own personal views and the insights that I gleaned from all the conversations. It focuses on:

• USDT and Binance P2P are Widely Popular

• Hunger To Earn On Merit and Not Geographical Location

• What Does The Future Entail?

Disclaimer: Every meet-up invited locals to learn about Ethereum and layer-2 protocols. The audience attending these events are very likely to have a keen interest in cryptocurrencies. It may not widely represent the population today, but it may in the future as crypto adoption continues to snowball.

USDT and Binance P2P Are Widely Popular

I asked the same set of questions at every meet-up:

• Who gets paid in crypto?

• Who gets paid in their local currency?

• Who prefers crypto as in BTC/ETH?

• Who prefers stablecoins?

• Who is actively using Binance p2p marketplace?

Across all meet-ups, the response was fairly consistent from nearly all participants:

• They had received a payment via cryptocurrency for their work.

• They prefer to be paid in stablecoins with a specific preference for USDT.

• They use Binance’s P2P marketplace to swap stablecoins into their local currency (and vice versa).

There was not a significant interest to hold native crypto assets like Bitcoin or Ethereum. Not only that, but participants preferred networks like Tron or Binance Smart Chain to transact.

The reason: Little to no fees with “rapid” confirmation times.

Binance is Popular

While there is a rise in competitors like onboard, nearly all participants continue to rely on Binance as their preferred choice for transacting.

It was explained to me that Binance moved into Africa with Binance labs around 2018. There was latent interest, but no initial plans to expand. It happened over time as Binance realised that African’s wanted access to stablecoins.

It became a significant market for the company and adoption is evident on the ground. I saw several locals wearing Binance swag, but they had never worked at the company.

To me, the rise of USDT seems to be coincidental. In 2018, there was no competition in the stablecoin market and Africa appears to have followed the wider market trend of the time as USDT overtook BTC as the most liquid and traded asset. I wish I had asked more about the preference of USDT over USDC.

Crypto Represents Convenient Access to Stablecoins

The rise of stablecoins cannot be understated.

• Stablecoins represent the single most important innovation from the perspective of Africans.

It enables convenient access to the US dollar:

• Africans can bypass the local black market.

• Africans no longer need to deal with its associated real-world dangers.

• Africans can exchange at a rate that reflects the wider market.

Even more, there is no need to hide US dollars under the mattress. It is all digital.

Of course — the work required to enable stablecoin adoption — is not an easy feat.

Some readers may think: “Well, if I can represent a US dollar as an asset on-chain, then I have solved the problem!”.

It is the first step towards solving the problem. The wider issue is creating an online marketplace that can foster a liquid market for swapping stablecoins into their local currency. The market must enable swaps at size and with minimal price slippage too.

Why is this the true challenge? There are around 42 currencies in the nations of Africa. We need to foster a liquid market that can facilitate swaps for all local currencies with the stablecoin. It requires many local participants to make it a reality.

Thankfully, the one thing crypto rails is really good at is allowing participants to collectively work together and provide liquidity for assets when there is a real demand for it.

So far, this works well in Kenya and Nigeria. I do not have data to confirm this is the case for all 42 currencies in Africa.

Why Stablecoins? And Not Crypto Assets?

It may come as a surprise to many, but local currencies in African nations have devalued at a fast pace relative to the US dollar. Some currencies, like in Zimbabwe, failed due to hyper inflation.

For example — since 2008:

• Nigerian Naira has depreciated by 7/8th relative to the US dollar.

• Kenyan Shilling has undergone a 50% devaluation relative to the US dollar.

The devaluation for the Kenyan Shilling is remarkable given that Kenya’s GDP has tripled in the same period from 2008 to 2023. The currency continues to devalue against a backdrop of economic growth. Increasing confidence in the economy, but not the local currency.

It may go without saying, but a large swath of the population in Kenya and Nigeria continue to live in absolute poverty.

To westerners, especially in the UK, the idea of poverty is living in a council flat with social security (benefit) payments. Families do struggle to put food on the table, but they have a roof over their head with access to healthcare. If we consider homelessness, there is a population of ~271,000 in the UK which represents 0.4% of the total population (~67m).

It is estimated that 60% of Nairobi’s population lives in a slum. Additionally, the worldbank estimates ~50% in both Nigeria and Kenya.

In the slums, an entire family may live inside a single room (“studio”). Outside their home is a tiny corridor that connects them to the main road. As we experienced, sewage passes through the tiny corridors and it is like an obstacle course to navigate your way through. Many live on <1 USD a day and there is little to no social welfare.

This is why the following statement is tone-death to Africans, especially those living in the slums.

• “The real win is helping people to understand why Bitcoin is the best long term savings asset.”

I am not a fan of criticising comments like the above, but it is out of touch with real-world situations and the reality that locals face.

I’m sure locals would love to have long-term saving goals, but they have an urgent necessity to address immediate expenses. For example, if they do not pay their bills for whatever reason, a landlord may pay $10 for a gang of youths with sharpened metal to threaten the tenant to pay their rent.

It is actually remarkable to think that slums still have landlords.

I do not believe even stablecoins can help the people living in slums. The solution is to create better market conditions for the locals to earn wealth, build better infrastructure, and escape the slums. I can see how individuals may seek to work online and receive payments via crypto rails, but that is not a readily available solution to many living in these conditions.

Put another way: Crypto rails is not yet relevant to ~50% of the population in Nigeria or Kenya outside of exceptional cases.

The Africans who use stablecoins are not living in the slums. I’d imagine they have achieved some form of financial stability and they can afford to pay for near-term expenses.

The crypto meme that the US dollar is losing its spending power over time and we should keep all our savings in native crypto assets means very little to them. It is an alien concept.

The opposite is true in Africa. The US Dollar’s spending power is up only relative to their own local currency. It is a far safer bet than holding native crypto assets.

To Africans, the US Dollar is extremely stable and that is why stablecoins have found product-market fit.

To Earn on Merit and Not Geographical Location

The demographics of attendees included:

• Community leaders,

• Software developers,

• Startup founders.

This demographic makes sense since our group represented ETHGlobal, Arbitrum and Scroll alongside a sponsorship by Optimism.

Hunger to Succeed Against a Backdrop of Discrimination and Mistrust

The following questions and answers originate from meet-ups in Nigeria.

Everyone in the audience raised their hand and laughed in tandem with each other.

It is very common to get locked out of services because the IP address in Africa (especially Nigeria) is considered suspicious by online service providers. Some of us also got locked out of our accounts.

The end result: African’s get locked out of services offered by global Fintech companies that we, in the west, take for granted.

We were told that ~70% of Nigerians do not hold a passport.

The Nigerian Government have put together a scheme called the National Identification Number (NIN) for identification and KYC purposes, but it is embroiled with issues and delays.

On the other hand, the Central Bank of Nigeria runs a separate identification process called the Bank Verification Number (BVN). It acts as a single identifier for the user across all banking services. Only 25% of Nigeria’s population (57 million) have signed up to it.

Identity is still a hard problem in Nigeria. It will impact the ability for companies to satisfy compliance requirements before funds can be sent to Nigerians. Crypto rails or not — this identity problem that can adhere to regulatory frameworks really needs solved.

No one laughed this time.

Everyone raised their hand and looked around the room. It was very sobering.

It is disheartening that locals are discriminated and considered untrustworthy, especially when it originates due to their nationality and geographical location. The Nigerian Prince meme encapsulates this online opinion.

If there is one takeaway to the reader. I believe this is why blockchain technology, and certainly rollup as a technology stack, is so important to our colleagues in Africa.

It diminishes the power dynamics between the user and operator, enabling parties who desire to engage in transactions but harbor mutual distrust, to ultimately carry out transactions in a secure manner with each other.

Put another way, it allows a user to:

• Lock funds into an operator’s service,

• Interact with the service,

• Eventually withdraw their funds from the service

…While not trusting the service operator.

Our ability to define, measure, and reduce trust in a financial interaction, is what makes the crypto space so special. I’ve called it the field of trust engineering for the longest time.

I hope someday the technology stack will be ready to benefit our colleagues at scale.

Allowing us to transact on their platform, pay them a fee for their service, and most importantly, without the need for us to be concerned about who they are or where they live.

One participant, alongside a few comments by others, gave an insightful speech to this question. I’ve tried to summarise the key points below.

“Nigerians, in particular, are hungry for opportunity. They are driven by incentives. Design the right incentive schemes and Nigerians will come.

Nigerians learn everything they know from the internet. Give them a Nokia 3310 and they’ll use it as a tool to go somewhere.

They want to escape the local environment, work online and join the global workforce. They see the blockchain as the great equalizer. Allowing them to earn on merit and not location.

The amount of money needed for a project to succeed (in Africa) is less. Every $1 spent in the US/EU, you’d get 1 point, but in Africa you’d get 1000 points.”

As another datapoint:

“If there is a Nigerian on the project, then there is money to be made. Be wary if there are no Nigerians.” - A local in Kenya

I laughed, but it really demonstrates that hunger to make it.

Web3 Bridge

Take a second to imagine:

• Leaving your friends and family for 16 weeks, traveling thousands of kilometres, to live in a house with 40 others (bunk beds) to learn about Web3.

• In the hope for a life changing opportunity.

• The opportunity to work online, earn based on merit, and not be discriminated against because of your geographical location.

That is Web3Bridge.

Web3Bridge is an educational programme that has been running, for free, since 2019.

The programme attracts Web2 developers, and aspiring programmers, who want to learn how to get started in the Web3 industry.

We met a woman who left her husband and three kids at home, so she could take part in it. I imagine many others in that room face similar dilemmas on leaving behind loved ones for a long time and that courage should not be understated.

The curriculum and the topics covered are impressive too. It ranges from basic concepts like what is a blockchain, to implementing your first solidity (or Cairo) smart contract, to learning the full-stack for implementing a Web3 application.

Again, the entire programme is free to attend, both in person and online. We learnt the continued existence of Web3Bridge relies on grants and personal investment (time and money) from the founders.

The physical setup consists of a few houses for now, but the Founder Ayo told us about his dream. He wants to buy nearby plots of land and open a larger campus. With this greater physical capacity, he can increase the cohort size and teach hundreds of developers at a time.

I do hope his vision can come true and the crypto community should consider how they can support Web3Bridge.

What Does The Future Entail?

Having had the opportunity to visit Kenya and Nigeria for nine days, I’ve gained some valuable insights that have led me to some important conclusions about the future — for its workforce, how crypto may play a role and whether we (the west) can support their growth.

Africa Is Uniquely Positioned to Succeed

In my opinion:

• Africans share the European time zone,

• They speak fluent European languages, especially English and French,

• Deep desire to succeed and earn their wealth.

Africans are in an advantageous position to compete in the online arena.

In the digital realm, if a worker is needed for a specific time zone and they can communicate in the same language, then it may not matter if the worker is in Europe or Africa.

Again, to me, the overarching goal to help Africans succeed:

• Better crypto rails to provide a reliable path for hiring and paying Africans,

• Reduce the key differentiators that allow an online community to distinguish between Africans and Europeans,

• Enable African developers to leverage crypto as a software stack and eliminate the role of a trusted service operator.

Long term: The two communities, Africans and Europeans, should become indistinguishable from each other, in the digital realm.

Only then, will Africans by and large have the ability to earn on merit, and not their geographical location.

Africans Understand Crypto

Thanks to the internet and our online communities, Africans are not isolated from the wider Ethereum community.

We met teams and individuals who:

• Are building projects on Arbitrum,

• Participated at ETHGlobal Hackathons and won bounties,

• Learning how to implement Cairo smart contracts for StarkNet.

• Aware of Optimism’s retrospective grants,

• Are eager to learn about ZKPs, so much so, that Ye Zhang failed to finish his slide deck during both developer workshops.

Africans do not need us, the west, to visit them and preach why they should care about Ethereum or the wider cryptocurrency ecosystem.

Heck, they have a crazy large NFT community.

Africans are already sold on crypto and the number of enthusiasts is steadily increasing.

How Can We Help Africa?

When it comes to understanding how crypto can be used, Africans do not need our help. If anything, we need their help to showcase the use cases.

As this article outlines, how Africans can conveniently access US dollars using crypto helps validate all the technology we are building. It provides indisputable evidence that crypto has product market fit and there are many people who depend on it.

On the other hand, we need to better understand the challenges that Africans face before they can participate in the online economy and be set up to kick-start their own ventures in the cryptocurrency space. Some challenges include:

• Lack of government support.

  • Kenya has no crypto law, but the Government just seized the hardware for WorldCoin, citing its failure to disclose true intentions.

  • Nigeria banned Banks from participating, but not individuals from using it.

• Little to no VC presence.

  • Angel investing is available, but it is very rare.

  • Issues around identity makes legal compliance difficult and it can act as a blocker to raising funds.

• No time to tinker.

  • The desire to succeed makes Africans very laser-focused on building the next product.

  • They lack the free time to simply tinker with technology for fun and this potentially hampers their ability to come up with innovative new ideas.

• Global perceptions

  • Westerns have misperceptions about the capability and the real-world needs of Africans,

  • Africans can demonstrate their ability and merit, but it needs all of us to amplify it.

Grant Programme for Africa

One solution that came up, time and time again, is the need for a grant programme that is focused on Africans.

There are a few points that I want to make in regards to grant programs and the feedback is relevant for any program (not just one focused on Africa):

• Grants should be given to projects and individuals who need it to push the needle,

• Grants should be given to individuals who may benefit from time to tinker and better understand research-oriented ideas,

• Grants can de-risk the pre-seed landscape for VCs,

• Grants should not be seen as a long-term funding source as it is very easy to continue funding projects that should be allowed to fail,

• Grants should ONLY be issued when there is clear and indisputable evidence of proof of work by the grantee,

• Grants can be offered to foster an environment, connect developers and grow a community who can knowledge share with each other.

Any grant program that seeks to work in Africa, or in any geographical location, really needs local leaders to run it. Grant managers can be paid to review and authorise grants. It can very well be a full-time role.

Most people, even exceptional local leaders, have no experience running or participating in a grant program. Like any system, it is always better to start small and allow it to build up over time. It is wise not to hand over a very large treasury to a brand new grant programme. Grant managers should have time to earn a reputation for how they manage the treasury and demonstrate impacted from the grants.

Grants are NOT a silver-bullet to solve the local problems, especially in Africa. There is only a finite treasury and it can very easily be depleted. It is best to be cautious on how the funds are spent. Grants should be reserved to help the most promising groups and individuals to push the needle on their project. It is “free” money, but it should not be and it cannot be widely available.

To me, Uniswap is one of the the best success stories. Hayden, the founder, was offered a $50k grant by the Ethereum Foundation to pay for audits. That was enough money to pay the audits, push the needle, and led to the tech giant that is Uniswap.

It doesn’t take a lot of money to push the needle. Less is often more.

Finally, there are two issues that block the success of any grant program.

• It may not be possible to offer grants to Africans if they cannot adhere to KYC/AML rules.

• A local venture capital network needs to emerge that can later fund any success stories.

Both are structural and infrastructure issues that live outside the realm of crypto. Especially the venture capital network, you need ex-founders who are willing to invest and help a new set of founders build large and sustainable companies.

Physical Education

The one thing missing in Africa, but abundant in the west, is on-site education.

In the west, there is an abundance of workshops at conferences, summer and winter schools, available to attend and learn about the core technology that fuels cryptocurrencies. Even more so, many of the educational events are free to attend.

Regrettably, many Africans face constraints when it comes to physically attending crypto-related events.

A significant number of Africans lack passports, and even if they possess one, the need for a visa and the potential financial burden of travel costs present considerable challenges.

They simply cannot come to us.

As an experiment, Ye Zhang and I ran a developer workshop in both Kenya and Nigeria.

To our surprise, software developers showed up and in great (unexpected) numbers too. They asked many good technical questions. Poor Ye, he did not manage to finish his slides, due to the onslaught of questions.

There is an abundance of technical savvy developers in Africa who want to learn about the core infrastructure of Ethereum alongside exotic topics like zero knowledge proofs.

To date, they have exclusively relied on the internet to learn about it, but there is nothing better than in-person interaction with world experts on a topic. Not only from a learning perspective, but to gain inspiration to pursue a topic as experts tend to love their topic and that type of intellectual love is contagious.

This leads me to next steps: We do not really need a conference that shills and markets new Web3 projects to Africans. There is a desire for knowledge sharing and learning.

The biggest contribution we can make to Africans is to organise and run an in-person educational program. Like a summer school — inviting experts to come and teach technical topics.

Final Conclusion

There are several takeaways from the above article:

• Crypto rails has found product market fit as a convenient method to access US dollars,

• Binance is popular in Africa due to early expansion and facilitating its peer to peer market,

• Africans want to earn based on merit rather than geographical location and they have the resilience to pursue it,

• Long term goal should be to reduce the differentiators between Europeans and Africans in the digital realm.

• Africans face many challenges from lack of regulatory support, inability to travel, difficulty to adhere to KYC/AML, little to no venture capital networks, and simply no time to experiment with new ideas.

• Even more so, nearly all Nigerians raised their hands to acknowledge that they lost an opportunity because people could not trust them.

• Web3Bridge’s educational program is doing God’s work and the next step is for the west to assist in-person with its own summer school.

One of the impacts of our visit was to help connect the community too. Many of the attendees did not know each other, especially the developers. It sounds like some of the local community leaders will attempt to keep organising more events. As more of us visit, hopefully it’ll help the local leaders build larger communities too.

There are two final topics that I’d like to discuss.

Africans have a fun-loving nature. We may have only visited Nigeria/Kenya, but we met other Africans from Uganda, Ghana alongside others. They happily make jokes about other African nations like Nigerians are all dramatic or They visit Ghana when they need to chill out.

The locals were more than happy to teach me some funny words like Mubaba, Alagba, m’soupa that are compliments for men and women. I took every opportunity to say the phrases and most of the time they laughed, especially the Kenyans.

They even told me that East Africans have round foreheads and West Africans have flat foreheads. lol.

It is very easy, as a programmer, to focus on the wider system and try to evaluate how it can be fixed to the benefit of all. However, we must never forget the people at the heart of this system. It is always worth taking the time to learn about their customs, humour, and to fully appreciate what they have had to give up to make it into the same room as the rest of us.

What is Africa?

One remarkable aspect about Africa is its immense cultural richness and how it impacts how Africans perceive the continent.

In West Africa, there is a Schengen-like arrangement that allows for visa-free travel across several countries. However, it is difficult and not common to travel from East Africa to West Africa (and vice versa). It requires a visa, it is financially costly, and it takes time too. For example, Lagos to Nairobi has a flight time of ~5 hours and may cost >$600 for a return flight.

I noticed that East and West Africa mutually recognise each other as an integral parts of the African identity. On the other hand, they do not consider South Africa or North Africa as “Africa” by the same standard. South Africa is considered more European and North Africa is more Islamic.

The sentiment was exemplified by the fact that no one, who I asked at least, had travelled to Algeria or expressed any intent to do so. This is interesting as my step father grew up in Algeria and he very much considers himself to be African.

I don’t have a great insight to why. I imagine it has to do with cultural differences and Africa’s colonial history. If anyone wants to comment with great reference points, I’d appreciate it!

There has been a substantial discussion on whether a validating bridge defines the rollup, or put another way:

rollup ==? bridge.

We need to step back and look at the problem from first principles.

• What is a blockchain?

• How do we bridge assets from one database to another database?

Short recap: Blockchain as a Database (Part 1)

Our previous blog post explored “what is a blockchain?” and it was a wonderful opportunity to appreciate the purpose of a blockchain.

So, what is a blockchain?

• A blockchain is just a data structure for dictating the total ordering of data (transactions).

It only has a single purpose:

• Anyone can fetch the blockchain, parse the data (transactions) in order, and compute a copy of the same database.

Now — one of the hardest problems in a blockchain network — is how all parties can verify they have a copy of the same database and the one true blockchain.

Put simply, this entire field of blockchain engineering is focused on:

• Instantiating a single database.

The only way for all parties, on a global scale, to converge on the same blockchain is to incorporate a consensus protocol. It allows all parties to collectively agree upon single decision — the latest block of data to append.

One interesting side note is that the block of data may not necessarily be a list of transactions and in fact there are two options:

• Transaction history. An explicit list of transactions to execute.

• State diffs. A list of “state diffs” that can be applied to update storage slots in the database.

It is up to the participants to decide on a rule set (“state transition function”) for how to parse the data into an update that can be applied to the database. The state diff approach is a very recent addition thanks to the rise of validity proofs.

So, in the end, all blockchain protocols are focused on guaranteeing that the right data is ordered correctly and publicly available to all. In fact, there is a very subtle assumption:

• Recent broadcast. A consensus protocol only guarantees the publication of data at a point of time.

There is no guarantee that historically agreed decisions are available at all and most nodes who provide it do so altruistically.

Finally — there is a choice a project can make when deciding how to ensure the data for the database is publicly available:

• Deploy a new consensus protocol (“layer-1”)?

• Re-use an existing consensus protocol (“the rollup”)?

The former is a Hercule effort. It requires bootstrapping an entire eco-system that is willing to step up and typically requires an honest majority of participants to protect the system.

The rollup approach admits that bootstrapping such an eco-system is hard and there is little value in attempting to repeat it. It is much easier to leverage the layer-1 blockchain as a public bulletin board and allow it to guarantee the availability (and ordering) of all relevant data.

Whether a project decides to deploy a new layer-1 or a rollup, all approaches leads to a world of databases with varying degrees of trust assumptions and security.

We could easily categorise them as ‘closed’, ‘public’, or ‘open’ databases which focuses on whether the database is publicly accessible to read and the mechanism used to enable write-access to the database.

The above sounds theoretical, but there is empirical evidence that we now live in a world of hundreds, and thousands, of databases that want to interact with crypto assets.

This brings us to the next question:

• How can a user move their assets from one database to another database?

We need to study how a user can move their assets from one database to another database. Even more generically, how can they pass messages across different systems.

Let’s find out!

Bridging Across Database

There is a single component that enables a world of blockchains:

• Bridge: Provides passage over something that is otherwise difficult or impossible to cross.

The job of a bridge is very simple. It should facilitate passing a message from one database to another database. It can be viewed as a communication protocol where an entity (bridge) sits between a sender and receiver.

All communication protocols strive to provide the following properties:

• Timely delivery. A message is available, at the earliest possible moment, to be consumed by the receiver.

• Integrity. A message’s content in its entirety should be delivered.

• Authentication. The receiver can verify that the message was indeed initiated by the sender.

One big difference is that the bridge, as as communication protocol, does not strive to protect confidentiality of the message. It is optional in the realm of bridges and there is no bridge protocol that protects the privacy of a message.

Now — the main problem that a bridge needs to solve — is the ability to convince the receiver about the message’s authenticity aka the attestation process.

Human-operated Bridges

In nearly all bridge designs, there is a set of authorities that sit between the sender (Database A) and receiver (Database B). Of course, the sender and receiver may be smart contracts that live on the respective database.

The authorities will:

• Fetch. Pick up new messages from Database A.

• Sign. Digitally sign all messages that should be sent to Database B.

• Attest. Send the digital signature and message to Database B.

The attestation process requires the receiver database (Database A) to verify the message was indeed digitally signed by the trusted authorities. If so, it can be confident about the message’s content and origin.

The key issue: trusting the appointed authorities.

Going further, both the sender and receiver must blindly trust the appointed authorities to deliver the message and attest to its integrity. This is because the sender and receiver cannot see the outside world without assistance from a third party.

This type of bridge design can be called a human-operated bridge.

It relies on humans (server-side applications) to facilitate communication and enforce all rules on behalf of the sender/receiver. It is the easiest type of bridge to deploy and it can be applied to a wide range of different blockchains, but it is the hardest to secure and protect at scale.

Unfortunately, the entire point of cryptocurrency and the movement started by Satoshi Nakamoto was to remove all the trust required to make a system work and to replace it with cryptographic proof.

We need to do better.

Evolving Attestation Confidence

We should send cryptographic evidence, alongside the sender’s message, that will attest to the message’s authenticity.

If successful, the evidence should convince the receiving smart contract beyond all reasonable doubt about the message’s authenticity without having to trust the human operator.

The human operator’s role can be reduced: Assist with relaying messages (“relayer”) from Database A to Database B.

Let’s explore several approaches with varying degrees to what the evidence can actually prove.

Enforce Delivery of Correct Attestation (Nomad)

We ask the following question for the first approach:

• Can we reduce trust in the operator by holding them accountable to their attestation?

In this approach, an authority still needs to attest to the authenticity of a message, but the authority can be immediately penalised if they attempt to cheat. For example, by attesting to a different and potentially conflicting message.

The Nomad Protocol is an example that implements the accountable approach.

It assumes there are two authorities:

• Endorsement authority. Responsible for reading Database A, signing its proposed message, and submitting the digital signature to Database A.

• Veto authority. Responsible for protecting Database B by cross-checking whether the signed message originated from Database A.

The endorsement authority should lock a considerable financial stake to deter malicious behaviour and potentially anyone can perform the role. On the other hand, the veto authority, must be appointed before the protocol is instantiated and it remains an open research problem on how to make the veto authority role permissionless.

The Nomad Protocol has three stages:

• Endorse message. The endorser reads the message in Database A, signs the message and submits signature to Database A.

• Relay message. Anyone can take the signed message and forward it onto Database B.

• Opportunity to veto. There is a fixed time window (i.e., 30 minutes) for the veto authority to check whether the message sent to Database B is exactly the same as the message on Database A. If it is not the same, then the authority should veto and cancel the message.

It is a lightweight protocol as the only on-chain task is to verify a digital signature and the trusted authorities only need to monitor the relevant database that receives a message.

While our example assumes a single receiving database for illustrative purposes, the Nomad Protocol can be extended to allow multiple databases to receive the same signed message.

We need to consider the case when an authority may attempt to cheat the bridge protocol:

• Endorser signs a message not endorsed by Database A.

• Veto authority vetoes a message that was endorsed by Database A.

In the first case, the endorser is forced to produce a digital signature that Database A will not recognise if they endeavour to deceive the receiver. Any party can take the signature, send it to Database A, and empower Database A to slash the endorser.

In the second case, it remains a fully trusted role and there is no in-protocol method to fight back. One caveat is that the protocol transcript is publicly available for all participants and the veto authority could be removed after the fact via a voting protocol. However, by then, the damage may already be done as veto’ing an honest message can have significant implications on smart contracts that rely on time-based actions (i.e., liquidations).

Check Agreement of Consensus Protocol (SPV)

We ask the following question for the second approach:

• Can we keep track of the consensus protocol for Database A?

As mentioned in the first post, all blockchain networks have a consensus protocol that periodically agrees to a new block at the tip of the chain. A block can be thought of as a batch update to the database.

In this approach, the goal is to allow the receiving smart contract on Database B to confidently track agreements produced by the consensus protocol of Database A.

To make this a reality, the consensus protocol must be light client friendly by default:

• Light client: Require the minimum computation and data to confidently be convinced about the current state of the database.

Put simply, a light client allows a user to learn the value for an entry in the database and have confidence that the consensus protocol agreed the entry should be in the database.

The notion of a light client is as old as Bitcoin.

It was called Simplified Payment Verification (SPV) mode in the Bitcoin white paper. SPV allows a user to verify that they had indeed received coins on Bitcoin without the need to validate and hold a copy of the entire Bitcoin database.

The SPV process operates in the following manner.

• Cryptographic commitments. Every block header contains a cryptographic commitment (tx_root) that represents the entire Bitcoin database. Additionally, the block header contains a link to the previous block and its own proof of work.

• Check longest chain. A user can fetch the list of block headers and independently verify the proof of work represents the heaviest chain seen so far.

• Inclusion proof. Once the user is confident that their list of block headers represents the canonical chain, anyone can then provide the user with an inclusion proof (Merkle tree) for a specific entry in the database.

• Convinced. The user can cross-check the inclusion proof with the relevant block header and then be convinced about a specific an entry in the database.

Bitcoin SPV mode can be used as the basis for building a light client bridge that allows a smart contract on another blockchain to learn about content in the Bitcoin database.

An old project called BTCRelay implemented a light client bridge between Bitcoin (Database A) and Ethereum (Database B). It was a smart contract on Ethereum that could parse Bitcoin block headers, inclusion proofs, and follow the heaviest chain via the proof of work. In the end, it’s purpose was to verify whether a UTXO was indeed stored in the Bitcoin database and then allow another smart contract to act upon it.

Unfortunately, BTCRelay was a bit ahead of its time. While it was functionally complete, it failed to garner any significant traction.

There are a few lessons that we can learn form the project:

• Accumulated gas cost. Tracking block headers requires many on-chain transactions and the financial cost accumulates over time.

• Only works for forks of Bitcoin. BTCRelay was only compatible with blockchains that forked the Bitcoin codebase. A blockchain with a different consensus protocol required a dedicated implementation of its respective light client.

• Still trusting consensus. BTCRelay can only check the proof of work is correct, but not whether the block header is valid. If an adversarial miner crafted a malicious block header with valid proof of work, then the bridge could be broken. It was still essential to wait ~6 confirmations and lean on Bitcoin’s the honest majority assumption (>51% of miners are honest).

Research has mostly focused on the ability to reduce the accumulated gas cost by aggregating several block headers into a single update. For example, NIPOPOWS and Glimpse which focus on PoW-related light clients.

However — there is a shimmer of success — as many bridges on other blockchain networks follow the philosophy of building a light client bridge:

• IBC on Cosmos

• Rainbow bridge by Near

• P-Chain on Ava

Both IBC and the P-Chain have a dedicated layer for keeping track of agreements from the various consensus protocols. They all mostly follow the honest majority of signatures produced by the consensus protocol, but more often than that, there is not always a consequence if the consensus protocol decides to cheat the base layer by signing a conflicting message.

Still Trusting Participants — Can We Do Better?

Our article has covered:

• Trusted bridges,

• Accountable bridges,

• Light client bridges,

In all cases, our reliance is consistently placed on a set of intermediaries who must vouch for the authenticity of a message sent across the bridge, even if it simply vouching that a consensus protocol concluded on a single decision.

I suspect there is a fundamental requirement that a bridge will always require a set of intermediaries to help transport a message from a sending database to a receiving database.

If we accept this premise, then we could also assume it makes sense to track decisions made by the participants in a consensus protocol, since they are the source of truth for deciding the total ordering of updates that will be applied to the database.

This brings us to the final question:

• Can we build a bridge that can independently check the validity of a decision made by the consensus protocol?

It is a subtle difference.

The bridge should not only check that a consensus protocol agreed to the total ordering of updates to the database, but the update itself is valid relative to all other updates to the database.

If this can be achieved — then the receiving smart contract (Database B) can be convinced that an update was applied to the database and convinced that an entry in the database is actually valid.

It can then read the database, extract the relevant message, and then perform an action on it.

Can it be done? The answer is Yes.

Rise of the Validating Bridge

Anyone who has followed the posts on this substack is no stranger to concept of a validating bridge.

At its heart — it is about enabling a smart contract to go beyond checking whether a decision was made, but to independently verify whether content of the decision is correct.

The general idea is to go a few extra steps than a light client bridge:

• Fraud vs Validity proof. Extending capability of light clients to succinctly verify a large computation is correct,

• Data availability layer. Removal of a consensus protocol from Database B by re-using Database A for ordering data blobs,

• Open membership. Allow parties to self-appoint and contribute towards towards the process of enforcing the validity of all database updates.

We have covered the topic in-depth several times with Deconstructing rollups, Where Is the One Honest Party for a Rollup? and A Better Mental Model for Rollups, Plasma, and Validating Bridges.

Now — to avoid rehashing a breakdown on validating bridges — there is one final insight to discuss.

This entire article has only focused on:

• Ability to pass a message back and forth between the databases.

• Enabling the receiver to have confidence about the authenticity of a message.

We have not discussed how a bridge can hold or transfer assets across the databases.

This is because, fundamentally, all bridges are responsible for passing messages in a timely manner and providing confidence about a message’s authenticity to the receiver.

Assets and Liabilities

We can now deploy smart contracts on each database and the smart contracts can interact with each other by sending messages across the bridge.

The most popular application is to enable moving assets from Database A to Database B (and vice versa). The two smart contracts include:

• Vault. A smart contract on the sending database that holds assets in custody.

• Issuance. A smart contract on the receiving database that has the right to issue an IOU for the assets held in the vault.

At a high level, the two smart contracts can enable a deposit/withdrawal flow that is very familiar for most users who want to move assets to another system:

• Deposit process. A user can deposit coins into the vault on Database A and the vault can send a message via the bridge for the same quantity of assets to be issued at the user’s address on Database B.

• Withdrawal process. A user can withdraw the coins by requesting the issuer to burn the coins on Database B and to send a message via the bridge for the same quantity of coins to be released by the vault to the user’s address.

One of the benefits of this design is that anyone with read access to the vault on Database A and read access to the issuer on Database B can verify that the assets cover the liabilities. Put another way, anyone can verify that the issued coins are backed up by a fully collateralised vault.

What’s next?

Of course, if we want to enable moving assets across database, and for this to work at scale, it all comes down to the security of the bridge and how we can trust the integrity of messages sent across.

We have historically failed to build secure bridges as they all relied on humans to protect the messages sent across. Most of the large exchanges including BitFinex, Binance, Bitstamp, and worst of all MtGox, have lost user funds due to an incident with their bridges. In addition to bridges that move funds across blockchains like PolyNetwork, Ronin Bridge, and Harmony.

As a community, we have experimented with various bridge designs over the years, some have simply relied on trusted intermediaries while others have tried to move trust from intermediaries to the consensus protocol of the respective blockchains.

Validating bridges are simply one step further — to not only trust the decision made by the consensus protocol, but to check that it is actually a valid decision.

Now — what about the question:

rollup ==? bridge

I hope the answer is obvious after reading both articles. If not, then I may follow up with a “Battle of the Bridges’ as a part 3 for the series.

Regardless, in the end, all we are doing is passing messages, and bits, into the ether :)

rollup ==? bridge.

We should step back and look at the problem from first principles.

• What is a blockchain?

• How do we bridge assets from one database to another database?

Both topics will be covered over the course of two blog posts and then we can re-visit the above statement to evaluate whether it is true or not.

What Is a Blockchain?

At the heart of a blockchain is a single database and it records:

• Account balances,

• Smart contract code,

• Program state.

In nearly all systems, the blockchain defines the total ordering of all historical transactions.

At least, for a very long time, that is what we have been taught.

There is no reason it has to be a list of transactions. It may very well be a list of state diffs alongside a zero knowledge proof!

So — what is a blockchain?

Blockchain. An ordered list of data “blobs” that is used to compute a copy of the database according to a fixed set of rules.

Let us re-iterate the ONLY purpose for a blockchain:

• Allow a user to compute a copy of the database.

The only job is to enable replication of a single database.

Boring, right?

Reach Agreement About the Blockchain

One of the harder puzzles:

• How can the community reach worldwide agreement and recognise what is indeed the one true blockchain.

If we can all agree upon the same blockchain, then we can all compute a copy of the same database!

This lead’s to the idea of a consensus protocol and the goal is simple:

• Enable a group of parties, potentially pseudonymous and mutually distrustful of each other, to reach agreement on a single decision.

In the context of a blockchain, the consensus protocol enables one party to propose a block of data ‘blobs’, append it to the tip of a chain of blocks and for all other parties to agree that it is indeed the new tip.

This is why it is called a blockchain as we are all reaching agreement on a chain of blocks!

There are many technical challenges to consider when designing and implementing a consensus protocol:

• Can we enable open membership so anyone can participate?

• What is the communication complexity for parties to reach agreement?

• Is it possible to add financial incentives for people to step up and participate?

We will not focus on these challenge although it is a really fun and complex topic to explore. The only takeaway is that we simply need a consensus protocol to exist and that it can enable all parties to reach agreement on new blocks of data.

New Instantiation Of A Consensus Protocol

Over the years, certainly in the pursuit of layer-1 blockchains, the community has experimented with a vast configuration of consensus protocols:

• Nakamoto on Bitcoin

• Gasper on Ethereum (Gasper)

• Tendermint on Cosmos

• Snowman++ on Avalanche

In nearly all cases, the go-to-market plan is to launch a new consensus protocol that will agree on updates to the database. Furthermore, it is not just about deploying a consensus protocol, but all the surrounding infrastructure for it alongside the social aspect of enabling an honest majority of parties to participate in it.

It is a Hercule feat to accomplish.

This brings us to an interesting question:

• If I want to launch a blockchain, and ultimately a new database, do I really need to instantiate a new consensus protocol?

Remarkably, the answer is no!

Reuse an Existing Consensus Protocol

We need to consider a single abstract concept before diving further:

• Public bulletin board. Guarantees a consistent view of the data to all participants that want access to it.

It is a concept related to e-voting protocols. A public board allows all users to get access to the same protocol transcript. The users can take the transcript, execute it independently, and verify the protocol was run correctly. In the case of e-voting, it is to check that the voting protocol was run correctly and that all the votes were indeed counted as part of the tally.

How is this related to blockchains? Well, as long as:

• Anyone can get access to the data posted on the public bulletin board

Then, anyone can get access to the timestamped data and compute a copy of the single database. In practice, many layer-1 blockchains, certainly Bitcoin and Ethereum, make really good public bulletin boards. Additionally, they make it easy for anyone to write data blobs to the public bulletin board too!

Reusing an existing blockchain system is called the rollup.

Rollup: All data is rolled up by the operator and posted to the respective blockchain.

The hard work of deciding the total ordering of data blobs and guaranteeing that anyone can access data is left to the existing blockchain system. It is not a new idea. In fact, it has been around for around 10 years. The rollup approach has gained popularity as a way to bootstrap a new database.

There are many examples:

• Coloredcoins

• MasterCoin / Omni

• Ordinals

• Arbitrum

• Optimism

• StarkEx

• ZkSync

• Polygon Hermez

• Scroll

All the above projects, alongside others, are trying to bootstrap a new database on top of Bitcoin or Ethereum.

In fact, due to the popularity of the approach, there is a project that will someday launch called Celestia. It is focused on building a platform that is dedicated to enabling rollup-like databases.

In all cases, we can still view rollups as blockchains:

• A batch of data blobs is periodically published,

• It is appended to the total ordering of all relevant data blobs.

The blocks may look different, it may even be a stream of data blobs, but the general idea sticks with an append-only data structure that eventually has a total (or causal) ordering.

In the end, whether we deploy a new consensus protocol or re-use an existing one, the goal is the same: bootstrap a single database.

Rules for Parsing Data Blobs

Assuming that all parties can get access to the same data, the final challenge is for the parties to all agree upon the same set of rules (‘state transition function’) for parsing the data blobs and computing a copy of the database.

An example of parsing the data:

• Take a data blob,

• Parse it as a transaction,

• Check if the transaction is executable,

• Execute it on a specific virtual machine,

• Apply update to the database.

It leads to a unique problem for cryptocurrencies:

• We need worldwide consensus on the same set of rules for parsing the data.

There are two scenarios we need to evaluate when coordinating worldwide consensus for parsing the rules:

• Operational enforcement. The rules, agreed by all parties, is enforced 99.9% of the time by the software run by the parties.

• Governance of rules. There is a set process for all parties to propose and agree to a new set rules.

First and foremost, nearly all discussions link the security of a blockchain network to the day-to-day operational enforcement of the rules. It is an important conversation as it focuses on how the software, and all parties, are continuously enforcing the same set of rules to protect the database.

However — the ultimate backstop for protecting a blockchain network, especially when the operational enforcement breaks down — is the process for updating the rules. There must be a process to achieve social consensus from all participants on how to change the rules and when the new rules will be enforced.

Let’s explore the concepts of enforcement and governance in more detail.

Operational Enforcement

The day-to-day operational enforcement is what makes a blockchain system for computing the database so exciting!

We simply need to agree on:

• Where to find the total ordering of data blobs

• A rule set for parsing the data blobs

And that is it. All participants have an opportunity to get the data blobs, enforce the rules, and only respect the database that follows the rules.

It doesn’t matter whether a participant is large, small, a proposer or an at-home node, everyone should have confidence about what the database’s content.

Going further, as long as all market participants enforce the same rules, and they can compute a copy of the same database, then we can allow the market to dictate what should be considered the one true blockchain.

Governance of Rules

Nearly all blockchain systems require a bootstrapping phase:

• Bitcoin core by Satoshi Nakamoto

• Yellow paper by Gavin Wood.

More often than not, a project is bootstrapped by a small group of developers who decide the rules, launches the blockchain, and then gives the software (alongside the rules) to a wider community.

The next step is the process for changing the rules.

There are good reasons why the rules should be changed over time such as to enable a software upgrade for a new feature or to fix known bugs. Any rule change requires agreement across a wide variety of participants, or put another way, social consensus.

There are two approaches for achieving consensus to change the rules:

• Rough consensus. An opaque and not well-defined process.

• On-chain governance. An explicit voting process by token holders.

The former, rough consensus, is at the heart of blockchain networks like Bitcoin and Ethereum. It involves human-oriented processes to reach agreement with various participants, then developers implement the upgrade and a flag day is organised for when the upgrade can go live.

The latter, on-chain governance, was first pioneered by Tezos to enable participants to explicitly vote on whether an upgrade should be deployed and then for provide a timeline for the software to be updated upon a successful vote. As we will see soon, the on-chain governance approach has become popular with DAOs as a way to govern the deployment of a single software instance.

In both cases, there is still a requirement to reach agreement on the proposed upgrade and there is no guarantee it will go without a hitch:

• No blockchain split: An upgrade is executed without a hitch and worldwide consensus (including the market) accepts only a single database with the new rules.

• Blockchain split: If the the upgrade is contentious and it still goes ahead, then it can lead to a permanent fork as both communicates apply different rules and compute different databases with their own market caps.

Put another way, the governance process provides an indication on whether the community may accept the proposed upgrade. We can only be certain after the flag day and execution of the upgrade. It is very well possible that community members will dissent, ignore the new rule, and allow two competing databases to emerge. Just like BTC/BCH and ETH/ETC.

As a final note, there are two ways to implement a new rule change:

• Hard fork. A detectable change to the rules that non-upgraded nodes will reject.

• Soft fork. A non-detectable change to the rules that non-upgraded nodes will ignore.

The idea of hard or soft forks focuses on whether non-upgraded software can detect the rule change and how it will respond to it. It is very easy to get into a heated debate around which approach should be used as it ultimately has an impact on the network’s censorship-resistance, ability to fend against hostile take overs and whether users can explicitly opt-in to the rule change.

A World of Databases?

Over the past 14 years, the largest experiments by the community has always focused on how to build a “better” database.

There has been a clear evolution:

• Custodial database. Replicate the web2 experience, but trust the operator to protect the integrity and liveness of the database.

• Public database. Allow anyone to read the database, but ultimately trust an operator to update it.

• Open database. Allow anyone to read, write, and protect the database.

To provide some examples:

• Centralised exchanges. Nearly all exchanges have implemented a web2-style database and it is not possible for anyone to compute a copy of the database.

• Proof of authority. Some blockchain systems rely on an appointed, or multiple appointed authorities, to publish a new block to update the database. Anyone can download the blocks, parse the data blobs, and compute a copy of the database. They just don’t have the authority to propose a new block.

• Nakamoto consensus. Anyone, who is willing to use the financial resources to do so, can participate in the process of updating the database by publishing (and voting on) new blocks. Again, anyone can download the blocks, parse the data blobs, and compute a copy of the database.

Now — we use the word “better” as the answer — because what makes a good database is very subjective and it depends what metric the community is trying to optimise for:

• Maximise participants who can participate in the consensus protocol?

• Maximise participants who can download a copy of the database?

• Restrict who can write to the database without approval of a trusted operator?

• Minimise the cost of transacting on the system? Perhaps while trying to keep the data public for anyone to download?

• What is the easiest for grandma to transact on?

We can objectively define metrics and evaluate how well a blockchain system achieves its stated goals. Communities will argue forever on the metrics that matter and how they achieve it better than their competitors. However, what ultimately matters is what the marketplace of users decides to transact on and why they made that decision.

There is only one problem — how do we move assets from one database to another database? For example, a typical user flow may involve:

• On-ramp. Buying coins on Coinbase,

• Transfer. Moving coins from Coinbase to Ethereum,

• Action. Experiment with DeFi applications,

• Transfer. Move coins from Ethereum to Arbitrum,

• Action. Experiment with DeFi applications,

• Transfer. Move coins from Arbitrum to Binance,

• Off-chain. Withdraw to fiat.

All the named systems are databases in their own right with various degrees of security and audibility. But, to enable the transfer of assets, we need to talk about bridges :)

That’ll be the focus of our next article!

I am joining the Arbitrum Foundation and will be more hands-on with the rollup effort for scaling Ethereum.

This may seem strange to people who view me as an independent rollup bystander.

I have, for the longest time, resisted the urge to join any rollup project and more generally any off-chain scalability project. The reason why I have stayed independent for so long is simple. It put me in a unique position to praise and provide constructive feedback to any project.

It has been a really long time too. I have spent most of my adult life happily immersed in the field of crypto and specifically off-chain scalability. About 10 years now.

Given the type of skills I possess. I convinced myself that I was best suited to bring technical people together and help get them up to speed on why the techniques for off-chain protocols was an important solution for blockchain scalability.

To highlight some of that work:

• Early technical explainers for the lightning network [1],

• Understanding state channels [2,3,4],

• Attempting to systemise the fast-moving field layer-2 protocols [5,6],

• Educational efforts focused on layer-2 [7,8,9] (including this substack!).

At heart, I am both an engineer and a researcher, who likes to explain how technology works. So I have simply done what I do best — conceptualise, systemise and teach.

The field of off-chain scalability is around ~8 years old now. It has exploded beyond my own comprehension and at a lightning fast pace. If I had to guess, I’d imagine there are >1,000 developers working on fundamental building blocks for off-chain protocols and even during this bear market the rate of growth is truly exponential.

It does not feel like 8 years has passed. But, it is really no longer 2015, or 2019, or even 2022. The community is so large and diverse now. A lot of the work I did in the early days, alongside a host of wonderful contributors, has and will continue to fade into the ether. I am happy that it will.

With that in mind, I came to the conclusion that my time as an independent in the context of rollups was up. It is time for me to join a project and help push the needle forward for rollups towards mass adoption by every financial institution on the planet.

I am a long-term fan of many rollup projects. From ZkSync’s pragmatic focus on product, StarkNet’s very opinionated virtual machine, Optimism’s spread of culture and public goods, and Scroll’s indisputable alignment with Ethereum’s core.

All the teams are great and I am still very bullish on their individual approaches.

So the question is — why Arbitrum?

I’ll be at the Arbitrum Foundation. It will allow me to continue my work on Ethereum, education and public goods. I don’t expect my day-to-day to change greatly and hope to continue publishing factual content about rollups.

But there is a longer story, so strap in.

How I Came To Learn About Arbitrum

The first time I heard about Arbitrum was at CESC’17 where I met Steven Goldfeder.

I was already aware of his research. He had worked on escrow protocols and threshold ECDSA alongside authoring the cryptocurrency book. I caught the opportunity to say hey and he mentioned that he was working on a blockchain scalability solution using refereed delegation.

I didn’t know anything about that technique and like all good academics he kept it a closely guarded secret. The research was due to be published imminently. A few months later, I found the project was published at USENIX and it was called Arbitrum.

I read the paper and I thought I had an idea what it was about.

Around this time I was organising a workshop (in co-operation with Binary District) to bring together off-chain researchers and projects. I invited Harry Kalodner to present Arbitrum at the workshop. You can see us in the picture above and the video is still available. He talks about AnyTrust too!

It was a great talk and again I thought I had an idea what it is was about.

This brings us to ~2019.

I was having a chat with my friend Malte Moser, (Harry’s colleague at Princeton). He told me that Harry was supposed to be working on Block Sci, but disappeared into the ether to work on Arbitrum full-time as a startup. A few months later, the announcement of Offchain’s labs funding round appeared.

I was excited to see them take the paper from theory to practice and I thought the story would end here. After all, I didn’t have a close relationship with the folks at Princeton.

Understanding The Problem Solved By Arbitrum

A few months later, I was working with Chris “The Radish” Buckland on some state channel research. To keep the story short, we accidentally replicated some of the work at the heart of Arbitrum. This led to a shared telegram group where I had an opportunity ask a bunch of questions about what Offchain Lab’s was building.

Something about their answers didn’t really feel right. They kept saying they were building a state channel, but it didn’t look like a state channel at all.

I don’t remember the exact moment, maybe near the end of ~2019, but I eventually realised they were not working on state channels at all.

They solved a fundamental problem that was plaguing the Plasma community.

What do I mean by this? Let’s highlight the two fundamental problems for off-chain scalability:

• Database. A technology that can create an off-chain database and allow it to inherit security from the main chain.

• Synchrony. A technology that allows updates to be synchronised across two or more off-chain databases.

For the longest time, the state channel community tried to solve the problem of creating an off-chain database (including myself), but hindsight tells us that channels are best suited as a synchrony solution alongside a host of different synchrony techniques.

The Plasma (and commitchain) community were working on the right technology to solve the off-chain database problem. They were plagued with a complicated design space and lacked the right abstractions to tackle the problem. That is why nearly all Plasma solutions (above) focused on payments and limited scripting mechanisms.

Remarkably, the Arbitrum paper solved one of the big problems in Plasma, enabling generalised smart contracts that inherit the main chain’s security via fraud proofs. The “AnyTrust” idea was an off-chain data availability committee and they eventually pivoted to enable rollup mode.

I’m sure Offchain Labs eventually came to the same conclusions. It is funny to think in hindsight they did not even have the idea of a centralized Sequencer yet! They were building for a set of decentralized and uncoordinated aggregators.

It was the best of times.

The biggest bottleneck to understanding the leap for Plasma (like the pun?) was a language barrier between the Arbitrum team and the wider Ethereum community. A lot of people didn’t understand what they were building including myself. In hindsight, this was a very useful competitive advantage for Arbitrum as they gained a significant head-start on the implementation.

The telegram chat eventually died as it became ‘crunch time’ for them to launch. But I finally understood what they were building!

Watching Arbitrum Evolve From a Paper to a Dominant Rollup

I was really excited to try out the technology as soon as I could. I was one of the first folks to try out Arbi Swap. It was a demo of running Uniswap on top of Arbitrum. The video is fun to watch and you’ll get to see the old school Arbitrum Bridge.

It was truly a “wow” moment. The gas cost went from ~120k gas on Ethereum to ~4k on Arbitrum. I was finally convinced that I was not senile or eccentric as this was empirical evidence that the off-chain scalability approach could really work.

At this point — the rest is history really.

They launched Arbitrum with interactive fraud proofs. The Ethereum community finally understood what they built and jumped onto the Arbitrum spaceship. The project is now on the path to decentralising and I hope to help them along the way with that mission.

In fact, there is a good chance that you have used Arbitrum and I’d love to hear your stories about using it!

Please drop a comment with your story or even just like this post as a way to let me know.

So Why Did I Join?

They offered me a smol brain NFT — jk.

I decided to join as I have been impressed by how the project has evolved over the years.

I have always found it remarkable how the three founders, Steven/Ed/Harry, rarely attend the crypto conference circuit. They are simply working day-in-day-out, in a very consistent manner, on Arbitrum alongside a team they have built up who share the same ethos.

Additionally, I have always found it easy to understand how Arbitrum works and their thought process on several topics:

• Code is easy to read,

• Research posts are informative,

• Team is always at hand to answer any questions.

Finally — and perhaps most importantly — I have sent them several ideas in the past and some of those ideas were picked up. It has been really fun to watch my recommendations play out in practice. Like anyone, I appreciate being listened too, especially since I am always right (joke). At the very least, it does help demonstrate that my thought process is in line with the Arbitrum team.

Closing off

I am joining the Arbitrum Foundation and not Offchain Labs.

I will work closely with the Offchain Labs team and I expect it will indeed be a complementary relationship.

But, at the end of the day, my duty is to Arbitrum and wider Ethereum eco-system. I hope to be held accountable and judged on that single goal since our job is to scale Ethereum.

A very interesting talk by Kelvin Fichter argues that zk rollups do not exist and how rollups actually work. Let’s take a fun snippet from it:

Kelvin (paraphrasing): You are happy, on Ethereum, with some money. Then, this scary bridge smart contract, its also on Ethereum, it gets you across to Optimism land. You send your money to the bridge, num num num, it spits the money out onto Optimism.

We know the Sequencer can be malicious, so we need to turn the bridge contract into a security guard and some ability to protect the rollup. We add some proofs, like fault proofs which is like giving them an AK-47, but then everyone knows that zk rollups are better than optimistic rollups because the marketing team said so. It is like giving it another AK-47, but its gold plated.

Now we are doubly protecting the rollup. No one is getting past the bridge contract with two AK-47s and we know this is how the bridge contract protects the rollup right?

Wrong. Every single thing here is wrong. If you think this is basically how rollups work, you are wrong.

It is a fun talk to watch, but let’s summarise his arguments:

• The development community is too focused on defining a rollup through the lens of a validating bridge.

• If other rollup projects are not too careful, they’ll ultimately constrain and hamper what their rollup can do. Just like his experience with building Optimism’s OVM V1.0 that was later abandoned (~October 2021).

• Rollups should be built first with the rules enforced by a community and only afterwards we should focus on building a validating bridge for it. 

It has motivated me to pursue a short rollup deconstruction and help explore the thoughts in his presentation. Some of the discussion includes:

• What are the basic components of a rollup?

• How can we think of ‘write permissions” for transacting on a rollup?

• What are the fundamental trust assumptions when transacting on a rollup?

• How can a rollup send and receive messages to other systems?

• What does it mean to bridge assets onto a rollup?

Hopefully, we will land at the same arguments made by Kelvin and work out what comes first — the rollup or the validating bridge?

Computing the Database

The only purpose of a rollup, and a blockchain in general, is to allow all parties to compute the same consistent view of a database. If we can all view, and write to, the same database, then it provides a platform for us to transact with each other and interact with programmable smart contracts without a trusted intermediary.

There are two basic ingredients for building an open database: 

• Rule set (state transition function): All parties must agree to the same rules on how to parse updates to the database (“data blobs”). 

• Data availability layer: A public bulletin board that takes the data blobs, decides their ordering, and publishes the total ordering of data blobs for anyone to download/read. 

Together, it allows anyone to gain access to the same data blobs, parse the blobs according to the same rules, and compute the same database. 

The next step is to decide who can publish a data blob. 

We need to define a user group. It can be a fixed set of parties, parties with certain attributes, or it can be fully open (777). The write permissions must be implemented at both the data availability layer and in the rule set to allow a user to publish a data blob for all other parties to pick up. 

In practice, the DA-layer implements an open policy and regulates who can transact using a transaction fee market. As long as the user is willing to pay a transaction fee, then they can post a data blob. Additionally, the DA-layer can record the details like an Ethereum address and block number, that can be used by the rule set to decide priority for processing the data blobs.

For example, if the Sequencer publishes a data blob, then the rule set can verify it was sent by them and prioritise their data blobs before all other data blobs.

Fundamental Security Assumptions

The separation of data availability and applying the rule set brings us to the fundamental security assumptions for a rollup.

Who is running the data availability layer? A rollup assumes that a data availability layer is a separate entity, it is readily available for use and trustworthy as a platform to post data blobs. 

Operators for the data availability layer have the power to view, re-order or drop published blobs that may be used by the rollup. The operators participate in a consensus protocol and in nearly all blockchain systems the consensus protocol assumes that a majority of the participants will honestly follow the protocol (“honest majority assumption”). For example, the operators can be miners in PoW Bitcoin, stakers in PoS Ethereum, or a new blockchain system set up to provide this exact service (like Celestia). 

Assuming the trust assumption is not violated, then the rollup can safely assume the total ordering of data blobs will be finalised and remain final.

How do we all agree on the rule set? A rule set is a specification on how the data blobs should be parsed. It should be agreed by all users and implemented in a software client. If we assume users agree upon a single rule set, then they can ascribe value to the rule set and ultimately to a single database. The value may be financial in nature or simply for support another use-case (like an oracle).

If we want to change the rules, then a governance mechanism is required to enable a group of stakeholders to reach agreement on it. There are many governance mechanisms that a rollup can implement. For example, they can rely on fuzzy consensus like in Bitcoin, transparent SnapShot voting, or simply encode the rules in the DA-layer for eternity.

If a sub-community emerges that wants to modify the rule set, and not all parties agree, then the sub-community can peacefully change the rules and create a new fork of the blockchain. We have already witnessed forks like BTC/BCH and ETH/ETC. In both cases, the market continues to ascribe value to the different rule sets and communities have formed around it.

To summarise. The security of a rollup relies on two sets of parties: 

• We need to trust the operators who run the data availability layer,

• We need to trust that a community will agree on the same rule set and ascribe real-world value to it. 

We typically assume the data availability layer “comes for free in the security analysis” and as a result projects mostly focus on how the rule set can be defined/enforced. 

Message Passing to Other Systems

Unfortunately, so far, the rollup lives in a silo. This brings us to the topic of bridge engineering and how to enable communication with other systems. We need two components, an inbox for the rollup, and an outbox for the rollup, to allow a bridge to connect the rollup to other systems. We dive into each component in more detail below. 

The inbox accepts data blobs from users. It is a single location where users can find the data blobs. A useful feature for the inbox is to record the sender’s identity alongside a time stamp. It can be implemented as a smart contract with an “accept blob” function that takes a data blob, the sender’s identity, and the current block number.

For example, if Uniswap wants to send a message to a rollup, then it can call the function on the inbox smart contract that accepts data blobs. All users can find the data blob alongside the time stamp, parse it according to the rule set, and verify that Uniswap sent a message for use in the rollup.

The outbox takes messages from the rollup and passes it to other systems. It is implemented as a smart contract and it must have a mechanism to gain confidence about the rollup’s database state before passing on a message. 

So, the focus for the outbox is not necessarily how it sends the message, but how it gains confidence the message is valid before sending it. There are two approaches: 

• Trusted authorities. One, or multiple authorities, attest to the database state.

• Light client. A smart contract, with an external/human assistant, has the capability to independently verify the database state.

There is a subtle detail we need to discuss about light clients before moving on. The purpose of a light client is to read the content of a database. More often than not, a light client protocol will verify what decision was made by a consensus protocol, but it will not check that the decision was correct. For example, a light client to verify proof of proof of work (NiPoPow) only reduces the computation required to check the total weight for a PoW blockchain fork, but it doesn’t check that the decision is right. As a result, this class of light clients is still ultimately relying upon one or multiple authorities to attest to the decision. 

In the context of rollups, and our article, a light client should verify that the decision by the external authority is correct. This can only be achieved by implementing a mechanism that empowers the bridge to independently check the computational integrity that underpins the authority’s decision. We know how to implement such a mechanism with a fault proof or validity proof system. 

In most cases, a light client outbox requires access to all data blobs and we normally assume it shares the same data availability layer as the inbox. There is interesting work, like Celestia’s Light Clients, focusing on how to transport data blobs from one DA-layer to another DA-layer, enabling outboxes for a rollup to be implemented on different blockchains networks. 

Separating the inbox and outbox. We often assume the inbox and the outbox are intertwined inside the bridge. This is not the case. The inbox can be a separate entity and the bridge should access it, like any other smart contract, when sending data blobs into the rollup.

Bridge engineering is about the outbox and how it gains confidence about the rollup’s database. Again, they may rely on attestations from authorities or a light client to check its validity. We call the latter a validating bridge. Other smart contracts and projects can evaluate how the bridge is implemented and opt-in to trust messages that originate from it. 

Representing and Protecting Assets

Now, just like any cryptocurrency system, it is essential to represent assets on the rollup database and enable the transfer of ownership. There are two approaches for bringing assets into the rollup, and generally speaking, any blockchain system.

Native issuance is when an asset is minted/issued/created on the rollup database. For example an ERC20 contract is deployed on the rollup and it airdrops tokens to a set of users. It is the simplest case as we only need to consider the security of the rollup and the set of parties with influence to change the rule set for parsing the data blobs. We should highlight that there is already precedent for a community to change the rule set and modify the balances of natively issued assets. For example, Ethereum reverted The DAO hack in 2016 and the Steem community rebranded the project as Hive with a modified ruleset that removed Justin Sun’s access to his hive tokens. 

Bridged assets require the asset to be locked with a bridge operator on a different system and for the operator to issue the same quantity of assets on the rollup. The assets issued by the operator represent a potential claim to the underlying locked collateral. If a user wants to withdraw the assets back to the origin blockchain, then the user can “burn the coins” on the rollup as a signal for the bridge operator to then return the underlying collateral back to the user on the origin system. 

If the assets are bridged, then it is no longer up to the community of the rollup to decide which rule set will protect the assets. The bridge operator, who has custody of the funds and charged with protecting it, has the sole discretion to pick which rules to follow. If the community changes the rules, like in the case of Steem, then the bridge operator can simply ignore the modified rules and refuse to honour withdrawals. 

We need to consider who is the bridge operator. If the bridge relies on trusted authorities to attest to the database state, then the authorities pick the rules. For example, stablecoin issuers like USDT will confirm which rule set they plan to follow if there is a proposed upgrade on Ethereum. On the other hand, if the bridge relies on a light client to validate the rules, then the rules are enshrined in the smart contract and it is up to the explicit upgrade process to change the smart contract code. 

What Can We Learn From This? 

Going back to Kelvin’s argument — should we focus more on the rollup over the validating bridge?

Before we dive in, the debate has little to do with the DA-layer. Thanks to the idea of a modular roadmap, the DA-layer is a separate beast and we can simply assume it is trustworthy alongside any smart contracts deployed on top of it.

The debate comes down to who defines the rule set for parsing the data blobs and the power struggle on how the rule set is ascribed value.

If all assets are natively minted on the rollup and there are no bridges, then the power struggle focuses on how the community collectively agrees to the rule set. It is not dissimilar to how a blockchain system like BTC/ETH is considered valuable. The best examples for a “silo” rollup includes MasterCoin or ColoredCoins that lived on Bitcoin a very long time ago.

If there are bridges, then the power struggle really comes down to how much influence the bridge operator can wield relative to the wider community for deciding which rule set is valuable. After all, if the community decides to change the rules, then the bridge operator can simply ignore it and only permit withdrawals according to the old rules. If the bridge holds 90% of all issued assets, then its sway may dominate over all other opinions.

Note, the bridge operator does not necessarily need to be human, it may very well be a validating bridge smart contract.

This brings us to the debate about whether the definition for a rollup should be viewed through the lens of a validating bridge or if it is ultimately up to the community.

We don’t think it is a one, or the other, but both. The reason we believe this to be true is thanks to Kelvin’s insight about how to separate the inbox and the outbox. The inbox has little to do with enforcing the rules and it should simply be a central repository for collecting data blobs.

Since a bridge, and an outbox, is simply reading the database and dropping messages into a globally shared inbox — then this implies that there can be more than one bridge. In fact, we can easily imagine a world of many bridges with various trust assumptions. Even more, there can be multiple validating bridges, who are protecting separate baskets of assets according to their enshrined rules for the rollup.

Now — not everything is rosey in a world of multiple validating bridges — as there are practical issues that arise with the fragmentation of assets. Every bridge is responsible for protecting the locked up collateral and issuing its own liabilities on the rollup. If there are competing bridges, especially validating bridges, then we may end up with several variants of the same asset like aETH, bETH, cETH, etc.

So far, from our perspective, the are several reasons why users have flocked to rely on a single validating bridge and typically assumes it is a single smart contract that defines the rollup:

• Avoid fragmentation of assets on the rollup,

• Inherit validation of rule set from parent blockchain (1 honest party assumption),

• Network effects as all other projects trust the same outbox.

Most importantly, and not to be overlooked, the primary reason why everyone looks at a rollup through the lens of a bridge is because only a single implementation is available for every rollup and there is no competition. The lack of competitive validating bridges is because building one is a mammoth and non-trivial task.

This brings us to another key part of Kelvin’s talk.

• How should we approach building a validating bridge? And are there gotchas to consider?

According to him, we can hinder a rollup’s full potential if we focus on building the rollup through the lens of a validating bridge, as we are always trying to fit the rollup within the constraints of the bridge and this can lead to a lack of good abstractions for dealing with hard problems. It is the exact issue that led to the deprecation of OVM v1 hit around October 2021 and zkEVMs may run into the same issues shortly.

On the other hand, if we only focus on building a rollup and not consider issues that may arise with a validating bridge, then it is very well possible to slip up with features that are very difficult to implement as a light client smart contract. A good example is the old and very janky PoW algorithm for Ethereum. It was not light client friendly and led to academic papers attempting to make it work.

So, perhaps like everything, both arguments are true to some extent. We should focus on building a rollup, but keep in mind to use primitives that will be light client friendly. It may also help to test it against different validating bridge implementations. This leads to the multi prover architecture by Vitalik and the multi verifier architecture described by Toghul. I suspect the zkEVMs may attempt this type of architecture, but ultimately fail due to nitty gritty details that were chosen to make it work with their specific light client implementation.

To conclude. The key takeaway is the disentanglement of the inbox and the outbox. An outbox is a read-only bridge that can pass on messages for the rollup. With a little bit of extra implementation, it can hold assets and drop messages into the inbox. I’m excited to see how this new mental model will impact the design of rollups and the implementation of validating bridges.

Hopefully this has helped you appreciate Kelvin’s talk a bit more alongside some of the insights I gleaned from it. It was very informative indeed frens!

As we have discussed before, Ethereum and adjacent communities are pursuing a modular (and layered) approach for blockchain scalability.

• Data Availability. A public bulletin board that guarantees all online parties can get access to recently published ordered data.

• Settlement Layer. A consensus protocol that collectively agrees on the balance of all accounts according to an ordered list of transactions.

• Execution Layer. Performs all the hard work of executing complex transactions and smart contract code.

In Ethereum, and even Bitcoin, the data availability layer and the settlement layer are combined. The combination is important for practical deployments of blockchain networks.

It allows the network to rate-limit the publication of data by entangling it with a fee market. If a user is willing to pay a competitive network fee and the data fits within agreed constraints, then the user can post whatever data they want.

For example:

• Bitcoin blobs. Ordinal NFTs are enabled due to the extra witness data allowance and fee discount associated with a SegWit witness alongside a further relaxation with Taproot.

• Ethereum blobs. EIP-2028 reduced the gas cost of CALLDATA to enable the initial versions of rollups. There is on-going work with EIP-4844 to create a separate fee market for CALLDATA and allow data blobs to be posted at a further discounted rate.

It is interesting, perhaps even surprising in the case of Bitcoin as an unintended pursuit, that both networks have worked towards reducing the cost of posting data blobs.

However, we need to keep in mind that while both Bitcoin and Ethereum can serve as a data availability layer (to some extent), they do not share the same capabilities when it comes to the settlement layer.

There is a small difference which has huge ramifications for the security of a rollup and arguably how practical it is to deploy as a technology.

How Do We Think About Rollup Security?

As we have explored in the past, there are two key components to consider when evaluating the security of a rollup:

• Validating bridge. A trusted third party who will enforce a fixed ruleset for evaluating whether a database update for the off-chain system is valid.

• One honest assistant. An honest party who can step up, assist the validating bridge, and save the day on behalf of all participants.

In regards to rollup security, nearly all discussions focus on how one honest party can assist the validating bridge. It is a new set of challenges that is unique to the land of rollups and ranges from participating in a fraud proof game, posting data blobs on-chain, or how to coordinate provers to submit validity proofs. The challenges can be summarised as data availability, state transition integrity, and censorship-resistance.

We normally make an assumption that the validating bridge works as expected because it is a trusted third party. It can access all assets in the underlying blockchain, it can be implemented as a smart contract, and we only need to pay a fee to Ethereum for the privilege of leveraging it to protect the off-chain system.

Of course, there can be challenges with the design and implementation of the bridge, but we can trust that a validating bridge will honestly follow the protocol.

What Security Will A Validating Bridge Inherit?

Now — if we dive into the assumption of the validating bridge and the underlying blockchain — it is crucial to truly understand the security properties we can inherit.

Sreeram Kannan has a nice thread on Twitter which tries to summarise the assumptions:

• Re-org resistance. The underlying blockchain decides and protects finality in regards to the total ordering of all transactions.

• Censorship resistance. Anyone, regardless of who they are, can issue a transaction for execution as long as they are willing to pay the appropriate network fee for it.

• Data availability. A public bulletin board that guarantees all online parties can get access to recently published ordered data. (same as above)

• Validity. The underlying blockchain can independently verify, without replaying every transaction, that all actions performed on the rollup (execution layer) are valid.

To achieve the above properties, we must rely on the underlying blockchain’s consensus protocol and wider network effects.

In Bitcoin and Ethereum, we assume there is an honest majority of block producers (stakers/miners) who are actively participating and a diverse network of verifiers (“running nodes”) who check the validity of all published blocks in real-time.

The honest majority assumption for block producers can be summarised as:

• Highest fee first. A block producer will always pick transactions that pay them the most money regardless of its content.

• Respect fork-choice rule. A block producer will always extend the blockchain’s tip according to the network’s fork-choice rule.

Put together, it allows anyone to transact as long as they are willing to pay a competitive fee and ensures that all block producers will eventually converge on a single blockchain fork.

Interestingly, as long as the blockchain is progressing, we do not need to trust the block producers to post valid blocks. All blocks can be checked and immediately rejected by verifiers running the node software.

As long as a sufficient number and diverse economically important agents run verifiers, then value will be ascribed to the one true blockchain that adheres to the rules.

Can Rollups Inherit Security From Bitcoin?

This brings us to the question:

• Do the security properties, as outlined by Sreeram Kannan, actually apply in practice for Bitcoin and Ethereum?

In Bitcoin and Ethereum, we have previously covered how well the networks achieve these security goals.

To summarise it, both networks provide re-org resistance, censorship resistance and data availability, to similar degrees. They provide a platform that allows anyone to post data as long as they are willing to pay a fee to do so.

ZombieCoin: As an interesting note, one of my first projects back in 2014, called ZombieCoin, used Bitcoin to coordinate a botnet’s command and control centre because of the above properties.

The subtle difference is validity and it differs greatly between Bitcoin and Ethereum.

As mentioned previously, we can deploy a validating bridge smart contract on Ethereum and inherit the validity property. On the other hand, in Bitcoin, the scripting language and UTXO model lacks the expressiveness to build a validating bridge. The platform cannot be used to check the validity of the data blobs or the off-chain database.

Put another way — outside of charging fees for posting data — we should treat Bitcoin as data availability layer that lacks any form of computation and we cannot build the kinds of rollups we have on Ethereum without drastic changes to Bitcoin.

Thankfully — this is not the end of the story.

The rise of Taproot Wizards, Eric Wall’s Talk and now the release of RollKit has shown that a different type of rollup can be built on Bitcoin.

A Sovereign Rollup?

This brings us to the question — what the hell is a Sovereign Rollup — and why can it be deployed on Bitcoin? Alongside other networks like Celestia.

The “Rollup” part is inspired by the original rollup repo by Barry Whitehat that solved the data availability problem of Plasma. It essentially “rolls up the transactions” and posts a data blob to an underlying blockchain. As long as the data is posted, which anyone can do, then it can be used.

The “Sovereign” part relates to how the validity of the data blobs is checked and used to compute the off-chain database. It relies on an external community to run a software client (a full node) that can fetch the data blobs, parse the data blobs according to a fixed set of rules, and compute the off-chain database.

Going further, the security of the Sovereign rollup relies upon a majority, or even a supermajority, of economically important agents to agree upon the same set of consensus rules for parsing the data. If they reach collective agreement, then they can all compute the same off-chain database, ascribe real economic value to it, and trust the assets will be protected.

This security assumption can be a bit fuzzy to explain sometimes. What does it mean for a majority or super majority to ascribe value? It is very similar to the governance rules for blockchain networks like Bitcoin and Ethereum. For example, why should BTC have more value than BCH? or ETH have more value than ETC?

It ultimately comes down to the market of buyers and how they ascribe value to a given ruleset.

Before continuing — the key takeaway — security does not depend on who or how the data is posted to the underlying blockchain, but how the economic agents parse the published data and who gets to decide the rules for parsing the data.

How Does A Sovereign Rollup Compare To An Ethereum Rollup?

An interesting way to compare the two systems is to consider the impact of replacing a validating bridge smart contract with an external software client run by economically important agents and unbeknownst to the underlying blockchain.

With that in mind, we have put together a comparison table to quickly highlight how that single difference — validating bridge vs external software client — impacts certain properties of a rollup.

Let’s cover each point one by one.

Security assumption.

• A Sovereign rollup depends on which ruleset (and off-chain database) is preferred by economically important agents. The underlying blockchain has no influence on the validity ruleset. It can only guarantee that data is publicly available and its total ordering.

• A validating bridge inherits all security properties from the underlying protocol and the new security challenge is the 1 honest assistant.

Upgradability.

• A Sovereign rollup relies on the community to collectively agree upon a fixed ruleset for parsing the data. An upgrade relies on a process for the economically important agents to agree to the new rules. It may reflect ‘rough consensus’ or an external governance protocol on which software client to adopt.

• A validating bridge will enforce all rules and changing the rules can only be performed by an upgrade procedure implemented in the smart contract code. The rules for upgrading the system is publicly verifiable to all.

Bridge assets.

• A Sovereign rollup cannot make use of the underlying rollup except for data availability. Native assets like BTC cannot be transferred while inheriting the underlying blockchain’s security. It must rely on an external bridge protocol with its own trust assumptions.

• A validating bridge has the sole responsibility protecting all assets it transfers from the underlying blockchain to the rollup.

Consensus fork. This is an interesting discussion on whether there is a conflict in the community in regards to the ruleset and if the off-chain system can split into two. This has already happened with BTC/BCH and ETH/ECH as both communities could go their separate ways and allow the market to decide which one should is valuable.

There are three type of assets to consider:

• Native bridging. An asset is bridged from the underlying blockchain to the rollup.

• Minted on the rollup. An asset is issued on the rollup and natively belongs to it.

• Bridge operators. An external operator is supporting the effort of moving funds from another blockchain system to this rollup. It has its own trust assumptions for securing the assets.

To keep the comparison simple:

• In a Sovereign rollup, the root of trust for deciding the ruleset and what is the off-chain database is up to the community. If there is a consensus fork, then the assets minted on the rollup will be replicated across the different forks and it is up to the external bridge operators to pick one of the forks.

• In a validating bridge, a consensus fork is not possible. It is up to the smart contract to decide the rule set, the off-chain database, and to ultimately protect all assets that are natively bridged onto the rollup.

Censorship-resistance. It is the same on both rollups — there must be a forced inclusion mechanism implemented that allows the user to submit their transaction to the data availability layer and for it to be picked up by others.

Consensus protocol. A consensus protocol can be useful in a rollup to allow a set of Sequencers to agree upon the ordering of transactions before the data blob is posted to the data availability layer or to help coordinate the executors to attest to the new database state after executing the data blob.

However, a consensus protocol is optional for both type of rollups, and it can be argued whether we should even call it a “consensus” as opposed to an “appointment/ordering” protocol.

Let’s consider the base case with no consensus protocol. We can rely on the forced inclusion mechanism to allow a user to submit a data blob directly to the data availability layer and its position in the total ordering will be decided by the platform. Anyone can pick up the ordered data blobs, execute the blobs, and then compute the off-chain database.

So, if we want to add a consensus protocol to a rollup, the extra rules for parsing the data blobs can be encoded into the validating bridge or the external software client. For example, a round-robin protocol or a fair-ordering protocol can be implemented in the smart contract.

Gossip protocol. There is no requirement for agents to coordinate via a peer to peer network. All data can be posted to the data availability layer and all agents can read the published data. Whether there is a validating bridge or an external software client has no impact on how to send messages within the rollups.

Sovereign Rollup == Settlement Layer?

The mental modular for scalability is often thought of in distinct layers of execution → settlement → data availability. Each layer should have a direct dependency on the next one, but otherwise it is independent in nature.

By evaluating how to deploy a rollup on top of a data availability layer, like in the case of Bitcoin, it does highlight some problems with this mental model of layers.

If there is no fee market to rate-limit the publication of data blobs, then it can easily lead to spam that must be parsed and discarded by a Sovereign rollup. At the same time, the lack of expressiveness of the settlement layer can impact our ability to deploy validating bridges and rely on the settlement layer to protect all systems built on top of it.

In practice, at least to me, it appears we want to combine the layers of settlement and data availability, as this allows users to pay for the privilege of publishing data while enabling the deployment of validating bridges.

The subtle difference between Bitcoin and Ethereum — the ability for the platform to validate data blobs to an attested execution — has huge ramifications for how we can deploy rollups.

• Do you want to deploy a validating bridge and allow the underlying blockchain to enforce the ruleset for determining what the off-chain system looks like?

• Do you want to deploy an external software client and use the platform as a bulletin board for fetching ordered data blobs?

Put another way, the question is really about deciding who should be responsible for validating the data.

• Can we trust the honest majority from the underlying platform to validate whether the data blobs leads to the the attested execution?

• Should we introduce a new set of economic actors for checking whether the data blobs leads to the attested execution? Alongside re-using the honest majority of the underlying platform to guarantee the data blobs are available.

I am excited, thanks to the openness and permissionless nature of blockchains, that both rollup approaches can be evaluated empirically by the different startups. It’ll be up to the market to decide what works in the long term.

For me, and my own thesis on how these systems may evolve, I do believe we should try to minimise the introduction of different parties who are actively involved in protecting the integrity of a system. After all, a system is only as secure as its weakest link.

In the world of Sovereign rollups, we need to trust the honest majority of the underlying blockchain for ordering the data blobs and another set of parties to protect the integrity of how the data blobs should be parsed. A new set of actors is needed for every deployment and we need a way to scale this human process across hundreds/thousands of rollup deployments.

That looks a lot harder than an Ethereum rollup, or I should call, the Validating Rollup. A project can just deploy a validating bridge and solve the problem of finding one honest assistant to help the bridge. There is no need to introduce an extra set of decision makers to protect the off-chain system and thus it allows us to rely on software to scale and support the deployment of hundreds/thousands of rollups.

There is another interesting thought experiment that I would like to highlight in regards to Sovereign rollups. If we squint our eyes, they look very familiar to how we can build new settlement layers on top of a data availability layer.

If we consider the case of Bitcoin, the platform’s fee market can be used to prevent spam on the data availability layer while allowing a Sovereign rollup to be deployed on top of it. This rollup can allow users to mint assets, transfer assets, and deploy validating bridges to other off-chain systems. As such, it follows the path of Layer-3s, SHARP and the SuperChain.

Of course, BTC the native asset can’t be transferred to the Sovereign rollup in a trustless manner, but it does allow an eco-system to emerge on top of Bitcoin while allowing BTC to be used to pay for the network fee.

Regardless, I hope you have enjoyed this blog post. I’d like to finish on naming conventions. I have always disliked the term ‘Discrete rollup’ (sorry apolynya) to describe the type of rollup deployed on Ethereum. It should really be called a Validating Rollup as an underlying validating bridge is responsible for protecting all assets locked into the off-chain system.

See you next time, frens! And thanks again to Ser Chris Buckland for the quick sanity skim/check.

As we are all aware, we need more than one chain and certainly more than one rollup, to help scale Ethereum for mass adoption.

Before we dive in — why rollups on top of Ethereum?

Remember — the core innovation that underpins the field of cryptocurrency is trust engineering — our ability to define, measure and minimise trust when interacting with a counterparty.

All systems, no matter how well designed, always rely on an element of trust to protect both safety and liveness. In most cases, it assumes a threshold of parties will honestly follow the defined protocol and some thresholds include N of N parties, an honest majority, or K of N parties.

Interestingly — in the field of trust engineering — the cheeky approach is to introduce a trusted third party (TTP) who can work with one honest party to protect the system. In academic research, many of these papers are often disregarded because it feels like cheating.

In the context of rollups — we do have a trusted third party — the bridge contract running on Ethereum. This is why the approach is so exciting as Ethereum becomes a root of trust that protects all systems deployed on top of it alongside the assistance of the one honest party.

You can read this article for more along this line of thinking, but this is an answer to the why argument for rollups on top of Ethereum. Now we focus on the how and this brings us to a fundamental question for a multi-chain world:

• Will rollups be deployed as silos on Ethereum?

• Can we deploy a new off-chain system/chain on top of a rollup?

Let’s find out!

How the Bridge Locks a Database Entry

As a bit of background, there are two components to a rollup:

• Off-chain database. It records the liabilities for the rollup including account balances, program state, smart contract code, etc.

• On-chain bridge. It holds all the assets and it is responsible for upholding the safety & liveness of the off-chain database.

In a rollup, it is the bridge smart contract and no one else, who has the sole discretion to decide the accepted state for the off-chain database.

Now — the question is — what does this look like at a technical level?

The bridge, just like any smart contract, is locking a single entry/row in the underlying database for its own purpose. It will have a smart contract address, balance, code, and a state. All of it is recorded in a single database row.

So, when we create a new bridge, let’s say from:

• Ethereum → Arbitrum,

• Ethereum → Optimism,

• Ethereum → StarkNet.

The bridge smart contract locks a row in Ethereum’s database and it stores an anchor for the new off-chain database. In practice, this is a cryptographic commitment that represents the off-chain database’s entire state. It is up to the smart contract code to determine what will be the next commitment/accepted state for the off-chain database.

A Land of Siloed Rollup

To date, all rollups are deployed on top of Ethereum and there is a growing list of projects including Arbitrum, Optimism, Scroll, StarkEx, ZkSync, etc.

There are many benefits to deploying your service as a rollup on top of Ethereum including:

• Secure access to >$400bn assets,

  • A user can deposit their coins held on Ethereum into the rollup without loss of security,

• Changed computational model,

  • It makes computation cheap, but data availability expensive — ideal for smart contract deployment and experimentation with new DeFi primitives.

• Granularly controlled user experience,

  • A centralised sequencer can offer a user experience that is on par with trusted cryptocurrency exchanges.

• Experimental virtual machines,

  • The ability to experiment with new features/execution/computation/languages while still inheriting the security of Ethereum.

All rollup deployments to date have empirically demonstrated how the technology stack can be adopted by projects to offer financial services while allowing software (and not humans) to protect billions of dollars.

The main issue with rollup deployments is all the infrastructure overhead that comes with it. Every rollup has its own bridge smart contract suite, sequencers, executors, security councils, RPC node providers, and generally very different approaches on how to decentralise the technology stack.

If we want cryptocurrency services to eventually replace their existing Web2 technology stack with a rollup (aka validating bridges), then there is simply too much overhead.

There must be a better way, right?

Disclaimer: Rollup technology is still in its infancy. You can and should evaluate the risk of each project on L2 Beats. We assume the reader is familiar with the separation of Sequencers and Executors. If not, then check out this article.

A Whole New World on Top of Rollups?

What if we can deploy a bridge to a new off-chain system on top of a rollup and re-use a lot of its existing infrastructure?

Is this possible? And are there benefits to doing so?

Yes!

A rollup is an ideal platform for deploying new bridges due to how it changes the computational model for smart contracts. It becomes significantly cheaper (financially) to execute actions on the bridge and pass messages between different bridges.

Additionally, it leads to an interesting mental model for layers of a blockchain system:

• Layer 1 → Data availability layer

• Layer 2 → Execution layer

• Layer 3 → Off-chain systems

The separation of chains is in line with the modular design approach taken by proof of stake Ethereum.

So, if we assume that new chains will be deployed as layer-3s on top of layer-2 rollup bridges, then what will this look like?

What Will The Off-chain Systems on Top of a Rollup Look Like?

Let’s refresh our memory on what it means to inherit security from Ethereum for a off-chain system:

• Data availability. Ethereum guarantees anyone can get a copy of an update for the off-chain database and apply it to their local copy of the database.

• Database integrity. Ethereum guarantees that all updates to the off-chain database are valid and released on a timely manner.

In an ideal world, we want the same security goals to apply for an off-chain system that is deployed on top of a rollup.

Stronger Trust Assumptions for Data Availability

The problem of data availability is a real pickle.

There is no discount for posting the data on top of a rollup and the off-chain system will incur approximately the same cost as the underlying rollup. This is because the cost of data availability is ultimately charged by Ethereum.

This leads to an obvious question:

Is it practical, or does it even make sense, to publish the off-chain system’s data on top of a rollup?

It is not necessarily a straight forward answer, but it is not the only option too. There are alternative solutions, albeit with stronger trust assumptions, to ensure the data is publicly available. For example, a project can adopt a data availability committee to attest to the data or they can simply post the data to another blockchain system (like Celestia).

There is also growing evidence that projects who want to deploy an off-chain system are willing to adopt a cheaper data availability approach (with stronger trust assumptions) as long as they can still leverage the underlying rollup to protect database integrity. For example, several companies have adopted StarkNet’s Validium committee and Reddit’s community points is run on Arbitrum Nova.

Regardless, we will not dwell on the problem of data availability. There is a far more interesting discussion to dive into as we discuss the goal of database integrity.

Who Will Be the Executors for the Off-Chain System?

If a project decides to deploy their own off-chain system, then we must assume they want to run the Sequencer and control the privileged role for deciding the order of transaction execution. Otherwise, they might as well deploy the smart contract suite to an existing rollup.

One of the critical design choices for a project is to decide what to do about the executors:

If an off-chain system is deployed on top of a rollup, then is it possible to re-use the same set of executors as the underlying rollup? Or is there a benefit to picking a new set of executors for this off-chain system?

The answer is surprising.

It is typically assumed, at least by me, that the primary role of an executor is to ultimately defend the off-chain system.

After all, we only need one honest executor to pick up the list of pending transactions, execute them, and convince the bridge about the final execution. If there is no honest party, then the off-chain system may halt indefinitely.

However, solely focusing on the one honest party assumption is very likely the wrong mental model for projects who want to deploy their application on top of a rollup. The technology stack should already take care of that problem for them and empower an honest party to step up at any time.

In practice, a project needs to envision the type of computation their off-chain system will require and which set of executors are capable of performing it.

Do they need their own independent set of executors? Or can they pay a fee to use the underlying rollup’s existing set of executors?

Let’s find out! Ahhh!

Project Appoints Independent Executors

An off-chain system can have:

• High computational requirements the underlying rollup’ executors cannot facilitate without charging an exceedingly expensive fee,

• Proprietary software the underlying rollup’s executors cannot easily run,

• Large and ever-growing database to query.

Project can picks its own executors to enable specialised execution as the dedicated executors can perform a crazy quantity of execution in a cost-effective manner.

This type of setup lends the off-chain system to act like an oracle. It can perform the execution and convince the bridge that the execution is correct before the result is passed onto other smart contracts. As such, all dependent smart contracts can have some confidence the result is correct before using it.

It potentially enables a new paradigm for passing messages in a blockchain context and we can call it a convincing oracle. The bridge’s primary role is no longer about protecting locked assets, but checking the validity of all messages sent from the off-chain system.

Some startups like AltLayer have already worked this out — although perhaps not as clearly as explained here — as they enable projects to spawn temporary off-chain systems to perform high loads of burst execution. For example, they have recently supported a large-scale NFT airdrop.

Of course, the off-chain system can be a permanent instance like indexing off-chain data and making it available to on-chain smart contracts or a temporary instance to handle a burst of traffic. Nevertheless, I am super excited to see what applications emerge and adopt this approach in the coming years.

Project Adopts Executors From the Rollup

The idea behind StarkNet’s SHARP and Optimism’s SuperChain is to empower projects to deploy a bridge, establish an off-chain database, and run the Sequencer for the off-chain system.

However, and most crucially, the project will only sequence the user’s transactions and leave the final execution up to the underlying rollup’s executors.

Put another way, if the off-chain system’s execution requirements are reasonable and it is cost-effective to rely on the underlying rollup’s executors, then why not just re-use them for it?

There are interesting properties to consider for such a setup:

• Off-chain database. Project’s sequencer can still have full control over the sequence of transactions for their off-chain database and it can still logically be a silo.

• Automatic execution. The underlying rollup, for a fee, will execute all sequenced transactions from the off-chain system.

• Globally sequenced. All transactions, across all off-chain systems, can have a single total ordering.

• Synchronisation. The underlying rollup’s sequencers, with the help of Sequencers from the various off-chain systems, can enable atomicity of transaction bundles across different off-chain systems.

The immediate benefit is to allow a project to pass on the hard work of executing transactions. Its only responsibility is to deploy a bridge, its smart contract suite on the new off-chain system, and the necessary infrastructure to run a Sequencer and sequence transactions for their users.

In fact, Rollups-as-a-Service companies may very well offer a one-click deployment solution for the off-chain infrastructure, enabling any Web2 companies to replace their legacy infrastructure with a rollup-like off-chain system.

Additionally, the off-chain system no longer lives in a silo and can access dapps deployed on other off-chain systems. In fact, all off-chain systems who share the same executors will have the same transaction queue and there will be a single total ordering for all transactions across the various systems.

If the Sequencers can cooperate, then atomic transaction bundles can be enabled that either execute in their entirety or do not execute at all. For example, a single bundle can allow the user to transact on system A, move funds from bridge A to bridge B, and then transact on system B.

There are many open research questions on how to achieve atomicity and synchronisation with this layer-3 style setup, but it is indeed within the realm of possibility.

Finally, I’d speculate the real benefit of deploying an off-chain system in this manner is to minimise liability as an operator. The project’s operators only needs to take care of sequencing transactions for their users and the process is very similar to the role of a block producer. Everything else such as custody of funds, censorship-resistance, RPC services, and executing transaction details, can be taken care off for them by the underlying rollup.

p.s. There are interesting cost-savings for data availability too. Transactions can be batched together and only a state-diff is posted on-chain. There is already so much information to take in, so let’s leave that for a future post :)

What Is the Takeaway?

We have tried to envision how projects may deploy a new off-chain system on top of a rollup and in this pursuit there are two questions to answer:

• How will they solve the data availability problem? And how are willing to make trade-offs?

• Who will take the published transactions and eventually execute them?

We did not spend a significant portion of time on data availability as it is the latter question which peaked our interest to write this blog post.

As someone who is trained in protocol design using applied cryptography, the first and foremost mindset is to pick the executor set which is most likely to have one honest party who can step up to protect it.

But — this is the wrong mindset!

How a project picks the executor set really depends on the new off-chain system’s envisioned usage and the financial costs associated with its execution.

Perhaps to establish an initial rule of thumb:

• Convincing oracle. If the off-chain system requires crazy quantities of execution to produce a single result, then it makes sense to have their own executor set and propriety software.

• Gateway system. If it is financially affordable for users to rely on the underlying rollup’s executors, then the benefits of synchronisation and minimal liability makes it a clear choice.

I’m sure the rule of thumb will expand, but this is my initial attempt at trying to articulate it. It is also why I find the announcements of StarkNet’s SHARP, Optimism’s SuperChain or even Arbitrum’s Nova are so exciting.

All approaches are making subtle assumptions on how a project will pick its set of executors. In SHARP and SuperChain, it assumes the project will re-use the same set of executors. Whereas in Nova, it allows the project to appoint its own execution committee.

If i had to take a stab at answering that, I suspect the vast majority of projects will pivot towards the gateway model using SHARP or a SuperChain as all the hard work is abstracted away alongside out-of-the-box global access to other off-chain systems.

It is a very attractive setup and may very well be why Coinbase decided to adopt the OPStack. If successful, Coinbase can become a gateway rather than a gatekeeper as startups deploy services on top of their off-chain system.

It will be interesting to see if a centralised gatekeeper on legacy Web2 technology can keep up with the mesh of venture funded startups replicating the same features and empowering the market to decide which service is the best/winner.

I hope you have all enjoyed this article and thanks to Ser Chris Buckland for skimming it. 🚀

We explore an interesting question in the context of rollups:

Transaction Finality → When is a rollup transaction considered final and irreversible?

Finality in a rollup is very different compared to a proof of work blockchain’s eventual consistency that waits on X confirmations or Ethereum’s proof of stake protocol that will finalise a transaction after two consecutive supermajority votes (epochs).

In a rollup, the pursuit of transaction finality has three stages:

• Sequencer’s Promise → Sequencer promises the user that the transaction will be ordered and executed as expected.

• Order Finality → The user’s transaction has a final ordering relative to all other transactions.

• Execution Settlement → The bridge smart contract is convinced about the final execution of a user’s transaction.

Our article focuses on the above three stages and how a transaction progresses through each stage. Before diving in further, the finality of transactions is the same for both Optimistic and Validity Rollups, or at least both type of rollups can take advantage of it :)

Sequencer’s Promise

At a high level, a transaction’s lifecycle starts with the user authorising it with a digital signature before passing the transaction to the Sequencer.

The Sequencer can respond with:

• The predicted execution of their transaction,

• A promise that this execution will hold when the transaction is settled as final.

This promise is possible as the Sequencer is the only party who has the list of all pending transactions. They have the authority to decide how the transactions will be ordered before passing it on. As a result, only the Sequencer is privy to the off-chain database’s pending state.

We call it a promise as the Sequencer can decide to return an invalid response to the user and ignore the transaction.

There are two ways that rollups can help fend against a malicious and lying Sequencer:

• Signed receipts. A Sequencer may have to return a receipt with their digital signature which can be later used to slash/punish them for lying to the user.

• Forced inclusion. A user can bypass the Sequencer and submit their transaction to the bridge smart contract.

While it is the Sequencer’s role to offer a fast path for deciding final order of transaction execution, it is not their sole discretion to do so. It is ultimately up to the bridge smart contract to decide the final ordering of all pending transactions.

Saying that, the bridge will prioritise the batch of transactions proposed by the Sequencer as long as it is published in a timely manner (~24 hours for Arbitrum).

Transaction Order Finality

The bridge smart contract, and the underlying blockchain, fulfills the role of a a data availability layer which provides a single guarantee:

Data Availability: A data item was published at a point in time and it was available for all online parties to fetch it.

In the case of rollups, the act of posting a batch of transactions to the bridge smart contract enables all honest users, executors, and other Sequencers, to fetch the list of transactions.

The new batch of transactions should be appended to the rollup’s canonical chain of transactions. Any party can execute the new transactions against their local copy of the database and compute the new state for the off-chain database. It is a deterministic process and all parties should derive the same state.

As we will see later — as long as you can trust that one honest party will step up and enforce execution settlement — then it is possible to build protocols on top of the bridge that only relies on order finality.

Note, some rollups bypass this stage as the Sequencer sends the transactions directly to the Executors, there are pros/cons to doing so which we will not discuss here.

Execution settlement

The only purpose for execution settlement is to convince the smart contract, not external parties or a consensus protocol, about the final execution of all ordered transactions.

After all, at this point in time:

• Bridge has ordered all transactions for execution,

• Anyone, including users, can compute a copy of the expected database.

The only party who does not know the current state of the database is the bridge smart contract as it lacks the computational resources to replay and process all pending transactions.

It is up to the Executors to attest and propose the new database state alongside convincing evidence that the attestation is correct. An Executor can decide to process one or more batches of transactions with the only constraint being that the execution must respect the final ordering of transactions. The evidence can be a fraud proof or a validity proof.

The only reason for execution settlement is to empower the bridge contract to perform a side-effect including transferring funds or sending messages from the off-chain system to an L1 smart contract. A side-effect can only be performed by the bridge once it is convinced about the execution of the relevant transactions

Put another way, the bridge will only release funds as long as it is convinced that all transactions are valid and executed correctly.

Tiers of Finality Summary

This brings us to one of the most interesting aspects of a rollup.

It separates the process of ordering transactions and computing its intended execution:

• Ordering First. All parties can determine the same list of transactions and locally compute the new state for the off-chain database.

• Delayed Execution. The entire process is focused on convincing the bridge smart contract about the new state of the database after the ordered transactions are executed.

Separating the processes allows anyone to deterministically compute what the database state will be before the execution is settled with the bridge smart contract.

The time delay between ordering and execution can be drastic. For example, if we consider how frequent transaction batches are sent to the bridge smart contract, then at the time of writing it is every 30 seconds on Arbitrum and Optimism.

So, order finality can be determined fairly quickly <10 minutes, but execution settlement may take at least 2 weeks.

This brings us to the key takeaway for the article:

Transact after ordering & before settlement. As long as you can trust that one honest party will step up and enforce eventual execution settlement with the bridge smart contract, then agents can act upon the unsettled database state once the ordering is final.

Let’s consider a user who wants to quickly withdraw funds from a rollup to Ethereum which has three steps:

• User sends funds + fee. A user can pick a liquidity provider (LP) and issue a transaction that transfers funds to the LP. This transaction is confirmed on the rollup and it will sends the funds to a special arbitration contract on Ethereum.

• LP waits for order finality. The LP will wait for the rollup transaction to have achieve order finality before deciding to send the user funds on Ethereum.

• LP or user gets the funds. The user’s funds will reach the arbitrum contract when the execution is settled. The Arbitrum contract will send the LP the funds if they have already paid the user or it will simply refund the user their funds on L1 if the LP failed to fulfil their duty.

In the above example, the user can optimistically receive the funds from the LP in <10 minutes and the LP will have confidence that they will be repaid the funds in ~2 weeks. If there is an issue and the LP does not fulfil their duty, then the user is repaid their funds after ~2 weeks. How exciting is that?!

To conclude, order finality is available for ANY rollup that posts transaction data directly to the bridge smart contract.

We have already mentioned that Arbitrum and Optimism support order finality, but I am also aware that Scroll, Polygon Hermez, and potentially ZkSync have implemented it too.

Most discussion focuses on how Optimistic Rollups can leverage order finality to bypass the execution settlement delay (~2 weeks).

However, it is just as useful for validity rollups, as users can assume the transactions are final as soon as it is ordered for execution. This provides wiggle-room for executors to wait for ordered transactions to pile up before putting together the validity proof and settling the execution.

up only my frens :)

As discussed in a previous post, the goal of decentralization in the context of rollups is to enable a single honest party to step up, assist the bridge smart contract, and ultimately protect the rollup against an all-powerful adversary.

In this article, our task is to find who can be the honest party and how they can participate in the rollup protocol.

It all begins with the protocol agents:

• Sequencer → Responsible for taking user-generated transactions, deciding the final order of execution, and passing it on.

• Executor → Takes an ordered list of transactions, executes them against the database, and proposes the database update to the bridge smart contract.

As explained in a previous post, a good mental model for the agents is to consider the Sequencer as offering the user facing frontend of the service for collecting transactions. It is up to the executors, the backend of the service, to process and protect all transactions.

Sequencers are Optional

The Sequencer offers the fast path for transaction inclusion and it can be argued that the role is optional.

All rollups must have a slow path available that allows the user to bypass all sequencers and send their transaction directly to the bridge smart contract for ordering. This is called the forced inclusion safeguard and a rollup is only considered secure if it actually implements it.

Rollups vs sidechains — The core difference between a rollup and a sidechain is whether a user can forcefully order a transaction for execution.

The forced inclusion safeguard is designed to handle the worst-case scenario of an adversary trying to censor a user’s transaction. If we only consider this absolute worst-case, then there is no need for an honest party to participate as a Sequencer. Thus, in the strictest sense, the Sequencer role is optional.

On the other hand, if we consider the average-case, then it can be very desirable for an honest party to participate as the Sequencer(s):

• Prevent or fairly extract MEV,

• Guaranteed inclusion of time sensitive transactions (liquidations),

• Reliable user experience (no dropped transactions, up to date info, etc)

Interestingly — the pursuit of decentralising Sequencers — may have a significant impact on the long-term architecture and roadmap of a rollup based on user experience needs — a topic for a future article.

But, as discussed here, it is strictly not necessary as users can bypass all Sequencers and single-handedly order their transaction for execution.

An Honest Executor

Executors form the backend of a rollup and they are tasked with updating the off-chain database.

Their tasks include:

• Take an ordered list of user-generated transactions,

• Execute them against the database,

• Propose a new database update to the bridge smart contract.

With this in mind, it is the executor who sits in-between the bridge smart contract and the off-chain database, responsible for sending messages about the off-chain world to the bridge smart contract.

This brings us to the need for one honest executor who can enforce the following properties:

• Liveness → Ordered and pending transactions will eventually be executed by the executors.

• Safety → There is convincing evidence that every proposed update to the database is valid.

Interestingly, depending on whether the rollup involves fraud proofs or validity proofs, it impacts the rules enforced by the honest executor:

• Optimistic Rollup → An honest executor protects safety and liveness.

• Validity Rollup → An honest executor only protect liveness.

Let’s take this opportunity to dive further into the topics of liveness and safety from the perspective of one honest executor.

Honest Executor for Safety

We need to define what it means for an adversary to attack the safety of a system and what an honest party is trying to fend against:

Adversary’s goal: Convincing the bridge smart contract of a database update that has a single invalid state transition (i.e., steals all funds).

Let’s consider the type of proofs in turn:

• Validity proof → cryptography. A cryptographic proof replaces the need for an honest party to protect the database update’s integrity. An adversary needs to break the underlying cryptography before they can produce a fake proof — which is no small feat.

• Fraud proof → honest executor. When an executor attests to a database update via the bridge, all other executors have an opportunity to review the attestation and potentially issue a challenge for it.

As a result — we are only concerned with the fraud proof approach when evaluating how an honest executor can protect safety.

There are two style of attacks an adversary can deploy against a fraud proof:

• Break safety. Honest executor is not available and the bridge is convinced of an invalid update.

• Delay attacks. Purposely forfeit staked funds with the goal of delaying the finality of executed transactions.

The fraud proof mechanism is only designed to protect safety as an honest executor can issue a challenge against all adversarial executors who have voted in favour of it. As long as the executor is honest, they are guaranteed to win every challenge against the adversary.

Delay attacks are an unfortunate side-effect for state-of-the-art challenge game designs. The fundamental issue is that a challenge game does not prove that an attestation is invalid, but that one player lost the game. An adversary can take advantage of this limitation by stretching out the challenge game for the full allocated time (~1 week or so) and publishing a new invalid attestation before the previous challenge game finishes. By repeating the two steps, it can prevent the finalisation of an honest attestation.

Of course, every challenge game will require the adversary to forfeit staked assets, so it is an expensive attack. There is a trade-off on the financial cost to perform a delay attack and the benefits of doing so. There are some hints that Arbitrum V3 will alleviate delay attacks, but there is no publicly known design for doing so.

Regardless, delay attacks represent an attack on liveness and not safety which brings us to the next topic!

Honest Executor for Liveness

It is up to one honest executor to “pick up the slack” and force the execution of all ordered transactions. To this end, success depends on the their ability to step in at the right time and how the adversary may stop them.

Again, we should define what it means for an adversary to attack the liveness of a rollup:

Adversary’s goal: Halt the execution of user generated transactions

In nearly all rollup designs, the current appointment protocol for picking an honest executor relies on a first-come-first serve basis which essentially relies on whoever can post the attestation first.

There are subtle race condition issues with the first-come-first-serve approach that can be leveraged by an adversary to stop the honest party’s participation indefinitely. For example, if two or more executors submit a proposed database update at the same time, then the adversary can simply front-run the honest party with a minimal database update.

At first-sight, the obvious solution is to offer an honest party, and all parties, a dedicated time slot for proposing a database update and remove the potential for race conditions altogether. The effectiveness of a dedicated time slot depends on how long it takes for an honest party to obtain it. The most significant threat to fend against is an adversary filling up all the slots and again delaying the honest executor’s opportunity to participate.

Another aspect to consider is the database update content. We can imagine an appointment protocol that slashes and ejects an executor that fails to propose a database update on time. In this case, we may want to prevent the adversary from posting empty database updates and effectively halting transaction execution by refusing to execute them.

Some projects like Arbitrum have implemented:

• Forced a minimum quantity of computation per database update,

• A deterministic transaction fee that cannot be tampered with by the system operators.

The combination forces a minimum execution progress as the executor must propose a meaningful database update. Additionally, it makes it expensive for an adversary to fill the ordered transaction queue with “junk”.

Future Directions

To summarise, we must ensure:

• An honest party has a guaranteed slot to propose a database slot,

• An honest party will obtain a slot in a timely manner,

• It is financially expensive for an adversary to fill the rollup with junk execution.

The above goals provide some rules of thumbs to help design new appointment protocols for onboarding executors and ensuring that one honest executor can step up at the right time. However, while rules of thumbs are great, there is still a lack of defined appointment protocols that rollup projects can adopt today.

On top of this, the entire discussion assumes that a single executor will perform all the work to produce a single database update and the entire set of executors are not cooperating with each other. This may very well be the case for Optimistic Rollups, but not for ZK Rollups.

Additional task: In a ZK Rollup, the executors need to replay all transactions and produce a validity proof that the execution of transactions is correct, an additional task than executors in an Optimistic Rollup.

It is already known that proof generation can be outsourced and parallelised amongst multiple provers, but there is still a lack of appointment protocols that can fairly segment transaction load, enable an open-membership group of provers to work together and ultimately aggregate all the independent proofs into a single proof that is published on-chain.

For example, one executor will prove transactions 1 to 1000 and the next executor will prove transactions 1001 to 2000. In the end, all sub-task proofs can be aggregated / recursively combined into a single proof.

We already have a trusted third party — the bridge smart contract — that can be leveraged to allocate transaction segments to specific executors and hold them accountable (slashing / ejection) if they fail to perform their task on time. So we have all the ingredients at our disposal, but it still remains a mostly unexplored research and design space to leverage this additional power of the bridge.

Hopefully, someone will propose an appointment protocol that 99.9% of the time enables an open-membership set of provers to collaboratively work together, but in the worst-case empowers one honest executor to forcefully make progress for all participants. :)

This brings us to the word decentralization.

It is thrown around by most projects and yet the answer to this critical question is often evaded by projects — decentralise what exactly? and how?

The word decentralization sparks the idea of an open, permissionless, and a significantly large set of participants with a more the merrier philosophy.

This is the default idea as most blockchain systems derive the source of truth from an honest majority (or supermajority) of active participants. It is of upmost importance that the appointment protocol is skewed towards prioritising honest participants to join and the honest participants will always outnumber the adversarial/dishonest participants.

Remarkably — it does not translate to the land of rollups. The technology stack relies on a fundamentally different trust assumption for finding the source of truth. Truth is not determined by an honest majority as instead it is decided by a trusted third party (TTP). In rollups, the TTP is a smart contract, a validating bridge, that lives on top of a secure layer-1 blockchain like Ethereum.

Thus — the goal of decentralization — is very different for a rollup compared to a layer-1 blockchain. It really focuses on:

Aid decision making— The goal is not to make sure the right decision is collectively agreed upon by an honest majority, but to ensure all potential decisions can be delivered and presented to the smart contract bridge in a timely manner.

A rollup system only needs one honest party to step up at the right time and deliver all messages (potential decisions) to the bridge smart contract — so it can make the final decision on behalf of all participants.

The goal of decentralisation is NOT to design a rollup that requires the participation of 100k active Validators. In fact, it is the opposite.

It is about ensuring that 1 honest party always has the opportunity to step up, at the the right time, and send all potential decisions to the smart contract bridge. So the smart contract and not an honest majority can make the final call.

Put another way:

Honest Majority → One Honest Party: Rollups take decision making away from the set of validators/system operators, as much as possible, and transfer the responsibility to a smart contract.

To this end — decentralization of a rollup must focus on the appointment protocol to ensure an honest party can participate when it is necessary and allow them to single-handedly assist the bridge smart contract and protect the entire system when it is under attack by an all powerful adversary.

Just like Gandalf as he stands on a bridge and defends the fellowship against Balrog whom he ultimately defeats at the peak of Zirakzigil.