Recently we published a DevEx 2024 recap, but we’ve got more to share. The whole 2025 is ahead of us, so let’s talk about it. We’re hyped, and we have a lot of plans.

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

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.

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?

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.

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.

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).

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.

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 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.

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!

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