This release delivers a high-performance, low-latency sequencer, support for multiple VM configurations (including full EVM equivalence), and integration with Airbender, the world’s most performant open source RISC-V proof system, for one-second finality with ZK proofs.

Global markets are moving onchain

Increasingly, businesses, institutions, and nations are embracing blockchains as a significant component of their financial infrastructure. Just this year we have seen:

• Regulatory clarity is unlocking payment use cases. With clearer rulesets arriving in major markets (such as the GENIUS Act in the US) and improved banking connectivity, we’re seeing significant momentum for payments and stablecoins.

• Major growth in onchain RWAs. rwa.xyz is tracking >$30B in tokenized real-world assets on public chains (excluding stablecoins), with sustained month-over-month growth across issuers and holders. Tradable has facilitated 38 private credit deals on ZKsync representing an active loan book of $2.1B.

• Tokenized funds at scale. BlackRock’s tokenized U.S. Treasury fund (BUIDL) crossed $1B AUM on Ethereum in March 2025.

• Institutional private chains on Ethereum. Deutsche Bank is working with Memento on tokenized asset infrastructure - an example of regulated, privacy-preserving domains that still anchor to public liquidity.

• Mainstream fintechs are moving onchain. Robinhood and Stripe have both recently announced plans to launch their own blockchains as they look to add support for tokenization and stablecoins

We believe this trajectory will continue, and that we’re heading towards a world in which business and institutions routinely participate in the digital asset economy via systems they control, deployed as part of their internal infrastructure. These systems will be configured differently to support specific use-cases, but will still need to integrate across a single network, able to exchange value with cryptographic guarantees of correctness.

ZKsync, and the ZK Stack, are designed for this future. ZKsync connects public and private chains into one cryptographically secure network, made incorruptible by ZK, and connected to the billions in onchain liquidity via Ethereum. The ZK Stack is a toolkit for deploying these high performance chains, providing builders with control over options related to privacy, economics, and access.

The ZK Stack’s Atlas upgrade

The Atlas upgrade going live is the culmination of several major projects by the ZKsync team.

A high-performance sequencer, capable of >15K TPS

Firstly, we are introducing a new transaction sequencer, designed from the ground up around three dimensions: improving throughput (including resilience to traffic bursts), reducing latency (for rapid tx inclusion), and system simplicity.

Some of the most impactful decisions included:

• We stripped all unnecessary functionality out of the sequencer, with a specific focus on minimizing synchronous persistence. The sequencer does not know about batches or L1, and is supported instead by separate asynchronous components.

• We enforced strong separation between aspects of the system’s state. This included the state needed to execute the VM, the state required by the APIs, and the state required to generate the ZK proof or to verify it on L1, reducing unnecessary overhead on components.

• We made it easy to replay blocks. The sequencer is fully idempotent, and other components have been optimized to reduce unnecessary computational work. This allows for a more resilient system with better developer experience.

The first results are already very exciting!

Before we get into the numbers, it is important to remember that transactions per second (TPS) is a flawed metric for profiling these systems; the computational resources required to execute a transaction vary depending on what it is doing. Gas/second has been proposed as a better metric, but for some systems this has a similar issue. The EVM’s gas prices are intended to directly price the computational work of Ethereum, but this strong coupling isn’t preserved when you also prove the transaction.

To help contextualize the sequencer capabilities we developed several demonstration scenarios, keeping in mind the limitations just described.

1. High frequency price updates. First, we model the situation in which a team wants to bring high frequency price feeds onchain, deploying an oracle contract and testing with generated traffic.

   In this scenario the system was able to sustain ~23K TPS, corresponding to ~0.66 gigagas per second, and an average tx inclusion time of 250ms.

2. Stablecoin transfers. Next, we model a payments focused system in which 50,000 simulated users are transacting between each other via ERC20 token transfers.

   In this scenario we saw a sustained performance of ~15K TPS, corresponding to ~0.5 gigagas per second, and an average tx inclusion time of 500ms.

3. ETH transfers. Finally, we tested the system with native ETH transfers, again with a pool of simulated users. In the other experiments we used a blocktime of 100ms, but here tested raising this to 500ms.

   This is where we saw the most significant performance, with the system processing ~43K TPS, corresponding to ~0.9 gigagas per second, and an average tx inclusion time of 450ms.

We’re excited to share these early numbers, and while we have designed this sequencer for performance and are excited by the early results, it is nowhere near optimized and many more improvements will be made as the system matures.

Unleashing Airbender: one-second block proofs and $0.0001/transfer

With this upgrade, we’re delighted to see Airbender stepping into the spotlight. Airbender, introduced in an earlier blog post, is the world’s fastest open-source RISC-V zkVM.

As a reminder, it offers:

• Fast proofs → fast finality: Airbender provides one-second block proofs and minutes-to-Ethereum finality.

• General-purpose: Airbender can prove any program that compiles to RISC-V.

• Best-in-class hardware utilization: Airbender is an incredibly efficient system, requiring a substantially smaller hardware footprint than competitor systems.

Efficient, near-real time ZK proofs are a breakthrough technology, enabling functionality that simply cannot be supported without it.

• Applications such as onchain order books, perps, exchanges, and AMMs depend on fast finality to reduce risk. Airbender allows systems to verify and settle extremely quickly.

• Public and private systems (such as ZKsync’s Prividiums) can interoperate without requiring third parties, as fast ZK proof generation allows for a network supporting near real time incorruptible connectivity. It will be possible to send assets of any size, anywhere in the network, in one second.

• Tokenized securities and FX trades cannot wait minutes or hours to finalize. Airbender will shorten settlement cycles and allow teams to meet compliance-driven SLAs.

One-second ZK finality

Airbender provides a critical property: one-second ZK finality.

At the network edge, blocks from ZK Stack chains are proved in ~1s and verified by the ZKsync Gateway (the coordination layer). Counterparties get cryptographic assurance of execution almost immediately, and the proofs are then settled to Ethereum within minutes for full L1 finality.

This is a fundamental change to how systems can integrate. In a world of many chains, the naïve way to trust another chain is to re-execute it yourself, meaning running full nodes on often powerful hardware for every system you connect to. That is prohibitively expensive and incompatible with privacy (you can’t re-execute what you can’t see inside a Prividium).

Proofs, not intermediaries, carry trust across domains. With one-second proofs, you don’t re-execute, you verify. Anyone (chain operators, exchanges, even a user’s mobile device) can quickly verify a succinct proof and act with confidence. This is also how private chains can keep user data private while still composing with public liquidity, revealing only the ZK proof of correctness.

The combination of a sequencer providing low latency tx inclusion, Airbender generating a proof within a second, and then Gateway verifying and coordinating cross-chain messages, is how this architecture is able to realize the vision of a world transacting onchain.

Native EVM support via a more flexible system architecture

Additionally, the Atlas upgrade brings significant improvements to how ZK Stack chains will operate. We have redesigned the system-level component that is responsible for executing transactions and managing the state. This component is implemented as a Rust program and is compiled to both the x86 and RISC-V instruction sets. x86 is used for running the sequencer and RISC-V is fed to Airbender, and used to compute the ZK proof attesting to the correctness of the system.

This design has several compelling properties, which serve as the foundation for the entire upgrade:

• One program, two targets. Compiling the same code to x86 for the sequencer and to RISC-V for proving means what you execute is what you prove, reducing the systemic risk and audit surface relative to previous proof system designs.

• Multi-VM by design: any VM that compiles to RISC-V can be proven by the same pipeline, allowing for more optionality for chain builders. The EVM is first, and native support is already live. Support for other execution environments, such as the EraVM and WASM, can be added later.

• Improved performance: proving an ERC20 transfer will cost ~$0.0001, with significant improvement in the throughput that can be supported by the sequencer.

Mainnets incoming

In our 2025 Roadmap, we committed to bytecode-level EVM equivalence and performance at industry scale. This upgrade advances those dimensions significantly, and further expands the toolkit available to ZK Stack builders. The first teams to be taking advantage of the Atlas upgrade already have testnets live, and we expect many other chains to follow in the coming weeks, on both testnet and mainnet.

High performance systems alone will not bring the world onchain because the endgame isn’t one big chain. It’s many sovereign systems, connected as part of a secure network. We expect banks, enterprises, public agencies, hospitals etc will all operate their own blockchain infrastructure (private where required) and participate an incorruptible network, anchored to Ethereum’s security and liquidity.

This vision requires both:

• High-performance, reliable systems, for builders to develop the applications their users want.

• Real-time ZK proofs so those systems can settle and interoperate without trusted intermediaries.

Alone, neither is sufficient.

With the Atlas upgrade, blocks are included quickly and proved quickly, so chains can finalize to Ethereum on minute timescales while keeping user-visible latency near real-time. Payments will clear with card-like UX but cryptographic finality. Price feeds will arrive at the speed finance applications need, and settle deterministically

This upgrade is another major step forward for the ZK Stack, which is ready today as a platform for teams looking to issue and settle real-world assets, run global payments with near-instant settlement, and tap into billions in onchain liquidity via Ethereum.

Find out more on the ZK Stack page.

• Smaller binaries without losing gas efficiency. Contracts compiled with --via-ir are 13% smaller on median vs 0.1.1, and about 22% smaller than solc 0.8.30 –via-ir.

• More often under the 24 KB limit. If a contract would exceed the cap, solx 0.1.2 optimizes for size more aggressively to make a contract deployable (PR-854).

• Better code quality. The compiler now eliminates unused stores (heap, transient, or persistent storage) (PR-865) and generates more efficient conditional jumps (PR-870).

• Improved tooling support. Integration with Hardhat v3 is now smoother out of the box.

This post walks through the current results and explains the optimizations in detail.

Still Beta, But Better Than solc --via-ir in Every Non-Functional Metric

solx 0.1.2 remains in beta. It passes the full Solidity test suite, internal tests, and 24 real-world Hardhat/Foundry projects (e.g., Uniswap V4, Aave V3, Solady, Beefy, Lens). Code coverage is tracked; PRs that reduce it are not accepted.

QA is sufficient for development use — some teams already build with solx. Deploying non-mission-critical contracts is also viable today.

Raw benchmarking data is available in the solx 0.1.2 release PR. The subsections below provide a summary view and key highlights from that data.

Runtime Code Size

solx 0.1.2 reduces contract size across both the --via-ir and default pipelines. Like solc, it still uses the legacy pipeline by default.

The table below shows the relative runtime size improvements compared to solx 0.1.1 and solc 0.8.30 (negative values indicate smaller size, i.e., better).

Despite a clear median win, the odds that a specific contract ends up smaller still slightly favor solc --via-ir. The measurement includes all artifacts produced by a foundry build.

The data shows considerable variation in whether a given contract compiles smaller with solc or solx; however, when solx wins, the margin is typically larger. The table below samples real-world contracts to show you how it looks in practice.

Gas Efficiency

The average gas metric remained stable in solx 0.1.2: the gas-for-size tradeoffs were offset by other optimizations introduced in this release.

The table below compares solx 0.1.2 against solx 0.1.1 and solc 0.8.30, showing relative gas changes (negative values indicate reduced gas usage, i.e., better).

The table below also shows the likelihood that a given test consumes less gas with solx 0.1.2 compared to solx 0.1.1 and solc 0.8.30.

Compilation Time

solx 0.1.2 doesn’t introduce pipeline changes, so compilation time remains similar to solx 0.1.1.

The table below shows how long each test run takes on our CI hardware (in seconds), comparing against solc 0.8.30 (both default and --via-ir).

How It Works: Optimizations Behind the Gains

The earlier sections focused on what solx 0.1.2 achieved — smaller contracts, same or better gas usage. This section explains how we got there.

Three new optimizations made this possible:

• The Constant Unfolder now splits PUSHN into multiple instructions if it reduces total bytecode size by at least 2.5× and fits within 4 instructions. Once the 24 kB limit is hit, it unfolds for any size reduction — prioritizing code outside of loops first, then loops of nesting depth 1, then 2, and so on. This acts as a hot/cold code heuristic to preserve performance while keeping contracts deployable.

• The Dead Store Elimination pass can now remove not only overwritten stores to memory and storage, but also accounts for contract termination scenarios like return and revert. In solx 0.1.2, the common free heap pointer initialization (PUSH1 0x40 PUSH1 0x80 MSTORE) is eliminated from runtime code when unused (see example in Compiler Explorer). On the main branch, it's also removed from deployment code.

• The Peephole Optimizer now emits more efficient code for conditional jumps involving OR conditions.

Hardhat v3 Integration

Starting with Hardhat v3.0.5, it’s now much easier to use solx in Hardhat.

To get started, just specify the following in your hardhat.config.ts:

solidity: {
  profiles: {
    default: {
      version: "0.8.28",
      path: "./path/to/solx",
    },
  },
},

You can find a detailed guide in the Hardhat documentation.

