Home
Developer guide
Getting started
  • Getting started
  • About the testnet
    • Connecting Metamask
    • Important links
    • Feature support status
    • Known issues
    • Try it out!
    • Reporting issues
  • ZK Rollup Basics
    • Contract deployment
    • Important: Account abstraction support
    • Block numbers and time
    • 2.0 Overview
    • Handling of ETH and tokens
    • Fee model
    • Transaction types
    • Transaction formats
    • Confirmations and finality
    • Decentralization roadmap
    • L1 / L2 Interoperability
    • Current limitations
    • Web3 API
  • Understanding zkSync 2.0
  • Home
  • /
  • Getting started
  • /
  • ZK Rollup Basics
  • /
  • Handling of ETH and tokens

Handling of ETH and tokens

zkSync has no "native" token, and the fees can be paid in ERC20 tokens. ETH is an ERC20 token with address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE. In order to allow easy and secure bridging of ERC20 tokens between layer 1 and layer 2, zkSync provides a canonical bridge within its smart contract. Tokens that are bridged this way have the same address on zkSync as on layer 1 and all of them have the same standard ERC20 smart contract code on layer 2.

We call such tokens native or first-class citizen, since they are managed on the protocol level. Anyone can, in a permissionless way, add a new native token to zkSync. While technically any of these tokens can be used to pay transaction fees, the operator may decide which tokens it accepts for fee payment (one possible reason to decline a token for fee payment is to remove the chance of exploitation using worthless, recently created ERC20 tokens).

Last updated: 8/17/2022, 2:45:12 PM
Previous
2.0 Overview
Next
Fee model
Edit on GitHub