Custom Tooling
Before the EVM Bytecode Interpreter made standard Ethereum toolchains work directly on ZKsync Era and other ZKsync chains powered by EraVM, several tools were built specifically for native EraVM workflows. This page keeps a high-level reference to those tools so older documentation, repositories, and search results remain understandable. For most new development on ZKsync Era and other ZKsync chains powered by EraVM, standard Ethereum tooling can now be used directly through the EVM Bytecode Interpreter.
EraVM-specific tools
hardhat-zksync
The official Hardhat plugin suite for ZKsync Era and EraVM-powered ZKsync chains. It was used to compile, deploy, verify, and upgrade contracts targeting native EraVM bytecode from Hardhat projects.
The main entrypoint was @matterlabs/hardhat-zksync, which bundled the plugin
suite for compilation, deployment, testing, and verification.
The tooling included @matterlabs/hardhat-zksync together with plugins such as
@matterlabs/hardhat-zksync-solc, @matterlabs/hardhat-zksync-vyper,
@matterlabs/hardhat-zksync-deploy, @matterlabs/hardhat-zksync-verify,
@matterlabs/hardhat-zksync-verify-vyper, @matterlabs/hardhat-zksync-upgradable,
@matterlabs/hardhat-zksync-ethers, and @matterlabs/hardhat-zksync-node.
Because the suite extended standard Hardhat behavior, it could also replace or
conflict with common plugins such as @nomicfoundation/hardhat-ethers.
Multichain projects could require additional care when combining it with
OpenZeppelin upgrades tooling.
- Repository: hardhat-zksync.
foundry-zksync
A specialized fork of Foundry for ZKsync Era and
EraVM-powered ZKsync chains.
It extended forge and cast with ZKsync-aware compilation, deployment, and
testing workflows, including support for zksolc, --zksync execution, and
other EraVM-specific behavior.
The toolchain was typically installed with foundryup-zksync.
It also shipped anvil-zksync for local development and debugging.
Typical workflows used commands such as forge build --zksync,
forge test --zksync, and forge create --zksync.
- Repository: foundry-zksync.
- Documentation: Foundry ZKsync Book.
anvil-zksync
The in-memory local node used for fast development on ZKsync Era and EraVM-powered ZKsync chains. It supported quick local startup, pre-funded test accounts, network forking, verbose execution traces, and replaying remote transactions locally for debugging.
It was the lightweight option for local testing. For workflows that needed deeper Layer 1 and Layer 2 interaction, the Dockerized local setup was the more complete environment.
The anvil-zksync GitHub Action was used to integrate anvil-zksync into
CI/CD workflows for ZKsync Era and EraVM-powered ZKsync chains.
It was mainly used in GitHub Actions pipelines to start a local node in run
or fork mode, then execute contract and integration tests against that
environment.
The action exposed configuration for the network, fork height, port, debug output, target architecture, and log file handling. It was a lightweight way to automate local EraVM testing in pull requests and other CI jobs.
- Repository: anvil-zksync.
- Marketplace: anvil-zksync-action.
Dockerized local setup
The Dockerized local setup provided a fuller local environment for ZKsync Era and
EraVM-powered ZKsync chains than anvil-zksync.
It ran a Postgres database, a local Layer 1 node, and a ZKsync node together so
you could test end-to-end Layer 1 to Layer 2 flows.
This setup was mainly used for integration scenarios that needed both chains present locally.
It was slower to start and heavier to operate than anvil-zksync, but it exposed a broader set of node behavior.
- Repository: local-setup.
Pre-configured rich wallets
anvil-zksync and the Dockerized local setup used the same public,
pre-funded development wallets for local testing.
Use these accounts only in local environments.
Never use their private keys or mnemonics on mainnet or with real funds.
ZKsync External Node
The ZKsync External Node was a read-only replica of the main node for ZKsync Era and other EraVM-powered ZKsync chains. It synchronized chain data from the main node, re-executed transactions locally, and exposed a Web3 API for querying chain state without relying directly on the primary public endpoint.
It was mainly used for archive-style access, local state verification, and running dedicated RPC infrastructure for applications and operators. It could proxy Layer 2 transactions to the main node, but it could not produce blocks, generate proofs, or act as a consensus node.
- Documentation: ZKsync External Node guide
zksync-ethers
zksync-ethers was the JavaScript SDK for ZKsync Era and other EraVM-powered
ZKsync chains.
It was designed to stay close to the ethers interface while adding support
for ZKsync-specific transaction fields and workflows.
It was commonly used for contract deployment, native account abstraction,
paymaster integrations, and Layer 1 to Layer 2 bridging.
- Repository: zksync-ethers
Other SDKs
Additional SDKs were also maintained for ZKsync Era and other EraVM-powered ZKsync chains in Java, Go, Python, and Swift. They provided helpers for contract deployment, native account abstraction, paymaster integrations, and bridging workflows.
- Java: zksync2-java
- Go: zksync2-go
- Python: zksync2-python
- Swift: zksync2-swift
zksync-cli
The all-in-one command-line tool for many workflows on ZKsync Era and EraVM-powered ZKsync chains. It could scaffold projects, start local development environments, inspect transactions, manage wallets, bridge assets, interact with contracts, and configure custom chains.
Older guides may reference commands such as zksync-cli create,
zksync-cli dev, zksync-cli wallet, zksync-cli bridge,
zksync-cli contract, zksync-cli transaction, and
zksync-cli config chains.
It was also used to bootstrap Hardhat-based starter projects and Docker-backed local environments.
- Repository: zksync-cli.
ZKsync Easy On-Ramp
ZKsync Easy On-Ramp was a hosted service for buying ETH and ERC-20 tokens on ZKsync Era with fiat payment methods such as cards, Apple Pay, Google Pay, and bank transfer. It was mainly used as a lightweight purchase flow through the ZKsync Portal, without requiring a custom SDK integration or a separate bridge step.