_____________________

Key Insights

• EOF is highly controversial among client teams and Solidity developers with no clear consensus.

• Implementing EOF has significant benefits for code security, backwards compatibility, and gas efficiency.

• It accomplishes this at the cost of adding complexity and potentially creating technical debt without clear short-term benefits to end-users.

• EOF may be a proxy for a larger debate within the Ethereum community about protocol ossification and prioritizing price/value-extraction versus technical competition with alternative L1s blockchains.

What is the EVM?

The Ethereum Virtual Machine (EVM) is the backbone of Ethereum that enables smart contracts to exist. It is the part of the code that a node runs, which actually loads and executes smart contract code during a transaction. Without the EVM, all you would be able to do is send Ether.

A virtual machine is very common in the Web2 World. When a computer simulates another computer, the computer being run within the other is a virtual machine. The benefit of using virtual machines is that they can be used to replicate computation on different devices. Multiple machines, each with different operating systems and geographically distributed, can perform the same computation.

Opcodes are instructions a computer uses to perform operations. Each opcode performs a specific operation. To add two numbers, use the ADD opcode. When one contract wants to call another, it uses the CALL opcode. EVM bytecode is a series of opcodes executed sequentially and produces an output. Two different machines, with access to the same bytecode and the same start state, will produce the same output. This is how Ethereum maintains consensus. Verifying a transaction means running it through the EVM and ensuring that the execution does not revert. It was the first mechanism for enabling smart contracts on a blockchain, and today remains an industry standard chosen for many new chains and L2’s.

What is EOF?

EVM Object Format (EOF) is an attempt by the Execution Layer(EL) teams to revamp how smart contract bytecode operates and the rules of the EVM. It is part of what Vitalik nicknamed The Splurge on the Ethereum roadmap. It is a combination of nearly a dozen different EIPs all targeting the execution-layer. EOF is several years into development and slated to be included in the next hard-fork (Fusaka) along with a basic version of data-availability sampling. However, the developer community has begun to push back hard against potentially implementing EOF, with many calling for its delay and exclusion from Fusaka. This article has been abbreviated significantly to focus on a few of the controversies surrounding EOF. Versioning, Jumpdest analysis, and SWAPN were chosen as uniquely salient and digestible, but there are many other aspects of EOF, including:

1. ZK friendliness

2. Data sectioning and formatting

3. Banning code introspection

4. Changes to gas forwarding rules

All of which are highly complex with reasonable arguments on both sides. This article should not be considered a complete and authoritative analysis of EVM object format, but rather to highlight the complicated and heated debate around the subject currently occurring.

EVM Versioning

For the most part, the EVM has not been significantly altered since its genesis. A contract deployed in the genesis block is executed using the same rules a contract deployed yesterday would. This means that any changes to the EVM must be compatible with 100% of existing contracts. Every time a rule is changed, it threatens to break a contract’s functionality in some way. Given the remaining items on the Ethereum roadmap, this can cause unexpected difficulties in designing alterations to Ethereum.

A few years ago, there was a proposal to deprecate the `SELFDESTRUCT` opcode, which allowed a smart contract to delete itself from the blockchain, as a precursor to the implementation of The Verge. As it turned out, there were several dapps on mainnet that made use of SELFDESTRUCT as part of their core functionality. Deprecating the opcode would mean immediately rendering all of those contracts unusable. These applications were not the largest in TVL, but they were still actively being worked on by the protocol team and had user deposits that could not quickly be withdrawn. This created an ideological split in the Ethereum developer community. Many argue that supporting Verkle Trees should be prioritized over supporting small applications with limited TVL/PMF. However, to allow the community to brick a contract unexpectedly and without recourse would go against the core principles of Ethereum and present a series of existential questions about its core values. In the end, a compromise was found between protocol and core developers, but this debate only occurred because the EVM doesn’t have a versioning scheme.

A versioning scheme would allow EVM maintainers to write new rules for how the EVM should operate without worrying about it breaking old ones. When the EVM executes an opcode, it would first check whether the bytecode should be executed under legacy rules or EOF rules, and if EOF rules, which version. By adding versioning, contracts can be executed under rules depending on when they were deployed. This allows a contract developer to be confident that the rules their contract is executed with don’t change. If the code is valid at deployment, it should be valid forever and executed the same way, even if the network’s execution rules change for new contracts.

Code Analysis and Contract Size Limits

There are two ways to analyze what code does: Static and Dynamic analysis. Static analysis is performed on code that is not currently running, dynamic is the opposite. Dynamic tests are the kind most people associate with code testing because they involve coming up with test cases and executing the code directly to make sure it does what you want. Static analysis tools look at the raw bytecode and stitch together what it’s supposed to do without ever running it, which enables massive gains in speed on larger codebases over dynamic analysis. There is significant demand from the Ethereum developer community to build better static analysis tools for bytecode for research purposes, including MEV Bots, hackers, and highly optimized applications. One of the central goals of EOF is to aid in building static analysis tools by making it easier for bytecode to be analyzed.

Why is EVM bytecode hard to statically analyze?

EVM bytecode follows no structure. When you call a contract, the EVM part of the EL client loads the bytecode into memory and starts executing from the first instruction until it either reverts, runs out of gas, or returns successfully. This makes developers’ jobs very hard because if there’s no specific structure to the code, then looking for bugs quickly becomes a needle in a haystack. Some challenges include:

1. Separating out hard-coded data from executable opcodes

2. Inability to run subroutines

3. Lack of versioning

4. Dynamic Jumps

EOF seeks to impose a structure on bytecode to simplify analysis and EVM maintenance.

For example the opcode 0x5b, JUMPDEST.

JUMPDEST is an opcode. It’s called after a `JUMP` opcode. The JUMP opcode simply moves you around to different parts of the code. So if the program counter, which tracks where you are, is on instruction 50 and it needs to do something at instruction 150, the JUMP opcode is used to continue executing from this part of the code. However, the location that you jump to must have a valid JUMDPEST opcode at it. It is a security feature that was introduced by Ethereum after genesis. By ensuring that there’s a valid JUMPDEST opcode at the location, an attacker could not hijack the execution of a program. If an attacker managed to find a bug that allowed them to jump to whatever part of the code they wanted, they could basically do anything they wanted and begin executing parts of the code that they should not be able to. There must be specific JUMPDEST opcodes at certain locations, typically located around various authorization checks.

