Web3 API

zkSync 2.0 fully supports standard Ethereum JSON-RPC API.

As long as the code does not involve deploying new smart contracts (they can only be deployed using EIP712 transactions, more on that below), no changes for the codebase are needed.

It is possible to continue using the SDK that is currently in use. Users will continue paying fees in ETH, and the UX will be identical to the one on Ethereum.

However, zkSync has its own specifics, which this section describes.

EIP712

To specify additional fields, like the token for fee payment or provide the bytecode for new smart contracts, EIP712 transactions should be used. These transactions have the same fields as standard Ethereum transactions, but also they have fields which contain additional L2-specific data (fee_token, etc):

"fee": {  "fee_token": "0x0000...0000",  "ergs_per_storage_limit": 100000,  "ergs_per_pubdata_limit": 1000},"withdraw_token": "0x00000...00000","factory_deps": ["0x..."]

• fee is a field that describes the token in which the fee is to be paid, and defines the limits on the price in ergs per storage slot write and per publishing a single pubdata byte.
• withdraw_token is a parameter that should be only supplied for Withdraw operations. Most likely will be removed after the testnet.
• factory_deps is a field that should be a non-empty array of bytes only for Deploy transactions. It should contain the bytecode of the contract being deployed. If the contract being deployed is a factory contract, i.e. it can deploy other contracts, the array should also contain the bytecodes of the contracts which can be deployed by it.

To let the server recognize EIP712 transactions, the transaction_type field is equal to 112 (unfortunately the number 712 can not be used as the transaction_type since the type has to be one byte long).

Instead of signing the RLP-encoded transaction, the user signs the following typed EIP712 structure:

These fields are conveniently handled by our SDK.

zkSync-specific JSON-RPC methods

All zkSync-specific methods are located in the zks_ namespace. The API may also provide methods other than those provided here. These methods are to be used internally by the team and are very unstable.

zks_getMainContract

Returns the address of the zkSync contract.

Input parameters

None.

Output format

"0xaBEA9132b05A70803a4E85094fD0e1800777fBEF"

zks_L1ChainId

Returns the chain id of the underlying L1.

Input parameters

None.

Output format

12

zks_getL1WithdrawalTx

Given the hash of the withdrawal transaction on layer 2, returns the hash of the layer 1 transaction that executed the withdrawal or null if the withdrawal has not been executed yet.

Input parameters

Output format

"0xd8a8165ada7ec780364368bf28e473d439e41c4c95164c23368d368cc3730ea7"

zks_getConfirmedTokens

Given from and limit, returns the information about the confirmed tokens with ids in the interval [from..from+limit-1]. Confirmed tokens are native tokens that are considered legit by the zkSync team. This method will be mostly used by the zkSync team internally.

The tokens are returned in alphabetical order by their symbol, so basically, the token id is its position in an alphabetically sorted array of tokens.

Input parameters

Output format

[
  {
    "address": "0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
    "decimals": 18,
    "name": "ETH",
    "symbol": "ETH"
  },
  {
    "address": "0xd2255612f9b045e9c81244bb874abb413ca139a3",
    "decimals": 18,
    "name": "TrueUSD",
    "symbol": "TUSD"
  },
  {
    "address": "0xd35cceead182dcee0f148ebac9447da2c4d449c4",
    "decimals": 6,
    "name": "USD Coin (goerli)",
    "symbol": "USDC"
  }
]

zks_isTokenLiquid

Given a token address, returns whether it can be used to pay fees.

Input parameters

Output format

true

PubSub API

zkSync is fully compatible with Geth's pubsub API, except for syncing subscription, as it doesn't have meaning for the zkSync network since technically our nodes are always synced.

The WebSocket URL is wss://zksync2-testnet.zksync.dev/ws.