A New Chapter in Aleph Zero’s Decentralization Journey

TL;DR:

• Aleph Zero is transitioning to a community-led governance model through a Swiss Association that serves as a legal framework for a DAO.
• The Foundation will be winding down, and the remaining assets after settling outstanding liabilities will be transferred to the new Association.
• AZERO sales have been and are currently limited moving forward as the largest costs have been cut.
• We are searching for a new developer team to continue building Aleph Zero’s core technologies. There are several options, and we are evaluating all of them.
• Cardinal Cryptography is still supporting the transition and handover over the technology stack.
• The Aleph Zero L2 will be sunset. 
• Strategic technology upgrades are planned, including support for ink!6 which requires smart contracts deployed on-chain to be compiled to RISC-V bytecode.
• We are exploring advanced bridge integrations using ZKBridge and BitVM.
• A native limit order book DEX and privacy pool are long-term goals.
• Community involvement is central. We invite participation in governance, growth, and future planning.

The Path to a Decentralized Autonomous Association

Aleph Zero is entering a new phase in its decentralization journey. As part of this transition, we are introducing a governance structure designed to support community involvement, operational clarity, and long-term sustainability.

We plan to establish a Swiss Association to serve as the legal wrapper for the DAO. This provides a bridge between the on-chain DAO and the offchain world, allowing us to engage with exchanges, service providers, legal entities, and handle responsibilities like contract execution and fiat payments. After meeting existing liabilities, the Foundation’s remaining assets will be transferred to this Association.

The Swiss Association will manage certain on-chain and off-chain assets and other obligations. Its structure consists of three components: Members (or Assembly), a Board of Directors (elected by Members), and the Body. The Board manages operations: holding IP, hiring service providers or employees, and entering into contracts. The Body will eventually oversee the approval of on-chain fund disbursements through governance voting. Over time, the Body’s authority can be expanded.

To balance the community’s voice with effective execution, we propose a model in which the Body—through governance votes—approves fund usage of certain on-chain assets. This could include grants to ecosystem projects or annual operating budgets for the Board. This gives the Board a clear mandate while avoiding the inefficiencies of constant referenda.

We’re also exploring a Community Council. Token holders would elect a small group of representatives to advise or act on the broader community’s behalf. This group would hold a non-voting board seat and act in a supervisory role.

This structure is a meaningful step toward fully open, community-driven governance, and the result of on-going discussions as a light-weight alternative to the Swiss Foundation model. Some of the nuanced details may change as we continue to consult with counsel on how best to structure the new association. In the meantime, we encourage everyone to join the ongoing conversation: https://t.me/alephzerodao. 

Development

With Cardinal Cryptography stepping away as the primary chain maintainer, we are seeking new developers. Fortunately, many of the building blocks we need have already been developed by the open-source community, which reduces strain and enables faster progress.

The current codebase does not require significant development, except for an upgrade to the latest version of ink!, which will bring major improvements in smart contract speed.

Sunsetting of the Aleph Zero L2

After considerable analysis and due to the timetables involved with external parties, we have made the determination that it is in the best interest to sunset Aleph Zero’s EVM compatible L2.  Sunsetting the L2 eliminates unnecessary maintenance fees and ongoing costs.

We will communicate the process and deadlines for bridging assets away from the L2 at a later time and will be in constant communication with developers and other external parties who are currently using the L2 to discuss their future options to integrate with the L1.  The next section details how these existing apps or integrations may be repurposed at a later point in time.   

RISC-V Support & ink!6 Upgrade

While the Aleph Zero blockchain will no longer be EVM compatible with the sunsetting of the L2 a fundamental upgrade to support RISC-V smart contracts will be underway on the L1.  

RISC-V is an open-source instruction set architecture that allows any chip manufacturer to use its design in the production of chips without the need to pay any royalties or licensing fees.  It is used in IoT devices, embedded systems, microcontrollers, etc. RISC stands for Reduced Instruction Set Computer and V denotes the fifth generation of the standard. 

Recently, RISC-V has been proposed (Long-term L1 execution layer proposal: replace the EVM with RISC-V) as a replacement for the Ethereum Virtual Machine (EVM) to improve the execution environment, as this is currently the primary bottleneck. Additionally, gas costs for verifying ZK-SNARKs or ZK-STARKs, which are way more expensive in the EVM, would be significantly reduced, which is paramount as ZK-SNARKs and ZK-STARKs are essential to the current long-term scaling solution of Ethereum.

Fortunately, RISC-V has already been considered within the PolkaDot ecosystem since as early as 2023 (Announcing PolkaVM) and support for RISC-V has replaced WebAssembly in the latest version of ink! (Project State in Q1/25). Furthermore, the article Why RISC-V and PolkaVM for Smart Contracts? provides some more reasons as to why one should use RISC-V over WebAssembly (WASM).

We intend to support ink!6 as soon as reasonably possible by including pallets-revive to the main codebase.

While not immediately available, one major advantage are the proposed plans to allow for solidity (the main contract language for EVM) and Yul (a lower level language for the EVM) to compile source code into RISC-V bytecode. This will enable continued access to the largest developer community in the blockchain space. 

Bridges, Bridges, and More Bridges

