ZKsync NFT Integration: Adding ZKsync Era to an NFT Platform

A ZKsync NFT project deploys its collection and marketplace contracts on ZKsync Era, a ZK rollup that settles to Ethereum. This guide explains what changes for NFT contracts on Era, what the coming switch to ZKsync OS means, and how much work an integration takes.

zkSync 2.0, ZKsync Era and the other names

zkSync 2.0 was the development name of the network that launched on mainnet in 2023 as ZKsync Era. Older material also calls gas "ergs", but the current documentation uses the word gas.

Matter Labs builds chains with a toolkit called the ZK Stack, and Era is one of them. Other ZK Stack chains share a bridge to Ethereum and can pass messages to each other.

The first zkSync is now called ZKsync Lite. It handles payments only and does not run general smart contracts, so NFT projects do not use it. ZKsync announced in December 2025 that it will shut ZKsync Lite down during 2026.

Why an NFT platform considers ZKsync Era

• Fees: Era bundles many transactions and posts one validity proof for them to Ethereum, so each transaction costs less than on Ethereum mainnet, and the proof shows that Era's balances and contract data are correct.
• Native account abstraction: on Era, every account can be a smart contract account. A platform can offer gasless mints, session keys for games and passkey recovery without ERC-4337, the Ethereum standard that needs extra contracts and a bundler service for smart accounts.
• Paymasters: a paymaster is a contract that pays gas for a user, either sponsoring the whole fee or accepting an ERC-20 token instead of ETH, so a buyer at an NFT drop does not need ETH on Era first.
• Solidity: most Solidity contracts compile and run on Era with small changes.

The move from EraVM to ZKsync OS

Era runs its own virtual machine called EraVM, and developers compile Solidity for it with a dedicated compiler, zksolc. Since 2025, Era can also run standard EVM bytecode through an EVM interpreter, and the same contract gets one address when deployed through EraVM and a different address when deployed through the interpreter.

Matter Labs is building a new execution system called ZKsync OS. The ZKsync OS FAQ says ZKsync OS will replace EraVM on ZKsync chains and that EraVM chains will eventually be deprecated, but gives no date. ZKsync OS has these properties:

• ZKsync OS is fully EVM equivalent, so standard compilers and tools such as Foundry and Hardhat work without zksolc.
• ZKsync OS does not support EraVM native account abstraction, so projects that rely on native accounts must move to ERC-4337. The FAQ says support is coming for EIP-7702, which lets a plain wallet run smart-account code.
• ZKsync OS can charge extra gas at the end of a transaction to pay for data it posts to Ethereum, so transactions may need higher gas limits.

A platform built on Era's native accounts and paymasters today may need to rebuild those parts for ERC-4337 later, a rebuild that a platform using ERC-4337 from the start avoids.

ZKsync NFT contracts: differences from Ethereum on EraVM

An NFT contract compiled for EraVM behaves differently from the same contract on Ethereum in these areas:

Signature checks need the most care. Many marketplaces check signed orders with ecrecover, which only works for plain wallets, so such a marketplace rejects orders signed by smart accounts. The marketplace contract should also accept EIP-1271 contract signatures, which matters on ZKsync OS too, because ERC-4337 accounts are smart contracts.

Tooling

• Hardhat with the Matter Labs ZKsync plugins compiles with zksolc, deploys and verifies contracts on Era.
• foundry-zksync is a Foundry fork for Era, while standard Foundry works on ZKsync OS.
• zksync-ethers extends ethers.js with paymaster flows and Era transaction types, and the viem library also supports ZKsync.
• Testing uses a local Era node and the ZKsync Sepolia testnet.

Integration paths

1. New deployment: deploy the collection and marketplace contracts on Era, a path that fits a new drop or a game.
2. Add Era to an existing platform: extend the indexer, the wallet connection and the order book to Era, and keep listings separate per chain.
3. Move an existing collection: bridge the tokens or re-mint them. The shared bridge handles ETH and ERC-20 tokens, so an NFT bridge is custom work. A re-mint takes a snapshot, freezes the original contract and mints copies on Era, but it breaks the on-chain history, so publish a table that maps old token IDs to new ones.
4. Add a paymaster: write or reuse a paymaster contract and fund it, then add limits per user and an allowlist of contracts, so bots cannot drain the paymaster's balance.
5. Audit: hire auditors with ZKsync experience, because compiler and VM differences cause bugs that a general EVM review can miss.

Where ZKsync Era fits

ZKsync Era suits NFT products that need smart-account features: games with session keys, consumer drops with sponsored gas and loyalty programs. NFT trading volume sits mostly on Ethereum mainnet, Base, Solana and a few other chains, so if resale volume drives your revenue, check where your collectors trade before you choose Era.

The NFT Layer 2 development guide compares rollups, the Ethereum NFT marketplace guide covers order protocols that also work on Era, and the scaling and interoperability article explains how rollups connect.

Effort

This is an estimate based on the work listed above, not on quotes. Adding Era to an existing EVM NFT platform takes two or three engineers four to eight weeks, and most of that time goes to deployment changes, signature handling, indexing and tests. A paymaster with spending limits adds one to two weeks, plus audit time.

Frequently asked questions