solx 0.1.2 also resolves a key integration issue by producing all the artifacts required by Ethereum Developer Runtime (PR #133).

Next Steps: From Optimization to Functionality

Considering non-functional metrics alone, solx now leads across the board — except for default-pipeline compile time, where solc remains faster. We expect the upcoming MLIR pipeline to close this final gap (learn more about it in the X thread). With performance largely handled, our focus is shifting toward functional gaps — starting with debugging support, which is now our top priority.

If you’ve read this far, chances are you care about solx. If you haven’t already, join our Telegram group and tell us more about your use case. Your input helps us prioritize wisely — especially as we move beyond optimization and work to make solx a first-class development experience.

solx removes the error entirely while keeping your contract’s behavior bit-for-bit identical.

solx memory layout and current constraints

Solx extends solidity’s memory layout — similarly to solc --via-ir — by inserting a dedicated region for spills. This guarantees that spills never interfere with user memory:

The spill region is laid out at compile time: the frontend reserves it starting at the first safe offset (0x80), the backend calculates the exact size of this region, and the free memory pointer (0x40) is updated to point immediately after it. Because the region cannot grow at runtime and all heap allocations begin beyond its end, neither user code nor memory-safe inline assembly can touch a spill slot, and a spill write can never run past its bounds. Memory corruption is therefore impossible by design.

This deterministic layout comes with an intentional tradeoff: self-recursive and indirectly recursive functions are not supported. Supporting recursion would require allocating a fresh set of spill slots for each call, but solx deliberately avoids dynamic memory allocation for spills. As a result, recursive functions are explicitly rejected at compile time if they have “stack too deep” issues. Developers writing inline assembly should be careful. When spilling is required and a contract contains an assembly block without the memory-safe annotation, solx will produce an error like the following:

Error (5726): This contract cannot be compiled due to a combination of a memory-unsafe assembly block and a stack-too-deep error. The compiler can automatically fix the stack-too-deep error, but only in the absence of memory-unsafe assembly.
To successfully compile this contract, please check if this assembly block is memory-safe according to the requirements at 

    https://docs.soliditylang.org/en/latest/assembly.html#memory-safety

and then mark it with a memory-safe tag.
Alternatively, if you feel confident, you may suppress this error project-wide by setting the EVM_DISABLE_MEMORY_SAFE_ASM_CHECK environment variable:

    EVM_DISABLE_MEMORY_SAFE_ASM_CHECK=1 <your build command>

Please be aware of the memory corruption risks described at the link above!
  --> forge/test/strategy/CommonBaseTest.t.sol:25:9:
   |
25 |         assembly {
   |         ^ (Relevant source part starts here and spans across multiple lines).

If an assembly block is memory-safe, it must be explicitly annotated with "memory-safe" to inform the compiler that it can safely reserve space for the spill region and emit spills.

On the other hand, if an assembly block is not memory-safe but is incorrectly annotated as such, it can lead to incorrect and undefined behavior — since memory used for spills may be overwritten unexpectedly.

There are also a few important current limitations to keep in mind. First, the EVM imposes a hard limit of 1024 elements on the operand stack, but solx does not currently track this global stack depth during code generation. While this rarely poses a problem in typical contracts, it may become relevant in cases involving very deep nesting or aggressive inlining. If the limit is exceeded at runtime, execution will fail without prior compiler warnings.

Another limitation arises when functions have a large number of arguments or return values — typically more than 16. In such cases, “stack too deep” issues may occur during stackification. While solx can often recover by spilling intermediate values to memory, this is not guaranteed in all scenarios, particularly when values remain live across complex control flow.

solx memory spills vs solc --via-ir

Both solc --via-ir and solx aim to solve the same problem: fixing “stack too deep” issues in EVM by introducing memory spills. However, they approach this problem with very different strategies.

solc’s StackLimitEvader makes assumptions about potential stack pressure and rewrites code to preemptively store intermediate results in memory. These spills are generally safe but tend to be precautionary, and once a value is stored in memory, the slot is not reused, even if it’s no longer needed. In some cases, contracts may still fail with “stack too deep” errors, as seen in several reported issues on GitHub.

In contrast, solx inserts spills during stackification, but only when needed. Memory slots are reused based on LLVM’s internal analysis, which considers liveness information. This reuse is not the result of custom logic in solx, but a natural benefit of LLVM’s infrastructure. solx pays more at compile time to produce more efficient and compact runtime code — an intentional tradeoff. Rather than assuming stack pressure might occur, it emits spills only when they are truly necessary.

Stack too deep resolvability table

This table illustrates the state of “stack too deep” solutions across different pipelines and codegens. We can see that thanks to additional IRs added on top of EVM assembly in the eponymous codegen, it becomes the most robust set of compiler settings without dangerous semantic changes that --via-ir could bring.

1. Only if the project was developed with viaIR, or migrated and has been tested later (total <20% of live projects).

2. Turning off the Yul optimizer from solx can alleviate the issue while keeping its library inlining intact.

   - It is coming in next releases of solx.

3. MLIR is a new codegen that will supersede EVM assembly and Yul in solx. It is still work-in-progress, but we’re going to share some interesting news soon.

From spills that just works to a production grade

When we began addressing “stack too deep” issues in solx this May, our expectations were modest. The immediate goal was pragmatic: unblock the largest real-world contracts that failed to compile in our early pre-alpha releases. The plan was simple — spill whatever caused “stack too deep” and prioritize correctness over performance. If a contract compiled, that was already a win, even if it meant some gas inefficiency. With just a few months of work, we didn’t anticipate significant improvements over solc on those same contracts. And even if we wanted to improve the implementation, LLVM seemed like an unlikely candidate for help. The EVM is a stack machine without registers, while LLVM was built for register-based architectures. Its register allocation infrastructure appeared irrelevant to a stack-based target.

Both expectations proved wrong. First, in the majority of real-world contracts we tested (around 2000 from production-grade projects), solx outperforms solc — even when spilling is required. Second, LLVM provides a solid foundation for building production-grade code generation — even for a stack-based architecture — allowing us to move quickly and iterate with minimal custom effort. What began as a simple implementation quickly evolved into a robust and efficient solution.

Choosing which register to spill

Spills are determined during stackification — the phase where code is lowered from an intermediate representation into the EVM’s bytecode. Registers that cannot be reached via DUP or SWAP are spilled to memory and later reloaded when needed. This process proceeds iteratively until all “stack too deep” issues are resolved.

In our initial implementation of register spilling, we selected a register that was unreachable via the DUP or SWAP instructions. While this approach ensured correctness, it resulted in a high number of spills. To improve on this, we used LLVM’s register weight heuristic, which estimates the cost of spilling each virtual register based on its usage frequency and live range:

let x := add(a, b)
let y := sub(c, d)
pop(init(y))             // first use of y

// Inside a loop
  ...
  let z := mul(x, e)     // first use of x
  ...

pop(final(x))            // second use of x
pop(done(y))             // second use of y

// Weights:
x: high - used in the loop
y: low  - used outside the loop

=> Heuristic prefers spilling y

At the point where a register becomes unreachable, the set of live registers from that register up to the top of the stack is examined, and the one with the lowest weight — the least expensive to spill — is selected. This change, combined with refining the heuristic to account for the number of uses of each register within the function, reduced the number of registers that needed to be spilled by an average of 65%. To enable this, we simply needed to hook into LLVM’s existing infrastructure, with a small customization to adjust for usage counts:

/// EVM-specific implementation of weight normalization.
class EVMVirtRegAuxInfo final : public VirtRegAuxInfo {
  float normalize(float UseDefFreq, unsigned Size, unsigned NumInstr) override {
    // All intervals have a spill weight that is mostly proportional to the
    // number of uses, with uses in loops having a bigger weight.
    return NumInstr * VirtRegAuxInfo::normalize(UseDefFreq, Size, 1);
  }

public:
  EVMVirtRegAuxInfo(MachineFunction &MF, LiveIntervals &LIS,
                    const VirtRegMap &VRM, const MachineLoopInfo &Loops,
                    const MachineBlockFrequencyInfo &MBFI)
      : VirtRegAuxInfo(MF, LIS, VRM, Loops, MBFI) {}
};

EVMVirtRegAuxInfo EVRAI(MF, LIS, VRM, *MLI, MBFI);
// Use LLVM's heuristic to assign weights to registers
EVRAI.calculateSpillWeightsAndHints();

Reducing spill memory

As the implementation matured, we introduced StackSlotColoring, a standard LLVM pass that reuses stack slots for variables whose lifetimes don’t overlap — meaning if two values are never alive at the same time, they can safely be assigned to the same memory location. Previously, each spill was assigned a dedicated slot, resulting in excessive memory usage. Enabling coloring, led to an average 25% reduction in allocated spill slots across multiple cases. Notably, this optimization was achieved with minimal effort by updating the analysis used by the pass and running that pass — demonstrating the advantages of leveraging LLVM’s infrastructure:

// Updating the analysis
StackSlot = VRM.assignVirt2StackSlot(Reg);
auto &StackInt =
    LSS.getOrCreateInterval(StackSlot, MF.getRegInfo().getRegClass(Reg));
StackInt.getNextValue(SlotIndex(), LSS.getVNInfoAllocator());
StackInt.MergeSegmentsInAsValue(LIS.getInterval(Reg),
                                StackInt.getValNumInfo(0));

// Running the pass
addPass(&StackSlotColoringID);

Small implementation, big infrastructure

To give you a sense of the implementation effort and code impact, the following output highlights the changes introduced by this feature in the solx EVM backend, how much code was reused and the implementation from solc. The solx implementation took approximately two months, while the original solc implementation required at least three and a half months, as indicated by this PR — possibly even longer.

Code changes introduced by the feature:
---------------------------------------------------------------------------------------
Language                   new files added          blank        comment           code
---------------------------------------------------------------------------------------
C++                                      2            100            116            495
C/C++ Header                             0              7             10             55
TableGen                                 0              1              0              3
CMake                                    0              0              0              2
---------------------------------------------------------------------------------------
SUM:                                     2            108            126            555
---------------------------------------------------------------------------------------

Reused LLVM code:
llvm/include/llvm/CodeGen/CalcSpillWeights.h
llvm/include/llvm/CodeGen/LiveIntervals.h
llvm/include/llvm/CodeGen/LiveStacks.h
llvm/include/llvm/CodeGen/MachineBlockFrequencyInfo.h
llvm/include/llvm/CodeGen/VirtRegMap.h
llvm/lib/CodeGen/CalcSpillWeights.cpp
llvm/lib/CodeGen/LiveIntervals.cpp
llvm/lib/CodeGen/LiveStacks.cpp
llvm/lib/CodeGen/MachineBlockFrequencyInfo.cpp
llvm/lib/CodeGen/StackSlotColoring.cpp
llvm/lib/CodeGen/VirtRegMap.cpp
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                              6            476            644           2650
C/C++ Header                     5            212            346            567
-------------------------------------------------------------------------------
SUM:                            11            688            990           3217
-------------------------------------------------------------------------------

solc:
libyul/optimiser/StackLimitEvader.cpp
libyul/optimiser/StackLimitEvader.h
libyul/optimiser/StackToMemoryMover.cpp
libyul/optimiser/StackToMemoryMover.h
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                              2             59             64            456
C/C++ Header                     2             24            179             85
-------------------------------------------------------------------------------
SUM:                             4             83            243            541
-------------------------------------------------------------------------------

Avoiding solc’s stack depth limits in legacy mode

One might assume we're simply relying on solc in legacy mode to compile contracts without running into “stack too deep” issues. But that’s not the full story. We’ve also modified solc itself to successfully produce EVM assembly by emitting extended stack manipulation instructions — specifically SWAPX and DUPX. These allow us to defer stack layout resolution to the LLVM backend, where the stackification and spill handling are performed in a controlled and optimized way.

If you have any thoughts, questions, or feedback — we’d love to hear it. You can reach us directly on Telegram. At the end of the day, we want solx to be useful to you. And if you haven’t tried it yet, head over to solx.zksync.io and get started in just a few clicks.

With that, we believe solx is ready for mainnet deployment of non-critical, well-tested contracts. We’re still raising the security bar, so please don’t rush into gas-saving migrations just yet.

solx ships two pipelines—default and --via-ir, the latter applying rewrites that can change semantics. solx leaves both untouched: solx (default) matches solc’s default semantics, and solx --via-ir mirrors solc --via-ir. If something looks off, double-check your Foundry or other configuration to ensure the expected pipeline is in use before filing a bug.

Stack-Too-Deep? Fixed — But Mind Inline Assembly

solx Beta eliminates the stack-too-deep error that has topped every Solidity-developer pain-point survey for years.

Like the solc --via-ir pipeline, solx resolves the issue by spilling selected stack values into a region of memory that starts right after 0x80 and is sized exactly to fit the spilled variables. The free-memory pointer (0x40) is then bumped so user-level allocations never collide with that region.

The approach carries the same inherent limits as --via-ir:

• The compiler can’t spill inside recursion because it must know the total spill size at compile time.

• Memory-unsafe inline assembly disables spilling for the entire contract.

Where solx differs is in how it achieves the fix: solx plugs the spilling logic into the default compiler pipeline, so no semantic changes are introduced. Your contract behaves exactly as it would under the legacy pipeline—just without the stack error.

Heads-up on inline assembly

• Whenever possible, prefer high-level Solidity; solx is steadily eroding the old performance edge of hand-rolled assembly.

• If you do need assembly, be honest: mark only truly safe blocks with assembly ("memory-safe") // preferred, future-proof or /// @solidity memory-safe-assembly // legacy form, kept only for old compilers. Mis-labelling unsafe code lets both your logic and the spill logic write to the same slots, silently corrupting data.

• In doubtful cases, skip the annotation and let the compiler disable spilling rather than risk undefined behavior.

We’ll publish an in-depth blog post on the algorithm later. For now remember: enjoy the automatic fix—just keep your assembly minimal, accurate, and genuinely memory-safe.

Runtime gas — widening lead

A proper benchmark that weights each function by real-world call frequency and uses representative inputs is still on the to-do list. For now we rely on raw forge test --gas-report data. Across 2 057 cases drawn from popular projects, solx consumes less gas than solc in 1 888 of them—about 92 %. The advantage ranges from small fractions of percent to double-digit cuts, depending on the code path. You can browse the full snapshot at https://matter-labs.github.io/solx/dashboard/. Pick any project from the drop-down to see a visual, test-by-test comparison of forge test --gas-report for solc vs. solx.

Recent compiler changes

• EVM constant folding (PR #835)

  add, mulmod, exp, signext, and byte now fold to literals when inputs are known at compile time, removing whole instruction sequences in the legacy pipeline.

• Sharper branch lowering (PR #817)

  solx now emits fewer instructions to set a JUMPI condition.

These wins were partly offset when we restored explicit local function calls and let LLVM decide what to inline (PR #1048). The refactor produced smaller byte-code and faster builds, but runtime gas ticked up slightly because LLVM’s default inliner is too cautious for the EVM cost model. We’re retuning those heuristics and expect to regain the lost gas efficiency.

Path forward

LLVM underpins both the default and --via-ir modes, so every EVM-specific optimization that lives only in --via-ircan migrate into the main LLVM path. Constant folding was the first step; more moves are underway, so the default pipeline will ultimately include all LLVM optimizations and every --via-ir improvement.

ERC-20 Gas Savings — Potential Network Impact

ERC-20 tokens (USDT, USDC, DAI, …) dominate Ethereum traffic, so we measured gas on the lean, audited Solady implementation. The same contract was compiled with solc 0.8.30 and with the current solx beta, then run through Foundry’s forge test --gas-report 200 times each (Solady’s harness injects randomness, so single runs are noisy). Average gas per call:

(Negative Δ means solx is cheaper.)

Why Solady?

It mirrors real-world ERC-20 patterns while staying easy to benchmark. Solady ships its own gas-benchmarking harness, making large-sample runs easy. OpenZeppelin’s implementation doesn’t include comparable tooling out of the box, so Solady was the quicker path; quick hand-written trials on OpenZeppelin actually showed larger gas cuts, making the table above a conservative lower bound on real-world savings.

Aggregating the savings — how much “-255 gas per transfer” is in dollars

Ethereum sees about 1.5 million main-net transactions a day, and roughly 60 % of them are simple ERC-20 transfers — close to 900 000 moves of tokens every 24 hours. Shaving 255 gas off each call with solx (-0.56 % versus solc) removes around 230 million gas daily. In the quieter 2025 market, where gas has hovered near 2.6 Gwei, that’s roughly 0.60 ETH saved every day — about $1 600, or $0.6 million a year at today’s $2 800/ETH. During 2024’s busier spell, with averages nearer 15 Gwei and frequent spikes, the same 230 million gas translated to about $10 000 per day, or $3–4 million over the year; slicing 0.56 % off the $2.48 billion users paid in 2024 fees would have left roughly $14 million in their wallets. Even if only half of new tokens adopted solx, annual network-wide savings would still run well into seven figures — without touching a single line of Solidity.

Please don’t rush critical contracts to mainnet.

solx already cuts gas and removes stack-too-deep, but we’re still hardening security. Treat these numbers as a preview of what full-scale adoption could unlock; test thoroughly before deploying anything mission-critical.

Code size — closing the gap

When we first spot-checked solx binaries earlier this year they were a little over 20 % larger than solc’s. In the current beta that overhead has fallen to about 6 %. The code-size dashboard (https://matter-labs.github.io/solx/codesize/0.1.0/) shows the details contract by contract; at this point only two default-pipeline builds —Aave’s StataTokenV2 and Beefy’s StrategyAuraGyroMainnet — still exceed Ethereum’s 24 576-byte limit.

Recent compiler changes

• Inlining shifted to LLVM. Already explained in the previous section.

• Large-constant unfolding (PR #833). The backend now emits shorter sequences for small negatives and other literals when the gas trade-off is minimal, avoiding full-width PUSH instructions.

The default pipeline remains gas-first — it adopts size tweaks only when they cost little or no runtime gas. For the few outlier contracts that still exceed the cap, we plan to offer an aggressive size-optimization fallback that prioritizes byte-code shrinkage over gas efficiency.

Compilation time — catching up

Right now the default solx pipeline still lags solc’s by a few-fold on wall-clock time, although it is already noticeably faster than solc --via-ir --optimize. We don’t have a public dashboard for this metric yet, but every pull request in the solx repo now gets a compile-time report from CI, so progress is tracked continuously.

Looking ahead, our MLIR pipeline is showing encouraging numbers: with LLVM optimizations enabled it compiles only a few‐tens-of-percent slower than solc with optimizations off. Once that pipeline is production-ready, we expect compilation speed to tighten further while keeping all current gas and size wins.

Why Trust a “New” Compiler? Because It Isn’t

Our May-2025 pre-alpha already cleared the Solidity compiler test-suite and real-world projects such as Uniswap V2 and Solmate. A detailed write-up (“Solx: The New Solidity Compiler — Why It Matters to You”) covers those results.

With the stack-too-deep issue resolved, we have widened our test pool. Every project below builds cleanly, and all unit tests pass on solx beta:

† Beefy note Inline assembly in Beefy lacks the memory-safe-assembly tag; adding it turns the suite green.

Totals: ≈ 2 000 contracts, ≈ 6 400 unit tests — all green.

That is far from all the testing we have run. While solx may look new, its core is not: the same LLVM fork has powered zksolc (Solidity) and zkvyper (Vyper) on ZKsync since 2021. The only delta is about 9 000 LoC in the EVM code generator. Across contracts deployed to ZKsync we have seen zero post-deployment miscompilations; the lone genuine LLVM issue—the AAVE miscompilation—was caught in testing and patched before release, plus five additional miscompilations introduced in our own ZKsync VM (EraVM) specific code; each was discovered during testing or bug-bounty report and is now fixed.

Today we believe solx is comparable at safety to solc --via-ir --optimize. The legacy solc pipeline — though ultra-conservative — delivers far fewer optimizations and often forces developers to hand-tune code. As compiler engineers we don’t think people at scale can do optimizations more securely than a thoroughly tested compiler. Nevertheless, the 401 open LLVM “miscompilation” tickets (label = miscompilation, 11 Jul 2025) remain a concern, and we do not assume LLVM is secure enough by default. Our first triage suggests that only 42 of them could realistically surface in solx:

Before tackling those 42, we are defining a permanent triage and tracking process so we never repeat this snapshot exercise. Reported LLVM miscompilations will be kept out of our next releases.

Recommendations

• Maintain 100 % test coverage in your own codebases; well-tested code is far less likely to conceal an undetected optimization bug.

• Feel free to battle-test solx on non-critical contracts today. For mission-critical deployments, wait until we raise our security bar further.

Conclusion — has solx really fixed stack-too-deep?

Two months after our first public release, the beta compiles every contract that previously tripped over stack-too-deep—the error that has topped Solidity-developer pain charts for years.

So is the problem gone for good? Partly.

Stack-too-deep is eliminated in optimizing builds, meaning you can point solx at production code today and ship byte-code that solc’s default pipeline could never produce. What remains is a smooth development-time experience: lightning-fast, non-optimizing builds with source maps and coverage. Delivering that requires a “debug” pipeline, but—unlike solc --via-ir  detour—solx doesn’t need a separate code generator. Turning off most LLVM passes is enough, because the spill strategy already lives in the backend.

That puts a developer-friendly, non-optimizing pipeline well within reach. Once it lands, teams will compile fast, debug smoothly, and then flip the optimizer on for deployment — all without ever seeing stack-too-deep again.

This is our best idea for what to tackle next, but if you think we’re wrong — or have any feedback at all — please reach out on Telegram or email. Above all else we want solx to meet your needs. And if you haven’t tried it yet, head over to solx.zksync.io for an easy start.

Airbender isn’t just fast. It’s the fastest open-source RISC-V zkVM we have seen. In benchmark tests, Airbender outperforms other leading systems by wide margins. It has achieved:

• sub-second proofs for ZKsync blocks, and ~3 second proofs using a single commodity GPU

• ~4-6x faster speedup than the closest contender.

• the fastest proofs on a single H100 (21.8 million cycles per second for base layer, 8.5 million cycles per second end to end)

• the ability to prove Ethereum blocks on average in under 35 seconds using just a single (!) GPU (vs existing set ups that use 50-160 GPUs for proofs in 12 seconds, depending on the size of the blocks).

• Airbender can also prove Ethereum blocks in 17 seconds without recursion, which tells us that real-time proving on a single GPU is in the realm of possibility.

These performance gains are more than just numbers. They unlock a future where chains coordinate and settle in real time, developers can build client-side apps with local proof generation, and entire ecosystems benefit from faster, cheaper, and more decentralized infrastructure.

World’s fastest open-source RISC-V zkVM

Airbender is fast, and we’ve got the numbers to back it up.

We tested Airbender against two leading zkVM proving systems, RiscZero and SP1 (Turbo), using a standardized Fibonacci program to ensure apples-to-apples comparison. Benchmarks were run on both NVIDIA L4 and H100 GPUs, and we measured performance across two stages:

• Base Proving: the first round of proof generation

• STARK Recursion: followup rounds where base proofs are aggregated into one or a small number of final proofs.

Here’s how Airbender stacks up (the higher the MHz, the faster the system):

What these numbers show:

• Airbender is the fastest base layer prover on both powerful (H100) GPUs and smaller, economical (L4) GPUs. On H100 it achieves 21.8 MHz (millions of cycles proven per second), compared to 3.45 MHz for SP1 Turbo and 1.1 MHz for RiscZero.

• Airbender is the fastest end to end prover (including recursion): 2.5-4X faster than SP1 Turbo and 8.5-11X faster than RiscZero.

You can reproduce these benchmarks yourself here. These are early results—and we’re just getting started. There are likely to be even more improvements in the coming weeks.

Near Real-time Ethereum Proofs on a Single (!) GPU

By leveraging ZKsync Airbender and ZKsync OS (our new EVM execution environment), we were able to prove execution of an average Ethereum block in ~17 seconds using just a single H100 with ZKsync OS storage model before recursion and ~35 seconds end-to-end (with recursion). These benchmarks can be reproduced here.

That is a major breakthrough that paves the path for home-proving Ethereum.

Existing alternatives require massive hardware to achieve comparable results. For example, in Succinct’s Real Time Proving announcement, SP1 Hypercube took ~12 seconds to prove Ethereum blocks, but required 50-160 GPUs (Nvidia 4090s, roughly equivalent to H100).

Airbender achieves comparable performance with a fraction of the hardware. More efficient proving doesn’t just mean lower costs. It’s what enables the future we are building toward: a decentralized network of chains that coordinate, settle, and interoperate in real time.

It’s worth noting that SP1 used a different execution environment and storage model, so this isn’t an apples-to-apples comparison of zkVMs. But that’s exactly our point: our performance stems from the strength of the full system, from zkVM to engine to proving architecture. Airbender’s efficiency is a product of deep integration across the ZKsync stack. In the end, what matters isn’t just raw benchmarks, but what a system can actually do. ZKsync can deliver near real-time block proving with consumer-grade hardware. That’s the breakthrough.

Sub-Second Block Proofs for ZKsync Chains and Beyond

All new ZKsync Chains will use Airbender as a proof system moving forward, replacing the current Boojum prover. Chains like Abstract, Sophon, GRVT, Lens, and Memento will be able to migrate to Airbender and leverage its speed and efficiency. Airbender reduces proving costs to just $0.0001 per transfer, already more than 10x cheaper than Boojum, bringing meaningful savings and performance gains to apps across the Elastic Network.

Airbender isn’t just for ZKsync Chains. Its open-source design and RISC-V zkVM make it suitable for proving any type of program. It unlocks a broader future for general-purpose, verifiable applications. Its design supports proving on ordinary consumer hardware, opening the door for new use cases in gaming, identity, and decentralized AI. We’re continuing to improve the developer experience and will share updates soon at @ZKsyncDevs on X.

Test Airbender Yourself!

We’ve released a fun app to showcase Airbender’s capabilities. It’s designed to highlight what this kind of performance means in practice: from submitting tx to full block proof verification on a ZKsync OS testnet.

While Airbender is still in beta and not production-ready yet, developers can start building with Airbender today. We are actively working on improving the developer experience, and would welcome feedback from any devs who try it out.

Whether you’re building private chains, ZK-native apps, or cross-chain infrastructure, Airbender offers a flexible zkVM and proving system purpose-built for fast, native interoperability. Its performance also unlocks new application design patterns, where chains can communicate in near real-time, and developers can coordinate logic across networks with trustless, low-latency execution.

Technical Deep Dive

What is ZKsync Airbender?

Those benchmarks are exciting, but let’s take a step back. What is Airbender?

Airbender is ZKsync’s new zkVM and proving system, designed to generate ZK proofs of RISC-V bytecode execution. It was built alongside ZKsync OS, our modular operating system for ZKsync Chains which is tailored to support a wide range of execution environments, including EVM, EraVM, and WASM. Put simply, Airbender and ZKsync OS bring more performance and more customizability for teams building in the Elastic Network.

The core proving engine is based on AIR constraints compiled into highly optimized DEEP STARK proofs over a Mersenne31 prime field. The system supports custom machine configurations, precompiled circuits (e.g. Blake2s/Blake3, big-integer arithmetic), and recursive proving modes.

This architecture allows developers and protocol operators to optimize for different use cases: decentralization, cost-efficiency, or proof compression.

Proving Architecture

Airbender’s performance, including the breakthrough to proving chains with a single GPU, is made possible by a set of carefully engineered components.

The proving pipeline follows a five-stage structure optimized for both flexibility and throughput:

1. Witness Commitment: Computes low-degree extensions (LDEs) and trace commitments.

2. Lookup & Memory Argument: Validates memory operations using lookup tables.

3. STARK Quotient Polynomial: Encodes circuit constraints via AIR polynomials.

4. DEEP Polynomial Construction: implements FRI batching to reduce proof size.

5. FRI IOPP: Generates the final proximity proof.

Execution Model

Airbender implements the RISC-V 32I+M instruction set, operating in a standard fetch-decode-execute loop. Bytecode is loaded via ROM and processed in chunks of ~4 million cycles. Prover performance can be scaled horizontally by stitching chunks together via memory arguments.

The system supports Kernel Mode for ZKsync OS system-level logic.

Design Considerations

• Hybrid CPU/GPU: Airbender supports proving with a CPU, a single GPU, or multiple GPUs. For the latter options, the CPU performs the RISC-V simulation and tracing, and then the GPU computes witness generation and the rest of the steps.

• RAM-Backed Registers: All 32-bit registers are implemented in RAM, simplifying the circuit and deferring register management to memory lookups.

• Mersenne31 Field Arithmetic: Fast arithmetic operations optimized for STARK performance.

• Custom Precompiles: Supports cryptographic operations and big integer math through a CSRRW-opcode-based delegation mechanism.

Acknowledgements

Thank you to the many cryptographers and engineers that have helped push this industry forward. Special thanks to RiscZero for pioneering RISC-V zkVMs, Starkware for STARKs including Circle STARKs, and Polygon for the Mersenne31 Prime and work on the Circle Group. More detailed acknowledgements can be found in the Airbender repository.

With the launch of ZKsync Prividium, they no longer have to choose.

Prividium is a new product from ZKsync that delivers something no other blockchain platform can today: enterprise-grade privacy, built-in compliance, and seamless connection to Ethereum, all in a fully customizable, production-ready stack.

Today we are proud to launch with our first partner, Memento ZK Chain.

Why ZKsync Prividium Matters

Enterprises, from global banks to fintech platforms, are under pressure to modernize the way they settle payments, manage assets, and move value across borders. But most private blockchain options come with serious limitations: they’re siloed, hard to audit, and disconnected from the broader public blockchain ecosystem.

Prividium changes that. It gives institutions a way to bring real-world financial systems onchain: privately, compliantly, and at scale.

With Prividium, institutions can:

• Deploy a private chain inside their own infrastructure. Run in a private cloud or on-premises. Data stays under their control.

• Meet regulatory standards from day one. Includes KYC/KYB, audit logs, onchain identity, and role-based access.

• Settle trustlessly on Ethereum. Every transaction is verified with ZK proofs and finalized on Ethereum for tamper-proof integrity.

• Customize every layer to match business needs. From governance to gas tokens to user experience, everything is configurable.

• Stay private without getting isolated. Each Prividium chain is custom-built, but can remain interoperable with Ethereum and other ZKsync Chains. Institutions can operate independently and still participate in cross-chain financial workflows.

Launching with Memento: A Real-World Deployment in Institutional Finance

The first in-production deployment of Prividium is Memento ZK Chain, a compliance-focused chain built on ZKsync in collaboration with Deutsche Bank, designed to bring fund servicing fully onchain.

Originally incubated as Project DAMA under MAS Project Guardian, Memento ZK Chain is now launching on mainnet. It supports digital fund creation, investor onboarding, custody, KYC-gated access, onchain identity, and multi-chain accounting. Everything is secured by ZK proofs and anchored to Ethereum.

This is what modern institutional finance infrastructure looks like.

Memento ZK Chain delivers:

• Private validium architecture for institutional-grade privacy and scalability.

• Near-instant settlements and automated fund servicing

• KYC-gated access to meet global compliance standards

• Full control over validator selection and data privacy

• A live partnership with Deutsche Bank, with more to follow.

Bring Your Infrastructure Onchain

The future of finance is onchain — but not all blockchains are built for institutions.

With Prividium, we’re giving enterprises the infrastructure they need to operate securely, meet compliance standards, and move faster in a connected ecosystem.

If you’re ready to bring your financial infrastructure onchain — without compromise — get in touch with our team.

This part is for tooling developers — those building new languages, compilers, debuggers, or targeting alternate EVMs and virtual machines. If you're only looking to use solx to compile smart contracts, Part 1 should cover everything you need.

If you're working on compilers, debuggers, or alternate VMs, we recommend starting with Part 1 for context, then continuing here.

With 2 man-years of engineering effort, solx has already reached a state where it produces better runtime gas efficiency than solc’s --via-ir --optimize pipeline — and it does so without tuning the LLVM optimizer or implementing any EVM-specific optimizations yet.

Thanks to LLVM, solx’s optimizer and code generator are under 8,000 lines of code and far easier to maintain than a custom pipeline. Much of the complexity typical of compiler development can be offloaded to LLVM’s existing infrastructure.

In this part, we briefly cover solx’s internal structure, how it can be reused or extended, and what it offers if you’re planning to:

• develop a new language or adapt an existing one for smart contract development,

• implement an experimental EVM feature,

• or retarget Solidity to something like RISC-V.

solx Architecture Overview

solx combines the standard Solidity front-end with a new LLVM-based back-end.

It reuses the entire solc front-end (lexer, parser, AST), ensuring full Solidity support and compatibility with language updates. From there, solc lowers the AST to Yul IR, which we translate into LLVM IR.

We also support solc’s legacy pipeline. Since it doesn't expose an IR, we lift the generated EVM assembly into LLVM IR. Because we observed some contracts that compile cleanly with the legacy pipeline fail or behave inconsistently under --via-ir, we’ve made the legacy path the default - just like solc does today. Users must explicitly pass --via-ir to use the Yul-based flow.

Once in LLVM IR, solx applies standard LLVM optimizations, then hands off to our custom EVM backend. This handles instruction selection, scheduling, stackification, and assembly or binary emission - reusing as much of LLVM’s infrastructure as possible.

This design let us deliver a working pre-alpha with two man-years of engineering effort, but it comes with trade-offs: some optimizations are currently inhibited, and binaries can be larger. We briefly touched on these issues in Part 1. To address them, we're developing a new high-level Solidity IR based on LLVM's MLIR framework.

But let’s start with focusing on what solx as a compiler infrastructure is offering today.

Why Modularity Matters: Solidity for RISC-V, Rust for EVM

One of LLVM’s most important innovations dating back to the early 2000s was its Intermediate Representation. At the time, most compilers tightly coupled language-specific ASTs with target-specific code generators. LLVM IR introduced a complete and self-contained representation of programs, including type information and debug metadata. This let compiler components and tools operate entirely at the IR level without requiring access to language-specific internals.

Frontend developers started to rely on a simple and stable interface - LLVM IR - without needing to understand code generation or debug formats. Backend developers only needed to support that IR format, regardless of how the source language worked. The optimizer, meanwhile, transformed IR and automatically updated associated metadata and debug info. And in 2025, LLVM’s optimizer preserves debug information in optimized builds reasonably well, thanks in large part to demands from the gaming industry, which needs fully optimized code to remain debuggable.

LLVM’s modularity is what makes solx adaptable.

Vitalik Buterin recently floated the idea of replacing the EVM with a RISC-V–based machine for Ethereum’s execution layer. If that ever happens, solx is ready - we estimate that adapting our LLVM IR from EVM to RISC-V would require less than 10% of the IR to change. In contrast, compilers like solc and Vyper would face a much steeper challenge. They would either need to start emitting LLVM IR or implement instruction selection, scheduling, register allocation, and binary emission for RISC-V from scratch.

This flexibility goes beyond backends. With LLVM, writing a new language for Ethereum requires just two entry points: IRBuilder for IR construction, and DIBuilder for debug info. You don’t need to know how the EVM works, or what ethdebug expects. You just write to the IR.

It makes the widespread idea of Rust for EVM within reach. We’re not working on this right now, and Rust isn’t a language designed for smart contract development. Still, supporting the EVM subset of LLVM IR we designed in Rust could be done with about one engineer-year of effort.

Modularity also means the ability to focus - without the necessity to maintain large bases of code.

Smaller Codebase, Easier Maintenance

At first glance, relying on LLVM might seem counterintuitive - it's a large system, and integrating it can appear to add complexity. But think of the alternative. Without reuse, not just optimizations, but all the foundational infrastructure - IR design, printing, parsing, assembly emission, and more - must be built from scratch and then maintained. In contrast, for solx we only maintains translation to LLVM IR and a custom LLVM backend for the EVM. To give you a sense of the difference, below is the cloc output for the EVM backend in solx compared to libyul and libevmasm from solc.

> cloc solidity/libyul
---------------------------------------------------------------------------
Language                     files          blank        comment           code
---------------------------------------------------------------------------
C++                             96           2652           2269          15585
C/C++ Header                   108           1784           3781           5597
CMake                            1              2              0            207
Markdown                         1              2              0              3
---------------------------------------------------------------------------
SUM:                           206           4440           6050          21392
---------------------------------------------------------------------------

> cloc solidity/libevmasm
---------------------------------------------------------------------------
Language                     files          blank        comment           code
---------------------------------------------------------------------------
C++                             20            716            649           6603
C/C++ Header                    24            583            995           2601
CMake                            1              1              0             47
---------------------------------------------------------------------------
SUM:                            45           1300           1644           9251
---------------------------------------------------------------------------

> cloc --force-lang="C/C++ Header",def llvm/lib/Target/EVM
---------------------------------------------------------------------------
Language                     files          blank        comment           code
---------------------------------------------------------------------------
C++                             39           1180           1400           5661
C/C++ Header                    24            366            434           1198
TableGen                         4            241            191            915
CMake                            4             16              0            106
LLVM IR                          1             15              0             69
---------------------------------------------------------------------------
SUM:                            72           1818           2025           7949

But it’s not the end, LLVM does not natively support stack machines, so we implemented stackification ourselves. In doing so, we drew inspiration from both the designs used in solc and the WASM backend in LLVM. This significantly increased the amount of code we need to maintain today.

Still, one can imagine generalizing stackification across stack-based targets - similar to how LLVM handles register machines through declarative target descriptions and shared algorithms. In LLVM, most of the code generation logic - like instruction selection, register allocation, and scheduling - is written once and reused across architectures. Targets such as x86, ARM, or RISC-V don’t each implement these from scratch; instead, they define their register sets, constraints, and instruction mappings declaratively. The LLVM backend then uses a shared pipeline to apply this information in a uniform way.

If integrated upstream, stackification generalization would be a meaningful contribution to LLVM itself - advancing support for all stack-based architectures and saving significant human-hours across the compiler ecosystem. It would also reduce solx maintenance burden in the long run. Here is the number of LoCs for stackification logic we have.

---------------------------------------------------------------------------
Language                     files          blank        comment           code
---------------------------------------------------------------------------
C++                              9            530            701           2759
C/C++ Header                     4            103            120            467
---------------------------------------------------------------------------
SUM:                            13            633            821           3226
---------------------------------------------------------------------------

This reflects a broader paradigm common in Web2 tooling: upstream whatever can be upstreamed. Maintaining compilers is expensive, and reducing custom logic is a proven way to keep development velocity high in long run.

Tooling Drives Compiler Development Speed

Small teams rarely have time to build tools that support compiler development. But since solx is built on LLVM, it gets them for free. Here are three tools that, in our experience, have each saved us at least a human-day during the week we were working on this blogpost.

Note: To try these tools yourself, you’ll need to build our LLVM fork - these tools aren’t bundled with solx directly.

opt and llc: Step-by-Step Transformation Tracking

opt and llc are LLVM’s command-line tools for running optimization passes and lowering IR to target code, respectively—and they’re invaluable for understanding what the compiler is doing.

In Part 1, we analyzed a contract’s performance and identified which transformations contributed to the observed gas savings. With LLVM, this kind of investigation is straightforward: opt -print-changed shows which passes modified the IR, and --debug reveals how those transformations were applied—or why some didn’t happen. The same applies to llc, which provides similar insights for the code generation phase.

bugpoint: Automatic Test Case Reduction

bugpoint is LLVM’s built-in tool for automatically minimizing test cases that trigger miscompilations or crashes.

While working on a stack-too-deep issue we found in a contract, we used bugpoint to reduce the size of problematic LLVM IR inputs—shrinking one from 67.6 KB to 8.6 KB of textual LLVM IR representation, and another from 75.3 KB to just 5.9 KB. These reductions made debugging faster and more focused.

llvm-lit and update_llc_test_checks.py: Making Regression Testing Simple

The contract reductions from the previous example were saved along with the bug fixes they exposed. Stackification is difficult to debug, and minimal test cases that trigger specific corner cases are worth preserving. LLVM’s testing tools make that easy: with llvm-lit, you can add IR-based tests that specify how to run the compiler and what to check. update_llc_test_checks.py then auto-generates assembly checks based on the current output.

These tools haven’t saved us a day yet on stackification - but based on prior experience, we know they will.

LLVM for Ethereum

solx isn't only a command-line compiler - it’s a rethink of how Ethereum tooling can be built.

By leveraging LLVM, solx provides a modular, maintainable, and extensible compiler infrastructure. Teams can specialize, collaborate, and reuse tooling instead of rebuilding everything from scratch.

It also challenges a long-standing belief: that the EVM is too different for general-purpose tooling. Yes, the EVM has unique constraints. But it shares more with other platforms than often acknowledged. Like embedded systems, it imposes strict size limits, making optimization a correctness issue. Like game engines, debugging optimized builds is essential - replaying transactions of optimized bytecode requires it. And EVM isn’t even the only stack-based VM; LLVM already supports WebAssembly.

LLVM for Ethereum isn’t theoretical anymore - it’s here.

And with LLVM, tools like llvm-cov for coverage, lldb and VS Code for step-debugging, and other mainstream dev tools are within reach.

Building With Us

If you're working on dev tools, solx is ready to be integrated, and extended to your needs. Here’s how you can start collaborating with us.

• 🧪 Integrate solx into dev tools: From a CLI perspective, solx works as a drop-in solc replacement. But if you encounter edge cases, we’re happy to help. If you need access to internal LLVM options not exposed in the CLI or to LLVM tools, we’re happy to assist with that as well.

• 🤝 Contribute to solx: solx is an open-source project, and we welcome contributions - with no gatekeeping. Small additions like tests, bug fixes, or features are always welcome. If you’re planning something larger, we recommend reaching out early - it helps align efforts and avoid duplicate work. We do expect major contributions to be maintained.

• 💬 Stay in touch: You can reach us via Telegram or by email at solx@matterlabs.dev. We’re always interested in hearing what you’re building, what you need, and where we can make things easier.

solx is a new optimizing compiler for Ethereum smart-contracts that could change the way you write and optimize Solidity code. Built on LLVM, solx focuses on improving runtime gas efficiency while reducing the need for manual workarounds.

If you're a smart-contracts developer and gas costs matter to you, solx could help - some low-level tweaks you’re used to making might already be unnecessary, and more improvements are on the way.

If you're a tooling or compiler engineer, or someone thinking about the future of Ethereum’s developer tooling, Part 2 explores solx as a modular compiler infrastructure — ready to support new languages, EVM extensions, or even compiling Solidity to RISC-V. We still suggest starting here to see what solx delivers today, in practice.

solx Today

solx was built to improve runtime gas efficiency - but there’s no single number that captures the effect, as different contracts benefit differently. The best way to see the impact is to try solx yourself using the demo we prepared. It’s streamlined for quick gas measurements, and adding new contracts is easy. The picture below shows some improvements from the demo - if it looks convincing, feel free to pause here and give it a try.

solx is currently in pre-alpha. It passes our internal test suite, including all tests from the Solidity compiler repository and a number of real-world contracts such as Uniswap V2 and Solmate. We haven’t observed code generation issues except for stack-too-deep errors in larger projects. A breakdown is included below. The numbers indicate how many contracts compiled successfully out of the total for each project.

Basic Foundry integration already works. solx can be used as a drop-in replacement for solc in Foundry workflows, although contract linking is not fully supported yet. Hardhat integration is more challenging and requires further work.

Still, don’t assume solx can be dropped into production just because it works as a solc replacement in Foundry. You will still need to retest your contracts. Even if the contracts have worked reliably with solc, solx may expose different edge cases - and vice versa. When switching back from solx to solc, especially its modern optimizing pipeline solc --via-ir --optimize retesting is essential as well.

Aiming for 100% code coverage almost excludes the possibility of compiler bugs affecting your project. Fuzzing and other forms of testing are welcome too - in our experience, when developers rigorously test their own code, compiler bugs simply don’t go unnoticed. Still, until we address the remaining stack-too-deep issues and check solx more broadly against real-world contracts, we recommend holding off on production use.

Or, if you're interested in doing more than just waiting - let us know about your project and your intent to use solx. We can add your contracts to our benchmarking suite and start optimizing for your use case. You can reach us via Telegram, or by email at solx@matterlabs.dev.

The next section explains when solx works well, where it might fall short, and how it compares to solc across common usage patterns.

When Gas Usage Drops

Don't worry - we won't explain every classical compiler optimization here. Instead, this section will walk you through four simple examples that highlight what solx can do in practice.

The examples are intentionally simple and focus on extremes to make the patterns obvious. But the broader guidance is:

• The more computations vs. storage operations your contract has, the more likely you’ll benefit from solx.

• The more branches and loops your code contains, the more likely you’ll benefit from solx.

• The cleaner your code and the fewer manual optimizations, the more solx can help.

  If you’ve manually inlined functions, precomputed constants, or reordered expressions to save gas, you probably did a good job. But solx might make that manual optimization unnecessary.

For each example, we share a link to Compiler Explorer, a tool that lets you inspect the generated EVM assembly and compare outputs from different compilers side by side. To keep things simple, we compare solc --optimize with solx using default parameters or solc --via-ir --optimize with solx --via-ir. You’re welcome to experiment with other options or LLVM-specific flags.

Note: solx emits a slightly different textual format for EVM assembly, but we’ve tried to make it comprehensible without needing to explain the syntax here.

Example 1: Caching Storage Variables

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract FactorialStorage {
    uint256 private result;

    // 57! fits in uint256, 58! does not
    uint256 constant MAX_SAFE_N = 57;

    function computeFactorial(uint256 n) external {
        if (n > MAX_SAFE_N) {
            revert("Overflow: n too large");
        }

        result = 1;
        unchecked {
            for (uint256 i = 2; i <= n; ++i) {
                result *= i;
            }
        }
    }

    function getResult() external view returns (uint256) {
        return result;
    }
}

In the FactorialStorage example (view on Compiler Explorer), both of solc's optimizing pipelines — the legacy path and --via-ir --optimize — keep storage accesses (sstore and sload) inside the loop. Specifically, solc emits:

• an initial sstore before the loop,

• and a sload/sstore pair on every loop iteration.

In contrast, solx recognizes the pattern and restructures the code:

• it uses a temporary variable for the loop computation,

• and lifts the sstore out of the loop.

Note that unchecked is essential — without it, the compiler cannot assume that multiplication won't overflow, so updating storage on each iteration becomes necessary for correctness. Still, solx will eliminate the sload from the loop even in that case.

The initial sstore before the loop remains, even though it’s possible to optimize it away. Except for that, the generated binary works as the following loop.

uint tmp = 1;
for (uint i = 2; i <= n; ++i) {
    tmp *= i;
}
result = tmp;

Example 2: A Complex Case of Constant Folding

// SPDX-License-Identifier: MIT
pragma solidity >=0.4.16;

contract Foldable {
    function entry() public pure returns(uint64) {
        return test() + test() + test();
    }

    function test() private pure returns(uint64) {
        for (uint8 i = 0; i < 2; i++) {
            uint8 j = 1;
            while (j < 4) {
                uint8 p = 0;
                do {
                    p += 2;
                    if (p == 8)
                        break;
                    for (uint8 h = 1; h <= 4; h++) {
                        if (h > 2)
                            break;
                        for (uint8 k = 10; k < 12; k++) {
                            uint8 x = 6;
                            do {
                                x -= 1;
                                if (x == 0)
                                    break;
                                uint8 y = 10;
                                while (y < 17) {
                                    y += 1;
                                }
                            } while (true);
                        }
                    }
                } while (true);
                j *= 2;
            }
        }
        return 1;
    }
}

The Foldableexample (view on Compiler Explorer) shows how LLVM is able to precompute even complex expressions that are doable at compile time.

While solc with --via-ir --optimize performs most of the computations written in the source, solx --via-ir detects that the final result is 3 and replaces the entire computation with the constant directly.

If you had previously put precomputed numbers into your contract, you can now leave computations written explicitly - it is often more robust than writing comments explaining what specific numbers mean.

More importantly, constant folding is not limited to precomputing standalone constants. Constant expressions often appear as a side effect of other optimization passes or logic lowering, such as addressing an array element by index. solx can fold such expressions even across branches and loops whenever they are statically determinable.

Example 3: Loop Optimizations

We observed that general-purpose sorting algorithms with no storage interaction work significantly better in solx than in Solidity’s current optimizers.

In particular, in our benchmarks on random input, Bubble Sort used 64% less gas and Quick Sort 51% less gas compared to solc --via-ir --optimize (with solc --optimize performing even worse).

One of the reasons why is that in solc, the base address of an array is recomputed on every iteration, while solx extracts loop-counter independent computations out of the loop and fold constants.

If computations with arrays are in your hot code, solx can automatically optimize them without requiring manual restructuring.

Example 4: Loop Unrolling And Arrays

Manual loop unrolling is common in Solidity libraries. In Uniswap V4’s TickMath.getSqrtPriceAtTick, 19 steps are unrolled explicitly instead of using a loop (view on Compiler Explorer).

We rewrote the logic using a for loop and an array of constants (view on Compiler Explorer):

• With solc, gas usage rose from 1365 to 3524 - a 2.5× increase.

• With solx, gas increased from 965 to 2451 - again about 2.5×.

• But solx can automatically unroll loops when the number of iterations is known at compile time.

To enable this, use:

--llvm-options='--unroll-count=20'

This brings gas down to 1197 - just a 24% increase instead of 150%, and already better than solc’s manually unrolled version.

We don’t enable this unrolling by default because it involves a trade-off: unrolling reduces runtime gas but increases bytecode size. Since Solidity contracts have a size cap, applying this optimization indiscriminately could backfire. That’s why solx leaves it up to you.

Some of the remaining overhead comes from inefficient constant array initialization- another area we’re targeting for improvement in our upcoming MLIR-based frontend.

What’s Coming Next

Here are the areas we currently consider most important - some are already in progress, others are next on our list:

• Stack-too-deep resolution is underway. This is our top priority and will remove one of the last blockers for solx adoption in large contracts.

• MLIR-based Solidity IR is in active development. Currently, solx reuses parts of solc’s frontend up to intermediate representation emission. This helped us deliver a pre-alpha faster, but it comes at the cost of bloated binaries and missed optimization opportunities. By replacing these components with our own frontend, we aim to unlock optimizations solc can’t support - like constant array folding (see Example 4) and eliminating redundant heap allocations, as shown in the example below.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract HeapLoopExample {
    struct Item {
        uint256 x;
        uint256 y;
    }

    function compute() public pure returns (uint256 sum) {
        for (uint256 i = 0; i < 100; ++i) {
            // This allocates memory for a struct in each iteration
            Item memory item = Item({x: i, y: i * 2});
            sum += item.x + item.y;
        }
    }
}

• ethdebug support is within reach. LLVM tracks debug info through optimization passes; solx will emit LLVM debug metadata in the frontend and translate it to ethdebug in the backend - making optimized contracts easier to debug.

Our priorities aren’t set in stone. Your input could help us focus on features that are truly in demand. If we’ve missed something - don’t hesitate to tell us.

How to Get Involved

If you’ve made it this far, chances are you’re interested in solx. Here’s how you can get started and contribute:

• 🔥 Try the Demo: If you haven’t already, take a moment to try the demo. It includes everything you need to start working with solx. But don’t stop at the bundled examples — compile your own contracts, compare gas usage, bytecode, and behavior. It’s the fastest way to see what solx can do.

• 📝 Share Feedback: As you experiment, let us know what you find. Did solx reduce gas for a specific function? Did it behave unexpectedly in some edge case? We’re listening. The best way to reach us is via our telegram channel. You can also send questions or feedback via email: solx@matterlabs.dev.

• 📣 Spread the Word: If you found solx interesting or useful, share it with your team, post your findings, or just mention it in developer forums. The more people experiment with it, the faster we can identify real-world needs and improve. We also promote blog posts, benchmarks, and feedback shared by the community - so if you write or record something about solx, let us know!

On April 13th, a compromised admin account minted the remaining unclaimed tokens from the ZK token Merkle distributors used for the ZKsync June 17th 2024 airdrop. The hacker successfully took control of 111,881,122 ZK tokens (equivalent to ~$5M at the moment of the initial transaction). The transaction can be viewed here.

On the morning of April 15th, Matter Labs engineering team identified the scope of the compromise. Together with the ZKsync Association and ZKsync Foundation, Matter Labs started investigating and initiated initial incident response measures.

This incident was contained to three specific ZK token Merkle distributor contracts from the June 2024 ZK airdrop with a compromised admin key. No additional ZK tokens can be minted from any of the distributors, as the total capped supply of each has been fully minted. No further exploits of these distributor contracts via this admin key are possible.

On April 23rd, following a safe harbor offer from the ZKsync Security Council, the hacker returned the funds, thus resolving the case. The funds are now in custody of the Security Council, and the decision on what will be done with the funds will be made by governance.

The compromise was possible due to a procedural error which misclassified the risks of the airdrop distributor contracts, resulting in a failure to update their security configuration.

The investigation has not uncovered any issues regarding distributor code standards, development, or implementation. The investigation also confirmed that the ZKsync protocol, ZK token contract, all three governance contracts, and all active Token Program capped minters were not impacted by this incident.

The identity of the hacker, and the exact method they used to compromise the key on the admin multisig, is still unknown at this time. The multisig that was the admin of the ZK token Merkle distributors was generated by a former ZKsync contributor who has not been employed at any ZKsync affiliated entity since last year. The investigation has not found evidence of malicious intent by the former contributor.

Exploit Methodology

The abnormal activity was identified to be linked to the three Merkle distributor contracts from the ZK airdrop in June 2024:

• ZK token Merkle distributor 1: 0x66fd4fc8fa52c9bec2aba368047a0b27e24ecfe4

• ZK token Merkle distributor 2: 0xb294F411cB52c7C6B6c0B0b61DBDf398a8b0725d

• ZK token Merkle distributor 3: 0xf29d698e74ef1904bcfdb20ed38f9f3ef0a89e5b

Upon investigation, the Matter Labs engineering team discovered that a breached key compromised the ZK token Merkle distributors’ admin, set as a 1/1 multisig (0x842822c797049269A3c29464221995C56da5587D).

The admin was not assigned to the Token Governor as expected after the initial setup process and was not set up as the standard 3/5 minimum used across all other contracts. The admin, unchanged since contract deployment, had access to a single function: sweepUnclaimed(). This function could not be initiated until after the end of the airdrop distribution period on January 3rd 2025. The multisig that was the admin of distribution contracts is not related to any other contracts.

The hacker called the sweepUnclaimed() function through the multisig and minted 111,881,122 unclaimed ZK tokens (tx:0x14b120ff26e8d678fdaa26eef81cf166cb8bc1a20e9bdef6a02fd2af2ee0071e).

The ZKsync Association has confirmed that the sweepUnclaimed() function called on the ZK token Merkle distributors was not a governance authorized action. Unclaimed ZK token supply was to remain unminted, unless actioned by the Token Assembly. The function design was included to give the Token Assembly the option to mint the unclaimed tokens and distribute them through a Token Program after the claim period was complete.

The method to access the secret key for the admin multisig signer has not been identified.

Impact

From 12:32 UTC on Sunday April 13th 2025 to 12:05 UTC on Tuesday April 15th 2025, the hacker swapped a total ~67,193,843 ZK tokens for ETH (swaps linked here). The swap from ZK to ETH took place via repeated transactions. Subsequently, the hacker withdrew ~1,116 ETH to Ethereum mainnet (transactions linked here) to the same address.

The ZKsync Security Council sent an onchain message to the hacker on Monday, April 21st at 15:03 UTC. In an effort to resolve this matter in the spirit of safe harbor, they offered a 10% bounty for returning 90% of the funds involved in the exploit. The return window was available for 72 hours from the time of publication of this message on Ethereum. On Wednesday, April 23rd at 14:39 UTC, 90% of the funds were returned to the Era and Ethereum L1 addresses controlled by the Security Council. As the funds were returned before the deadline, no legal action is being taken with regards to this incident. This post acknowledges their cooperation and closed the case without further action.

Scope

This incident is isolated to the admin of the ZK token Merkle distributor contracts used for the ZK airdrop in June 2024. The ongoing investigation has identified that this incident was enabled by a compromised airdrop admin key of the 1/1 admin multisig controlling these distributor contracts. No additional ZK tokens can be minted from any of the distributors, as the total capped supply of each has been fully minted. No further exploits of these distributor contracts via this method are possible. The compromised admin key was not in control of any other contracts and could not perform any actions besides minting unclaimed tokens from the airdrop after the claim window expired.

The ZKsync protocol, ZK token contract, all three governance contracts and timelocks, and all active Token Program capped minters were not impacted by this incident.

Investigation Results

• The ZK token Merkle distributors were not classified as high risk. The security review processes completed at the launch of the ZK token and governance system addressed all critical issues related to the in-scope protocol and governance system. However, the investigation confirmed that the ZK token Merkle distributors used for the airdrop were not included in the same review process; they were not considered the same risk profile. As a result, the security review did not uncover risks related to administrative controls of the ZK token Merkle distributors after the airdrop claim window closed. The security review also did not identify the distributors as a recommendation to include in the Token Assembly’s Safe Harbor agreement.

• The ZK token Merkle distributor contracts included the sweepUnclaimed() function, which was not necessary given the design of the ZKsync token governance, based on minting rights. The function should have been omitted from the initial design.

• There were insufficient monitoring methods on the ZK token distributors. Monitoring has been in place for all critical functions of the token, Merkle distributor contracts, and capped minters, including the mint function. However, it wasn’t triggered due to and error in its implementation.

• The multisig that was the admin of the ZK token Merkle distributors remained a 1/1 after creation. The standard process of creating multisigs for contract admins is to initially configure a multisig as a 1/1. This provided flexibility to deploy the Merkle distributor contract, and update it with the appropriate target configuration. Should there have been an active admin role, the role should have been transferred to the ZKsync Token Governor upon governance launch. This transition did not happen. The security review of onchain access management conducted as a part of the current investigation has not identified any other contract with access misconfigurations.

• The multisig that was the admin of the ZK token Merkle distributors was generated by a former ZKsync contributor. This individual has not been employed at any ZKsync affiliated entity (ZKsync Association, ZKsync Foundation, Matter Labs) since last year. The investigation has not found evidence of malicious intent by the former contributor.

• The identity of the hacker, and the exact method they used to compromise the key on the admin multisig, is still unknown at this time.

Mitigation Efforts

The hacker continued to swap ZK into ETH until measures were taken to prevent further transactions on April 15th.

At 12:05 UTC on April 15th Matter Labs implemented temporary transaction filtering for the compromised account on the ZKsync Era sequencer, preventing the account from completing any additional transactions and moving any additional funds. At 12:16 UTC on April 15th, transaction filtering for this account was applied on L1 forced inclusion queue as well. After the funds had been returned, Matter Labs fully disabled the temporary transaction filter—removing it from the sequencer and L1 contracts at 13:42 UTC on April 24th.

Matter Labs, as the ZKsync Era Mainnet chain sole sequencer, implemented transaction filtering to protect the funds that should have been in control by the Token Assembly. This action was taken by Matter Labs once they confirmed with the ZKsync Association that the minting of unclaimed ZK tokens was an unauthorized action.

While the work is under way to upgrade ZKsync to Stage 1 and implement decentralized sequencing, Era is currently operating as a Stage 0 rollup, which made this measure possible. At the point that Stage 1 is reached or a decentralized sequencing is implemented, any sequencer has the technical ability to refuse serving specific transactions. It is important to emphasize that ZKsync governance and the Security Council have the ability to replace the sequencer at any point and remove all filters.

Preventative Recommendations

This incident primarily highlighted a failure in security risk assessment. However, contract design, multisig management, and monitoring processes on ZK token distributors can be improved to further mitigate risks related to potential future incidents.

The following measures will be implemented:

• Implementation of scheduled key rotation for every critical multisig associated with ZK token and protocol.

• Development and adherence to an updated contract risk assessment policy and governance contract multisig policy, to be documented publicly on the ZK Nation Documentation portal.

• Deployment and e2e testing of real-time monitoring and alerting infrastructure for all onchain contracts with access to the ZK token or Protocol.

• Amendment of Token Program guidelines to require usage of Capped Minter V2 introduced in December 2024 for all token programs, which includes a pre-specified end-date that automatically prevents minting outside of the token program window.

• Finalization of ongoing Minter Modifiers development which include security enhancements such as Rate Limits, Mint Delay, and Minter Eligibility (read more here).

Path Forward for Returned Funds

The ZKsync Association is working with the Security Council to explore options to exchange the recovered ETH into ZK tokens over time, and return the final ZK to the Token Assembly. Feedback on the plan will be requested from Guardians, Security Council, Delegates, and the ZKsync Foundation.

Once the plan is agreed, a proposal will then be put forward and voted on by the Token Assembly following the standard proposal guidelines. Additional information regarding ZKsync governance proposals can be found at docs.zknation.io.

Closing Statement

ZKsync Association, ZKsync Foundation, and Matter Labs appreciate the patience and support of the ZKsync community during the investigation of this incident.

Thank you to technical partners, security experts, and exchanges for their support in the incident investigation to date. We are grateful for the active and engaged Telegram and Discord community who raised the issue to community mods which helped identify the incident and respond. If you have questions or concerns, please reach out at incident@zksync.io.

Appendix 1: List of Contracts and Addresses

• ZK token Merkle distributor contracts on ZKsync Era L2

  • ZK token Merkle distributor 1: 0x66fd4fc8fa52c9bec2aba368047a0b27e24ecfe4

  • ZK token Merkle distributor 2: 0xb294F411cB52c7C6B6c0B0b61DBDf398a8b0725d

  • ZK token Merkle distributor 3: 0xf29d698e74ef1904bcfdb20ed38f9f3ef0a89e5b

• Compromised Multisig on ZKsync Era L2

  • 0x842822c797049269A3c29464221995C56da5587D

• Compromised Signer on ZKsync Era L2

  • 0x649CDf36A1cc0E27A0D157a161E4Fe4E92B29E6f

• Hacker sweepUnclaimed() transaction on ZKsync Era L2

  • 0x14b120ff26e8d678fdaa26eef81cf166cb8bc1a20e9bdef6a02fd2af2ee0071e

• Hacker Address

  • 0xb1027ED67f89c9F588E097f70807163feC1005d3

• ZK to ETH Swap Transaction List

  • https://era.zksync.network/address/0xb1027ED67f89c9F588E097f70807163feC1005d3#tokentxns

• Withdrawal Transaction from ZKsync Era L1 to Ethereum Mainnet L1

  • https://docs.google.com/spreadsheets/d/1rDgIy50PTMn4775FJR1_hiL0eTo4dtVkDYscqwL88_A/edit?gid=279392287#gid=279392287

  • Bridge Withdrawal txn on L1 for 1,002 ETH: https://etherscan.io/tx/0x334a716559dd95b368af1dc1b4587b9c555cc94711b7018c9551537974a80030

• Onchain message from Security Council to hacker: https://etherscan.io/tx/0xca7b921ae9174616fc443e36f4aec8610ee3c7da0f8dc49b3cd97f9d38a05b1b

• Return Transaction to ZKsync Security Council on ZKsync Era and Ethereum Mainnet L1

  • ZKsync Era: https://explorer.zksync.io/address/0xfFB6126FF8401665081b771bB11cCD0e09f95D5A#transfers

  • Ethereum L1: https://etherscan.io/tx/0xa344a0e759652246e51b1def91c8081b3527bdbbcab92128100f8fbc11c204df

Appendix 2: Detailed Timeline of Incident Events

• Sunday, June 16th 2024

  • [19:45 UTC] The first ZK Token Merkle distributors deployed

• Monday, June 17th 2024

  • [06:45 UTC] The first round of ZK Token Airdrop begins

• Friday, June 21st 2024

  • [17:40 UTC] The second ZK Token Merkle distributors deployed

• Monday, June 24th 2024

  • [07:00 UTC] The second round of ZK Token Airdrop begins

• Tuesday, June 25th 2024

  • [21:09 UTC] The third ZK Token Merkle distributors deployed

• Thursday, June 27th 2024

  • [07:00 UTC] The third round of ZK Token Airdrop begins

• Friday, January 3rd 2025

  • [10:59 UTC] The first ZK Token Airdrop claim window ends and sweepUnclaimed() function becomes active.

  • [22:59 UTC] The second and the third ZK Token Airdrop claim window ends and sweepUnclaimed() function becomes active.

• Sunday, April 13th 2025

  • [12:18 UTC] Hacker calls sweepUnclaimed() to mint the remaining unclaimed ZK from three Merkle distributor contracts used during the initial ZK token airdrop in June 2024.

  • [12:32 UTC] Hacker begins swapping ZK for ETH.

• Monday, April 14th 2025

  • [20:05 UTC] Community discussion on Telegram and Discord raises questions whether the token movements might be an exploit or an OTC sell.

  • [20:47 UTC] Individual Matter Labs team member explains to community members that Matter Labs Team and Investors have locked tokens and, as a result, would not be selling.

• Tuesday, April 15th 2025

  • [7:14 UTC] Discord community members escalate report of continued abnormal activity to Matter Labs community manager. Community manager gathers facts related to possible incident.

  • [7:40 UTC] Matter Labs team is internally alerted by community manager to confirm abnormal activity from an unknown account.

  • [9:27 UTC] Matter Labs engineering team begins internal inquiry to try and determine the owner of the wallet and analyze the token movements.

  • [9:39 UTC] ZKsync Association is notified by Matter Labs and Discord Community mods of ongoing discussion regarding suspicious activity related to recent mint transaction. ZKsync Association begins internal review of active capped minters.

  • [10:09 UTC] Upon review, ZKsync Association confirms the mint activity is not related to any active Token Program capped minters. The ZKsync Foundation confirms the minting activity is not related to capped minters under their control. ZKsync Association, Matter Labs, and ZKsync Foundation escalate incident priority.

  • [10:20 UTC] Incident investigation call started with members of Matter Labs, ZKSync Association, and ZKsync Foundation.

  • [10:25 UTC] The joint investigation confirms ZK token Merkle Distributor contracts deployed in June 2025 were the source of minted tokens and admin configuration was compromised.

  • [10:32 UTC] Guardians and Security Council notified of the incident.

  • [11:00 UTC] ZKsync Association begins internal security review of all ZKsync token related contracts to determine if any other contracts are at risk.

  • [13:35 UTC]: Matter Labs confirms transaction filter deployed on ZKsync Era L2 contracts and ZKsync protocol L1 contracts to reject transactions related to hacker address.

  • [13:49 UTC] First X post was published from ZKSync’s X account notifying the community of the known details of the incident.

  • [14:05 UTC] Seal 911 establishes contact with Matter Labs to confirm the hacker’s address.

  • [14:13 UTC] Seal 911 reported hacker address to major centralized exchanges and instant-swap providers.

  • [14:43 UTC]: ZKsync Foundation confirms contact with CEX’s to prevent further fund movement.

  • [15:25 UTC] Second X post was published from ZKSync’s X account updating the community with additional known details of the incident.

  • [15:31 UTC] X AMA thread started by Alex Gluchowski, CEO of Matter Labs, from his X account.

• Wednesday, April 16th 2025

  • [18:11 UTC] X update post confirming attack contained to airdrop distribution contracts and no additional ZK tokens can be minted from this contract.

  • [20:16 UTC] Matter Labs prepares emergency upgrade calldata that would burn ZK tokens held by the hacker on the ZKsync Era network, to be executed only if additional issues are identified.

  • [21:11 UTC] Guardians convene to assess the emergency upgrade proposal based on ZK Credo principles.

• Thursday, April 17th 2025

  • [11:53 UTC] Security Council, Guardians, and ZKsync Foundation begin gathering signatures for Emergency-upgrade proposal, in line with governance procedures.

• Friday, April 18th 2025

  • [10:17 UTC] Emergency upgrade transaction receives all required signatures and is queued for execution in case further issues would be detected.

  • [19:59 UTC] Security Council discusses Safe Harbor offer that would grant the hacker a 10% bounty for returning the funds.

• Saturday, April 19th 2025

  • [15:12 UTC] Security Council begins gathering signatures for the on-chain message addressed to the hacker.

• Monday, April 21st 2025

  • [15:03 UTC] Onchain message sent from Security Council to hacker.

  • [15:19 UTC] X post from ZKsync with update on ongoing investigation, mitigation efforts, and path forward.

  • [15:20 UTC] X post from ZK Nation announcing onchain message from the Security Council to hacker with a 10% bounty offer for 72 hours.

• Tuesday, April 22nd 2025

  • Finalization of communications and response measures based on bounty offer outcomes.

• Wednesday, April 23th 2025

  • [14:39 UTC] Hacker returns 100% of ZK on L2 to Security Council address (see transaction).

  • [14:45 UTC] Hacker returns 100% of ETH on L2 to Security Council address (see transaction).

  • [14:53 UTC] Hacker returns 776 ETH on L1 to Security Council address (see transaction).

  • [18:27 UTC] X post from ZK Nation announcing funds has been returned to Security Council addresses.

• Thursday, April 24th 2025

  • [15:49 UTC] Transaction removing the Transaction Filterer is executed.

  • Finalization of incident report and publishing plan.

• Friday, April 25th 2025

  • Publication of incident report.

ZKsync has achieved EVM equivalence with EVM Interpreter:

• Developers can run unmodified EVM bytecode.

• This means tools like Foundry and Hardhat just work out of the box.

EVM bytecode interpreter features:

• Deploy Solidity & Vyper contracts without recompilation — just like on Ethereum.

• Works with Foundry, Hardhat, and Remix natively, no plugins needed.

• Same address derivation (create, create2) as Ethereum.

• Pre-deployed contracts (Create2 Proxy, Safe Factory, Multicall3…) for seamless onboarding.

• Some limitations remain (e.g., higher gas costs than native EraVM, no delegatecall between EVM and EraVM).

Enabling EVM Bytecode Compatibility on ZKsync Era

When Matter Labs started working on ZKsync Era, achieving full EVM compatibility in a general-purpose ZK rollup was widely viewed as a major technical challenge. There were no existing general-purpose ZK virtual machines or open-source circuits for proving Ethereum opcodes. The team had to build everything from scratch, making trade-offs to bring ZKsync to production.

One of those trade-offs was not implementing a Type 2 ZK-EVM (which fully matches EVM bytecode) but instead designing a ZK-optimized and stable virtual machine: EraVM. This allowed ZKsync to launch much sooner, but it introduced differences from the EVM that affected developer experience and tooling compatibility.

Over the past two years, the team has made significant improvements to developer experience, refining tooling and addressing key pain points. However, despite these efforts, some teams were still unable to deploy their projects due to incompatibilities with EraVM, while others simply required full EVM equivalence to maintain consistency with their existing codebase. The demand for a solution that allows unmodified EVM bytecode to run seamlessly on ZKsync was clear and today we’re addressing that.

The Path Forward

While EVM Equivalence is here today, we want to make it even better in the future:

1. EVM Interpreter (Today): The first step is an EVM Interpreter that runs on top of EraVM and allows EVM bytecode execution. This enables EVM tools like Foundry and Hardhat to work out of the box on ZK chains like Era, without requiring plugins or extensions.

2. Native EVM Execution (Coming Soon): The next step will come with Boojum 2.0, a new proving system and VM that will enable native EVM execution. We shared some technical details during ETH Denver with more to come in the following weeks. For an overview, refer to this post from Anthony Rose in the ZK Nation forum.

The EVM Interpreter, included in protocol upgrade v27, is a significant milestone, adding EVM equivalence to ZKsync Sepolia testnet, and soon to all ZK Chains.

What Developers Can Expect

With the introduction of the EVM Bytecode Interpreter, developers can now deploy and execute unmodified EVM bytecode, eliminating the need for custom compilers or modified tooling.

• The interpreter targets the Cancun EVM version, which was activated on Ethereum mainnet in March 2024.

• Developers can deploy EVM bytecode contracts without recompilation, using standard Solidity and Vyper compilers. Foundry, Hardhat, and Remix work out of the box without requiring special plugins or modifications.

• Address derivation follows Ethereum’s behavior, meaning contracts deployed using create and create2 generate the same addresses as they would on Ethereum.

• EVM bytecode contracts and EraVM contracts can interact normally, except for delegatecall, which is not supported across environments.

To further improve compatibility, the interpreter includes pre-deployed contracts for common use cases:

• Create2 proxy (Arachnid) – 0x4e59b44847b379578588920cA78FbF26c0B4956C

• Create2 deployer (pcaversaccio) - 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2

• ERC2470 singleton factory – 0xce0042B868300000d44A59004Da54A005ffdcf9f

• Safe Singleton Factory – 0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7

• Multicall3 (mds1) – 0xcA11bde05977b3631167028862bE2a173976CA11

• Create2 proxy (Zoltu) - 0x7A0D94F55792C434d74a40883C6ed8545E406D12

How It Works

ZKsync’s EVM Interpreter allows developers to deploy and run unmodified EVM bytecode on top of EraVM. Instead of requiring contracts to be compiled into EraVM-specific bytecode, the interpreter interprets EVM opcodes at runtime, making it possible to use standard Ethereum tooling without modifications.

At a high level, here’s how it works:

• EraVM remains the core execution environment. The EVM Interpreter does not replace EraVM but runs as a translation layer inside it. This means both native EraVM contracts and EVM bytecode contracts can coexist.

• EVM contracts are flagged and routed through the interpreter. When an EVM contract is deployed, it is tagged with a special identifier. Instead of executing native bytecode, the EVM Interpreter is invoked to process its logic.

• Opcodes are interpreted in real-time. The interpreter translates EVM instructions into EraVM operations as they execute, ensuring compatibility with Ethereum’s behavior.

• EraVM gas (ergs) is used, not EVM gas. Gas fees are paid in ergs (EraVM gas units), and while the costs may differ from Ethereum’s pricing model, transactions remain significantly cheaper than on Layer 1.

For more details, read the EVM Emulator documentation.

EVM Emulation vs. Native EraVM Execution

While the EVM Interpreter makes it easy to bring existing Ethereum contracts to ZKsync, EraVM-native bytecode remains the best choice for most projects due to its better performance and lower gas costs.

We recommend:

• Use native EraVM bytecode whenever possible for optimal efficiency.

• Use the EVM Emulator only if you need features like exact create2 address derivation or other EVM-specific behaviors.

Limitations & Unsupported Features

While the EVM Interpreter significantly improves developer experience, there are still some limitations due to the underlying EraVM architecture:

• Gas Behavior: EVM bytecode is translated at execution time, making transaction fees higher than running native EraVM bytecode.

• Debugging Limitations: Some EVM debugging tools and RPC methods are unavailable due to differences between EVM and EraVM execution.

• Opcodes and precompiles: CALLCODE, SELFDESTRUCT, BLOBHASH, BLOBBASEFEE and modexp, blake2f, pointEvaluation are not supported as they’re not implemented in EraVM yet.

• No Access Lists (EIP-2930): The interpreter does not support access lists for optimizing gas costs.

• Different Warm/Cold Storage Mechanics: Only contracts accessed within the EVM environment are considered warm.

• delegatecall Between EVM and EraVM Contracts is Not Supported.

Learn more in the EVM Emulator documentation.

What’s Next & Getting Started

The EVM Interpreter is live on the ZKsync Era Sepolia testnet with mainnet activation planned in the weeks ahead, pending governance approval. The feature is available across the Elastic Network, meaning other ZK chains running v27 can enable the interpreter at any time.

The next version of the proof system, Boojum2.0, will allow native EVM execution, significantly reducing the costs of EVM equivalence.

We encourage developers to test the EVM Interpreter and share their feedback on our developer forum. Deploying an EVM contract on ZKsync Era is now as straightforward as deploying on Ethereum — no special compilers or modifications are required.

Resources

EVM Bytecode Interpreter Docs

https://docs.zksync.io/zksync-protocol/evm-emulator/overview

• [ZIP-9] V27 EVM Emulation Upgrade

[ZIP-9] V27 EVM Emulation Upgrade

Proposal Type ZIP One Sentence Summary ZIP-9 proposes the V27 upgrade for ZKsync with two key features: (1) EVM emulation, and (2) Fflonk verifier. Proposal Author Matter Labs Proposal Sponsor Cyfrin Date Created TBC Version v1 Summary of Action Upgrade ZKsync to V27 Link to Contracts GitHub - matter-labs/era-contracts at release-v27 Abstract ZIP-9 proposes the V27 upgrade for ZKsync.

https://forum.zknation.io

With the expansion of the Elastic Network, governance shifts, and a new era of interconnected ZK Chains, the community plays a greater role than ever. This evolution brings new opportunities for contributors to engage, shape discussions, and drive ecosystem growth.

That’s where the ZKsync Community Program comes in: a structured six-month initiative designed to empower contributors, reward meaningful participation, and provide clear pathways for community members to play an active role in expanding the ecosystem.

With over 5 million ZK tokens funded by ZKsync Foundation and allocated to Gitcoin for distribution over the next six months, the program ensures that active community contributors are recognized and rewarded monthly based on their engagement, impact, and participation. Eligibility criteria, including the roles and responsibilities of participants, will be outlined by Gitcoin as part of the program’s rollout.

Who Can Participate and How Are Rewards Distributed?

The ZKsync Community Program is designed to recognize key contributors who actively support and grow the ecosystem. Eligibility is based on designated community roles within the program, which include:

🔹 Community Moderators – Maintaining and moderating a welcoming and informed environment across Discord and other platforms.

🔹 Captains – Leading discussions, mentoring members, and organizing key initiatives.

🔹 Mateys – Actively participating in campaigns, amplifying messages, and onboarding new users.

Contributions will be assessed monthly through a structured self-reporting process, where participants submit their activities via a dedicated form. These reports will be reviewed by Gitcoin — managing the program — in collaboration with Community Moderators and verified against engagement data from community platforms, including activity metrics, event participation, and interaction logs. This evaluation ensures that contributions meet the program’s criteria before rewards are distributed at the end of each month.

How Participants Will Contribute

The program offers structured activities designed to strengthen engagement and ecosystem growth. Participants will be able to:

🔹 Engage in community discussions to help onboard new users and maintain an active, positive environment.

🔹 Take part in ecosystem campaigns and weekly activities to play games, participate to new launches, help spread awareness and support the Elastic Network, ZK Chains, and dApps.

🔹 Join Squads, dedicated working groups focused on areas like Governance, Security, Onboarding, and Event Coordination.

🔹 Host and participate in community events and AMAs to drive meaningful engagement.

Who Manages the Program?

The ZKsync Community Program will be managed collaboratively to ensure fairness, transparency, and efficiency throughout its six-month duration:

🔹 Gitcoin – Responsible for program ideation, execution, rewards distribution, and participant evaluations, ensuring a structured and transparent process.

🔹 Discord Admins – Supporting community engagement by facilitating discussions, assisting contributors, and ensuring smooth day-to-day operations.

🔹 Community Moderators – Helping onboard new participants, maintaining a positive and constructive environment, and guiding contributors through the program’s structure.

This management structure ensures that the program remains well-organized, scalable, and effectively supports all participants as they take an active role in the ZKsync ecosystem.

What Makes The Program Unique?

A decentralized ecosystem grows with its community, shaping the future through participation and collaboration.

🔹 Opportunities to Grow – Through structured activities, advocacy, and ecosystem engagement, the community actively contributes to expansion.

🔹 Community Ownership – A step toward a more aligned community model where participation actively shapes the ecosystem.

🔹 Transparency and Fairness – Managed by Gitcoin, ensuring an open and fair process that includes community contributions from early 2024. Eligibility criteria and selection processes will be communicated by Gitcoin.

🔹 Expanding Local Communities – The program supports localized communities, known as Elastic Teams, starting with ZK Amigos in Argentina. These teams focus on regional engagement, education, and ecosystem growth, creating stronger connections between local users and the broader ZKsync network.

What does that mean for you?

🔹 Be part of the growth – The Elastic Network is introducing new ZK Chains and dApps every day. This program gives the community opportunities to contribute to its development.

🔹 New ways to participate and be rewarded – Whether by joining ecosystem campaigns, supporting new users, or helping shape discussions, the program provides clear roles and incentives.

🔹 A future-proof community – This program strengthens the role of the community in the Elastic Network’s ongoing expansion.

🔹 A path to governance – Over the next six months, the community will have direct opportunities to influence the future of the program through Squads, structured governance discussions, and surveys. Community input will shape improvements to fairness, reward structures, and long-term participation models, ensuring the program evolves based on real needs.

What Does the Onboarding Process Look Like?

The onboarding process, managed by Gitcoin, will assess the eligibility of participants before they officially join the program. Once onboarded, participants will:

🔹 Gain access to structured activities, Squads, and engagement opportunities.

🔹 Start contributing through discussions, ecosystem campaigns, and community initiatives.

🔹 Receive guidance on how to track and report their contributions to qualify for rewards.

Gitcoin will provide further details on onboarding and reporting guidelines, ensuring participants have everything needed to engage effectively from day one.

What’s Next?

• March 5 – The Community Program details will be communicated by Gitcoin, and available on the ZKsync Community Hub. A dedicated Q&A channel will also open on Discord, providing a space for the community to ask questions and get insights.

• March 7 – A Discord AMA at 4PM UTC will offer a deep dive into the program, its roles, and the rewards structure. The onboarding process will officially begin, inviting eligible participants to start their journey in the program.

This is just the beginning: how far the program grows depends on the community. Get ready to participate, contribute, and help shape the future of ZKsync! 🚀

WonderFi provides access to DeFi through ZKsync’s Ethereum-level security, with scalability and cost-efficiency

WonderFi, a global leader in centralized and decentralized financial services and products, has launched a Layer 2 (“L2”) blockchain, powered by ZKsync, and a digital wallet on ZKsync’s Elastic Network, through its innovation arm WonderFi Labs. The new ZK Chain and wallet provide users with premier, innovative services and applications and connect them to decentralized finance (“DeFi”) through industrial-grade security and scalability at a competitive cost.

The decision to launch on the Elastic Network strategically positions WonderFi as a first-mover using ZKsync technology to give retail users seamless access to decentralized finance. Importantly, this integration unlocks a new universe of financial applications and services for WonderFi users, including lending, borrowing, staking, and decentralized exchange trading, subject to geo-restrictions. Acting as a gateway to DeFi and leveraging access to an ever-expanding network of applications and services within ZKsync’s Elastic Network, WonderFi’s ZK Chain and wallet will also be an innovation hub for crypto developers, allowing them to build and ship next-generation decentralized applications. This network and wallet will be available globally, but access may be restricted and geo-blocked based on the jurisdiction of a user.

"WonderFi is committed to continuously innovating our offerings to provide our users with a best-in-class experience. Launching on ZKsync marks the next phase of increasing the accessibility and scalability of WonderFi’s products – positioning us at the forefront of tech innovation in the crypto space. By integrating ZKsync technology, we gain scalability while ensuring unparalleled ease of use for new entrants to the DeFi space,” said Dean Skurka, President and CEO of WonderFi.

“WonderFi’s deployment into the Elastic Network showcases the capabilities of ZKsync’s technology to meet the needs of retail users while creating scalable blockchain solutions”, said Alex Gluchowski, Co-Inventor of ZKsync. ZKsync’s advanced ZK technology will empower WonderFi to offer its users unparalleled scalability, security, and low transaction fees. This integration drives a more accessible and inclusive onchain finance ecosystem, creating a seamless and accessible web3 experience that accelerates mass adoption, aligning with ZKsync’s mission to build web3 without compromise.”

WonderFi’s L2 joins ZKsync’s Elastic Network of ZK Chains that are designed to be natively interoperable and leverage ZK Stack to handle a significantly higher volume of transactions, thus reducing congestion and lowering fees. The launch of WonderFi’s L2 in testnet demonstrates how ZKsync’s scalable infrastructure can unlock mainstream adoption for retail-focused financial platforms. Furthermore, WonderFi’s freemium, gasless wallet - powered by ZKsync’s native account abstraction - will offer seamless access to the world of DeFi and NFTs, eliminating barriers to entry for new users.

Key Features

Through the launch of these products in testnet, WonderFi:

• Eliminates the "gas token paradox" where users need tokens just to start using the network

• Creates a sustainable economic model through power user fees rather than relying on external subsidies

• Removes complex fee calculations and gas management for casual users

• Maintains network efficiency through intelligent transaction prioritization

• Enables true decentralization without compromising user experience

• Leverages ZKsync to ensure the products can scale to meet any level of future demand

Now that the wallet and testnet for the L2 are live, users can:

• Start using DeFi applications immediately without any upfront costs

• Execute basic transactions and dApp interactions completely free

• Access premium features like priority processing when needed

• Seamlessly transition between free and premium services based on usage patterns

• Engage with DeFi protocols without technical barriers

More information on both products can be found at labs.wonder.fi.

About WonderFi

WonderFi is a global leader in centralized and decentralized financial services and products. With over $2.1 billion in client assets under custody, WonderFi's regulated trading platforms are well-positioned to service crypto participants on a global scale with trading, payments and decentralized products, including purpose-built blockchains and non-custodial wallet applications. Designed to provide investors with diversified investment exposure across the global digital asset ecosystem, the Company has a proven track record of launching new products and obtaining registrations. It is also the owner of market-leading brands, including Bitbuy, Coinsquare, SmartPay, Bitcoin.ca and Tetra Trust. As the world continues to move on- chain, WonderFi is strategically placed to capture both market and wallet share through ongoing innovation within the digital asset space.

For more information, visit www.wonder.fi

About ZKsync

ZKsync is the pioneering zero-knowledge technology powering the next generation of builders with improved scale. Secured by math and designed for native interoperability, ZKsync enables the Elastic Network, an ever-expanding ecosystem of customizable chains. Deeply rooted in its mission to advance personal freedom for all, the ZKsync technology makes digital self-ownership widely available.

To learn more about ZKsync, visit http://www.zksync.io

But before we start discussing what is going to happen, it’s the right time to talk about why.

Reflection

We heard you: the DevEx on ZKsync wasn’t great. So, if we will just continue doing what we were doing, the situation is unlikely to change. We took our time to analyze what was wrong in the first place, and discovered three main issues:

We focused on quantity, not quality.

We rushed to get as much stuff as we could in the shortest time possible. 5+ SDKs, hardhat support, portal, explorer, zksync-cli, tons of integrations, dockerized setup, in-memory-node, foundry-zksync, and even one-time projects like ZK Quest.

That’s a lot for a relatively small team. That was justified, to a degree: without this infrastructure, ZKsync wouldn’t be as accessible. But the problem with this workflow is that once something reached a “proof of concept” state, we were moving on to the next thing.

And the result is predictable: death by thousand cuts. Everything seems to be working fine, but little bugs and inconveniences here and there ruin the experience all the time.

We haven't listened enough to feedback.

Our development was often a black box. We didn’t know about the issues until they were reported, we often didn’t provide updates when bugs were fixed or new features were shipped. We didn’t respond well enough to GitHub issues or GitHub discussions.

This certainly didn’t provide a good public image.

We had no clear plan.

When we had no ecosystem, the plan was clear: to get the ecosystem.

But after a while, you have most of the things you want, and the question arises: what next? How do you evolve the tooling you have? What are features people need? What bugs need to be prioritized?

We had no answer. Partially because of that, we often have been choosing to start working on something else.

These things may seem obvious, but when you’re fully occupied building things non-stop, it becomes pretty hard to realize. So, the conclusion we came to is: we need a new course.

New course

The basic principles of the new course we take are the inverse of the problems we discovered:

• Focus on quality

• Be transparent

• Stick to plan

You can see some movement in this direction already.

Developer experience has been recognized as a top priority in the protocol roadmap.

We now have live developer support that is actively monitored by our engineers, so every inquiry gets a response.

DevEx work was moved from a private issue tracker to GitHub issues, and moreover: our dashboard is now public, so you can see how issues are being prioritized and processed.

We’re working on actively reacting to the issues in all of our public repositories (although it takes time to set up as a process, so for now using developer support is more reliable — bear with us!).

And we’re only getting started!

Now, what should you expect in 2025?

Elastic-first

ZKsync Era is the first chain in the Elastic Network family. It still plays an important role in being a hub for governance and a center for DeFi, but now it’s one of the many chains. With Abstract and Sophon launched, and many more chains coming, ZKsync DevEx is no longer about Era. Or rather, not only about Era.

We are going to:

• Carefully revisit the documentation to make sure that we focus on the entire ecosystem. You can expect more coverage for custom chains, e.g. Validiums and chains with custom base tokens.

• Adapt our tooling accordingly. Whatever works with Era, must work exactly the same way with any ZK chain in the Elastic Network, regardless of its configuration.

• Change how we prioritize work. So far it was natural: we were running Era, so we prioritized feature requests and issues for Era. Now, we need to re-learn how we operate. Developer friction on any chain, no matter who runs it, harms the Elastic Network as a whole.

Full interop support

But it’s not only about having N chains, right? All of these chains will be able to interact with each other natively.

The interoperability is much more than just protocol capabilities and specifications. The tooling must provide the required level of convenience.

Sending a cross-chain message should be a simple method in the SDK. You should be able to replay an interop transaction locally, just like you can replay any other transaction with anvil-zksync. When you see a cross-chain transaction in the explorer, you should be able to reach the destination counterpart in one click.

Overall, developing cross-chain applications must be as easy as building common dApps on a single chain.

Stable releases

No more fear of having to update your dependency. No more wondering what’s even inside of the update.

We’re actively working on raising the bar for our releases. You can expect timely announcements, changelogs with meaningful information, and no accidental breaking changes.

Our goal for this year is to develop release calendars that would be:

• Externally observable (you will know which features will go into the next release)

• Predictable (you will know when the release should happen)

• Documented (if something the released, the documentation must be updated).

Consistent communication

We are always working on many exciting features in parallel, but we don’t always promote them as much as they deserve. We added TEE verification to our sequencer as an additional security measure in summer 2024, but it took us half a year to actually write a blog post about it.

Who knows how much else cool stuff is already available on ZKsync or will be available shortly?

Well, soon you will!

We are now working with all the internal teams to make sure that any feature gets appropriate coverage, from early announcements through demos and showcases to the release.

Smart Sign-On

Have you heard about ZKsync Smart Sign-On (SSO)? Hope you did, because that’s a very sleek way to interact with Web3, powered by passkeys and sessions. If you didn’t, definitely try it out and check the docs! Or at the very least, check out this video 👀

ZKsync SSO was rolled out to the ZKsync Era testnet in December, and now our goal is to make it available on many chains in the Elastic Network.

Besides reaching the mainnet, here’s a sneak peek of what you can expect:

• Advanced account recovery options (multiple passkeys, guardian accounts, social recovery)

• Interop support out of the box

• Integrated fiat-to-crypto onramps

Note that SSO on its own is not a wallet, it’s a smart account (with a sprinkle of magic) and it’s open source. So if you’re interested in providing great UX for your users on ZKsync, it’s certainly worth checking out.

foundry-zksync 1.0

Foundry is a fantastic toolkit for Ethereum application development. It quickly becomes a central part of the modern Ethereum developer stack. It will soon reach a 1.0 release, becoming a mature and stable product.

Foundry-zksync is a much younger product, and it only recently got out of the alpha stage, but we put a lot of effort into making sure that ZKsync developers get all the power of the Foundry stack, and more.

And in 2025, we’re going to reach a 1.0 release as well!

Main criteria here:

• foundry-zksync can be installed alongside “vanilla” foundry and you can use both at the same time

• Feature parity with upstream Foundry

• Custom features specific to ZKsync, such as interop support.

Who are “we”?

We use the word “we” a lot here. But who’s hiding behind this work?

A lot of people, actually.

First and foremost, two teams within Matter Labs: DevEx and DevRel. The former is responsible for working on the tooling, the latter works hard to get you great documentation, up-to-date tutorials, and cool events.

Then, it’s two amazing teams who dedicate a lot of their time to the tooling:

TxFusion, who works on the SDKs, hardhat, explorer, and portal.

MoonSongLabs, who works on foundry-zksync and zkstack CLI.

And now, the exciting part: the developers of many Elastic Chains! We already receive contributions from external teams that both fix issues and bring new cool features, and we hope that the number of such contributions will grow significantly during 2025.

And finally, maybe, you?

We have prepared a coordination channel for all the people who want to build ZKsync to make it easier to build on ZKsync. If you want to be on the frontier of ZKsync development, join us!

… and beyond

You may notice that there are very few “concrete” promises in this roadmap. That’s intentional.

As we stated in the beginning, our main focus is to provide a polished, predictable, and hopefully magic experience for all the Elastic Chains developers. That doesn’t mean shipping X new fancy things, that means changing how we work. That’s going to be tough, but we’re up to the challenge.

ZKsync Builders Hub

Home for ZKsync builders. https://x.com/zkSyncDevs

https://t.me

Union Chain is a ZK Chain designed to bridge the worlds of Crypto and Traditional Finance (TradFi) by uniting top centralized crypto exchanges (CEXs) and licensed real-world asset tokenization leaders with top Blockchain technology to build, issue, distribute, and transact on one chain. This opens up new markets and use cases for digital assets and tokenized financial products to cater to crypto natives and the next billion crypto users.

Union Chain will be led by Wei Zhou, Chairman of Union Chain (CEO of Coins.ph and former CFO of Binance), and Junde Yu as CEO, (formerly VP at Cobo VP, and MD/GM at Data.ai).

Union Chain: Bridging TradFi and Crypto

Union Chain was created to bridge TradFi and Crypto, solving fragmentation, regulatory hurdles, and interoperability issues. Leveraging regional licenses, on/off-ramps, local stablecoins, and the reach of exchanges, Union offers toolkits for licensing, fiat integration, and distribution, enabling seamless interaction between the two worlds. This opens up markets and use cases between TradFi and Crypto.

Key verticals of Union Chain’s testnet would include:

• RWA: By leveraging the licenses and expertise of InvestaX (CMS, RMO) and the regulated CEXs, Union goes beyond the typical tokenization platform to provide a full stack of RWA solutions with services across structuring, issuance, tokenization, distribution, and fiat on/off ramps to ensure a seamless experience for TradFi companies bridging into Crypto.

• Payments/Remittance: Providing access to the on/off-ramps and local stablecoins of Indodax (Indonesia), Coins PH (Philippines), Coinhako (Singapore), and Coins TH (Thailand), Union Chain offers faster, cost-effective remittance solutions tailored for Southeast Asia.

• Regional enterprise adoption: Equipped with regional licenses, expertise, user access, and support teams, Union is best positioned to provide regulated blockchain solutions with locally licensed and compliant frameworks to scale adoption for the SEA market and, subsequently, the broader Asian market.

• Broad Market Access:  Developers on Union gain access to >20M KYC’ed users in a total addressable market of 600M users. Union is also planning to work with additional CEXs in the future.

ZKsync Technology & The Elastic Network, A New Era For Blockchain Utility

This strategic initiative represents a significant milestone in the evolution of blockchain technology. By integrating Union Chain’s regulated infrastructure with ZKsync’s scalability and security, this initiative is poised to transform the landscapes of both web3 and TradFi, delivering unmatched compliance, reach, and technological sophistication.

Leading regulated crypto exchanges in Southeast Asia choosing to leverage ZKsync technology further demonstrates that the Elastic Network is the key ecosystem for entities looking to tokenize assets. The ZK Stack infrastructure enables financial institutions to tokenize and issue compliant RWAs through the Union Chain. Similarly, by incorporating top regulated exchanges and issuers onto the chain,  Union Chain will facilitate the flow of crypto liquidity and yield into TradFi through enhanced distribution, packaging, and fiat capabilities, giving institutions access to lower transaction costs, more sources of liquidity, and higher yields through trusted on/off-ramps.

Wei, Chairman of Union Chain and CEO of Coins.PH, stated:"We are excited to work with ZKsync’s cutting-edge ZK technology and the top-regulated exchanges in Asia to bring crypto liquidity and innovation to the world, setting new standards for compliance and user safety.

Alex Gluchowski, Co-Inventor of ZKsync, commented, “The integration of ZKsync with Union Chain marks a pivotal moment in the evolution of blockchain technology. Combining ZKsync’s scalability and security with Union Chain’s regulated infrastructure is another large step in bridging the gap between crypto and traditional finance while also shaping the future of global finance. This initiative is a testament to the potential of blockchain to drive innovation, unlock new opportunities, and serve millions of users worldwide. ZKsync has established itself as one of the premier infrastructures for those looking to tokenize assets, and the launch of Union Chain is a further testament to that fact.”

Julian, CEO of InvestaX & IX Swap, stated:"Union Chain is delivering what no other protocol has achieved - an institutional-grade RWA Layer 2 on Ethereum, seamlessly connecting millions of crypto users with regulated financial infrastructure. This ecosystem enables fiat-to-stablecoin conversion and direct investment into RWA tokens across six regulated platforms while simultaneously bridging crypto liquidity and yield into TradFi markets. By providing RWAs to crypto exchange users and unlocking new capital flows for traditional finance, Union Chain establishes the full lifecycle for RWA issuance, investment, and trading. With compliance at its core, every partner involved is a licensed entity, ensuring trust and accessibility for both institutional and retail investors."

William, CTO of Indodax, stated:"“Union Chain is a major step forward for Indonesia and Southeast Asia’s digital economy. As part of the founding team, we see a huge opportunity to leverage blockchain technology, DeFi, and tokenization to solve real financial challenges in emerging markets. By enabling secure and transparent RWA-based lending and funding solutions, we are making SME financing more accessible, helping businesses grow and thrive. At the same time, we are revolutionizing remittance services, ensuring faster, more cost-effective, and seamless cross-border transactions. This initiative bridges the gap between traditional finance and digital assets, creating new financial opportunities for millions across Indonesia and Southeast Asia.”

About Union Chain

Union Chain is a groundbreaking Layer 2 blockchain that bridges the worlds of crypto and traditional finance (Tradfi) by uniting top-regulated companies with top Blockchain companies to build, issue, distribute, and transact on one chain. This opens up new markets and use cases for digital assets and tokenized financial products to cater to crypto natives and the next billion crypto users.

For more information or media inquiries, please contact: press@unionchain.io

About ZKsync

ZKsync is the pioneering zero-knowledge technology powering the next generation of builders with unlimited scale. Secured by mathematics and designed for native interoperability, ZKsync enables an elastic, ever-expanding network of customizable chains. Deeply rooted in its mission to promote personal freedom for all, ZKsync technology puts digital property within everyone's reach.

For more information about ZKsync, visit http://enterprise.zksync.io.

A strategic step toward modernizing digital gold investments with blockchain technology

Overview

UBS recently conducted a technical proof-of-concept (PoC) for tokenized gold, testing ZKsync Validium, a Layer 2 (L2) blockchain solution designed to scale Ethereum while maintaining privacy. Financial service providers leveraging Ethereum must adopt strategies to maximize the network’s utility.

The goal of the technical PoC was to address challenges in scalability, privacy, and interoperability as UBS experimented to expand UBS Gold into global markets, in a test environment. Following a thorough evaluation of blockchain options, ZKsync Validium was selected for its ability to meet the specific requirements of a hypothetical tokenized gold network. This PoC reflects UBS’s continued efforts to explore how blockchain can enhance its financial offerings.

Selecting ZKsync Validium

To address these challenges, UBS evaluated multiple blockchain technologies and identified ZKsync Validium as a promising choice. ZKsync Validium addresses three critical needs:

• Enhanced scalability: High transaction throughput at lower costs by storing data off-chain

• Privacy: Transaction data is stored off-chain, ensuring confidentiality for users

• Interoperability: Seamlessly connects to Ethereum, ‘’the foundational layer for Decentralized Finance (DeFi)’’ (-UBS)  enabling cross-network asset transfers

The PoC: Objectives and Results

The PoC simulated a tokenized gold Network on ZKsync Validium, testing the feasibility of meeting all above mentioned requirements, while assessing cost implications. To achieve this, smart contracts were deployed on a testnet to simulate a gold network. These contracts carried out key functionalities, including: gold token issuance, transaction processing and reconciliation.

Key Objectives:

• Technical feasibility: evaluate operational requirements and implementation options for scalability and privacy

• Business viability: Analyze cost implications under various transaction volume scenarios

Results

The PoC successfully demonstrated UBS’s ability to meet its privacy and interoperability objectives while addressing scalability requirements to a significant extent. By leveraging Validium mode, UBS ensured user privacy, allowing participants to view only their activity while enabling verifiability through Ethereum’s L1 bridge smart contract. Interoperability was also validated in the test as stablecoins bridged from Ethereum were successfully utilized to purchase gold tokens, and dummy tokens were employed to simplify reconciliation processes for back-office operations. While ZKsync’s Validium supported high throughput, achieving optimal cost efficiency would require thousands of transactions per hour, highlighting opportunities for further scalability optimization.

Future opportunities for UBS

Building on the success of the PoC, the results underscored the broader potential for integrating L2 solutions into UBS’s operations. Key opportunities include:

• Future proofing: Preparing for increased transaction volumes without bottlenecks

• Customization: Creating tailored solutions to address specific financial needs

• Customer demand: Meeting expectations for real-time, cost-efficient financial services

• Market access: Seamlessly participating in multichain ecosystem to access liquidity

• Cost predictability: Stabilizing operational expenses to support scalable growth

Conclusion

This PoC highlighted ZKsync Validium’s capability to support UBS privacy and interoperability requirements. By leveraging blockchain technology, UBS continues to explore innovative ways to enhance its financial offerings.

About ZKsync

ZKsync is the pioneering ZK technology powering the next generation of builders with limitless scale. Secured by math and designed for native interoperability, ZKsync enables an elastic network, an ever-expanding ecosystem of customizable chains. Deeply rooted in its mission to advance personal freedom for all, the ZKsync technology makes digital self-ownership universally available.

To learn more about ZKsync, visit https://enterprise.zksync.io/

Abstract joins a half-dozen ZK Chains on mainnet with its deployment to the Elastic Network, powered by ZKsync, to bring Web3 to everyday users.

Abstract, the consumer chain

Abstract, the industry-leading chain for consumer crypto joins the Elastic Network with its mainnet deployment. This launch is accompanied by over 100 consumer-friendly apps ready for users to play with on day one, along with over 200 more to deploy in the following weeks.

Prioritizing user experience without sacrificing crypto’s core- values, Abstract is on a mission to build the world's largest onchain community. With nothing more than an email address, anyone can create an Abstract Global Wallet and unlock access to a thriving ecosystem of hundreds of consumer-friendly onchain apps and projects. By combining the ease of Web2 with the transformative potential of Web3, Abstract provides an intuitive, engaging, and accessible experience, bringing the onchain world to the masses like never before.

Abstract

@AbstractChain

Abstract is only as strong as the teams behind it.

We're crafting an ecosystem powered by unmatched infrastructure to make consumer crypto a reality.

Check out our partners below.

2,595

4:17 PM • Jan 23, 2025

“For too long, the industry has prioritized technology over user experience, creating barriers to mainstream adoption,” said Luca Netz, Abstract Co-Inventor. “The launch of Abstract is more than just a technical milestone—it’s a shift in how everyday users – and not just crypto natives – experience blockchain. We’ve built Abstract to strip away the complexities of crypto, offering an intuitive and enjoyable experience that empowers users to explore and create effortlessly.”

Abstract is built for enjoyment, while under the hood, ZKsync’s tech stack powers this enhanced experience, seamlessly connecting users on the internet, to the internet of money. Abstract’s unique approach is that it isn’t catered towards crypto people, it’s intuitive for the TikTok generation of consumers. In the same way that people don’t select Zoom over Google Meet due to which cloud infrastructure they're using, in the near future, people won’t select Web3 apps based on the underlying technology stack. Instead, the technology, user experience, and benefits to consumers and creators needs to be an order of magnitude better than what they had before.

A key feature of Abstract is the network’s Portal which aims to be a  “Digital Disneyland of Fun” for not only seasoned Web3 power-users, but for anyone with access to the Internet. In addition to applications, NFTs, gamified experiences, and the gamut of web3 projects we’ve seen to date, Abstract’s Portal will put streaming front-and-center. The creator economy, connected directly to their communities, but offering real token-based rewards for both creators and consumers alike will drive a unique behavior blending the power of platforms like Twitch with Web3 incentive models.

“Look at the rise of gaming, sports, hip-hop, and streetwear—an entire generation transformed entertainment, music, and luxury. They shifted the narrative from publisher to streamer, owner to athlete, corporation to artist, and from price tags to culture,” Michael Lee, Abstract co-inventor and CEO of Cube Labs, explained, “Consumer crypto is the tech evolution of this revolution. Abstract brings back what the internet lost—fun, ownership, and creativity—while making it accessible to everyone."

Powered by ZKsync

Abstract joins the ever-growing Elastic Network, powered by ZKsync, to become the 7th chain deployed to mainnet, with several more launching this year. The Elastic Network is an ever-expanding network of chains that deliver convenience, performance, security, verifiability and connectivity all at once. Building and deploying using the ZK Stack enables organizations to focus on developing the platform, its features, and the user-experience, while also supporting their ecosystem and communities without the need to focus resources on maintaining core underlying infrastructures. ZKsync’s ZK Stack touts easy-to-use developer kits that enable any developer  or organization to deploy their own customized L2.

ZKsync

@zksync

Luca went on @theempirepod, to talk about all things @pudgypenguins and @AbstractChain.

Here’s what @LucaNetz had to say about @ZKsync, the tech powering the cultural revolution

262

12:51 PM • Jan 16, 2025

Hear from Abstract’s Co-Inventor, Luca Netz, on why they chose to build on ZKsync.

https://zksync.mirror.xyz/aHYcSWlY2cB-jDd96TdNBmmQosQ77kOVqLqphsbCe6w

Abstract’s mission is to build the largest onchain community and drive the mainstream adoption of Web3. To achieve this, the platform is designed to make developing decentralized apps easier, cheaper, and safer than ever before. By leveraging cutting-edge zero-knowledge (ZK) cryptography, Abstract delivers low-cost, lightning-fast, and highly secure transactions for both users and builders. The platform integrates ZK Stack by ZKsync and Celestia data availability to streamline the development process, while Abstract provides dedicated support to builders, brands and creators ensuring a seamless onboarding experience.

“We've spent the past year reimagining what it means to create crypto experiences that put consumers first. What we're unveiling today reflects those efforts—a first-of-its-kind consumer terminal, a frictionless wallet with limitless capabilities, and a chain powering dozens of consumer-friendly crypto applications,” said Cygaar, CTO of Cube Labs. “None of this would have been possible without our incredible engineering, product, and design teams."

Alex Gluchowski, Co-Founder of ZKsync, commented, “For blockchain to reach the masses, we must abstract away the complexity. Users need to experience better apps, builders need to have more engaged users, and creators need to be rewarded for their efforts - while cutting out unnecessary middlemen. Abstract building for everyone, not just Web3 power-users, is the path to get the next billion onchain.

Abstract joins Cronos (Crypto[dot]com’s zkEVM L2), Zero Network (Zerion wallet’s native L2), Treasure (the leading Web3 gaming community’s L2), Sophon (general purpose L2), GRVT (the hybrid crypto exchange’s L2), and ZKsync Era (the flagship L2 for the elastic network).

To learn more about Abstract, explore The Portal, and join in on the wave of consumer crypto learn more at abs.xyz.

TL;DR: Over the past year, we’ve made building on ZKsync easier and more enjoyable with better tools, integrations, and resources. Highlights include a unified Hardhat plugin, enhanced Foundry and Viem support, the launch of ZKsync SSO and the ZK Stack CLI, and integrations with Alchemy, Chainlink, and Etherscan. Combined with redesigned docs, new tutorials, and exciting updates for 2025 like EVM bytecode equivalence, there’s never been a better time to build on ZKsync!

Over the last year, we’ve been on a mission to make building on ZKsync easier, faster, and more enjoyable. Developer experience has been a big focus for us, and a lot has changed in just 12 months.

It’s not just about the tools we’ve built (though we’re pretty excited about those too). We’ve reworked our documentation to make it clearer and more useful, added deeper integrations with popular frameworks, and made using third-party tools with ZKsync easier. Whether you’re building apps on Era or want to launch your own ZK chain, we want everything to feel seamless.

In this post, we’ll walk you through the key improvements we’ve made and how they’ve transformed the developer experience on ZKsync.

Developer tools: faster, smarter development

We’ve introduced new tools and strengthened integrations with leading frameworks and services.

One of the biggest ways we’ve improved the developer experience on ZKsync is by leveling up our tooling. Whether you use Foundry or Hardhat to write smart contracts or explore new ways to enhance your app’s UX, we’ve got you covered. Here’s what’s new.

Hardhat simplified

We’ve combined all ZKsync plugins (like hardhat-zksync-deploy, hardhat-zksync-upgradable, hardhat-zksync-solc, etc) into a single, streamlined plugin: hardhat-zksync. Now, you get all ZKsync-specific features with one installation. But that’s not all. The updated plugin now supports EVM-like scripts, so there’s no need to rewrite your deployment or proxy upgrade scripts for ZKsync. Migrating your projects to ZKsync just got a whole lot easier.

Find more info in our docs.

Foundry-zksync

Foundry has quickly become the go-to framework for smart contract developers, and for good reason—its performance and testing capabilities are unmatched. We knew we had to prioritize Foundry support, and now, Foundry-zksync offers an almost identical experience as its Ethereum counterpart.

Here’s what’s new:

• EraVM Support: Full integration with our custom compilers and virtual machine ensures smooth testing and deployment.

• Anvil-zksync: Formerly known as era-test-node, this tool is now automatically installed and allows super fast testing and network forks.

• Foundry Book for ZKsync: We’ve written a dedicated version of the Foundry Book that includes step-by-step tutorials to help you get started.

See the foundry-zksync installation details.

Viem and Wagmi: First-class support

Viem is one of the most popular JavaScript libraries, thanks to its speed, modularity, and developer-friendly APIs. With viem/zksync, you now get first-class support for ZKsync-specific features, including:

• Native Account Abstraction: Smart account classes and helpers for paymaster transactions.

• Contract Deployment: Simplify and streamline your smart contract workflows.

• L1-L2 Communication: Easily bridge the gap between Ethereum and ZKsync chains.

This integration ensures compatibility with tools like Wagmi, a popular library for building Web3 frontends. Developers can now use Wagmi out of the box with ZKsync to create modern, responsive, and feature-rich dApp interfaces.

Check out the Viem ZKsync docs.

ZKsync SSO: Revolutionizing UX

User experience is key to onboarding millions of people to Web3, and ZKsync SSO takes things to the next level. This SDK is designed to make integrating modular smart accounts into web applications easier than ever. Here’s what it offers:

• Modular Smart Accounts: Based on ERC-7579 for maximum flexibility.

• Passkeys: Enable biometric authentication for a passwordless experience.

• Sessions: No more manually signing every transaction—users can enjoy seamless interactions.

• Spending Limits: Add an extra layer of security with controlled transaction parameters.

With ZKsync SSO, building user-friendly dApps becomes simpler than ever. Y

Try a live demo of SSO here and get started in our docs.

ZK Stack CLI: a new tool for chain operators

With the launch of the Elastic Network, we knew many developers would want to explore running a ZK chain locally. The ZK Stack CLI simplifies the process of creating and managing an Elastic Chain ecosystem and ZK chains, giving developers more control and flexibility to build and test their ideas.

Try ZK Stack CLI.

Compiler Updates

In 2024, both the zksolc and zkvyper compilers closely tracked their L1 counterparts, unifying the interfaces and supporting new Solidity and Vyper releases within a week of their release.

Alongside compatibility updates, we introduced the following performance improvements and features:

• Deploy-Time Linking: We introduced support for deploy-time linking, which allows you to resolve addresses of libraries after a contract is compiled.

• Faster Compilation Times: Compilation times were halved by implementing the industry-standard LLVM-based post-compile-time (deploy-time) linker. If you're working on a large project and regularly compiling contracts, upgrading to the latest version could significantly speed up the development.

• Gas Consumption Reduction: As per our benchmarks contracts are now consuming 10% less gas. If you’re preparing an upgrade for your contracts, make sure to update the version of the compiler. Your users may notice the difference in a good way.

• Vyper v0.4.0 Support: Despite numerous breaking changes, we duplicated our test database to allow running our CI for both vyper v0.3.x and v0.4.x languages.

• Unification of Interfaces: Standard JSON and combined JSON I/O have been unified to become closer to their solc counterparts, as well as to provide a predictable protocol for tooling such Foundry and Hardhat.

• Disassembler: We implemented an LLVM-based disassembler. If you're interested in inspecting the EraVM bytecode of your contract, pass the compiled contract to zksolc with the --disassemble option.

• IPFS Hash Format: Unblocked several large projects by allowing them to use this method of metadata hashing with IPFS services.

• Multi-Language Support: Allowed compilation Yul, LLVM IR, EraVM Assembly with the same workflow as Solidity and Vyper. The support on the tooling side is yet to come.

Learn more about the ZKsync compilers.

Remix Plugin: Code in your browser

In collaboration with Nethermind, we launched a plugin for the beloved browser-based IDE, Remix. This makes it possible to build and deploy contracts directly from your browser.

Check out the guide to get started.

Third-party integrations

Over the past year, we’ve worked closely with some of the most popular tools and services in the Web3 space to make ZKsync Era even more developer-friendly. Here’s a quick rundown of the key integrations.

Etherscan: your favourite explorer, now on Era

The most popular block explorer, Etherscan, is now available on ZKsync Era. Whether you’re debugging, tracking transactions, or just exploring the ZKsync Era network, you can do it all in a familiar interface. Start exploring Era on Etherscan.

Chainlink: price feeds and CCIP

Chainlink price feeds are now live on ZKsync Era, providing secure and accurate data for DeFi protocols. Additionally, Cross-Chain Interoperability Protocol (CCIP) integration opens up new possibilities for cross-chain applications. These two products were top requirements from many teams and we’re excited to have them available now.

Alchemy: full suite of tools

One of the most popular RPC and tooling providers, Alchemy has fully integrated ZKsync Era. Developers now have access to robust support for RPC nodes as well as additional APIs like the Token API, NFT API, Transfers API, Webhooks, Subgraphs, and more—making it easier than ever to build and scale dApps on ZKsync. Start building with Alchemy on ZKsync.

Native USDC powered by Circle

Native USDC issued directly by Circle is now available on ZKsync Era. This is a big step for DeFi and payments on the network. To avoid confusion, the bridged version of USDC (used in most DeFi apps on ZKsync Era) was renamed to USDC.e. Read the announcement here.

Thirdweb: all-in-one development tools

Thirdweb has added full support for ZKsync Era across all their tools, including:

• Template smart contracts

• CLIs

• Developer utilities

If you’re using Thirdweb to kickstart your projects, you can now leverage their entire suite of tools on ZKsync Era without extra setup.

Documentation & Support: Empowering Developers

We’ve reimagined how developers interact with our resources, from updated documentation to improved support.

• Redesigned Docs: A cleaner, more intuitive site for faster navigation. See the new docs.

• Content Reorganization: Whether you’re building apps on Era, exploring the protocol, or running your own ZK chain, finding what you need is easier than ever.

• Developer Discussions Portal: the ZKsync developer discussions portal has become the to go-to place for devs to get support and help each other. We’ve doubled down our efforts to make sure no question gets unanswered. Visit the discussions portal.

Tutorials and Education: Leveling up your skills

We’ve also introduced new educational content to help developers sharpen their skills and explore ZKsync:

• Quickstart Guides and Tutorials: With the new documentation, we released a new quickstart and 101 sections to help you hit the ground running.

• Cyfrin Updraft Courses: We partnered up with Patrick Collins, one of the most popular educators in the web3 space, and all their courses are now updated with new sections on ZKsync topics. Courses cover blockchain basics, Solidity, Foundry, and Python/Vyper fundamentals. See all courses.

• Community Code: An open source portal with more than 25 tutorials submitted by Matter Labs and community members.

• Hands-On Video Tutorials:

  • 
    
  • 
    
  • 
    

  • Building web3 apps with web2 UX with SSO

  • Alchemy Learn series:

    • 
      
    • 
      

    • Build a web3 app: Part 1 & Part 2

Looking ahead: What’s Next for 2025

With the recently announced 2025 protocol roadmap, we’re excited to keep pushing the boundaries of what’s possible on ZKsync. Big updates like EVM bytecode equivalence are on the way, and we’re doubling down on improving the developer experience.

Here are some of the areas we’re focusing on:

• Foundry: Ensuring complete ZKsync support for all remaining features, so building with Foundry feels seamless and intuitive.

• Improved Debugging Tools: Giving developers better ways to troubleshoot, test, and optimize their smart contracts.

• Third-Party Integrations: Expanding our Chainlink partnership and bringing more tools into the ecosystem.

• ZKsync SSO: Launching the first stable version of the library to make Web3 onboarding smoother than ever.

We’ll share a detailed developer experience roadmap for 2025 in the upcoming weeks. Stay tunned!

We’re dedicated to making ZKsync the best platform for building the future of Web3. With everything we’ve accomplished and what’s coming next, there’s no better time to dive in.

Visit our docs to start building on ZKsync. Let’s create something amazing together!

In a recent appearance on the Blockworks Empire podcast, hosted by Jason Yanowitz and Santiago R Santos, Luca speaks clearly on ZKsync’s competitive edge as the leading tech stack to deploy an L2.

“ZKsync does all the things I need it to. They’re ahead of the curve by a Texas mile on account abstraction. They have low fees, fast transactions, and I believe in that tech stack to power the types of chains we want to build.”

Listen to the full episode here.

ZKsync

@zksync

Luca went on @theempirepod, to talk about all things @pudgypenguins and @AbstractChain.

Here’s what @LucaNetz had to say about @ZKsync, the tech powering the cultural revolution

262

12:51 PM • Jan 16, 2025

Luca Netz’s Vision: Beyond Memes and Markets

Pudgy Penguins has become synonymous with creativity and inclusivity in the crypto space. Netz champions an important principle that blockchain can—and should—reach every demographic, from seasoned crypto investors to youth encountering digital assets for the first time. For Netz, the future of blockchain isn’t just about building infrastructure; it’s about crafting experiences that resonate universally.

“Everybody loves the penguin,” Netz says, underscoring the universal appeal of the Pudgy Penguins brand. From toys on retail shelves to viral social media content, Pudgy Penguins demonstrates how blockchain-backed IP can connect with diverse audiences.

ZKsync: The Technology Empowering Visionaries

A critical enabler of Netz’s vision is ZKsync due to its account abstraction and interoperability. With ZKsync, founders like Netz can focus on building consumer-facing experiences without worrying about the technical friction that often deters mainstream users.

“The ZK stack is lightyears ahead,” Netz noted, praising ZKsync for solving hurdles like low fees, fast transactions, and seamless user interactions. This combination of advanced technology and intuitive usability makes ZKsync a cornerstone for projects that want to focus on building consumer applications without reinventing the underlying technology

Cultural Phenomena: The Key to Mass Adoption

Netz’s emphasis on creating cultural relevance within blockchain is a guiding principle for projects looking to succeed in web3. He argues that memes, tokens, and NFTs shouldn’t remain stagnant symbols. Instead, they should evolve into cultural phenomena that inspire demand and emotional connection.

“Why stop with a singular image or a token?” Netz asked. “The highest upside for these tokens is for them to become cultural phenomena.” Pudgy Penguins exemplifies this philosophy, blending blockchain innovation with mass-market appeal through retail partnerships, viral media, and community engagement.

ZKsync’s Role in Fostering Innovation

For Netz, ZKsync is not just another platform, but a tool for creators and entrepreneurs to push boundaries. By eliminating barriers like high transaction fees and clunky user interfaces, ZKsync enables projects like Pudgy Penguins to thrive on a global scale. Its commitment to open-source development and inclusivity mirrors Netz’s belief in making blockchain accessible to everyone.

“We’re not just building for Ethereum or Solana; we’re building for crypto,” Netz says, highlighting ZKsync’s chain-agnostic appeal and its role in fostering collaboration across ecosystems.

Looking Ahead: A Blueprint for Blockchain Success

As blockchain technology matures, the lessons from Netz and ZKsync’s collaboration offer a blueprint for success. By combining technological innovation with cultural resonance, projects can break free from niche markets and capture the imagination of the mainstream.

Whether it’s through the charm of a penguin or the efficiency of ZKsync’s architecture, the future of blockchain lies in creating experiences that are as engaging as they are empowering. As Netz continues to build bridges between cultures and technology, ZKsync stands ready to support those who dare to dream bigger.

About ZKsync

ZKsync is the pioneering zero-knowledge technology powering the next generation of builders with limitless scale. Secured by math and designed for native interoperability, ZKsync enables an elastic, ever-expanding network of customizable chains. Deeply rooted in its mission to advance personal freedom for all, the ZKsync technology makes digital self-ownership universally available.

To learn more about ZKsync, visit http://www.zksync.io

Tradable’s mission is to bring web3 technology to traditional asset managers and tokenize institutional grade investment opportunities, enabling access to high-quality, wealth-generating assets for new and existing investor bases. The next generation of wealth advisory, treasury management, neobanks, regulated trading venues, and financial transactions will be on-chain, and Tradable enables connectivity between the world’s leading asset managers and powerful web3 financial technology.

“Tradable seamlessly bridges the on-chain / off-chain divide, while abstracting away all the complexity of adopting web3 technology,” said Alex Cordover, CEO of Tradable. “By leveraging blockchain rails, we’re enabling the supply side to provide any arbitrary institutional grade asset, starting with best-in-class private credit opportunities, to any number of demand side investors, whether on-chain or not.”

Separately, Tradable has also received a strategic investment from ParaFi Capital (“ParaFi”), an alternative asset management and technology firm focused on the digital asset ecosystem. ParaFi joins existing Tradable ecosystem partners Victory Park Capital (“VPC”), Janus Henderson Group (“Janus Henderson”), Matter Labs, and Spring Labs, who have been instrumental in supporting the development, rollout, and expansion of Tradable’s innovative platform.

Ben Forman, Founder and Managing Partner of ParaFi, stated, “We're excited to collaborate with Victory Park Capital and Matter Labs on building the future of private credit on-chain. The potential to modernize the backend of capital markets shines bright for blockchain, and Tradable's blend of financial expertise, commitment to compliance, and institutional user-friendliness positions the firm strongly in the pursuit of that objective.”

Tradable’s on-chain technology is built on ZKsync, allowing for the creation of an efficient, cost-effective, and secure process for institutional asset managers to migrate investment strategies on-chain and access a broader investor base. The security, interoperability, customization, and confidentiality features of ZKsync’s tech empower financial institutions like Victory Park Capital to fully capitalize on tokenization and confidently transition eventually to an entirely on-chain issuance and value transfer model.

Alex Gluchowski, co-inventor of ZKsync, said, “Tradable is making it possible to benefit from high-quality, institutional-grade investments, democratizing financial opportunities that were previously out of reach. This aligns perfectly with the mission of ZKsync technology, which was made to advance personal freedom through the mass adoption of crypto. By bringing these assets on-chain in an efficient, cost-effective, and compliant way, they’re ensuring more access to high-quality financial tools. This is the value of ZKsync offering user-friendly and scalable technology, to bring such advancements without sacrificing security or decentralization.”

“We are strong believers in Tradable’s mission to build towards a tokenized financial future,” said Richard Levy, CEO, CIO, and Founder of VPC. “The existing network and the waitlist of customers eager to leverage the Tradable platform is a testament to growing demand from institutional asset managers seeking a user-friendly, compliant, secure, and efficient way to tokenize their strategies and tap into new pockets of investor capital.”

By building technology that smooths the asset tokenization and distribution processes, Tradable is rapidly growing an ecosystem of leading institutional partners which will be key to driving market-wide adoption.

Nick Cherney, Janus Henderson’s Head of Innovation, elaborated: “As a global asset manager, we view blockchain technology as possibly one of the most disruptive future developments in financial services. The path and pace of that disruption will be set by the efficiency and adoption of tokenization of traditional (real world) assets, and Tradable is bringing together key players across alternative and traditional finance which is the critical path to broad adoption of tokenization.”

To view Tradable’s tokenization metrics, please visit https://app.rwa.xyz/private_credit.

About Tradable

About Tradable

Tradable’s technology platform helps leading asset managers (originators) adopt web3 technology and grow AUM by reaching a new on-chain investor audience. Investors are able to access institutional quality opportunities via an intuitive interface built to simplify asset discovery and due diligence. Tradable has developed secure smart contracts for deal representation and AML/KYC/KYB/KYT compliance. Tradable’s blockchain-based systems improve on traditional marketplaces by enabling on-chain investments and programmatic execution of key tasks while maintaining a high bar of asset quality. Tradable is led by seasoned fintech operators with backgrounds spanning payments, marketplaces, AI, web3, trading, and private credit. For more information, visit tradable.xyz.

About ZKsync

ZKsync is the pioneering ZK technology powering the next generation of builders with limitless scale. Secured by math and designed for native interoperability, ZKsync enables the elastic network, an ever-expanding ecosystem of customizable chains. Deeply rooted in its mission to advance personal freedom for all, the ZKsync technology makes digital self-ownership universally available. For more information, visit zksync.io.

The article also provides instructions on how to verify these proofs using the verify-era-proof-attestation tool with Docker. The main takeaway is understanding how TEEs improve blockchain security through isolated, secure computations and how to verify these proofs programmatically.

What is a TEE?

A Trusted Execution Environment (TEE) is a secure area inside a hardware device to protect sensitive operations and data from external attacks or unauthorized access. It provides an isolated environment where encryption, decryption, authentication, and other security-critical functions can be executed while ensuring confidentiality and integrity.

Key features of TEEs include:

1. Isolation: The TEE is isolated from the main operating system and applications running on it, making it more difficult for attackers to access or tamper with the data being processed within the TEE.

2. Hardware-Based Security: Many TEE implementations leverage hardware security features such as Trusted Platform Modules (TPMs), secure enclaves, or hardware-based encryption accelerators to enhance security posture.

3. Attestation: TEEs can provide attestation services, allowing other systems to verify certain TEEs ran the correct computation on the correct data.

4. Confidential Computing: TEEs enable confidential computing by ensuring that data processed within the environment remains encrypted and protected from both software and hardware vulnerabilities outside the secure area.

5. Secure Key Management: They facilitate secure management and storage of cryptographic keys, which are essential for encryption and decryption processes.

TEEs are widely used in various applications such as financial transactions, mobile payments, identity verification, IoT security, and more. TEEs help protect against data breaches, malware attacks, and other cybersecurity threats by providing a trusted environment for sensitive operations.

What is SGX?

Intel Software Guard Extensions (SGX) is a specific type of TEE built into modern Intel processors. SGX provides a way to isolate specific portions of memory on a device to create an enclave, which is a protected area of execution where code and data are secure and cannot be accessed by any process outside of the enclave. This includes even privileged processes like the operating system or hypervisor, offering a strong defense against many forms of security threats.

Why does ZKsync use TEEs?

ZKsync already uses ZK to prove the validity of the chain. Why do we also use TEEs? One reason is that TEEs can further verify the ZK computation. By using both ZK and TEE provers (multiprover architecture), the chain is even more secure. Another reason is that TEEs are faster than ZK Proofs, so TEEs can help make interoperability between ZK chains faster.

What are ZKsync TEE proofs?

Note*: This section is only meant for developers who want to run our attestation verification tool. If you are not a developer, you can skip to the end! *

The ZKsync TEE proof consist of a cryptographic signature of the block root hash in addition to a SGX attestation report, which contains the signing public key in its report user data. The signing key pair is created inside the TEE and changes every time the TEE starts up. The SGX attestation report is signed by the CPU, which is signed by Intel. The SGX attestation report contains the hash sum of the TEE, called mrenclave.

What are the mrenclave values?

The mrenclave hex strings represent a SHA sum. The initial state (memory, mode of operation, etc.) of the program loaded in the TEE (SGX enclave) is measured and a SHA sum is calculated. This SHA can be calculated beforehand from the executables and assets. So by rebuilding the TEE contents from source reproducibly and getting to the same hash, we can verify that the TEE was running the source.

What does the ZKsync TEE prover prove?

The TEE prover is given all input and the expected partial state merkle tree, which produces the block root hash. Now the TEE prover runs the transactions in its VM and checks at the end, that the same merkle tree was produced. If that was the case, it signs the root hash with its signature key.

Running the verify-era-proof-attestation tool

At the time of writing this, ZKsync Era has TEE proves from block 493218 on. To verify those programmatically, we use the verify-era-proof-attestation tool. For portability reasons, the tool is shipped as a docker container. Check with --help for more arguments.

The source code for this can be seen in the teepot repository and this document uses version v0.4.0.

The TEE prover from the zksync-era repo has mrenclave 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65 for version core-v25.0.0 and 6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a for core-v25.1.0.

Run this on an x86 Linux computer to verify all batches from 493218 to the current:

docker run --env RUST_LOG=INFO -i --rm matterlabsrobot/verify-era-proof-attestation:v0.4.0 \
    --log-level=info \
    --rpc https://mainnet.era.zksync.io \
    --sgx-allowed-tcb-levels Ok,SwHardeningNeeded \
    --mrenclaves 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65,6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a \
  --continuous 493218

This should verify all blocks until at least block 494489:

INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493218 signature=f7feaeba077215e9fe693a95ff484f373a64a237feb939966e4299c0cb5dadf720b29aa590b30fe3fcfba1208602186caa49c43418d88cb1f2e09fbbabbf8887
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493218 proof.proved_at="2024-11-13T11:04:39.202856Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493219 signature=c8c08c32fec52dc9f315e24c6710220a461da61bea78db690df416b1294a57b1492661e8ec539ee0a98b7bb9d1eb6bab92771694b6eccdf57e77e7208a9c7152
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493219 proof.proved_at="2024-11-13T11:05:16.664133Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493220 signature=e836d0b209bb35aea6b19480bdf4747670d3bbebeeadce5dd7cadb5d08e2d73d3a219a13158b9e3d3ee36004c79c391373f2f9ebebd6a18e0aabf98a65f04580
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493220 proof.proved_at="2024-11-13T11:05:54.828465Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493221 signature=15a66df5c078cee10d9d8ee889730141cf2dbfa021f0ded22955e954ccd6917838b96a84d680b21a468c85c7d62a687af58e82e91d3defc846edac0e6478f576

(...)

The next used mrenclave value for v25.2.0 is expected to be 2174b836363c1def6e6893b07839753351e10199fc0b489c2233b516e244ec9d.

How can I verify the mrenclave values?

On a fast x86 Linux system with docker installed, run:

git clone --recurse-submodules https://github.com/matter-labs/zksync-era.git
cd zksync-era
git switch --recurse-submodules -c b25.0.0 tags/core-v25.0.0
docker run --privileged -it -v .:/mnt nixos/nix:2.18.1

Then run inside the container shell and answer all question with N.

echo 'experimental-features = nix-command flakes' >> /etc/nix/nix.conf
echo 'sandbox = true' >> /etc/nix/nix.conf
cd /mnt
nix build -L .#container-tee-prover-azure
cp result oci-image.tar.gz

It will run for a long time, and build a lot of software from source. After it is finished, don’t close the session, but switch to another terminal in the zksync-era directory and run:

export IMAGE_TAG=$(docker load -i oci-image.tar.gz | grep -Po 'Loaded image.*: \K.*')
docker run -i --rm $IMAGE_TAG "gramine-sgx-sigstruct-view app.sig"

Which gives the following output:

Attributes:
    mr_signer: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d
    mr_enclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65
    isv_prod_id: 0
    isv_svn: 0
    debug_enclave: False

Now, let’s checkout tag core-v25.1.0 from the non-container/host shell:

git switch --recurse-submodules -c b25.1.0 tags/core-v25.1.0

Back to the container shell and still answer any questions with N:

nix build -L .#container-tee-prover-azure
cp result oci-image.tar.gz

This build should be faster, due to most artifacts already built.

Back to the outside host shell:

export IMAGE_TAG=$(docker load -i oci-image.tar.gz | grep -Po 'Loaded image.*: \K.*')
docker run -i --rm $IMAGE_TAG "gramine-sgx-sigstruct-view app.sig"

Which gives the following output:

Attributes:
    mr_signer: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d
    mr_enclave: 6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a
    isv_prod_id: 0
    isv_svn: 0
    debug_enclave: False

Those mr_enclave values should match those used previously in the verify-era-proof-attestation tool.

What’s next for ZKsync TEEs?

In 2025, you can look forward to TEEs helping with ZKsync’s interoperability, as well as acting as a security backup for ZK proofs.

If you’d like to get in touch, join our Discord.