When looking directly at a bytecode, there are two ways in which this opcode may appear. The first is its intended purpose to indicate a JUMP destination. However, it is also possible to use that same data for something else. In human-readable ASCII, 0x5b is designated as the open-bracket “[“‘. Users may want to use that character in their code as a literal value. When statically analyzing code, it is quite difficult to discern whether a byte is being used as an opcode or as a piece of data. One of the mechanisms EOF uses to fix this is by separating code into distinct sections, isolating raw data from executable opcodes. This ensures there is no ambiguity on code analysis and makes it easier to deconstruct any raw data being used. Take the following examples:

0x…a5b1c4d908504a9c5ba4f8…

0x…a5b1c4d964504a9c5ba4f8… (1)

1: While this would be valid bytecode by the EVM as every opcode is technically valid, this code would not run without reverting, and has been arbitrarily created for the purposes of the example.

Can you tell which is the valid JUMPDEST? The second one uses the hex-value 0x5b, but since it’s preceded by a 0x64 (PUSH4), this means it shouldn’t be interpreted as a JUMPDEST. This quickly becomes very difficult to manage as bytecode size and complexity increases.

What is JUMPDEST analysis?

When a contract is called, the EVM performs JUMPDEST analysis. It goes through the bytecode of the contract and looks for every usage of the JUMPDEST (0x5b) opcode. It then compiles this information into a format retrievable later from all the valid JUMPDEST locations. When the EVM during execution encounters a jump, the code checks that the destination is a valid JUMPDEST from the analysis it did earlier. However, the issue comes from the fact that it has to be performed every time a contract is invoked. For a contract like USDC that may be called in every single block, that’s a lot of computation being needlessly expended. It’s also part of the reason why Ethereum contracts are limited in size.

Currently on mainnet, contracts are prohibited from being larger than ~24.5Kb in size. The contract size limit was decided a long time ago as part of a security solution to a potential denial-of-service attack on nodes. Many developers want to get rid of it, as they believe that, similar to gas limits, hardware has evolved to the point where nodes can handle an increase in size. Many developers oppose increasing the contract size limit as it may cause higher overhead for EL clients due to larger contracts taking longer to analyze. One of the central goals of EOF is to change the rules so that instead of doing JUMPDEST analysis every time a specific contract is loaded, it’s only done once at deployment. The structure of this actually enables any kind of code validation beyond just JUMPDEST at deployment time. Since this reduces the overhead of executing contracts, it paves the way for gas limit increases in the future as well.

So that sounds reasonable, but why can’t we just do that anyway without EOF if it’s causing so many issues

Since EOF is close to a dozen EIPs, the developers decided that they should all be introduced at once, especially as many rely on one another to function. If this change to code validation is implemented, this can have significant positive impacts for developers, the most important of which is eliminating the contract size limit. Developers hate the limit because it prevents contracts from being large enough to do everything they want to do. Most often, when developers write contracts that exceed the size limit, they are between a rock and a hard place. Conventional wisdom would say to just slim down the size and complexity of your contract to fit the limit, but developers don’t always think that way. Often, complexity can't be sufficiently reduced to fit within the limit. This led to the creation of the Diamond-Proxy standard (ERC-2535). Diamond proxy is an architectural design where the functionality of a contract is essentially split among several contracts, which each serve a specific purpose and interact with each other in part of the same application, because to combine it all into one file would make it too large to be deployed.

Diamond-Proxies can have benefits for contract upgradability but at the cost of security and gas. Several contracts communicating with each other introduce new configuration complexity that is susceptible to security vulnerabilities. Similarly, having multiple contracts deployed and configured increases both deployment and runtime costs from a series of external calls. It is also argued that eliminating the contract size limit would enable developers to build more complex and feature-rich smart contracts that are currently not feasible. Currently, the smart contract development community is united in their dislike of the contract size limit and want to remove it, but specific plans for its removal remain stalled due to issues surrounding exactly how to do so safely. Some have argued that the existing gas limits in place should prevent abuse of a no-limit system, but the exact merits of that argument are beyond the scope of this article. Various L1s & L2s have recently been experimenting with removing this themselves, such as MegaETH, Monad, and Starknet.

Eliminating Stack Too Deep Errors: SWAPN/DUPN

Anybody who has spent any amount of time writing Solidity code would already be familiar with the “stack too deep” error code. It occurs during compilation and is perhaps the single largest pain point of writing Solidity code to date. However, since Solidity has matured, there have been a variety of methods invented by developers to work around these limitations, rendering the error code more of an annoyance than an unsurpassable barrier to development. However, that also often results in code that is messier and less gas-efficient. One of the core EIPs as part of EOF is to replace SWAP1-16 and DUP1-16 with SWAPN and DUPN. These new opcodes would allow manipulating of a stack variable at any depth, eliminating the stack-too-deep error forever. Naturally, when this was announced, developers were very excited about the elimination of the error. However, client devs quickly pointed out that there were a variety of potential issues with JUMPDEST analysis that come from allowing more dynamic opcodes.

This has caused a significant debate between solidity developers, and the lower-level developers who implement the tools they rely on. Many have argued that instead of introducing new complexity to the EVM-level, the issue should instead be tackled at the compiler-level through optimizations. Both sides have valid points and there is no clear consensus.

Should Non-Devs Care?

EOF is NOT a “number go up” upgrade like danksharding or the merge. EOF is strictly a technical upgrade for the developers that make Ethereum run and drive the platform forward. There is no financial case for how EOF affects tokenomics, liquidity, usability, etc. that the Ethereum community tends to associate with price. This should not be considered a negative, but it is difficult to elucidate a case for the short-term benefit to Ethereum’s price. However, if one is to take a longer-term view of Ethereum, then the value proposition becomes somewhat clearer.

EOF is important because it enhances developer tooling. However, eliminating the stack-too-deep error is not a benefit that end-users will notice, but the overwhelming majority of developers desire. Implementing EOF improves the security of smart contracts and can be beneficial in preventing hacks. Raising contract size limits can enable new applications currently constrained by size restrictions. Static relative jumps shorten development time and lower gas cost. Code validation enables future EVM upgrades in less time with better backwards compatibility. These are all things that trickle down to end-users later, in the form of better applications, shorter development times, lower gas costs, and higher security. Similarly, despite the criticism of Ethereum’s development time, EOF getting to this point should nonetheless be seen as a positive for the long-term stability of the network given the overwhelming complexity and difficulty in implementation.

Why is EOF so controversial?

The benefits of EOF are difficult to explain to the layman. The merge, danksharding, and EIP-1559 all have easy-to-understand value propositions for users and provide good narratives for Ethereum. EOF does not in the same way account abstraction does. There are significantly harder challenges that still need to be solved, and the continued prioritization of EOF could potentially crowd out progress on these. It can also be argued that depending on the issue, the work done on EOF may potentially make their implementation easier by knocking down roadblocks that would only show up later on in the process if nothing was done, similar to SELFDESTRUCT’s deprecation. This cannot be completely known now, and it is equally likely that EOF could have the opposite effect, causing more issues down the road.

The debate over EOF is rare because it appears that the developer community is not in alignment over whether or not it should go into effect. Twitter discourse as well as the Ethereum-Magicians Forums have been in very heated debate over the subject, and it is not clear which side has more support. Client developers have valid concerns about the additional technical debt that they may be incurring. There are also ideological debates about the simplicity of Ethereum as a base layer. Many argue that the L1 should remain as simple as possible, and that the addition of excess rules and bytecode formats present an affront to some of the ideological principles Ethereum is founded on. These arguments are typically coupled with debates about protocol-ossification, of which Bitcoin’s own community should be studied as a relevant analogue.

EOF does, however, potentially introduce new technical debt for client teams. Given that the EVM operates at the execution layer, keeping the codebase simple can enhance development time and security while lowering computational overhead. This upgrade could have the opposite effect and create an astounding amount of new complexity in the codebase. This comes from having to maintain two versions of an already complex project. It’s not difficult to foresee how additional rulesets can become an increasingly sprawling mess of branches in the code. Every new rule becomes one more piece of code that must be maintained in the future and is a liability.

Many chains in the crypto industry have attempted to eschew the EVM in recent years. This is coupled with their insistence that a different architecture for decentralized computation can enhance scalability. These include Solana, Aptos, and Sui. These competitors do claim the ability to achieve higher levels of throughput under their alternative models. On the other side, some argue that given the EVM’s continued dominance and large lead on the competition, major structural changes are not needed to compete in the marketplace. Chains and L2s such as Fuel argue that rather than EOF, strategies such as parallel computation can result in the necessary efficiency gains to achieve sufficient scalability.

One of the largest concerns among Solidity developers is concerns around how it interacts with the rollup-centric roadmap. Not all L2s are equivalent to the L1. When new features are introduced on mainnet, there is often significant lag time between then and when those features are implemented on an L2. This is why you often hear about EVM-compatibility vs. EVM equivalence. When a new change is made on the L1 it must eventually be implemented on all layer-twos.

As tools for deployment improve, more protocols have embraced deploying on as many chains as possible, as it’s quite easy. For many chains this means simply changing an RPC URL and hitting deploy. But for other chains that do not have exact feature parity this can be a real issue. If the target chain does not support something, then application developers may be forced to recompile and maintain multiple separate versions of bytecode based on the chain. This is a frequent pain point for multi-chain developers in the status quo over existing functionality like Create2 and Transient Storage. Developers at rollups such as Optimism have expressed support for implementing EOF on OP if integrated on mainnet, but this is by no means a perfect solution and involves additional trust assumptions.

While scalability is not a primary goal of EOF’s implementation, one additional benefit to it would be decreases in the proving time for the generation of Zero-Knowledge proofs over EVM execution. Since EOF decreases the number of possible execution paths and adds additional structure to bytecode, ZK-proof generation can progress significantly. As illustrated by the chart below, this results in smaller proof sizes and faster generation over arbitrary computation in the EVM. Currently, many bottlenecks still exist for the computationally expensive generation of ZK-proofs, which prevent their enshrinement into various parts of the Ethereum-stack. Completion and deployment of EOF thus stands to help accelerate the development and implementation of Zero-Knowledge cryptography through Ethereum. This would have significant long-term benefits to the ecosystem, such as enhancing privacy-preserving technology, shortening of block-times, interoperability between L2’s, and complete enshrinement of ZK-proofs into block verification. However, Zero-Knowledge cryptography remains in its infancy, and it is possible that such improvements may occur inevitably due to increasingly rapid improvements in the general engineering of zero-knowledge-proof generation.

Should EOF Ship in Fusaka?

Not all objections from core devs are over EOF’s existence, but rather the process of implementation. Fusaka already plans to ship with a base implementation of data-availability-sampling, which will increase network scalability by several orders of magnitude. It is argued by developers that Fusaka should not be expanded in scope. Furthermore, proceeding with EOF potentially crowds out available resources for the remaining work for larger-impact upgrades like the verge and the purge. One option is to have L2s implement EOF first to gauge the potential impact and perform more analysis. Since many L2 sequencers use modified versions of Geth, or other clients which have already implemented EOF, this is a viable option. This would potentially be a less damaging choice as years of work have already gone into getting EOF to its current status, and implementation on L2s would prevent this work from being wasted. Few are arguing for it to be completely scrapped, but without a clear path to inclusion, the future of EOF would become uncertain.

This entire debate, while simmering below the surface, only really exploded recently when Solidity 0.8.29 was announced, which focused on preliminary support for EOF. The Solidity compiler team has announced their support for EOF recently as well. As of writing, Geth, which makes up ~43% of EL nodes, has come out against EOF in Fusaka, while the second largest, Nethermind (36%) has come out in favor. Notable researchers Dankrad Feist(2) and pcaversaccio argue adamantly against EOF with Tim Beiko and Vitalik in favor. This has also ignited further debate about the decision-making authority of various client developers and teams, specifically around potential veto-powers for EL upgrades. As of March 25, 2025 the team behind Besu Client and symbolic-execution engine hevm have come out in support of EOF shipping in Fusaka. The deadline for deciding whether or not to include EOF is April 10, 2025, and as of writing, it is unclear what the final decision will be, but there does appear to be at least enough consensus on implementing some form of EOF rather than removing it altogether.

2: The researcher behind the appropriately named: “Danksharding” scaling protocol for Ethereum

There is also a series of potential options for modifying the scope of EOF to be more limited and remove some of the more contentious issues. As it stands, one of the most contentious issues surrounding EOF concerns the significant amount of breaking-changes to application-development on Ethereum, and how developers must adapt. Many of the options and debate revolve around how best to manage this and minimize roadblocks for developers. This includes allowing both legacy and EOF contracts to be deployed and leaving the choice to the developer which version to use. It has been agreed by the core developers that EOF should only be excluded if it would result in a delay of PeerDAS shipping as well.

Conclusion

The debate over EOF is ongoing, and new information is being released constantly. However, it should also be noted that this spirited debate should be seen as a positive for the community. Despite the heated conversation, many prominent researchers and developers have entered the debate because they want to ensure the best possible future for Ethereum’s technological superiority. EOF is not being built in the shadows, and the debate is playing out in public with some of Ethereum’s best and brightest. There has not been a deference to authority, and many of the community’s most venerated developers are on opposite sides of the issue. What ultimately ends up happening next is unknown, but there should still be confidence that whatever ends up happening will be the best course of action, and not the result of an unelected and unaccountable shadow group of Ethereum’s leaders.

While EOF remains controversial among developers, it represents a significant milestone in the maturity of Ethereum. The initial design of the Ethereum Virtual machine was intended to be simple because the scope of what was possible with smart contracts was limited. As time goes on, and as the crypto development ecosystem evolves, EOF is another indicator of how Ethereum must grow with it. EOF has the potential to improve the development experience and position Ethereum to lead the pack in the next generation of smart contract development, or it could have little effect at all. The effects of EOF may not be felt right away, and only time will tell whether or not the impact is worthwhile. Every item on the Ethereum roadmap thus far and into the future was meant to improve Ethereum in some way, and EOF is no different, this time targeting shortcomings of the execution-layer, just as the merge targeted the consensus layer.

Controversy comes with the territory — even The Merge drew opposition. However, the mere act of shipping such a complicated upgrade, championed by some of Ethereum’s most dedicated, highlights its continuing relevance in the increasingly-competitive L1 market. Regardless of the impact, the perseverance and dedication of the development community in iterating and prioritizing improvement of the technology over short-term profiteering should be a sign that Ethereum is on the right track and poised to succeed well into the future.

This article attempts to be as accurate as possible, but due to the highly fluid and constantly evolving nature of EOF some information may be outdated or incorrect. If you find any errors or have feedback, please reach out to the author directly.

                                                            _____________________

Key Insights

• MegaETH aims to achieve 1ms block times and 100,000 TPS. The architecture relies on high-performance sequencers, software optimizations, and other existing L2 features.

• 1ms block times enable new applications like real-time DeFi, on-chain high-frequency trading, fully onchain games, and real-time computing DePIN. This ultra-low latency will be MegaETH’s primary value add and unlocks use cases previously thought impossible on traditional blockchains.

• MegaETH’s high-performance architecture relies on a single sequencer model, leading to tradeoffs like increased censorship risks, liveliness issues, and MEV concentration. Solutions such as ZK proofs and priority ordering could address these challenges but may impact performance.

• If successful, MegaETH’s design could challenge the direction of existing L2s. Many L2s will likely find themselves in a middle ground, offering neither the decentralization of Ethereum nor the performance of MegaETH.

What is MegaETH?

Backed by $20 million in funding from Ethereum co-founders Vitatlik Buterin and Joseph Lubin, as well as Dragonfly Capital, along with an additional $10 million raised from the community, MegaETH is an in-development Layer-2 (L2) that aims to be the first “real-time blockchain”. Through software optimizations and high-performance hardware requirements, MegaETH claims to achieve a throughput of over 100,000 transactions per second (tps) and block times of less than 1 millisecond (ms).

MegaETH plans to launch as an Optimium - an L2 that uses fraud proofs (optimistic) for settlement to Ethereum and EigenDA for offchain data availability. The public testnet, initially expected to go live in Q4, was delayed to Q1 to allow for further development and feedback, but a private testnet is currently running for MegaMafia builders.

Technology

To achieve high throughput and low latency, MegaETH aims to optimize the L2 architecture to deliver high performance without compromising security or decentralization - a challenge often faced by standalone Layer-1 (L1) networks. MegaETH relies on node specialization, software optimizations, and existing L2 features, such as escape hatches to accomplish this.

Node Specialization

MegaETH employs node specialization, unlike traditional L1s, where all nodes perform identical tasks. This approach distributes responsibilities across various node types, enabling Web2-level performance with decentralized validation.

Sequencer Nodes

MegaETH’s sequencer nodes are responsible for:

• rapid ordering and executing of transactions

• dissemination of state diffs(1) to replica nodes and full blocks to provers and full nodes every 1-10ms

To achieve its level of throughput and latency, MegaETH sequencer nodes are 5-10 times more performant than Solana L1 nodes.

1: The state diff represents the specific change to a blockchain's state. For example, if Alice initially has a balance of 10 ETH (pre-state), sends 5 ETH to Bob (transaction), and her new balance becomes 5 ETH (post-state), the state diff reflects this change: Alice's balance decreases by 5 ETH.

Prover Nodes

Provers validate blocks executed by the sequencer through an optimistic proof system.

Proof System:

• State updates are presumed valid unless challenged within a dispute window (typically seven days)

• Using stateless verification, provers require lower hardware resources than Ethereum L1 nodes and do not need to store the entire blockchain state

Prover Function:

• Receive blocks, state data, and cryptographic witnesses(2) from the sequencer to validate the correctness of state updates

• Detect discrepancies (e.g., double spending occurred) and submit fraud proofs to challenge invalid updates

  2: Witnesses consist of the necessary state data (e.g., pre-state balance, transaction, post-state balance) and cryptographic proofs to verify the data is part of the state.

Replica Nodes

Replica nodes make up the majority of nodes in the MegaETH network and are designed to help relay information to and from frontend applications efficiently:

• Receive and relay state diffs (e.g., Alice’s balance changing from 10 ETH to 5 ETH) from the sequencer and apply them to their local states

• Use prover-generated proofs for verification of state diffs, instead of re-executing transactions, allowing for lighter hardware requirements

Full Nodes

Full nodes re-execute every transaction, unlike replica nodes, and are designed for power users, like centralized exchanges:

• Offer quicker assurances of correctness through independent re-execution (i.e. don’t want to wait the full seven-day challenge period)

• Slightly higher hardware demands than replica nodes but more affordable than sequencers

Together, these nodes and EigenDA for data availability compromise the architecture shown below.

Software Optimizations

MegaETH also intends to implement various software optimizations to achieve its goals:

• Real-Time EVM Execution Engine: Combining a “low-latency, streaming-based block building algorithm” that continuously processes transactions as they arrive with a “concurrency control protocol” for parallel transaction processing. These features will allow MegaETH to handle large volumes of transactions efficiently and publish state diffs at intervals as short as 10ms.

• In-Memory Computation: Sequencer nodes store the entire EVM state in memory, boosting state access speeds up to 1,000x compared to solid-state drives (SSD) systems. This enables high-performance, data-intensive, Web2-like applications to operate onchain with minimal latency.

• JIT Compilation: Sequencer nodes will leverage Just-In-Time (JIT) compilation to convert smart contracts (EVM bytecode) into native machine code at runtime, achieving significant performance improvements. This client-level optimization could enable up to 100x speedups for compute-intensive applications by bypassing the overhead of interpreting EVM bytecode line-by-line and emulating a stack machine, the approach used by most Ethereum L1 execution clients.

• Optimized State Trie: Replacing Ethereum’s Merkle Patricia Trie (MPT), a data structure used for storing the state, with a custom state trie that minimizes disk I/O operations and efficiently scales to terabytes of state data.

• State Sync Protocol: To propagate state diffs from the sequencer to replica nodes with high throughput and low latency, MegaETH will use an efficient peer-to-peer protocol. This ensures that nodes with a “modest internet connection” can remain synchronized with the latest state.

Specific technical documentation for these features is not yet available.

The Mega Vision

Overall, MegaETH aims to scale to Web2 standards with over 100,000 tps and 1ms block times. It seeks to realize Vitalik’s Endgame vision where “Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented”.

While many projects are building on MegaETH, specific technical documentation on how MegaETH will achieve its ambitious performance goals has not yet been publicly released, and the high expectations bring a certain degree of execution risk that should be carefully considered.

Evaluating the Mega Ecosystem

What Matters More? TPS, Block Times, Something Else?

MegaETH is being built for applications that produce a high volume of [compute-intensive] transactions as well as highly interactive applications that require extremely low latency. To optimize for these applications, MegaETH has focused on:

• increasing throughput (high tps),

• reducing the cost for compute and data-intensive transactions, and

• decreasing latency (low block times).

Analyzing how MegaETH compares to other L2 and L1s will provide valuable insight into if it has an advantage in these key metrics.

Analyzing Throughput

In today’s blockchain ecosystem, high throughput (high tps) blockchains are a dime a dozen:

• Solana (Launched): a Parallel non-EVM L1 claiming to scale to 65,000 tps

• Sei (Launched): a Parallel EVM L1 claiming to scale to 12,500 tps

• Monad (In-Dev.): a Parallel EVM L1 claiming to scale to 10,000 tps

Compared to these existing and planned high-throughput EVM chains, MegaETH will likely be on par or slightly better in theoretical throughput.

However, there is currently an abundance of blockspace: no application is in need of this throughput, and no chain is close to reaching its theoretical capacity. Solana, as an example, currently averages ~1,100 tps (voting transactions excluded) and has only recorded a max tps of 7,229, according to Chainspect. As such, other metrics are likely more important to determining if MegaETH will be successful.

Analyzing Compute Efficiency

Through JIT Compilation, In-Memory Computation, and an Optimized State Trie, MegaETH has the potential to significantly increase throughput and reduce the costs for compute-intensive and data-intensive transactions. However, other L2 teams are also working to do this.

Offchain Labs launched Arbitrum Stylus on Arbitrum One and Nova on September 3, 2024, enabling developers to write smart contracts in Rust, C, and C++ (compiling to WebAssembly, WASM) alongside Solidity. Stylus introduces a WASM VM alongside the EVM, ensuring full interoperability between Solidity and Stylus contracts. It significantly reduces compute costs (10–100x) and memory costs (100–500x) compared to the Ethereum EVM, unlocking compute-intensive applications like Renegade. Renegade leverages Stylus for multi-party computation (MPC) and zero-knowledge proofs to build an on-chain dark pool (a privacy-preserving DEX) with no MEV or slippage.

Analyzing Latency

Because MegaETH relies on a centralized sequencer model and does not require consensus,  it could theoretically enable ultra-low 1ms block times—over 100x faster than nearly all other live or planned chains. This brings latency on par with Web2 levels, where delays depend mainly on a user’s proximity to the sequencer rather than a chain’s block times. This is primarily what sets MegaETH apart.

1ms block times will be MegaETH’s primary driver of new applications and better user experiences, previously thought impossible on traditional blockchains.

Onchain Gaming

MegaETH’s low latency and support for compute-intensive applications enable real-time, fully on-chain virtual games and worlds. Without latency below 100ms, player interactions would lag significantly, making it impossible to create an immersive and smooth real-time experience that players would enjoy.

Biomes, a sandbox game like Minecraft, is leveraging MegaETH to build a fully on-chain virtual world where everything—dirt, ores, and physics—is tokenized, ensuring true scarcity and tamper-proof rules. Items like chests and doors will also have smart contract programmability, enabling mechanics such as an NFT-gated door for a virtual club. The team believes these features will allow them to create a virtual world with the largest GDP.

Real-Time DeFi

Research by Uniswap Labs shows that(3) lower latency reduces arbitrage losses, thereby increasing profitability for liquidity providers (LPs). Shorter block times minimize price discrepancies between CEXs and DeFi, making arbitrage trades less profitable. On MegaETH, higher profitability from lower block times could incentivize LPs to migrate, attracting DeFi projects and creating a liquidity flywheel.

3: “In the LVR with fees framework, arbitrage losses increase with the square root of block time.”

MegaETH could lower the barriers for high-frequency trading (HFT) to happen onchain, as market makers and HFT firms could colocate next to the sequencer for the lowest possible latency. Onchain HFT could not otherwise happen where latency exceeds 10ms. Onchain HFT has the potential to:

• decrease spreads

• increase liquidity

• improve the overall DeFi experience for the average user

However, chains designed for MEV to be captured and distributed back to users, such as Unichain, might offset the advantages of ultra-low latency and onchain HFT. Moreover, the potential enablement of onchain HFT has sparked concerns, drawing comparisons to the negative effects electronic trading firms have had on traditional financial markets.

Some DeFi projects building on MegaETH are listed below. Of note, some are still in stealth and limited information has been disclosed.

• CAP Labs: stablecoin engine for maximum yield

• GTE: launchpads, spot, and leverage trading DEX

• Valhalla: perpetuals DEX

• Noise: the platform for trading trends

• MegaBot: native high-frequency trading bot & sniper

• Teko Finance: real-time money markets

Real-Time Computing DePIN

Low latency can also be useful for some DePIN applications, such as decentralized VPNs (dVPN), which encrypt and route traffic between p2p individual nodes instead of servers. To plan the routes for data packets, dVPNs use a  “Control Layer” on a blockchain. MegaETH's ultra-low block times enable these calculations to be published in just milliseconds, ensuring minimal delays. Hop Network is leveraging MegaETH to build a dVPN Control Layer that matches the speed of traditional VPNs while offering superior anonymity and censorship resistance.

The Mega Tradeoff

The use cases for MegaETH appear compelling. So what’s the catch?

MegaETH employs a single sequencer model, where one active sequencer is responsible for ordering and executing transactions at a time. The team has expressed plans for the active sequencer role to be rotated across different sequencers, with a long-term vision of having an extensive list of permissioned, non-MegaETH-owned sequencers included in the rotation. However, the specifics of the model, including the timeline for implementation and the rotation interval, are still being finalized. Rotation could be based on factors such as geography to reduce latency for active users, behavior, or other considerations.

While most L2s have centralized sequencers today, many L2s have committed to decentralizing their sequencers, including Arbitrum, Eclipse, Movement, and others. Offchain Labs has already established a partnership with Espresso Systems, the protocol focused on decentralizing sequencing for rollups, to decentralize their sequencer sometime in 2025.

Arbitrum wants to avoid a “rotating centralized” approach and instead use a consensus of sequencers to publish a block. Like Ethereum, a sequencer, chosen at random for each new block, will propose a block and a consensus of a committee of sequencers will validate this block through a voting process.

Since a decentralized sequencer committee must first reach consensus to publish a block, block times are bottlenecked by the speed of global back-and-forth communication (speed of light) between sequencers in the committee. As the size of the committee grows, communication becomes more complex, requiring multiple rounds to reach consensus. This leads to delays of a few hundred milliseconds, making ultra-low latency nearly impossible.

The Mega Tradeoff, therefore, for MegaETH, is increased performance mainly in the form of exceptionally low latency at the expense of:

Real-Time Censorship Resistance

All chains also face the issue of censorship, albeit to differing degrees. On Ethereum, around 10.6% of validators (responsible for proposing and verifying new blocks) censor OFAC-sanctioned transactions. In these cases, users may experience delays, waiting for a non-censoring validator to include their transaction. On average, censorship would cause the average OFAC-sanctioned transaction to have to wait 13.4 seconds as opposed to the normal 12-second block times.

For MegaETH, if a user is censored by the single active sequencer, the user would either:

• need to force include the transaction on the L1, or

• wait for the active sequencer role to rotate (once implemented) to a different node, which could take a couple hours

While this may result in real-time censorship, it prevents indefinite censorship as the transaction would likely eventually be processed by one of the sequencers.

To further address this, on a podcast with Logan Jastremski, MegaETH CTO Lei Yang brainstorms a solution involving a decentralized committee of sequencers that could force the single active sequencer node to include a transaction in a timely manner or face slashing. If implemented, this could further reduce the duration a user is censored without increasing latency.

Liveliness / Increased Risk of a Reorg

MegaETH could face liveness risks with a single sequencer model, as any immediate downtime or failure by the sequencer could disrupt transaction processing and hinder network reliability. To mitigate this risk, the team plans to maintain a standby sequencer as a fallback once the rotation model is implemented.

Additionally, in the event a sequencer acts maliciously and publishes an invalid block, the invalid block would be detected by provers and the network would need to reorganize (reorg). This would entail rolling back the chain to remove the invalid block and replacing it with a correct one. Depending on how many new blocks have been published after the invalid block, this could be highly disruptive as all blocks after the invalid block would also need to be discarded and replaced.

This risk can be mitigated by requiring the active sequencer node to post a bond, which would be slashed if an invalid block is published, disincentivizing malicious behavior. However, to date, the MegaETH team has not publicly indicated that this will be required by their sequencers at launch or at an unspecified time in the future.

Adopting a Zero-Knowledge proof system could fully eliminate this risk by ensuring only valid blocks are published through cryptographic validation. However, as ZK proofs improve, uncertainties remain about latency penalties and the need for hardware specialization, which may differ from MegaETH's proposed setup.

MEV Centralization

MegaETH's high-performance single-sequencer architecture will likely concentrate MEV profits among a limited number of entities. The platform currently plans to implement a First-In-First-Out (FIFO) transaction ordering scheme, which may be enforced through a trusted execution environment (TEE) like SGX. Under FIFO, transactions are processed strictly in the order they are received, effectively mitigating sandwich attacks and other MEV strategies reliant on transaction reordering.

In this model, the chain may experience more spam and frequent reverts from searchers trying to get their transactions included. Additionally, searchers that colocate next to the sequencer will be the first to capture MEV generated from DEX arbitrage and liquidations. Without explicit mechanisms, MEV profits will remain with colocated searchers rather than accruing to the sequencer or the broader MegaETH ecosystem.

One alternative is to adopt priority ordering, like that used by OP Mainnet, where the sequencer orders transactions by priority fees. If there was competition among colocated searchers, most MEV could shift from searchers to sequencers while also allowing applications to capture some of the MEV they generate. A TEE could ensure compliance with priority ordering, while an encrypted mempool could safeguard against sandwich attacks—both integral to the endgame architecture envisioned for UniChain.

In the priority ordering model, applications and users could capture MEV through MEV Taxes. Applications would charge transactions a percentage of their priority fee (e.g., $99 charged by the application per every $1 of priority fee charged). Searchers competing for arbitrage opportunities would set high priority fees to get their transaction included, while regular transactions would remain unaffected. Of note, for MEV Taxes to work, priority ordering must be strictly followed without censoring, viewing or delaying any transactions.

Incorporating encrypted mempools and TEE enforcement could add latency, conflicting with MegaETH's performance goals. Application Specific Sequencing (ASS) includes a wide variety of other methods where applications capture more of the MEV they generate:

• Oracle Extracable Value (OEV) Capture,

• Function Maxaiing AMMs, or

• Rollup-Based Solutions.

However, applications that attempt to capture more value could reduce their composability within MegaETH or introduce additional latency to their application.

A trend of applications increasingly building appchains to capture value and deliver custom experiences has emerged however. Sei’s Parallel Chain Stack is among the first to enable high-throughput L2s through parallel processing. As such, successful high-performance applications on MegaETH may seek their own L2 or L3 appchains for MEV capture or custom features like private transactions, though MegaETH has no plans to develop such a chain stack.

MegaETH believes the new use cases unlocked by ultra-low latency are worth these tradeoffs.

What’s the Case for Decentralized Blockspace?

The decision to prioritize censorship-resistance and security through a decentralized sequencer comes at the cost of higher latency. For latency sensitive applications such as gaming, real-time DeFi, and real-time DePIN, low latency is highly important. That said, some sectors value uninterrupted operation, robust decentralization, and strong censorship resistance over low latency and throughput.

Potential Sectors

Restaking

Restaking protocols, such as EigenLayer, allow users to lock their tokens to secure the main network (e.g., stake ETH, securing the Ethereum network) and additionally reuse those tokens to secure other networks/protocols (e.g., restake ETH to secure a data availability service such as EigenDA). These protocols are likely to remain on Mainnet as downtime or security issues could compromise their operations and the systems relying on them.

Ultra-High Net Worth DeFi

DeFi platforms that manage large reserves of capital require maximum security and uptime. AAVE, with over $19.1 billion in TVL on Ethereum Mainnet, must remain operational even during high market volatility. Any extended downtime could disrupt the protocol’s liquidation process, leaving under-collateralized loans unresolved and potentially causing cascading insolvencies. As such, institutions and individuals highly concerned about the security and preservation of their wealth will likely keep their funds in resilient Mainnet DeFi protocols.

Censorship-resistant Cross Border Payments

In countries with unstable financial systems, censorship-resistant cross-border payments are critical for ensuring that transactions can occur without interference from governments or intermediaries. While Ethereum Mainnet offers the highest degree of censorship resistance, and the best choice for moving billions of dollars, high fees could be less ideal for smaller remittances. Censorship-resistance and cheap fees on decentralized sequencer L2s could offer a solution here.

Based Rollups, however, could provide greater liveliness and censorship-resistance guarantees than decentralized sequencer L2s that would be beneficial in cross border payments. This is because based rollups are sequenced by Ethereum Mainnet validators and therefore inherit Ethereum’s liveliness. Decentralized sequencers will likely have smaller sequencer sets and transactions could therefore be more prone to delays from censorship.

L2s that don’t immediately follow MegaETH’s path will likely end up in a middle-ground state between not being the most decentralized (Mainnet & Based Rollups) or the most performant (MegaETH). Given that most users will likely either prefer high performance and usability or high decentralization and security, the market for applications in this decentralized sequencer L2 middle ground (that don’t fully deliver on either high security or high performance) appears limited.

Measuring Success

MegaETH's success will hinge on its ability to enable new and compelling zero-to-one applications that leverage its high throughput and unique 1ms block times - unlocking possibilities previously thought impossible on traditional blockchains.

To build these applications, MegaETH has been collaborating with founders through its Mega Mafia program, which includes global gatherings, isolated offsites, and co-building sessions with core team advisors. While many teams are actively building (and likely many more in stealth), only time will reveal whether the revolutionary potential of these applications can meet expectations.

The community's early enthusiasm is evident, as MegaLabs raised $10 million in under three minutes on Echo – the community investor platform founded by Cobie – from over 3,400 investors across 90 countries.

Moreover, the future launch of other high-performance L2s like RISE Chain, Atlas, and Heiko will further validate this report’s thesis. Comparing MegaETH's activity against existing L2s like Optimism and Arbitrum, which offer low fees and fast execution (though not on MegaETH’s scale), will be crucial. Ultimately, the market's demand for significantly lower block times and fees, beyond what most L2s already provide, will determine the future direction of the L2 space.

Closing Thoughts

MegaETH’s endgame blockchain architecture will allow it to theoretically produce the most performant, lowest latency chain on the market, making it the best infrastructure for many applications to develop on. Because MegaETH could provide the best platform for applications in gaming, DeFi, DePIN, and more to satisfy their users' wants in the quickest way possible, it has the potential to capture a significant amount of market share. Before a clear winner emerges on the performance side of the spectrum, the plethora of over 100+ L2s will need to make a choice: aim to compete with MegaETH now or find a new niche in the middle ground.

                                                       _____________________

Key Insights

• Fewer than 30% of participants in DAOs, with between 1,000 and 10,000 members, engage in the governance process regularly. Low voting participation combined with a high supply of tokens on markets exposes DAOs to governance attacks, where bad actors can easily buy tokens to push malicious proposals.

• Limited token value accrual and misaligned delegate incentives can prevent strong project fundamentals from translating into higher token prices. Lower prices, in turn, cause community members and delegates to stop caring, which makes DAOs more susceptible to governance attacks.

• When token prices are high, token holders tend to lock their assets in DeFi to earn yield rather than to vote on proposals. Restaked governance tokens have grown 978.2% YTD and pose an existential threat to DAO security.

• The Tally Protocol offers a solution to the conflict between governance and token utility. By introducing Liquid Staking Tokens (LSTs), the protocol allows token holders to earn yield while maintaining or delegating their voting power, improving DAO security.

Introduction

On July 28th, 2024, after two failed attempts, an unknown group going by Humpy, also known as the “Golden Boys,” narrowly pushed through Proposal 289 to the Compound DAO. The proposal, which appeared harmless at first, proposed to transfer 5% of Compound’s treasury, or 499,000 COMP tokens, to goldCOMP, a yield-bearing vault. The catch, however, was that the funds would be stored in a vault controlled by the Golden Boys instead of the DAO, leading many to accuse the group of engineering a governance attack against Compound DAO.

Governance attacks can occur when an entity amasses sufficient voting power in a DAO with low voter participation in order to push through proposals that favor their own interests over those of the DAO. In the case of Compound DAO, the passage of Proposal 289, with over 682,191 votes in favor and 633,636 against, led the Compound Delegates and the Alpha Growth team (Compound DAO’s outsourced BD team) to step in. The Alpha Growth team published a governance post to implement a similar staking instrument, created and managed by Compound DAO, as opposed to the Golden Boys, in return for the Golden Boys to cancel proposal 289. Additionally, if the Golden Boys didn’t cancel their proposal, Compound Delegates threatened to move forward with Proposal 290, which, if passed, would allow for voting power to be removed from the wallet that authorized Proposal 289.

Fortunately for Compound DAO, the Golden Boys decided to cancel Proposal 289 and accept Alpha Growth’s staking idea. However, governance attacks are not going away. In fact, the current dynamics of governance tokens worsen the problem, weaken DAO security and make DAOs more susceptible to these types of attacks.

Why Do Governance Attacks Happen?

To prevent governance attacks, DAOs must first understand the key contributing factors. These attacks are possible because many projects have:

1. A high supply of tokens on exchanges and DeFi markets

2. Low participation & low concentration of voting power among active delegates

High Supply of Tokens on the Market

In today’s most popular DAOs - such as Arbitrum, Optimism, and Uniswap - creating and voting on proposals requires that token holders either delegate to themselves (self-delegate) or delegate to another member of the DAO. When a token holder sells their tokens or locks their tokens in a DeFi application (e.g., DEXs) their delegation is automatically undelegated, which results in a reduction of voting power for the protocol.

For Arbitrum, Optimism, and Uniswap, the percentage of total token supply listed on CEXs and DeFi is 10.9%, 7.7%, and 10.2%, respectively, as shown in the graphic below. These tokens are not currently being used in governance, but because they are readily available for purchase, they can be acquired by bad actors to be used in governance.

For these same DAOs, the quorum threshold for a proposal to pass is only 1.8%(1)$$,$$ 0.6%, and 4.0% of the total token supply, respectively. For Arbitrum, Optimism, and Uniswap, the tokens available for a bad actor to buy on CEXs and DeFi are 6.2 times, 13.6 times, and 2.5 times the needed quorum to pass a proposal, as shown in the graphic below.

1: Quorum for Constitutional AIPs; Quorum increases as the number of tokens delegated to the “exclude address” decreases. The largest holder delegating to the “exclude address” is the Arbitrum DAO treasury.

In the case of Compound DAO, over 36.9% of the total token supply was locked on CEXs (22.0%) and DeFi markets (15.0%) while only 3.99% of the total token supply was required to meet quorum, a 9.3 times difference.

Low Participation

Low quorum requirements wouldn’t be an issue if DAOs had many active community members who could easily block governance attacks. However, this is not true today. According to a study by two academics at the University of Complutense of Madrid, fewer than 30% of participants in DAOs, between 1,000 and 10,000 members, engage in the governance process regularly. To pass proposal 289, Humpy had acquired around 680K COMP tokens (~$32 million) to meet the 400K COMP (~$19 million) quorum requirement and overcome dissent from other delegates.

Low quorum requirements are often indicative of the average participation needed for normal, good-faith delegates to successfully pass legitimate proposals. For Arbitrum, Optimism, and Uniswap, over the past 10 proposals as of October 25th, 2024, the total votes on those proposals on average were 149.8%, 164.4%, and 118.8% of the quorum requirement. This poses a major security risk as bad actors could acquire tokens from large CEX and DeFi markets to easily meet low quorum requirements and overcome low voting participation to push through malicious proposals.

For example, the Arbitrum DAO has accumulated ~$29.4 million worth of ETH in surplus fees from Arbitrum One and Nova. While the number of total votes has remained relatively constant, the ratio of votes to circulating supply has decreased by 40.6%. If voter participation does not keep up with the increased circulating supply, and the treasury accumulates more ETH, its growing value could attract malicious actors. This may make it profitable for them to acquire a significant amount of ARB tokens from open markets and enable an attack on the DAO.

Even for well-established DAOs with strong fundamental growth in TVL, users, and partnerships, reaching low quorum requirements still remains a struggle. One would expect strong project fundamentals would drive up the governance token's price, which in turn would lead to greater enthusiasm and member participation, making the DAO more secure and resistant to governance attacks. However, these expected links between project fundamentals and token price, and token price and participation do not hold true in reality.

Why Fundamentals Don’t Always Raise Prices

Though the crypto market is highly narrative-driven, one would expect strong project fundamentals should eventually lead to higher token prices, as seen in TradFi. However, several factors can disrupt this alignment, with one of the most obvious being supply unlocks. These unlocks create consistent sell pressure, which can stifle price growth despite positive fundamentals.

However, the disconnect can still persist for governance tokens that are fully diluted because of two reasons:

1. Limited Token Value Accrual

2. Misaligned Delegate Incentives

Limited Token Value Accrual

Governance power by itself has generally been a poor way to accrue value to tokens. On February 23, 2024, the price of UNI spiked 53.8% from $7.4 to $11.3 over speculation from a Uniswap Foundation proposal that the fee switch would be turned on, showcasing the market’s demand for token value accrual through protocol revenue generation and revenue-sharing.

When governance tokens have little control over even turning on protocol revenue (and as such accrue little value from the underlying protocol), holders tend to stop caring and token prices are predestined to fall even if project fundamentals are strong. The average token holder no longer has an incentive to delegate and keep their tokens delegated to an active delegate. This discount for lack of control (DLOC) is a common downward price adjustment in TradFi, applied to valuations of minority stakes in businesses.

Misaligned Delegate Incentives

Today's DAO environment has evolved into a complex web of providers working together to service DAO operations. The role of researching and voting on tens to hundreds of proposals has become a full-time job, and is generally not feasible for the average token holder. As such, professional delegates such as L2Beat, GFX Labs, and StableLab are among a few organizations that have emerged to take on the full-time role.

While discussions around professional delegate incentives have become more common, many DAOs including Compound DAO have no delegate rewards program. Unpredictable incentives lead delegates to feel apathetic about investing resources into the DAO, causing many delegates with large delegations to become inactive in forums and voting. For Compound DAO, 13 of the top 30 delegates by voting power had not voted over the last 10 proposals as of October 25th, 2024.

Many other DAOs such as Uniswap or Arbitrum have delegate incentives but it is often tied to metrics such as voting record or forum activity as opposed to project fundamentals like DAO revenue. While this incentive structure increases DAO participation and delegate transparency, it creates misaligned incentives where delegate rewards are not tied to the performance of the protocol.

The lack of incentive to drive high ROI proposals may lead to excessive spending, where delegates might approve significant DAO treasury allocations for activities with low upside. While DAO spending is relatively minuscule compared to unlocks for many young DAOs, the lack of austerity and unchecked spending can still be damaging to the token price. When communities see large amounts of DAO spending, it can add gas to a burning fire and put further sell pressure on the token as DAO service providers and grant recipients sell their allocated tokens.

If a DAO has good fundamentals, it should have an increased ability to use its revenue to provide sustained incentives to professional delegates. This would keep professional delegates aligned with the success of the DAO and a higher token price. Consistent incentives would provide delegates with the funds to consistently research and support proposals that provide good returns to the DAO and therefore to themselves.

Why Higher Prices Don’t Always Enhance DAO Security

The Dichotomy of Governance Tokens

Even when token prices increase, low participation and weak DAO security can still be present. This is due to governance tokens serving as both:

• Voting Rights: Use your governance tokens to vote on proposals, protocol changes, or funding decisions without any expectation of rewards.

• Assets: Earn yield on one’s tokens by locking them in DeFi but forgo participation in governance.

When token prices increase, more users will opt to use their governance tokens as an asset within the DeFi ecosystem and compound their yield as opposed to voting.

Historically, yield could be earned on governance tokens in two ways: providing liquidity on DEXs or lending (which is limited to very few tokens). However, restaking has recently emerged as an alternative to earn yield on governance tokens. Restaking enables users to secure multiple networks or services by staking a single set of tokens, earning yield across each service secured. However, as more governance tokens are locked into restaking protocols to secure other networks, they become unavailable for securing their underlying DAO, threatening its security.

What is Restaking?

Restaking allows users to use their tokens to secure the main network (e.g., stake ETH, securing the Ethereum network), and additionally reuse those tokens to secure other networks/protocols (e.g., restake ETH to secure a data availability service such as EigenDA). The protocols and networks that rely on restaked security will pay out rewards for that security service allowing restakers to earn extra yield on their assets. However, stakers that re-delegate their tokens to protocol, and fail to perform services for the network or misbehave, such as providing incorrect price data to an oracle service, could be slashed.

Restaking protocols have accumulated ~$15.0 billion in TVL as of writing and grew over 978.2% YTD (till September 30, 2024). Currently, ETH and ETH Liquid Staking Tokens (LSTs) or Liquid Restaked Tokens (LRTs) dominate this TVL, making up over 93.7% of the total.

Eigenlayer, one of the first restaking protocols, launched in June 2023 holds about 80.8% of the TVL. However, during Q3 2024, Symbiotic, which allows for a broader variety of ERC-20 assets to be restaked (including governance tokens), compared to Eigenlayer (which primarily supported ETH), grew from 1.7% to 11.2% of restaked TVL quarter-over-quarter (QoQ).

The Growth of Governance Token Restaking

While restaked governance token TVL only makes up 0.8% of all restaked TVL, the number of governance tokens and dollar value of those governance tokens restaked has grown significantly. QoQ, TVL of governance tokens restaked has increased 40.1%, rising from $82.0 million to $114.9 million. This stands in contrast to the broader restaking market, which saw a decline in TVL of approximately 20.0% QoQ, dropping from $18.8 billion to $15.0 billion, largely due to a decrease in ETH price.

Of the $114.9 million of restaked governance tokens, 92.8% of all restaked governance token TVL was made up by:

• Filecoin’s FIL had $58.5 million restaked (50.9% share)

• Ethena’s ENA had $24.6 million restaked (21.39% share)

• Etherfi’s ETHFI had $23.6 million restaked (20.5% share)

At the beginning of Q3, only two tokens made up the entire TVL:

• Filecoin’s FIL had $61.1 million restaked (74.5% share)

• Ethena’s ENA had $20.9 million restaked (25.48% share)

As restaking protocols seek more capital, and governance token holders look for additional yield, restaked governance token TVL is expected to grow. DAOs that see an increasing governance token price are threatened by restaking protocols which will always offer users a higher yield than the underlying DAO. While DAOs provide inflationary rewards or revenue sharing, restaking protocols offer these returns plus additional yield from the networks they secure. As more governance tokens are locked in restaking, fewer remain available for DAO voting, increasing the risk of governance attacks and therefore reducing DAO security.

These challenges have undermined confidence in the effectiveness of current governance structures. The Tally Protocol plans to address these challenges.

The Tally Protocol

Background

While the Tally Protocol was announced in June 2024, Tally was founded in 2019 by Dennison Bertram and Rafael Solari and has since gained strong traction among DAOs. Tally (not the Tally Protocol) is a comprehensive frontend for running and operating onchain DAOs on Ethereum and other EVM chains. Over 500+ DAOs, including Arbitrum, Uniswap, AAVE and more use Tally to create and vote on onchain proposals, elect members to Security Councils, and in some cases, execute the movement of treasury funds. The governance tokens on Tally collectively have a market cap of over $30 billion. As a key player in DAO governance, the Tally team is well-suited to solve these aforementioned problems.

Tally Protocol Introduction

The Tally Protocol is a smart contract layer for creating Liquid Staked Tokens (LSTs) for governance tokens. Governance token holders can deposit their tokens into the Tally Protocol in exchange for the equivalent stLST (e.g., ARB to stARB). stLSTs holders are able to vote on underlying DAO proposals as they normally would through the Tally interface.

The protocol aims to fix the links between project fundamentals and DAO security by solving the following problems:

• Limited Token Value Accrual -> Staking Rewards: By staking a governance token, one accrues a portion of DAO revenues in the form of auto-compounding yield.

• Misaligned Delegate Incentives -> Built-in Delegate Rewards: Active delegates receive a portion of staking rewards giving them a predictable income stream tied to project fundamentals.

• Governance Token Dichotomy -> Undelegated Voting Power Redistribution: stLST voting power that is not delegated (such as where stLST tokens are locked on a CEX or in DeFi to earn extra yield) is redistributed back to active delegates.

When a project’s fundamentals increase, its token price should increase as a result of increased Staking Rewards and increased Delegate Rewards. This increase in price will drive users to compound their yield. To do this, users will stake their governance tokens (stLSTs) for rewards and use their stLSTs in DeFi. stLSTs will then Redistribute Undelegated Voting Power locked in DeFi to active delegates, further securing the DAO against governance attacks, as shown below.

Tally Protocol for Arbitrum DAO

On August 20, 2024, Frisson from the Tally team posted the proposal: “ARB Staking: Unlock ARB Utility and Align Governance”. The proposal outlined a plan for implementing ARB staking through the Tally Protocol, to increase the token’s utility and the DAO’s security. The proposal passed with overwhelming support (134.5 million ARB in favor and 4.51 million against) and funds for smart contract development were distributed to the Tally team.

Features of stLSTs & stARB

Staking Rewards

stLSTs are liquid, auto-compounding ERC-20 tokens that accrue value in the underlying governance token, with the stLST to governance token ratio increasing over time as rewards compound. The claiming of underlying DAO rewards/revenue and compounding of those rewards/revenue into the staked position is called “Rebalancing”. The Tally DAO sets a fee to cover the gas cost of rebalancing. The Tally Protocol is also compatible with future staking designs. Additionally, there may be a withdrawal period to prevent users from immediately staking before a reward, claiming a part of the reward, and immediately unstaking.

stARB follows many of these same properties. It is a liquid, auto-compounding ERC-20 token. However, to receive rewards, stARB holders must delegate their voting power to an “Active Delegate” as defined by their Karma Score (a measure of a delegate’s offchain voting record, onchain voting record, and forum activity) or choose not to delegate their tokens to anyone (undelegated) where the DAO will allocate their voting power to “Active Delegates”. By incentivizing delegation to active delegates, voting power can stay concentrated among active delegates who will more quickly respond to governance attacks. It should be noted that Arbitrum has not turned on any staking rewards as of the time of this writing. However, new working groups around staking and delegation implementation have formed.

Built-In Delegate Rewards

The Tally Protocol can take a percent of DAO rewards/revenue distributed for each stLST as a “fee”. This fee could be distributed among active delegates in the underlying DAO proportional to the underlying governance tokens delegated to them. The percent of total DAO rewards/revenue paid to delegates is determined by the Tally DAO, but is capped by the Tally Protocol to ensure the majority of rewards/revenue goes to stLST holders. The underlying DAO can also add additional incentives to reward good delegates. This will allow professional delegates to build businesses with a consistent income stream that is linked to their performance (DAO rewards/revenue and voting power delegated to them).

The delegate incentives component for ARB Staking has yet to be determined.

Undelegated Voting Power Redistribution

If a stLST holder decides not to delegate their voting power to anyone (undelegated), that voting power goes back to the underlying DAO for redistribution to active delegates. Tokens that are locked on CEXs, DeFi, or restaking protocols that do not implement a Flexible Voting Client will have their voting power returned to the DAO. The Tally Protocol can provide a default strategy to redistribute voting power to trusted delegates but this can always be overridden by the underlying DAO. This enables DeFi / restaking protocols to be compatible with DAO security. As more stLSTs are locked in restaking protocols, more voting power will be redistributed to active delegates.

Arbitrum will establish its own default redistribution strategy for undelegated stARB to active delegates. If stARB tokens locked DeFi / restaking protocols are undelegated, users could still earn the underlying DAO rewards/revenue because their voting power will be redistributed to active delegates by the DAO.

Closing Thoughts

Overall, the Tally Protocol offers a promising solution to the ongoing security challenges faced by DAOs. By creating stLSTs, such as stARB for Arbitrum, the Tally Protocol can implement three key features that solve the problems associated with low DAO security:

• Staking Rewards: stLSTs return value to token holders by receiving and compounding yield from DAO rewards/revenue.

• Built-in Delegate Rewards: Active delegates are awarded a share of DAO rewards/revenue paid out, providing them with a consistent income stream tied to performance.

• Undelegated Voting Power Redistribution: stLST voting power that remains undelegated, such as when stLST tokens are locked on CEXs or in DeFi, is redistributed to active delegates.

All these solutions together help to increase the voting power delegated to active delegates and better align the incentives of those actors who contribute to the DAO. This, in turn, creates more robust security for the DAO and decreases the chance of a successful governance attack.