ZKsync is a zero-knowledge rollup on Ethereum: it executes transactions off Ethereum and proves their validity with cryptographic proofs verified on Ethereum. It supports Solidity and Vyper, but runs them on its own virtual machine rather than a byte-for-byte copy of the EVM. For a project, this means familiar languages with a set of behavioral differences that must be tested and reviewed explicitly.
Building on ZKsync
Solidity and Vyper sources are compiled with dedicated ZKsync compilers to the network's virtual machine. Most application code works as written, but some low-level behaviors differ from Ethereum. ZKsync has native account abstraction: every account can be a smart contract with custom validation, which enables features such as sponsored fees but changes assumptions about who initiates a transaction.
- Languages: Solidity, Vyper
- Tooling: ZKsync plugins for Hardhat and a ZKsync-adapted version of Foundry
- Differences to check: contract deployment and address derivation, some opcodes and precompiles, gas and data costs
What auditors look at
- EVM differences: code relying on CREATE or CREATE2 address prediction, inline assembly, or specific opcodes that behave differently
- Account abstraction: assumptions that the caller is a simple externally owned account, signature validation, paymaster logic
- L1 to L2 messaging and bridged assets, including authentication of messages coming from Ethereum
- Gas and data cost assumptions copied from Ethereum
- Classic EVM application risks: reentrancy, oracle manipulation, access control
Before requesting quotes
- Confirm the code compiles with the ZKsync toolchain and that tests run against it, not only on a standard EVM
- Flag any inline assembly, factory contracts or address precomputation
- Describe custom accounts or paymasters if your project uses them
- List deployment targets if the same code also runs on other EVM chains