There are two types of bridges that we see as necessary for Aleph Zero.

1. A two-way bridge that allows users to bridge assets between two independent chains that both have probabilistic 1 finality.
2. A one-way bridge that allows users to bridge Nakamoto-consensus (i.e. longest chain rule) assets to Aleph Zero and then bridging those same assets back, but not bridging Aleph Zero assets to a Nakamoto-consensus chain.

Two-Way Cross-Chain Bridges Using Zero-Knowledge Proofs

Moving assets between two independent chains from chain A to chain B requires some type of proof regarding the state of Chain A that can be verified by Chain B. The primary challenge that has previously existed is that any ZK proof that verifies a large number of digital signatures has an underlying circuit (the mathematical terminology used to define how a proof is generated) that is very large and costly.  We propose to utilize a protocol pioneered by Polyhedra Network known as ZKBridge (zkBridge: Trustless Cross-chain Bridges Made Practical) that is universal in its design to connect two arbitrary chains.

The ZKBridge framework consists of two components: 1) a relayer network that fetches block headers from the source chain, generates proofs authenticating the headers, and transmits the headers and proofs to the receiving chain’s updater contract and 2) an updater contract on the receiving chain that maintains a light client of the source chain by verifying proofs associated to the block headers and incorporating the verified headers to keep the source chain’s status up-to-date.  In order to maintain a two-way bridge, the above needs to be replicated on both chains. 

One clear advantage of ZKBridge is that only one node in the relayer network is required to be honest, as opposed to a majority or supermajority of nodes in other cross-chain bridge designs.  This greatly increases the security of the bridge because essentially any user bridging his or her assets could be the one honest party in the relayer network that verifies the proof, thus eliminating the trust assumptions of an external party. For practical reasons, not every user would participate in the relayer network, but the possibility exists.

Essentially, the first component constructs a state proof of the source chain and sends this proof to the receiving chain, which then verifies it. However, constructing a state proof for Ethereum using full nodes (and not just the sync committee) requires generating proofs for more than 20000 digital signatures. Each circuit for proving a digital signature contains more than 2 million gates! Not only is the time to generate a proof impractical for most bridge applications, but the cost to verify this proof on-chain is astronomical in terms of gas cost.

Instead, the innovation behind ZKBridge is in generating an off-chain proof that takes advantage of the fact that you have a bunch of digital signatures and hashes, parallelizes each of these into separate proofs, and then combines these proofs into a new Groth16 zk-SNARK proof that is much smaller in its proof size and way cheaper to compute and verify on chain.

Our development goals should be simple and leverage existing open-source technology instead of creating our own.  New research endeavors can be cast aside so we don’t have to sink resources into improving the ‘state of the art.’ 

Upon initial inspection, we believe that Polyhedra Network’s Expander product (Expander, an open-source GKR prover) will allow us to begin our implementation of ZKBridge to Ethereum and other chains. Note that the team behind Polyhedra Network are the same researchers who wrote the initial ZKBridge paper.

We will be evaluating Expander as an option to achieve this goal in the foreseeable future.

One important note is that Expander was released 3 days after the initial announcement of Aleph Zero’s Most Bridge.  This means that the technology to implement a trust-minimized cross-chain bridge using the ZKBridge protocol had not been released during the time the Cardinal Cryptography team researched practical design solutions for Most.

BitVM Bridge 

BitVM was originally proposed in December 2023 (bitvm.pdf) to show that there exists a means to achieve Turing-complete smart contracts on Bitcoin using fraud proofs to verify the execution of an arbitrary program.  While the initial BitVM design is computationally intensive and the practical uses of it are rather limited, two new versions (one as recently as 15 June 2025 or at least this is the date based on an X post announcing the new version and an earlier version detailing a bridge solution in October 2024) have been recently proposed that have improved on the original scheme. These two improvements offer pragmatic solutions, particularly to the use case of pegging bitcoin in and out of a side chain or another L1 chain (which is precisely the application Aleph Zero wants to adopt).

BitVM2 bridges are already deployed on the BitLayer L2; similarly, Starknet is planning to deploy a Bitcoin bridge using the BitVM protocol on garden.finance in the near future.

While Bitcoin scripts exist for the peg-out functionality, the only existing software for redeeming BTC natively on the Bitcoin network is written in Solidity.

We would need to find developers who would implement the smart contracts in ink! for redemptions to work.

Once a Bitcoin bridge is complete, other chains which use the bitcoin-core library, such as Litecoin, Dogecoin, DASH, VIA, VTC, PIVX, etc., would also have the ability to have their native assets be bridged to Aleph Zero.

Decentralized Limit Order Book

While AMMs have dominated DeFi, we propose building a native limit order book exchange on Aleph Zero. This model improves throughput, eliminates slippage, and provides a familiar trading experience for institutions and users alike. 

Limit order books also open the door for privacy-preserving pools using differential privacy.

Community-Led Growth

Aleph Zero’s future depends on the strength of its community. We will revamp our ambassador program and support independent, community-led initiatives—marketing, events, X Spaces, and more. Further details to follow.

None of this would be possible without you, our community. We understand that trust takes time to rebuild. But together, we can decide where Aleph Zero goes from here.

With gratitude, 

The Aleph Zero Foundation