# Getting started
Introducing Cronos zkEVM
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-users/cronos-zkevm-bridge) **before the network is fully decommissioned.**
{% endhint %}
## Introduction
In December 2023 [Cronos](https://cronos.org), a leading open-source blockchain project and ecosystem, announced the launch of Cronos zkEVM Chain public testnet, a zero-knowledge (ZK) layer 2 blockchain network that represents a significant milestone on Cronos' journey towards scalability and mainstream adoption.
Cronos zkEVM is a blockchain network using [ZK Stack](https://zkstack.io/), launched in a partnership between Cronos Labs and engineering teams from Matter Labs (the team behind [ZKsync](https://zksync.io/)), [Crypto.com](https://crypto.com), [VVS Finance](https://vvs.finance/), [Fulcrom Finance](https://fulcrom.finance/en/) and [Veno Finance](https://veno.finance/).
Cronos zkEVM's value proposition includes the following differentiating features:
* Leverages Cronos' vibrant ecosystem of end-users and developers (#CROFam). Utilizes zkCRO, a liquid staked version of CRO, as the gas token.
* Scalable and cost-efficient zero-knowledge proof system leveraging Ethereum security.
* First ZK chain to go live in mainnet besides ZKsync Era, participating in the "end game" of Ethereum scalability.
* "Triple yield" concept supported natively by the DeFi ecosystem: natively yield-bearing cryptocurrencies, DeFi yield, loyalty points.
* Native account abstraction enabling gasless transactions.
To provide feedback, please join the [Discord server]().
# Network status
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-users/cronos-zkevm-bridge) **before the network is fully decommissioned.**
{% endhint %}
## :rocket: **Cronos zkEVM Alpha Mainnet (Chain-id: `388)`**
* **Network status:** :white\_check\_mark: **Live**
* [**Explorer**](https://explorer.zkevm.cronos.org/)
* [RPCs and network details ](https://docs-zkevm.cronos.org/for-developers/json-rpc-api-overview#mainnet)
* L1 : *Ethereum mainnet*
## :test\_tube: Cronos zkEVM Sepolia Testnet (**Chain-id: `240`)**
* **Network status:** :white\_check\_mark: **Live**
* [**Explorer**](https://explorer.zkevm.cronos.org/testnet)
* [RPCs and network details ](https://docs-zkevm.cronos.org/for-developers/json-rpc-api-overview#testnet)
* [Testnet faucet](https://zkevm.cronos.org/faucet/)
* L1 : *Ethereum Sepolia testnet*
# Architecture
Cronos zkEVM is a customized deployment of the ZK Stack, utilizing zkCRO as the custom gas token.
As a new Layer 2 blockchain network, Cronos zkEVM will coexist with the flagship Cronos EVM chain (EVM compatible Layer 1 built on Cosmos SDK) and Cronos POS chain (aka "layer zero" built on Cosmos SDK). This is aligned with Cronos' vision of a multi-chain world.
The target timeframe for mainnet launch is summer 2024.
## **Leverages Cronos' vibrant ecosystem of end-users and developers (#CROFam)**
\#CROFam is a strong community of users and dapps that have proven their passion and resilience through the bear market.
Partners like VVS Finance, Veno Finance and Fulcrom Finance have crafted high quality apps that deserve to be better known and have the potential to scale in the next market cycle.
The new chain will enable participating apps to scale to the next level.
Cronos zkEVM utilizes zkCRO, a liquid staked version of CRO, powered by Veno Finance, as the gas token. Each zkCRO is backed by a variable amount of LCRO locked on the Cronos EVM chain, which itself is backed by an amount of CRO staked on the Cronos POS chain. The zkCRO/CRO exchange rate varies over time to reflect the amount of CRO staked.
## Scalable and cost-efficient zero-knowledge proof system leveraging Ethereum security
As a Layer 2 on top of Ethereum, Cronos zkEVM leverages the decentralized security of Ethereum to record proofs of its state and user balances.
Cronos zkEVM uses the latest [Boojum](https://zksync.mirror.xyz/HJ2Pj45EJkRdt5Pau-ZXwkV2ctPx8qFL19STM5jdYhc) STARK-based zero-knowledge proof system, which in addition to its ability to run on GPUs with as little as 16 GB of RAM, boasts [amongst the lowest fees](https://l2fees.info/) of any layer 2, with further cost optimizations planned in the near future.
As part of internal performance benchmarks, hyperchain technology can already deliver in excess of 100 transactions per second, with significant performance improvements planned for the coming months. The community is invited to run additional tests and share them with the [Cronos community](https://discord.com/invite/cronos).
## First ZK chain to go live in mainnet besides ZKsync Era, participating in the "end game" of Ethereum scalability
Cronos zkEVM leverages the concept of [Elastic chain](https://zksync.mirror.xyz/BqdsMuLluf6AlWBgWOKoa587eQcFZq20zTf7dYblxsU), an ever-expanding network of ZK rollups, secured by math and natively interoperable under a uniform, intuitive UX. Ethereum’s rollup-centric roadmap successfully reduced transaction fees, but fragmented liquidity and user experience. The recent ZKsync 3.0 upgrade solves this by enabling native, trustless, low-cost interoperability between the chains powered by ZK Stack, Ethereum’s most performant ZK rollup framework.
Cronos zkEVM is linked to Ethereum by a Layer 1 <> Layer 2 bridge secured by Ethereum, which is shared with ZKsync Era and other ZK chains.
## "Triple yield" concept supported natively by the DeFi ecosystem
Cronos zkEVM is partnering with [Veno Finance](https://veno.finance) to enable users to hold natively yield-bearing tokens when they hold crypto assets on the Cronos zkEVM blockchain.
Cronos zkEVM has the potential to create an entire ecosystem of dapps that treat yield-bearing tokens as first class citizens and can effectively compete in a high interest rate economy.
By holding yield-bearing tokens, users can access the staking yields and stablecoin savings yields while at the same time participating in DeFi protocols and by being an active community member, creating an opportunity for **"*****Triple Yield".***
Triple yield means that users may accumulate rewards **in three ways**:
* **Staking rewards:** Earn yields simply by holding yield-bearing tokens such as zkCRO, vETH, or vUSD, powered by Veno Finance.
* **DeFi yields:** Put crypto-assets to work by deploying them into various DeFi protocols hosted on the Cronos zkEVM blockchain.
* **Pioneer Program rewards:** Additional rewards from participating dapps (to be announced at a later stage) for users who completed certain types of actions that benefited the whole ecosystem.
## Native account abstraction enabling gasless transactions
Like other ZK chains, Cronos zkEVM offers native account abstraction implemented at the protocol level.
Account abstraction has been possible for a while on EVM compatible chains, but it has been challenging for legacy chains to migrate existing liquidity to AA-enabled wallets.
Thanks to AA, users can deposit their funds to the chain and transact with dapps without ever having to switch network. Instead, they can opt to emit off-chain signatures from any EVM home chain, or even from mobile apps or games with usual login.
Dapps on Cronos zkEVM should support AA by default, so that they can take care of relaying transactions to Cronos zkEVM and even pay for gas. This will unleash the power of AA to support mainstream adoption.
See the [ZKsync documentation](https://docs.zksync.io/build/developer-reference/account-abstraction) for details.
# About zkCRO, vETH, vUSD
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## About zkCRO, vETH, vUSD
Cronos zkEVM is partnering with [Veno Finance](https://veno.finance/) to enable users to hold natively yield-bearing tokens when they hold crypto assets on the Cronos zkEVM blockchain.
***
### Understanding zkCRO
zkCRO is a yield bearing version of CRO. It increases in value over time as CRO staking rewards are earned. It is minted on Ethereum directly from CRO, bringing the staking yield earned on Cronos POS into the Ethereum network. zkCRO is bridged to Cronos zkEVM, where it functions as the native token - the token that gas fees are paid in.
#### Backed by LCRO
All CRO deposited into zkCRO is [migrated](https://cronos-pos.org/migration/) to Cronos POS, bridged to Cronos EVM via [IBC](https://docs.cronos.org/for-users/bridge/other_chain) and staked for [LCRO](https://medium.com/@VenoFinance/veno-finance-announces-lcro-backing-for-cronos-zkevm-zkcro-token-d7748c1279b3). LCRO is a yield bearing token based on CRO. This provides the following advantages:
* **Leverage Liquidity**: Users that wish to redeem their zkCRO for CRO, can receive LCRO almost immediately and can sell LCRO into the already existing Liquidity on Cronos EVM if they want to circumvent the unstaking period of 28 days.
* **Rewards Sharing**: 50% of all validator rewards collected by Veno Finance through LCRO are returned back to [VNO depositors](https://docs.veno.finance/veno-finance/protocol/reservoir) on Cronos EVM,
* **Insurance Module**: LCRO has an existing [mechanism](https://docs.veno.finance/veno-finance/protocol/reservoir) to provide insurance against the risk of a slashing penalty.
For details of zkCRO, visit the following pages:
* [zkCRO](/getting-started/about-zkcro-veth-vusd/zkcro)
* [zkCRO](/getting-started/about-zkcro-veth-vusd/zkcro#how-to-obtain-zkcro)
* [zkCRO](/getting-started/about-zkcro-veth-vusd/zkcro#how-to-redeem-zkcro-for-cro)
***
### Understanding ybETH, vETH, ybUSD and vUSD
The Cronos zkEVM blockchain aims to support yield generating tokens as first class citizens while at the same be fully interoperable with the larger ZK ecosystem. The design goals of vETH and vUSD are as follows:
* Interoperability: The yield can be transferred together with the token across chains
* Stability: The value of the yield earning token should stay close to the underlying token. The reason for this is that most users will struggle to trade vETH and vUSD if their value is not aligned with that of ETH and USD.
#### Interoperability
On the current Zksync shared bridge any token that is deployed on Ethereum and deposited into the bridge contract on Ethereum will have a corresponding token contract on the layer 2 chain. This token contract is deployed by the bridge itself and conforms to the ERC-20 standard. However, any additional custom logic is not included in the deployed default token contract on Layer 2. This has two implications:
* Any actions on the original deployed contract that are outside of the ERC-20 specifications will not be synchronized to bridged tokens deployed on any other network.
* The token value itself needs to include any earned yield
The tokens ybETH and ybUSD are designed to meet these requirements. They are standard ERC20 tokens, fully interoperable with the ZKsync shared bridge. Both tokens are yield-bearing, and their value changes over time relative to ETH and USD, in order to reflect the accumulated yield.
#### Stability
Most users wish to use yield generating tokens as if they were the same as the underlying. For example a yield generating stablecoin should always be pegged to 1 USD. However, a yield-bearing token cannot be both pegged to the underlying and interoperable, because custom token logic is not supported by the bridge.
This is why Veno Finance introduced two pairs of tokens: the interoperable "yb tokens" (ybETH, ybUSD) and the stable v tokens (vETH, vUSD). ybETH and ybUSD are interoperable tokens that can transfer both principal and yield across chains. vETH and vUSD are stable tokens that earn yield, backed by ybETH and ybUSD, visit [ybETH & vETH](/getting-started/about-zkcro-veth-vusd/veth/ybeth-and-veth) and [ybUSD & vUSD](/getting-started/about-zkcro-veth-vusd/vusd/ybusd-and-vusd) for details
ybETH and ybUSD both increase in value over time, while vUSD and vETH are pegged 1:1 to DAI and ETH.
For details of vETH and vUSD, visit the following pages:
* [vETH](/getting-started/about-zkcro-veth-vusd/veth)
* [vUSD](/getting-started/about-zkcro-veth-vusd/vusd)
# zkCRO
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## **What is zkCRO?**
zkCRO is the native gas token of the Cronos zkEVM blockchain.
Powered by [Veno Finance](https://veno.finance/), it is a liquid staked token backed by [LCRO](https://docs.veno.finance/veno-finance/protocol/liquid-cro-staking). This means that each zkCRO is backed by an amount of CRO staked on the Cronos POS chain.
The zkCRO/CRO exchange rate varies over time, to reflect accumulated rewards from CRO staking. When rewards are accumulated, the zkCRO/CRO exchange rate increases. Conversely, in case of slashing event on the Cronos POS chain, the value of zkCRO may be impacted.
### How does it work?
When users deposit Ethereum mainnet CRO on the Cronos zkEVM native bridge, they will receive zkCRO which is a yield-bearing version of CRO. The price of zkCRO is expected to appreciate over time relative to CRO, reflecting the accumulated yield. Conversely, in case of slashing event on the Cronos POS chain, the value of zkCRO may be impacted.
zkCRO is created by the decentralized Veno Finance protocol, in partnership with Cronos zkEVM.
### How to obtain zkCRO
Users can receive zkCRO on Cronos zkEVM by depositing Ethereum CRO on the [Cronos zkEVM Bridge](https://zkevm.cronos.org/bridge). The deposited CRO is staked into the zkCRO contract and mints zkCRO and then bridged to the user’s wallet on Cronos zkEVM.
How to obtain or redeem zkCRO
### How to redeem zkCRO for CRO
Given that each zkCRO is backed by LCRO locked on Cronos EVM chain, users can redeem their zkCRO on Cronos zkEVM chain and they will receive CRO on Cronos EVM chain in return. Steps involved to redeem zkCRO:
1. Withdraw zkCRO from Cronos zkEVM to Ethereum
2. Claim zkCRO & Redeem for LCRO
3. Unstake or sell LCRO for CRO
Users that wish to redeem their zkCRO for CRO can do so via the official [Cronos zkEVM bridge](https://zkevm.cronos.org/bridge). The bridge allows users to withdraw zkCRO for LCRO on Cronos EVM. LCRO can be redeemed for CRO with a 28-32 waiting period. Users that wish to receive their CRO earlier can sell their LCRO within the [Cronos EVM DeFi Ecosystem](https://discover.cronos.org/).
### **How is the yield generated?**
The CRO assets will actually be bridged over to the Cronos EVM chain by Veno Finance, in order to be staked on Veno. This means that the CRO will be sent to Cronos POS chain to be staked. Veno Finance will issue LCRO (liquid CRO) to back every single zkCRO issued, and the corresponding LCRO will be locked on a smart contract on Cronos EVM.
### How to get zkCRO rewards
All rewards earned are already included in the value of zkCRO. The amount CRO that can be received when redeeming zkCRO increases accordingly. So no additional actions have to be taken to redeem rewards earned.
### zkCRO: security considerations
zkCRO has been audited by Slowmist. zkCRO is operated by Veno which also operates LCRO, the backing token behind zkCRO. Veno & LCRO have been operating without incident since their launch in December 2022. Veno’s deployments on Cronos EVM are covered by a [bug bounty program](https://hackenproof.com/company/cronos/programs), incentivizing and rewarding researchers to ethically disclose any vulnerability discovered.
***
### Contract addresses
* Cronos zkEVM Mainnet (Chain ID: `388`) and Etherum Mainnet
For details of contracts and their interactions involved when bridging $CRO and $zkCRO to and from Ethereum (L1) and Cronos zkEVM (L2), and unwraping of $zkCRO, visit [zkCRO](/for-developers/using-zkcro-veth-and-vusd/zkcro)
# vETH
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## What is vETH?
vETH is a ERC20 token which aims to follow the value of ETH, while enabling its holders to accumulate rewards generated by proof-of-stake on the Ethereum mainnet.
vETH is powered by [Veno Finance](https://veno.finance/).
To collect rewards, vETH token holders must claim rewards on a dedicated decentralized application which will be published after Cronos zkEVM mainnet launch. The value of the rewards depends on the rewards generated by ETH staking, and may be impacted by slashing events.
When vETH is locked into DeFi protocols on Cronos zkEVM, the rewards accrue to these protocols so it is the responsibility of these protocols to decide and communicate how these rewards are distributed between users and other protocol stakeholders.
### **How does it work?**
When users deposit ETH on the Cronos zkEVM native bridge, they will receive vETH (Veno Ethereum) which is an asset that aims to approximate the value of 1 ETH. vETH holders will be able to earn yield.
vETH will not appreciate relative to ETH to reflect the accumulated yield, as this would offer a confusing user experience. Rather, vETH holders will be able to claim the accumulated yield from a "Reward Vault" (link to be provided when available) that will be updated every week to account for their new holdings.
Under the hood, vETH is backed by [ybETH](/getting-started/about-zkcro-veth-vusd/veth/ybeth-and-veth#what-is-ybeth), which is a yield-bearing token that appreciates relative to ETH over time.
vETH is created by the decentralized Veno Finance protocol, in partnership with Cronos zkEVM.
### **How is the yield generated?**
The ETH collected by the Cronos zkEVM native bridge will be staked by the Veno Finance protocol into a reputable self-custodial ETH staking platform on Ethereum.
Veno Finance currently uses Kiln’s staking pool on Ethereum [for the existing LETH token on zkSync Era](https://docs.veno.finance/veno-finance/protocol/liquid-eth-staking). vETH is different from LETH, but the staking mechanics are similar.
### How to get vETH rewards
See [Yield rewards](/for-users/yield-rewards)
### **How can users convert vETH back into ETH?**
When users send their vETH to the Cronos zkEVM native bridge on Cronos zkEVM, the vETH is bridged to Ethereum mainnet, and it is used to unlock the underlying amount of ETH from staking pool, potentially minus any slashing penalty that may have been incurred by the staking pool.
This process can take around 1 week (see [here](https://docs.veno.finance/veno-finance/protocol/liquid-eth-staking) on how this works for LETH).
We can refer to [ybETH & vETH](/getting-started/about-zkcro-veth-vusd/veth/ybeth-and-veth#how-to-redeem-veth-into-eth) page for details.
### vETH: security considerations
vETH has been audited by Slowmist. vETH is operated by Veno which also operates LETH on zkSync Era. All deposited ETH is staked within [Kiln’s staking pool](https://www.kiln.fi/kiln-staking-pool), the leading staking infrastructure provider on Ethereum.
***
### Contract addresses
* Cronos zkEVM Mainnet (Chain ID: `388`) and Etherum Mainnet
For details of contracts and their interactions involved when bridging to and from Ethereum (L1 - $ETH) and Cronos zkEVM (L2 - $vETH ), visit [vETH](/for-developers/using-zkcro-veth-and-vusd/veth)
# ybETH & vETH
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## What is ybETH?
ybETH is a yield bearing token powered by Veno Finance, backed by staked ETH. It increases in value as it accrues yield earned from ETH staking rewards. ybETH is deployed on Ethereum and can be bridged via any permissionless chain to other networks, including Cronos zkEVM.
### Why ybETH
ybETH is an important building block of the elastic chain, as it embodies both the value of the staked ETH and the staking rewards earned. This enables seamless bridging of staked ETH across chains.
## What is vETH?
vETH is a wrapper of ybETH on Cronos zkEVM. It splits the principle of ybETH from the yield, pegging its value 1:1 to ETH. This enables yield to be separately distributed to vETH holders. vETH can be used in place of ETH, where an ETH valued asset is desired, while continuing to earn ETH staking yield.
### How to obtain vETH
Users can mint vETH directly from ETH on Ethereum using the [Cronos zkEVM Bridge](https://zkevm.cronos.org/bridge). This only requires a single transaction on Ethereum. Under the hood the ETH is deposited into ybETH, which is bridged to Cronos zkEVM and then wrapped into vETH.
How to obtain or redeem vETH
### How to redeem vETH into ETH
Redeeming vETH back to the underlying ETH is a multistep process:
1. Redeem vETH for the underlying ybETH
2. Bridge ybETH to Ethereum
3. Withdraw ETH from ybETH
Note that ETH withdrawn from ybETH is unstaked and hence there is a waiting period. This waiting period can vary depending on the total demand for withdrawing staked ETH on Ethereum at that time. In most cases users should be able to claim their withdrawn ETH within a day or two, but we have observed periods in which withdrawals took up to 10 days. See the user guide for a step-by-step explanation (available soon).
### How to get vETH rewards
Any address holding vETH earns yield in the form of additional vETH tokens. The yield earned can be viewed on the Missions page (available soon) . The yield will be made claimable some time after the public launch of the Cronos zkEVM network. Users will be allocated claimable yield on a weekly basis based on their average balance holdings. DeFi protocols that hold vETH can forward their yield to their users. If you are the developer of a DeFi protocol holding vETH please [reach out](https://crofam.me/contact) if you need technical support for claiming yield.
###
## How does ybETH & vETH earn yield
All ETH deposited into ybETH are staked within[ Kiln’s staking pool](https://www.kiln.fi/kiln-staking-pool). Once a day the rewards earned from staked ETH are updated in the ybETH contract, increasing the exchange rate from `ybETH:ETH`. Whenever this exchange rate is updated, the `vETH:ybETH` rate is also updated accordingly on the vETH contract on Cronos zkEVM. Ensuring that vETH stays pegged 1:1 to ETH, while minting new vETH ready to be distributed as rewards.
### Are there any fees on ybETH or vETH?
There are no fees on vETH. However, all staking yield earned from the ETH staked through ybETH is subject to a 12% commission, from which half given to the staking infrastructure provider Kiln and the other half to Veno.
***
### Contract addresses
* Cronos zkEVM Mainnet (Chain ID: `388`) and Etherum Mainnet
| Token Name | Symbol | Decimal | Contract Addresses |
| ---------------------- | ------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Veno ETH | vETH | `18` |
|
For details of contracts and their interactions involved when bridging to and from Ethereum (L1 - $ETH) and Cronos zkEVM (L2 - $vETH ), visit this [page](https://docs-zkevm.cronos.org/for-developers/using-zkcro-veth-and-vusd/veth).
# vUSD
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## What is vUSD?
vUSD is a ERC20 token which aims to follow the value of DAI, while enabling its holders to accumulate rewards generated by DeFi protocols such as MakerDAO on the Ethereum mainnet.
vUSD is powered by [Veno Finance](https://veno.finance/).
To collect rewards, vUSD token holders must claim rewards on a dedicated decentralized application which will be published after Cronos zkEVM mainnet launch. The value of the rewards depends on the rewards generated by the underlying DeFi protocols on Ethereum.
When vUSD is locked into DeFi protocols on Cronos zkEVM, the rewards accrue to these protocols so it is the responsibility of these protocols to decide and communicate how these rewards are distributed between users and other protocol stakeholders.
### How does it work?
When users deposit DAI, USDC or USDT on the Cronos zkEVM native bridge, they will receive vUSD (Veno USD) which is a stable asset that aims to approximate the value of 1 USD. vUSD holders will be able to earn yield.
vUSD will not appreciate to reflect the accumulated yield, as this would offer a confusing user experience. Rather, vUSD holders will be able to claim the accumulated yield from a "Reward Vault" (link to be provided when available) that will be updated every week to account for their new holdings.
Under the hood, vUSD is backed by [ybUSD](/getting-started/about-zkcro-veth-vusd/vusd/ybusd-and-vusd#what-is-ybusd), which is a yield-bearing token that appreciates relative to DAI over time.
vUSD is created by the decentralized Veno Finance protocol, in partnership with Cronos zkEVM.
### **How is the yield generated?**
Initially, the stable assets deposit on the bridge will be converted into DAI and invested into the Maker Protocol's DSD (Dai Savings Rate).
Later on, additional yield-generating protocols can be considered.
### How to get USD rewards
See [Yield rewards](/for-users/yield-rewards)
### **How can users convert vUSD back into DAI?**
When users send their vUSD to the Cronos zkEVM native bridge on Cronos zkEVM, the vUSD is bridged to Ethereum mainnet, and it is used to unlock the underlying amount of DAI from the DSR contract. Users then receive DAI on Ethereum mainnet.
We can refer to [ybUSD & vUSD](/getting-started/about-zkcro-veth-vusd/vusd/ybusd-and-vusd#how-to-redeem-vusd) page for details.
### vUSD: security considerations
vUSD has been audited by Slowmist. vUSD is backed by Maker DAO’s sDAI, which has been earning stablecoin yields since 2023. DAI itself has been a staple among stablecoins since its launch in 2017.
***
### Contract addresses
* Cronos zkEVM Mainnet (Chain ID: `388`) and Etherum Mainnet
For details on contracts and their interactions involved when bridging to and from Ethereum (L1 - $DAI/$USDC/$USDT) and Cronos zkEVM (L2 - $vUSD ), visit [vUSD](/for-developers/using-zkcro-veth-and-vusd/vusd)
# ybUSD & vUSD
{% hint style="danger" %}
## **Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets before the network is fully decommissioned.**](/for-users/cronos-zkevm-bridge)
{% endhint %}
## What is ybUSD?
ybUSD is a yield bearing token powered by Veno Finance, backed by sDAI. It increases in value as it sDAI value increases. ybUSD is deployed on Ethereum and can be bridged via any permissionless chain to other networks, including Cronos zkEVM. In order to diversify the risk in the future ybUSD might be backed by a basket of different stablecoin earning yield sources.
### Why ybUSD?
ybUSD is an important building block of the elastic chain, as it embodies both the value of a stablecoin and any yield earned from it. This enables seamless bridging of a yield earning stablecoin across chains.
## Whats is vUSD?
vUSD is a wrapper of ybUSD on Cronos zkEVM. It splits the principle of ybUSD from the yield, pegging its value 1:1 to DAI. This enables yield to be separately distributed to vUSD holders. vUSD can be used in place of a stablecoin, where an USD valued asset is desired, while continuing to earn USD nominated staking yield.
### How to obtain vUSD
Users can mint vUSD directly from DAI, USDC or USDT on Ethereum using the [Cronos zkEVM Bridge](https://zkevm.cronos.org/bridge). This only requires a single transaction on Ethereum. Under the hood the DAI is deposited into ybUSD, which is bridged to Cronos zkEVM and then wrapped into vUSD. If USDC, or USDT is deposited, it is first swapped to DAI on Curve at a 1% slippage, before being deposited into ybUSD. See the user guide for a step by step explanation (available soon).
How to obtain or redeem vUSD
### How to redeem vUSD
Redeeming vUSD back to the underlying DAI is a multistep process:
1. Redeem vUSD for the underlying ybUSD
2. Bridge ybUSD to Ethereum
3. Withdraw DAI from ybUSD
Note that there is no waiting period when withdrawing DAI from ybUSD.
See the user guide for a step-by-step explanation (available soon).
### How to get vUSD rewards
Any address holding vUSD earns yield in the form of additional vETH tokens. The yield earned can be viewed on the Missions page (available soon). The yield will be made claimable some time after the public launch of the Cronos zkEVM network. Users will be allocated claimable yield on a weekly basis based on their average balance holdings. DeFi protocols that hold vUSD can forward their yield to their users. If you are the developer of a DeFi protocol holding vUSD please [reach out](https://crofam.me/contact) if you need technical support for claiming yield.
###
## How does ybUSD & vUSD earn yield
All DAI deposited into ybUSD are deposited into the DAI savings rate module. Meaning ybUSD contract is holding sDAI. As sDAI increases its internal exchange rate from `sDAI:DAI`, so does increase the `ybUSD:DAI` exchange rate within ybUSD. Whenever this exchange rate is updated, the `vUSD:ybUSD` rate is also updated accordingly on the vUSD contract on Cronos zkEVM. Ensuring that vUSD stays pegged 1:1 to DAI, and minting new vUSD ready to be distributed as rewards.
### Are there any fees on ybUSD or vUSD?
There are no fees on ybUSD. However, on all vUSD yield minted, a 5% commission is charged by Veno Finance.
***
### Contract addresses
* Cronos zkEVM Mainnet (Chain ID: `388`) and Etherum Mainnet
| Token Name | Symbol | Decimal | Contract Addresses |
| ----------------------- | ------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Veno USD | vUSD | `18` |
|
For details on contracts and their interactions involved when bridging to and from Ethereum (L1 - $DAI/$USDC/$USDT) and Cronos zkEVM (L2 - $vUSD ), visit this [page](https://docs-zkevm.cronos.org/for-developers/using-zkcro-veth-and-vusd/vusd).
# zkEVM Litepaper v1.0
## Executive Summary
The value creation potential of cryptocurrency is as compelling today as it has ever been. Decentralized financial rails based on open-source blockchain technology have continued to innovate and demonstrate their robustness during some of the most challenging years experienced by the world economy in recent history, marked by a global pandemic, record inflation and intense geopolitical conflicts. Progress within self-custodial DeFi has transformed it from a complex and cumbersome ecosystem to one that is increasingly user-centric. Yet the space is still nascent and shows significant room for optimization and simplification.
The Cronos ecosystem is a prime example of this evolution. During the last several years, the Cronos and Cronos POS blockchain networks have demonstrated their safety and reliability, while building up a passionate user community and a vibrant universe of decentralized applications. It is now time for this ecosystem to prepare for the next level of mainstream and institutional adoption, leveraging its strengths and learning from the bottlenecks and pain points experienced by crypto users.
Driving this evolution is Cronos zkEVM, incubated by Cronos Labs, which aims to further transition liquidity from the control of centralized platforms to a decentralized, on-chain ecosystem. This approach directly addresses some of DeFi's most pressing concerns: the fragmentation of liquidity, the complexity of generating yield, and the cumbersome user experience associated with managing blockchain transactions.
Cronos zkEVM explores the latest frontiers of zero-knowledge layer 2 technology and modular data availability in order to increase transaction speed and reduce transaction costs while delivering strong security. Additionally, the network is set apart by three key features that respond to DeFi's challenges:
1. Shared Liquidity: It enables asset fluidity across hyperchains (which are Ethereum Layer 2s and Layer 3s powered by ZK Stack), addressing liquidity fragmentation.
2. Yield-bearing Assets: Assets such as ETH, CRO, and certain stablecoins natively produce yield on Cronos zkEVM, which simplifies the process for users.
3. Native Account Abstraction: The introduction of Smart Accounts and Paymasters facilitates easier transactions, enhancing the overall user experience.
Leveraging Matter Labs' ZK Stack framework, Cronos zkEVM operates alongside the Cronos blockchain (EVM Layer 1) as a Layer 2 solution that benefits from the security of the Ethereum network. Cronos zkEVM represents a measured step forward in the maturation of the DeFi sector, aiming to address key issues and prepare the ecosystem for sustainable growth and broader adoption.
Cronos zkEVM mainnet will use zkCRO, a yield-generating version of $CRO, as its protocol token, further enhancing the utility of $CRO and leveraging its global addressable user base of more than 80 million #CROFam members.
## Vision
In today’s financial landscape, centralized platforms are known for their efficiency but suffer from trust-based vulnerabilities, while DeFi presents a promising yet sometimes complex alternative. Cronos zkEVM envisions a transformative shift, recentering liquidity from large centralized entities to self-governing decentralized organizations, creating a secure and simple platform that doesn't compromise on user experience.
Cronos zkEVM's vision is underpinned by several core principles:
* Empowering Financial Independence: By promoting self-custody solutions, Cronos zkEVM aims to reduce risks associated with centralized entities, giving users full control over their assets.
* Promoting Fairness and Transparency: Countering the opaque practices of traditional financial entities, it emphasizes transparency based on public, open-source protocols.
* Transforming the Liquidity Landscape: The goal is to shift power from traditional entities to decentralized, self-governing organizations.
To achieve this, scalability in DeFi remains a significant challenge. Zero Knowledge layer-2 networks are posited as a solution, enabling off-chain data and computation execution while maintaining data integrity on the main chain. Cronos zkEVM aims to leverage this technology as a zk-enabled layer-2 built on Ethereum's robust, secure platform. Through utilizing Matter Labs’ ZK Stack framework, Cronos zkEVM is its own sovereign blockchain with seamless connectivity, aligning with our aspiration to provide a trustworthy, scalable, and user-centric blockchain solution.
On another front, parallel execution EVM has emerged as one potential solution for a more sustainable way to achieve scalability. It involves processing multiple transactions simultaneously, rather than the sequential method in traditional blockchain. This is achieved by identifying and concurrently executing transactions that are independent of each other, thereby significantly boosting throughput. For instance, transactions that don’t share common dependencies can be processed in parallel, optimizing the use of network resources. Cronos zkEVM is exploring the integration of parallel execution within its EVM as one of the potential solutions. By exploring this innovative approach, Cronos zkEVM aims to marry the efficiency of centralized systems with the trust and security of decentralized ones, paving the way for scalable, high-performance DeFi applications.
## Mission
Cronos zkEVM embarks on a mission to advance DeFi by tackling its fragmentation and complexity, setting a new standard for efficient, and user-centric decentralized finance. Overall, Cronos zkEVM’s raison d'etre comprises three key goals:
* Unifying fragmented liquidity - A significant pain point in today’s DeFi is fragmented liquidity. Traditionally, liquidity is dispersed across an array of blockchains, leading to a splintered market with inefficiencies at every turn. This results in higher slippage, diminished returns for liquidity providers, and a complex workflow for users who navigate. Cronos zkEVM capitalizes on the interoperability of ZK Stack-based hyperchains, and consolidates scattered liquidity.
* Simplifying Yield Generation - Another layer of complexity arises when users seek to generate yield on their crypto assets. The current process often requires engaging with multiple protocols, each introducing its own set of risks. This cumbersome process not only complicates the yield generation but also poses a barrier to entry for the average user. Our approach simplifies yield generation, making it not only more user-friendly but also safer.
* Intuitive Account Management - Cumbersome user experience in DeFi has been a barrier for mass adoption. For new users, the technicalities of blockchain—such as understanding gas fees, managing wallet addresses, and ensuring transaction security—can be daunting. Native account abstraction on Cronos zkEVM represents a leap forward in user experience. It introduces the possibility for users to interact with DeFi through alternative signature schemes and automated transactions. This not only simplifies the process but also opens the doors to a broader audience, paving the way for a more inclusive DeFi landscape.
## Architecture
Cronos zkEVM operates at a strategic juncture across blockchain networks, enhancing scalability and efficiency. Overall Cronos zkEVM is uniquely positioned among 3 ecosystems:
1. Ethereum ecosystem
2. Hyperchain ecosystem, based on zkSync's ZK Stack
3. Cronos ecosystem
Integrated within the ZK Stack Hyperchain Ecosystem, it connects to the Ethereum Mainnet via a shared bridge, tapping into Ethereum's user base and security while incorporating zkSync's features for secure and efficient cross-chain interactions. As part of the wider Cronos ecosystem, Cronos zkEVM works in tandem with the Cronos blockchain (Layer 1 EVM) and the Cronos POS Chain.
The Cronos blockchain supports diverse DApps with a Proof-of-Authority (POA) model, and can even support optimistic rollups operated for app-specific use cases, while the Cronos POS Chain, formerly named Crypto.org, secures assets and oversees $CRO token issuance. Furthermore, Cosmos SDK’s Inter Blockchain Communication (IBC) protocol facilitates interoperability within the Cosmos network.
The introduction of Cronos zkEVM does not render the existing Cronos chain obsolete. Instead, the current Cronos chain continues to serve a wide variety of general use cases, including gaming, DeFi, and NFTs, and remains an integral part of the Cosmos ecosystem.
Cronos zkEVM, on the other hand, is designed to address high-performance and high-throughput DeFi use cases, meeting the demands of sophisticated retail and institutional investors with its future-proof performance. Envisioned as a liquidity hub, it aims to simplify transactions between Cronos, the Ethereum mainnet, and other Layer 2s, thereby unifying the liquidity across the blockchain ecosystems and leveling the playing field.
Overview of Cronos ecosystem and connected networks
## Core Proposition
Cronos zkEVM targets key DeFi challenges by offering solutions for liquidity fragmentation, yield-generation complexity, and user experience barriers.
It establishes shared liquidity with trustless bridges, simplifies earning with native yield-bearing assets, and improves usability through account abstraction. These solutions set the stage for a future of unified liquidity, passive yield accrual, and intuitive wallet management.
Value proposition
### Shared Liquidity
Shared Liquidity in Cronos zkEVM addresses the critical issue of liquidity fragmentation in DeFi. This feature ensures that assets, while distributed across various hyperchains, are consistently secured by Ethereum's robust consensus. Our goal is to simplify the process of asset transfer and withdrawal, making it more cost-effective for users.
In this ecosystem, Shared Liquidity means that assets are pooled in a shared bridge contract on Layer 1, creating a centralized pool. This structure is key to enhancing interoperability and efficiency within the network. It's a direct solution to the fragmentation issue, presenting Cronos zkEVM as a more integrated and streamlined platform for DeFi transactions.
The hyperbridge architecture, a network of smart contracts, underpins this system by offering trustless validating transactions across chains. Initially Cronos zkEVM will support the transfer of Ether and ERC20 tokens, with plans to expand to ERC721 and ERC1155 assets.
Shared Liquidity is a fundamental aspect of Cronos zkEVM's strategy to address market fragmentation and improve the DeFi experience.
Hyperbridge overview
### Yield Bearing Assets
In today's DeFi, assets such as ETH offer a 3-4% yield through staking on Layer 1, serving as a form of risk-free rate in the ecosystem. Yet, this earning potential is often lost when assets are locked in bridges and moved to Layer 2 platforms like Optimism or Arbitrum. This forfeited yield is akin to losing value due to the inflation of the network, resulting in loss in purchasing power. Similarly, stablecoins typically do not generate yield on either layer, leading to a missed opportunity.
Within the Cronos zkEVM network, the native token CRO, along with ETH and various stablecoins, will inherently produce yield and accrue APY for holders. To be more specific, iInstead of holding and trading CRO, ETH and DAI/USDC/USDT, Cronos zkEVM users will have the option to bridge, hold and trade the following yield-bearing assets powered by Veno Finance:
* zkCRO, a yield-bearing version of CRO, used as the protocol token on Cronos zkEVM. zkCRO is backed by LCRO (Veno's liquid staked CRO) which represents CRO staked on the Cronos POS chain.
* vETH, a yield-bearing version of ETH, backed by ETH committed to Ethereum's proof of stake protocol.
* vUSD, a yield-bearing stablecoin, backed by investments into yield-generating lending protocols on Ethereum mainnet.
This fosters a dynamic ecosystem where dApps are built around and benefit from yield-bearing tokens, enabling them to remain competitive in a market where yield optimization is key. This offers dApps a simplified approach for revenue-generation from user assets. By making minor adjustments, dApps can utilize Cronos zkEVM's native yield capabilities to improve their value proposition to users.
The yield generation within Cronos zkEVM will be facilitated through strategic partnerships with decentralized protocol Veno Finance, which currently provides liquid staking solutions for CRO, ETH and ATOM, and additional tokens in the future. This approach is part of a larger strategy to weave yield-generating features directly into the network's structure, enhancing utility for both users and developers.
Yield bearing tokens
### Native Account Abstraction
Native Account Abstraction (AA) in Cronos zkEVM is designed to transform how users interact with their accounts, offering enhanced functionalities like bundled transactions, key recovery options, and alternative token payments for gas fees. By leveraging the ZK Stack, Cronos zkEVM simplifies its account structure, adopting a single account type compared to Ethereum's dual model of Externally Owned Accounts (EOAs) and contract accounts.
While Account Abstraction itself isn't new, its integration into blockchains has been slow, especially when transferring existing liquidity to AA-enabled wallets. Cronos zkEVM utilizes AA to allow seamless fund deposits and interactions with dApps, eliminating the need for network switching.
Using AA, most of the dApps on Cronos zkEVM can make it easy for users to transact even if they don't own enough protocol token to pay for gas. Additionally, users can create off-chain signatures from any EVM-compatible chain or through familiar social logins. With dApps on Cronos zkEVM expected to natively support AA, dApps can manage transaction relays and even cover gas costs for users, further simplifying the experience.
The introduction of Native Account Abstraction in Cronos zkEVM marks a significant step toward making blockchain technology more user-friendly and accessible. It not only enhances the security and efficiency of user interactions but also fosters a more welcoming environment for broader adoption.
## Security & Governance
From day one, Cronos zkEVM relies on the security of the underlying Ethereum network, one of the most decentralized and robust blockchains, for transaction settlement and finality. The hyperbridge, a cross-chain messaging protocol that binds together all hyperchains as part of the ZK Stack, is secured by Ethereum as well. Finally, the use of validity proofs powered by zero-knowledge technology enables crypto users to withdraw their assets from the Layer 2 to the Layer 1 at any time, if these assets have been originally bridged from the Layer 1. These enhancements are game changers for retail and institutional crypto holders, compared with the occasional chain and/or bridge failures that have plagued the DeFi sector in 2022 and 2023.
Modular data availability is an important area of research and development for layer-2 blockchains, unlocking significant savings in transaction fees. Cronos zkEVM will utilize these new developments as they become available.
The Cronos zkEVM protocol engineering team is committed to participating actively in the development of the open-source ZK Stack over time, and Cronos zkEVM will aim to participate in the governance of the broader stack.
The longer term vision of this stack includes the development of decentralized validator networks at the Layer 2 level, which will further enhance the censorship resistance of the network.
## Path Forward
Cronos zkEVM is embarking on an ambitious journey to reshape DeFi, mapped out in strategic phases designed to build upon each other.
**Phase 0: Testnet**
* Cronos zkEVM Testnet optimization and upgrades.
* (Soon) Testnet quests and proof of participation for early adopters.
**Phase 1: Foundation and Infrastructure**
* Initiate with the beta launch of Cronos zkEVM mainnet, laying the foundational infrastructure.
* Connection readiness with ZKStack hyperchains to ensure shared liquidity.
* Integration with liquid staking protocol to enable yield bearing assets on Cronos zkEVM.
* Foundational elements for Native AA to improve user interaction workflow.
* Onboard key DeFi protocols offering essential services like money market and DEXs (spot & perpetual).
* Launch mainnet quests & point system in preparation of airdrop waves, in partnership with participating dApps.
**Phase 2: Solidifying the Ecosystem as a Liquidity Hub**
* Prioritize VM optimizations and proof size reductions to enhance efficiency and cost-effectiveness.
* Enrich the DeFi suite by expanding into high-capacity spot and perpetual trading systems and liquidity management solutions, particularly those based on order books, real word assets, and artificial intelligence.
* Invest in use cases that take further advantage of the connectivity between hyperchains and the composability of crypto assets supported by shared liquidity.
**Phase 3: Continuous Development**
* Broaden the ecosystem's utility to include more ambitious use cases, such as payments, synthetic assets, and asset & yield management solutions.
* Continue to optimize gas fee mechanisms and gradually transition towards a community-driven governance structure.
* Experiment and test decentralized validator networks to enhance censorship resistance.
* Investigate adopting parallel execution to increase transaction throughput and efficiency.
As we continue to forge ahead with the development of Cronos zkEVM, we are committed to keeping our community informed and engaged. Detailed updates on the roadmap's progress will be released in due course. We understand the importance of transparency and collaboration and are working diligently to bring these innovative solutions to fruition.
To stay up-to-date with the latest developments and insights, [follow Cronos on X](https://twitter.com/cronos_chain), and [subscribe to the blog](https://blog.cronos.org) for news and updates. Your engagement and support propel #CROFam forward, and we look forward to continuing this journey with you as we collectively shape the future of DeFi.
# Cronos roadmap
Updated as of: Nov 2024
2024 has been a momentous year for the Cronos ecosystem! As we are well into the last quarter of the year, and prepare for 2025, it is time for a Cronos roadmap update.
## State of Cronos
One of the key developments of 2024 has been the launch of the Cronos zkEVM network, representing a new milestone in Cronos' journey towards scalability, interoperability, and lower transaction costs.
The Cronos ecosystem now encompasses 3 chains:
* **Cronos zkEVM** is the new high-performance zero-knowledge (ZK) layer 2 network secured by Ethereum built on ZKsync technology, featuring a scalable zero-knowledge proof system, gasless transactions via native account abstraction, and native zkCRO, a yield-bearing token accruing CRO validator yield, as gas token. Cronos zkEVM already holds around USD $50M of Ethereum bridged funds.
* **Cronos EVM** is the Ethereum Virtual Machine-compatible, permissionless, programmable layer-1 built on Cosmos SDK, home to more than 500 project teams who have created decentralized applications powered by smart contracts. Cronos EVM uses CRO as the gas token. The Cronos EVM chain has securely delivered more than 120M transactions for more than 1.4M users to date, and secures around USD $500M of DeFi Total Value Locked and several billions of USD of total assets.
* Cronos POS is the layer-zero network that guarantees the security of the Cronos ecosystem. It is the native protocol of the CRO utility token, secured by a vast network of more than 100 validators, representing around USD $1B in staked value. Since its inception, Cronos POS chain has securely validated around 37M transactions, with an average transaction fee of USD $0.00001.
All three chains leverage the ecosystem's utility token CRO, which is controlled by the decentralized governance of the Cronos POS chain. The CRO token serves different utility purposes across the chains, specifically:
* **For Cronos zkEVM:** The CRO token serves as the underlying token for zkCRO, a yield bearing version of CRO token accruing CRO validator yield powered by Veno Finance staking protocols. zkCRO serves as the native gas token of the Cronos zkEVM layer-2 chain.
* **For Cronos EVM:** The CRO token is used to pay for transaction fees (gas), which are collected by validators who play a crucial role in maintaining the security and integrity of the network. Transaction fees incentivize validators to participate in the network, ensuring that transactions are processed efficiently and securely.
* **For Cronos POS:** The CRO is used to pay for transaction fees (gas), which are collected by validators. Additionally, CRO holders can participate in the network's governance by staking their tokens with validators, which enables them to vote on proposals and contribute to the decision-making process. In return, they earn rewards for maintaining the network, creating a sustainable and decentralized governance model.
The launch of a new network (Cronos zkEVM) has not been the only area of progress in 2024, far from it. Key developments include:
Cronos zkEVM
* Launched the Layer 2 scaling solution Cronos zkEVM mainnet in alpha.
* Launched zkCRO, vETH and vUSD, natively yield-bearing tokens supported by the entire Cronos zkEVM DeFi application ecosystem.
* Conducted the Cronos zkEVM Pioneer Program, a groundbreaking loyalty program rewarding users who contribute to the growth of the ecosystem.
* Established the underlying infrastructure and connected with ZKsync Elastic Chains to enable shared liquidity.
* Integrated with liquid staking protocols and developed the foundational elements for Native Account Abstraction.
* Onboarded key DeFi protocols that offer essential services like money markets and decentralized exchanges.
* Improved Cronos Explorer to deliver blockchain explorer features in line with market best practices.
* Participated in the broader ZKsync ecosystem's roadmap towards implementation of coordinated upgrades, layer-2 to layer-2 cross-chain messaging, optimization of proof batching.
Cronos EVM
* Improved Cronos Explorer to deliver blockchain explorer features in line with market best practices.
* Integrated IBC RPC data Into the Blockchain Explorer.
* Improved transaction execution performance by 30% through address cache optimization and migration of parameters from JSON to protobuf.
* Completed major node and RPC performance improvement thanks to MemIAVL, VersionDB. Notably, node improvements resulted in 10x faster block execution, 80% response time reduction and 65% reduction in storage size.
* Incorporated the latest Cosmos SDK V0.47 and IBC Upgrades.
* Published CRC21 Standard for IBC compatibility.
* Explored parallel and optimistic execution of transactions.
Cronos POS
* Surpassed initial CRO staking ratio target of 30%, and introduced new target at 60%. As the decentralized governance increased the staking ration target and the network's CRO emissions, nearly 40% of the total CRO supply is now being staked and further strengthening the network's security.
* Explored the liquid staking module, and potential conditions that may allow the distribution of liquid staked CRO across multiple nodes.
## Vision And Mission
Cronos is committed to building a financial ecosystem where fairness, openness, and community empowerment are at the core. We envision a future where decentralized finance is accessible to all, giving everyone the tools to take control of their financial destiny.
**We envision that AI agents will be the main enabler of this future.**
**AI agents built on top of blockchain infrastructure will provide limitless opportunities.**
Artificial intelligence (AI) stands poised to transform digital experiences in several ways. Initially, end-users will come to expect natural language interfaces for a wide array of services. Subsequently, they will be able to deploy agents capable of acting on their behalf, executing a spectrum of actions geared toward fulfilling specific objectives, whether financial or otherwise. These capabilities can serve as potent vectors for mainstream adoption. Concurrently, it is anticipated that a growing number of AI developers, who may not possess a profound understanding of blockchain technology, will nevertheless seek to harness its potential to empower their users to make or receive instantaneous payments or to monetize their own applications.
It is imperative that Cronos assumes a pivotal role in these evolutions.
Every day, users and developers will be able to create semi-autonomous AI agents powered by Cronos, assign goals to them, and delegate frequent and repetitive tasks to them.
For example, networks of AI agents will be able to:
* Scan through the social media trends and identify cultural shifts. Use those insights to launch billion dollar memecoin concepts, complete with token economics and marketing.
* Build a network of 1,000 AI content producers to promote a business venture, and collect the ad revenue collected by these AI influencers.
* Combine real-time game data and social media discussions to improve risk pricing in decentralized sports wagering and create high-return strategies.
* Organize events in 100 cities, recruit staff and compensate them in stable coins.
The proliferation of AI agents will create a powerful flywheel that will benefit the Cronos ecosystem and its users.
## Roadmap Overview
Cronos can already leverage a strong foundation and ecosystem to deliver on its vision:
* Reliable, robust decentralized protocols.
* Powerful community of creators, builders and 100 M users.
* Bridge connectivity to all other major blockchain protocols (ZK gateway, IBC, third party bridge providers).
* Rich dapp ecosystem.
The Cronos roadmap aims to overcome several challenges associated with fully powering a billion AI agent world:
* Chain scalability.
* Integration of LLM with Web3 developer tooling (LLM agnostic).
* End to end dapp deployment and servicing.
* Enhanced token economics to ensure the ecosystem's sustainability.
The Cronos roadmap can be summarized as follows:
First, all three Cronos chains will engage in a collaborative effort to develop a unified suite of Cronos AI capabilities. This strategic initiative encompasses the creation of end-user interfaces facilitated by AI (bots, "CRONOS ONE" portal), the introduction of developer infrastructure to empower AI-enabled applications, and ongoing collaboration with Crypto.com's AI Agent SDK as a strategic partner.
Additionally, extensive research and development endeavors will be initiated with the purpose of improving the fundamental operational efficiency of each blockchain network.
In the context of Cronos zkEVM, this entails active participation in the ZK Nation governance and development roadmap, and the evolution to at least Stage 0 Layer 2, and possibly Stage 1 status. For Cronos EVM, it involves harnessing the potential of parallel execution to its maximum capacity. In the latest benchmarking tests, parallel execution delivered up to 30,000 TPS when applied to Cronos EVM technology. In the case of Cronos POS, it entails ongoing involvement in the roadmap of Cosmos SDK, which is recognized as one of the fastest and most robust platforms in the blockchain industry.
Concurrently, the Cronos project will identify and implement stronger synergies between the three chains.
Using Cosmos SDK’s most recent modules, such as interchain accounts and liquid staking, cross-chain protocols like Veno Finance can be bolstered to enhance their security and decentralization. Interchain security, another Cosmos SDK module, could potentially reinforce the security of Cronos EVM through the extensive validator network of Cronos POS. Furthermore, simplifying cross-chain transactions between Cronos zkEVM and Cronos EVM is another significant priority for the upcoming year.
The token economics roadmap will combine a comprehensive set of mechanisms that will increase demand for Cronos blockchain networks while ensuring that supply is right-sized.
It is too early to describe precisely how token economics will evolve. We look forward to seeing community input and Cronos POS governance proposals on this topic.
## Renewed Commitment To Developers
App creators are the life and blood of blockchain ecosystems and, as the industry’s momentum accelerates, Cronos must compete to attract the most skilled and committed teams among them.
The brand new [cronos.org/build](http://cronos.org/build) page consolidates all the critical resources to help builders to get started.
Cronos’ renewed commitment to developers will involve the following key support areas in 2025.
**World-Class Infrastructure Partners.** The Cronos ecosystem encompasses network partners with stellar reputations such as Crypto.com, Google Cloud, AWS, Ubisoft, Exaion, Blockdaemon and Matter Labs. Moreover, it boasts a network of more than 100 validators that can be considered an industry benchmark, thanks to its many years of experience. More announcements are planned in 2024/25 that will instill further confidence in the network's ability to be here to stay and to perform under pressure.
**Investments In Dev Tooling And Cross-Chain Bridging.** 2024 has been a transition year as far as developer tools are concerned, with the gradual migration to homegrown solutions for the blockchain explorer (Cronos Explorer for [zkEVM](https://explorer.zkevm.cronos.org/) and [EVM](https://explorer.zkevm.cronos.org/)) and the developer portal (Cronos Developer Portal for [zkEVM](https://explorer-api-doc.zkevm.cronos.org/mainnet/index.html) and [EVM](https://explorer-api-doc.cronos.org/mainnet/)). The development team is committed to incorporating feedback and accelerating the speed of new feature launches in 2025.
Another pain point for developers in 2024, has been the relative lack of cross-chain bridges and communication protocols aside from IBC (between Cosmos chains) and the exchanges (Crypto.com). In addition to the native bridge between Ethereum and Cronos zkEVM, several independent bridges have been introduced or scaled up in 2024. Additional announcements are planned, and user navigation will be enhanced by the consolidation of all bridge connections on the primary bridge interfaces for [zkEVM](https://zkevm.cronos.org/bridge) and [EVM](https://cronos.org/bridge). Please refer to sections below for details.
**Builders program.** The [builders program](https://cronoslabs.org/cronos-builders-program) is a directory of curated solutions and discounted tools which are made available exclusively to Cronos ecosystem developers. The program was introduced in 2023, and will be revamped in 2025 with a new, more relevant and more exciting set of partners.
**Grant program.** [Cronos ecosystem grants](https://cronos.org/grants) consist of milestone-based financial incentives, typically ranging from 5,000 to 20,000 USD, which encourage app creators to invest in Cronos and scale up their user base. The ideal candidate is an end-user application that has organically demonstrated the ability to acquire several hundred daily active users and has the potential to scale up to several thousand or more daily users with support. To enhance the program's effectiveness, the grant program will be augmented in 2025 to introduce mechanisms whereby projects can be incentivized retroactively according to the transaction fees that they generate on the network.
**Marketing partnerships.** According to many app creators, marketing support is the greatest possible contribution that a blockchain ecosystem can provide to a developer. 2025 will see continued investments into the various channels that enable Cronos to increase the visibility of new and existing apps: [Cronos Newsletter](https://blog.cronos.org), [Cronos Discover](https://discover.cronos.org), [Twitter/X Amplification](https://x.com/cronos_chain), Conference Sponsorships, Swag Packs.
**Business accelerator and advisory.** A revamped business acceleration program will be inaugurated in 2025. This initiative will consist in a more bespoke range of partnership arrangements between Cronos Labs and projects exhibiting exceptional growth potential - a "menu of options" throughout the year, rather than a few standardized cohorts a few times a year..
Cronos is firmly dedicated to the success of ecosystem builders. In addition to the initiatives listed above, a comprehensive array of novel initiatives and services are under development that will further bolster the support provided to the community.
## Roadmap By Blockchain Network
Each Cronos chain will play a distinctive role in achieving the ecosystem’s goals, with a particular but not exclusive focus on certain use cases:
* Cronos zkEVM is particularly well suited for use cases that benefit from deep liquidity and integration with Ethereum, all powered by AI agents, such as DeFi, trading, and cross-chain decentralized applications.
* Cronos EVM remains the preferred network for community-based use cases around Web3 games and NFTs, thanks to its established communities and the innovative crop of AI agents empowering them. Additionally, Cronos EVM is the preferred network for developers who prioritize connectivity with the Cosmos SDK ecosystem via IBC.
* Cronos POS is the preferred chain for many Enterprise applications thanks to its low transaction fees. This includes custodial payments and custodial NFT trading as well as AI-to-AI communication.
### Cronos zkEVM
Cronos zkEVM will continue to contribute and benefit from major developments of the ZK Stack in partnership with ZKsync and other ZK Chains.
While ZKsync Era and Cronos zkEVM were the first two chains to go live in mainnet, many other ZK chains are moving rapidly towards testnet and/or mainnet in verticals such as DeFi (GRVT), social (Lens), and gaming (PlayFi, Sophon).
Together with ZK chains, Cronos zkEVM will prioritize the following features for late 2024 and early 2025:
Timeframe
Priorities
Late 2024/H1 2025
Core protocol
Operationalize the ZKsync governance and implement an updated, decentralized process to review and deploy protocol upgrades.
Migrate to ZK Gateway, which enables fast and secure L2 to L2 communications for token transfer and cross-chain dapps.
Implement proof aggregation across several L2 chains to further reduce transaction costs.
Publish transaction data onto Ethereum or an external Data Availability Layer, to graduate as Stage 0 chain.
AI capabilities
Launch Cronos Assistant, a news digest, notification and Q&A service over Telegram.
Launch CRONOS ONE, a crypto super agent that radically simplifies user access to a broad range of crypto dapps and use cases.
Develop bespoke implementations of account abstraction and paymaster specifically designed to address the unique requirements of artificial intelligence applications, such as "agent wallets."
Collaborate with Crypto.com to broaden the capabilities of Crypto.com AI Agent SDK for developers.
H2 2025
Core protocol
Optimize proof generation at the server level to further reduce transaction costs.
Explore decentralized validator networks to enhance censorship resistance and graduate as Stage 1 chain.
Deployment of attester committee to walk towards decentralization of the network.
Achieve consensus on L2 blocks.
Progressively introduce the ability to transform external nodes into main nodes.
Expand the DeFi ecosystem with apps and use cases that leverage hyperchain connectivity and composability.
AI capabilities
Expand the autonomy of CRONOS ONE, moving gradually from natural language instructions to enhanced agent autonomy over hours or days to achieve goals assigned by the end-user.
Develop new smart contract standards enabling AI developers to implement advanced on-chain business logic such as limit order book and escrow for agent payment.
Introduce identity protocol for humans and human-directed agents (eg, proof of humanity).
Collaborate with Crypto.com to broaden the capabilities of Crypto.com AI Agent SDK for developers.
\
Bridge connectivity will remain an important priority area:
* Existing bridges
* Native Ethereum <> Cronos zkEVM bridge, shared with all other ZK chains, secured by Ethereum.
* Custodial cross-chain transfers via exchanges, such as Crypto.com
* Rhino Finance (third party bridge)
* Upcoming bridges
* 1 additional third party bridge to improve Cronos zkEVM's connection to Solana and other top chains
* 2 additional third party bridges connecting Cronos zkEVM to multiple EVM chains including Cronos EVM
### Cronos EVM
Cronos EVM will continue to contribute and benefit from major innovations pioneered by the Cosmos SDK community.
Cronos EVM will prioritize the following features for late 2024 and early 2025:
Timeframe
Priorities
Late 2024/H1 2025
Core protocol
Introduce parallel execution of transactions, to increase transaction throughput and efficiency. Performance benchmarks have shown that parallel execution can increase Cronos EVM's TPS up to 30,000 transactions per second.
Optimize the virtual machine (VM).
AI capabilities
Similar to Cronos zkEVM, with more focus on Web3 gaming and NFT use cases.
H2 2025
Core protocol
Unlock broad availability of Cosmos SDK interchain accounts and interchain security.
Explore deeper synergies between Cronos EVM and Cronos POS.
Explore MEV optimization to improve gas fee mechanisms.
AI capabilities
Similar to Cronos zkEVM, with more focus on Web3 gaming and NFT use cases.
\
Bridge connectivity will remain an important priority area:
* Existing bridges
* Native IBC bridges, connecting Cronos EVM to Cronos POS and other Cosmos SDK chains
* Symbiosis (third party bridge)
* Upcoming bridges
* 2 additional third party bridges connecting Cronos EVM to multiple EVM chains including Cronos zkEVM
### Cronos POS
Cronos POS will also continue to contribute and benefit from major innovations pioneered by the Cosmos SDK community.
Cronos POS will prioritize the following features for late 2024 and early 2025:
Timeframe
Priorities
Late 2024/H1 2025
Core protocol
Enable distribution of Cronos zkEVM's zkCRO staking among multiple validator nodes.
AI capabilities
Identify Cosmos SDK primitives / modules needed to support Agent to Agent transactions.
H2 2025
Core protocol
Unlock broad availability of Cosmos SDK interchain accounts and interchain security.
Explore deeper synergies between Cronos EVM and Cronos POS.
AI capabilities
Introduce Agent to Agent on-chain commerce protocol, a suite of tools that can be used when independent AI agents collaborate with each other (immutable on-chain communication records, escrow/staking).
Expand Agent to Agent on-chain commerce functionalities to position Cronos POS as a B2B platform for agent collaboration and task outsourcing.
## An exciting future
The global crypto industry has made tremendous progress in 2023 and 2024, overcoming significant economic and regulatory headwinds. Several new use cases have found product/market fit in DeFi (eg, liquid staking, restaking, perpetuals) and outside DeFi (social, meme coins, inscriptions).
There are currently more than 600 million crypto holders worldwide, many of them frequent users of centralized crypto exchanges and now ready to explore self-custody and Web3 apps.
AI agents will unlock the next phase of mainstream adoption.
Picture a world soon where AI agents act as your personal guides, experts, and collaborators, effortlessly responding to your needs —all accessible through simple natural language. Couple this with the transparency and trust nature of blockchain, the possibilities for innovation and empowerment are limitless.
With the strong foundation and three-layer architecture, the Cronos ecosystem is poised to take the leap into this brave new world.
# Crypto.com Card Top Up
### Simplify Your Crypto.com Card Top-Up with Cronos zkEVM Chain
We’re thrilled to introduce a feature that makes funding your Crypto.com card easier than ever. By linking your non-custodial wallet directly to your card, you can top up quickly and conveniently. Follow these simple steps to get started!
### How to Link Your Wallet
1\. Visit[ https://zkevm.cronos.org/](https://zkevm.cronos.org/).
2\. Connect your non-custodial wallet to the platform.
3\. Click "Learn More" to explore the feature.
4\. You’ll be directed to the . Click "Link Crypto.com wallet".
5\. Enter your Crypto.com wallet address carefully. Ensure the address is correct to avoid losing funds. Click "Link", and authorise the connection via your non-custodial wallet provider to link your wallet.
6\. Open the Crypto.com App, navigate to the Card Module, and go to Card Settings. Enable the Top-Up with Cronos EVM/zkEVM Chain option.
7\. Once complete, you’ll see the linked wallet address.
### How to Top Up Your Crypto.com Card
1\. Select the token you wish to use and enter the amount you’d like to top up. If you choose a token other than USDC or ETH, it will automatically be swapped to the best available rate for USDC or ETH via [H2 Finance](https://h2.finance/swap). Please note that additional fees and slippage may apply. Confirm the transaction by signing the approval request in your wallet.
2\. Once the transaction is processed, you’ll see a "Transaction Successful" notification. It may take a few minutes to send the fund to the Crypto.com Card.
3\. You can view your top-up history in the History tab of the platform.
### How to Unlink Your Wallet
1\. Go to the wallet linking page on the platform.
2\. Click "Unlink", and authorise the disconnection of your non-custodial wallet to your Crypto.com deposit address.
3\. Open the Crypto.com App, navigate to the Card Module, and disable the Top-Up with Cronos EVM/zkEVM Chain option in Card Settings.
### Support
If you have any questions, please contact [Crypto.com support](https://chat.crypto.com/) or Cronos chain on [Discord](http://crofam.me/discord).
Follow the[ Cronos Twitter account](https://twitter.com/cronos_chain) and[ blog](https://blog.cronos.org/) to be among the first to know.
# Crypto Wallets
In order to use Cronos zkEVM, you need to have a self-custodial crypto wallet connected to Cronos zkEVM's testnet network.
You can use:
* [Crypto.com O](https://crypto.com/defi-wallet)[nchain Wallet](https://crypto.com/onchain): available as browser extension for desktop and as mobile app. Cronos zkEVM mainnet is supported by default.
* [Crypto.com Onchain Wallet configuration](/for-users/crypto-wallets/crypto.com-onchain-wallet-configuration)
* [Rabby](https://rabby.io) wallet: available as browser extension for desktop. Cronos zkEVM mainnet is supported by default. See configuration instructions here:
* [Rabby Configuration](/for-users/crypto-wallets/rabby-configuration)
* [MetaMask](https://metamask.io/): available as browser extension for desktop and as mobile app, with custom network configuration. See configuration instructions here:
* [MetaMask Configuration](/for-users/crypto-wallets/metamask-configuration)
* [Brave Wallet](https://brave.com/wallet/): available as browser extension for desktop, with custom network configuration. See configuration instructions here:
* [Brave Wallet Configuration](/for-users/crypto-wallets/brave-wallet-configuration)
# Crypto.com Onchain Wallet configuration
The Crypto.com Onchain Wallet is available as:
* a mobile app
* a browser extension for desktop
You can download the wallet at: [https://crypto.com/onchain](https://crypto.com/eea/onchain)
Cronos zkEVM is supported by default, no configuration is needed.
# Rabby Configuration
In this guide, you will learn how to configure the [Rabby](https://rabby.io) extension on Google Chrome to send and receive tokens, and interact with the Cronos zkEVM network.
Cronos zkEVM is supported by default, no configuration is needed.
## Create a Rabby wallet
You need to:
* Download the [Rabby](https://rabby.io) browser extension for desktop.
* And then either create a new wallet (in this case, the seed phrase will be generated by the wallet), or import an existing wallet (using the seed phrase or private key).
## Connect Rabby to Cronos zkEVM mainnet network
Rabby Wallet has integrated Cronos zkEVM Mainnet. Once the wallet is connected, you will be able to view the balance of your address on mainnet, for example:
***
## Connect Rabby to Cronos zkEVM Sepolia testnet
For connecting your Rabby wallet to the Cronos zkEVM Sepolia testnet:
Open the Rabby extension and click on the "More" icon:
Select "Add custom network":
After clicking "Add custom network" once more you should see a window similar to this:
Here you can enter the details of Cronos zkEVM testnet:
{% tabs %}
{% tab title="Testnet" %}
**Name:** Cronos zkEVM Sepolia Testnet
**New RPC URL:** `https://testnet.zkevm.cronos.org/`
**Chain ID:** 240
**Symbol:** zkTCRO
**Block explorer URL:** [**https://explorer.zkevm.cronos.org/testnet/**](https://explorer.zkevm.cronos.org/testnet/)
{% endtab %}
{% endtabs %}
Subsequently, to connect to the network, you will need to click on the "Network" icon in the Rabby main window:
Here, you can select Cronos zkEVM Sepolia testnet under Custom networks:
To see your zktCRO test tokenbalance, click on the arrow next to network, then "Custom network" and you should see your zkCRO balance:
## Connect Rabby to Ethereum Sepolia testnet
If you need to execute cross-chain transactions between Cronos zkEVM testnet and Ethereum testnet, you definitely need to configure the Ethereum Sepolia testnet too.
The procedure is similar to above.
You need to find a RPC URL either from a commercial provider, or from one of the active links listed on this page:
For example:
{% tabs %}
{% tab title="Testnet" %}
\
**Name:** Ethereum Sepolia
**RPC URL:** [**https://sepolia.gateway.tenderly.co**]()
**Chain ID:** 11155111
**Symbol:** SepoliaETH
**Block explorer URL:** [**https://sepolia.etherscan.io**](https://sepolia.etherscan.io)
{% endtab %}
{% endtabs %}
After saving the network configuration, we should be able to see your SepoliaETH token balance.
# MetaMask Configuration
In this guide, you will learn how to configure the [MetaMask](https://metamask.io) extension on Google Chrome to send and receive tokens, and interact with the Cronos zkEVM network.
The configuration process is similar if you are using the MetaMask mobile app.
## Create a MetaMask wallet
You need to:
* Download the [MetaMask](https://metamask.io) browser extension for desktop, or mobile app.
* And then either create a new wallet (in this case, the seed phrase will be generated by the wallet), or import an existing wallet (using the seed phrase or private key).
## Connect MetaMask to Cronos zkEVM Sepolia testnet
Let's connect your MetaMask wallet to the Cronos zkEVM network.
Click the **"My Account"** button in the top right corner. Then select **"Networks"** in the settings menu.
Click **"Add Network" and fill in the network details:**
{% tabs %}
{% tab title="Mainnet " %}
**Name:** Cronos zkEVM Mainnet
**New RPC URL: `https://mainnet.zkevm.cronos.org/`**
**Chain ID: 388**
**Symbol: zkCRO**
**Block explorer URL:** [**https://explorer.zkevm.cronos.org/**](https://explorer.zkevm.cronos.org/)
{% endtab %}
{% tab title="Testnet" %}
**Name:** Cronos zkEVM Sepolia Testnet
**New RPC URL:** `https://testnet.zkevm.cronos.org/`
**Chain ID: 240**
**Symbol: zkTCRO**
**Block explorer URL:** [**https://explorer.zkevm.cronos.org/testnet/**](https://explorer.zkevm.cronos.org/testnet/)
{% endtab %}
{% endtabs %}
After saving the network configuration, we should be able to see your token balance.
## Connect MetaMask to Ethereum Sepolia testnet
If you need to execute cross-chain transactions between Cronos zkEVM testnet and Ethereum testnet, you definitely need to configure the Ethereum Sepolia testnet too.
Open MetaMask and click on the network icon:
MetaMask home screen
Then, simply toggle "Show test networks" and click on Sepolia to activate the Ethereum Sepolia testnet network:
# Brave Wallet Configuration
In this guide, you will learn how to use the Brave browser Wallet to interact with the Cronos zkEVM network.
## Add Cronos zkEVM to the Brave Wallet
Let's connect your Brave Wallet to the Cronos zkEVM network:
#### Step 1
On the top right-hand corner of the Brave browser, click the  (Wallet) icon. \
If you don’t see it, then Click **Update** in the toolbar for the latest version of Brave.
#### Step 2
Now follow the wizard to either [**create a new wallet**](https://support.brave.com/hc/en-us/articles/12753544357645-Creating-your-Brave-Wallet) or **import an existing wallet**. \
Once you have your wallet ready, click the **three dots** in the upper right corner of your wallet to view and go to "**Settings**".
#### Step 3
In the settings page, under the"**Web3"** tab**,** click **"Wallet Networks".** \
Alternatively, you can visit `brave://settings/wallet/networks` in the browser URL.
#### Step 4
Now in the list of networks, click "**Add**" in the top right corner to add Cronos zkEVM network.
#### Step 5
In the new pop-up window, add the following config:
Under "**Search network**" in the drop-down menu, Select
* "**388 Cronos zkEVM Mainnet**" for mainnet or
* “**282 Cronos zkEVM Testnet**” for testnet.
Most fields should now be pre-populated, as shown below:
In order to display the Cronos zkEVM logo, set the "**Icon URLs**" field to
```
https://zkevm.cronos.org/images/text-logo-zkevm.png
```
and click **"Submit".**
#### Step 6
Congratulations, we should now be able to see the Cronos zkEVM network in the wallet view.
# Holdstation Smart Wallet
Holdstation's smart wallet supports Cronos zkEVM out of the box
# Zerion
[Zerion wallet](https://zerion.io) supports Cronos zkEVM by default for dapp connections.
However, token positions, DeFi positions and NFT positions are not yet supported.
# Cronos zkEVM Bridge
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-users/cronos-zkevm-bridge) **before the network is fully decommissioned.**
{% endhint %}
The Cronos zkEVM bridge enable users to bridge ERC20 tokens from Ethereum (L1) to Cronos zkEVM (L2), and back.
**The bridge is available at** [**https://zkevm.cronos.org/bridge**](https://zkevm.cronos.org/bridge)**.**
It will only support selected tokens which have been originally created on Ethereum. The list of allowed tokens will expand over time.\
\
**In the page, we cover:**
* [#how-to-withdraw-zkcro-for-cro](#how-to-withdraw-zkcro-for-cro "mention")
* [#how-to-withdraw-veth-for-eth](#how-to-withdraw-veth-for-eth "mention")
* [#how-to-withdraw-vusd-for-dai](#how-to-withdraw-vusd-for-dai "mention")
## Bridge User Guides
### How to withdraw zkCRO for CRO
{% hint style="info" %}
Before we start, make sure you have enough zkCRO in your wallet as gas fee during the journey. And here is [the high-level steps](#how-to-withdraw-zkcro-for-cro) for overview.
{% endhint %}
#### Bridging zkCRO from Cronos zkEVM to Cronos EVM
1. Head to and connect your wallet.
2. On the “Withdraw” tab, in the “FROM” field select zkCRO and LCRO will automatically appear in the “TO” field. Enter the amount of zkCRO to bridge. *Keep in mind that zkCRO is needed to pay the gas fees*.
3. When the ’Withdraw‘ button is clicked, a prompt modal and the wallet approval window will automatically pop up. Kindly confirm transaction for the bridge to spend your zkCRO.
4. On the “Pending Withdrawals” tab, you could see the pending withdrawals is listed. You need wait for almost 48 hours to start to claim zkCRO on Ethereum mainnet.
5. After almost 48 hours, we could see 'proceed' tag alongside. Click it to start to claim zkCRO on Ethereum mainnet.
6. A wallet approval window pops up. Click '**Confirm**' button to approve the transaction.
Now, you should see the target amount of zkCRO on your wallet on Ethereum mainnet.
7. Followingly, go ahead to withdraw zkCRO from Ethereum to Cronos EVM, wherein zkCRO will be finally wrapped into LCRO on Cronos EVM.
Now, you could see the target amount of LCRO on Cronos EVM, and you could choose to 'Unstake'/'Sell' LCRO for CRO.
### How to withdraw vETH for ETH
{% hint style="info" %}
Before we start, make sure you have enough zkCRO in your wallet as gas fee during the journey.
{% endhint %}
1. Head to and connect your wallet.
2. On the “Withdraw” tab, in the “FROM” field select vETH and ETH will automatically appear in the “TO” field. Then enter the amount of vETH to bridge. *Keep in mind that zkCRO is needed to pay the gas fees*.
3. When the ’Withdraw‘ button is clicked, an prompt modal and the wallet approval window will automatically pop up. Kindly confirm transaction to approve and unwrap your vETH.
After the transaction is confirmed, vETH is unwrapped into ybETH.
4. Now, a new wallet approval window will automatically pop up. Kindly confirm transaction to approve and withdraw your ybETH.
5. On the “Pending Withdrawals” tab, you could see the pending withdrawals is listed.
6. After almost 48 hours, we could see 'proceed' tag alongside, meaning we could claim and request for ETH.
7. Kindly hit 'proceed' button, and later confirm the two transactions *respectively* on the wallet approval windows.
8. From now, we need wait for almost 1\~10 days for the final step to '**Claim ETH**'.
9. After 1\~10 days, we could finally claim the ETH back to our wallet. Kindly hit 'Claim ETH' button to start.
10. The wallet approval window will automatically pop up. Kindly confirm transaction to approve it.
You should now see an additional amount of ETH in your wallet on Ethereum mainnet.
### How to withdraw vUSD for DAI
{% hint style="info" %}
Before we start, make sure you have enough zkCRO in your wallet as gas fee during the journey.
{% endhint %}
1. Head to and connect your wallet.
2. On the “Withdraw” tab, in the “FROM” field select vUSD and DAI will automatically appear in the “TO” field. Then enter the amount of vUSD to bridge. *Keep in mind that zkCRO is needed to pay the gas fees*.
3. When the ’Withdraw‘ button is clicked, an prompt modal and the wallet approval window will automatically pop up. Kindly confirm transaction to approve and unwrap your vUSD.
After the transaction is confirmed, vUSD is unwrapped into ybUSD.
4. Then, a new wallet approval window will automatically pop up. Kindly confirm transaction to approve and withdraw your ybUSD.
5. On the “Pending Withdrawals” tab, you could see the pending withdrawals is listed.
6. After almost 48 hours, we could start to claim ybUSD and request for DAI by clicking 'Proceed' button.
7. Then the wallet approval window will automatically pop up for 'Claim ybUSD' on Ethereum mainnet. The wallet click 'Confirm' to approve the transaction.
8. Click 'Confirm' to approve the transaction to finally claim DAI.
Now you could see the target amount of DAI has been shown on your wallet.
# Independent bridges
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-users/cronos-zkevm-bridge) **before the network is fully decommissioned.**
{% endhint %}
The following bridges are operated by independent protocols. Use them at your own risks.
* [Rhino Finance](https://app.rhino.fi/bridge)
* [Symbiosis](https://symbiosis.finance/)
# Pioneer Program
Rewards Distribution Guide
Congratulations on earning rewards in Pioneer Program Season 1!
You can claim your rewards if you earned points during the Pioneer Program for the launch of Cronos zkEVM.
### Rewards Tokens
The reward tokens include $wzkCRO, $vUSD, $H2, $AMPLY, $FUL.
### Key Dates
* 18 December 2024: First claim day.
* 18 March 2025 00:00:00 UTC: Last claim day. Tokens afterwards will expire and can no longer be claimed.
### How to claim your rewards
1\. Head to [https://zkevm.cronos.org](https://zkevm.cronos.org/home) and connect your wallet.
2\. Once you have connected your wallet, click “Check Rewards” to see the rewards you have earned.
\
3\. Click “Claim Rewards”. Proceed with the transaction approval on your wallet.
4\. You have successfully claimed your rewards.
\
5\. Click the “History” tab to see the claim history.
### Support
If you have any questions or need assistance, please join the discussion on [Discord](https://discord.com/invite/cronos).\
Follow the [Cronos Twitter account](https://twitter.com/cronos_chain) and [blog](https://blog.cronos.org/) to be among the first to know.\
\
[Read the announcement post](https://blog.cronos.org/p/announcing-the-cronos-zkevm-pioneer).
# Yield rewards
How to claim yield rewards generated by your zkCRO, vETH and vUSD holdings
The Cronos zkEVM network hosts natively yield-bearing cryptocurrencies such as zkCRO, vETH and vUSD, powered by Veno Finance, that enable users to accumulate yield rewards simply by holding them. The reward distribution mechanism is different for zkCRO on one hand, and vETH and vUSD on the other hand.
## zkCRO Rewards
The exchange rate between zkCRO and CRO is expected to reflect not just the CRO staked originally to obtain zkCRO, but also the accumulated rewards.
When staked CRO generates more CRO, the value of zkCRO increases relative to CRO. Therefore, as a token holder you do not need to take any action to claim your rewards.
When you un-stake or sell your zkCRO, you receive the value of the CRO that you originally staked, as well as any accumulated rewards since then (unless there is a slashing event).
## vETH & vUSD Rewards
vETH and vUSD are ERC20 tokens which aim to follow the value of ETH and DAI (a USD stable coin) respectively. Therefore, the value of vETH relative to ETH does not increase to reflect accumulated rewards, nor does the value of vUSD relative to DAI.
As a token holder, you need to manually claim your rewards from the smart contracts. You can do this at regular intervals, for example every month.
### Tracking your rewards
All rewards can be viewed on the [Cronos zkEVM Rewards](https://zkevm.cronos.org/rewards) page. Pending rewards are accumulated daily, but they only become claimable after a few days. On the [Rewards](https://zkevm.cronos.org/rewards) page, you can track both your immediately claimable vETH and vUSD rewards, and the other pending rewards.
Pending rewards are updated every time that a Cronos zKEVM transaction batch is [finalized](https://docs.zksync.io/zk-stack/concepts/finality#finality-on-zksync-era) on Ethereum, which is every day on average. These rewards become claimable after 5 transaction batches have been finalized on Ethereum, which could take 4-7 days on average depending on network traffic.
**Claiming your rewards**
On the [Rewards](https://zkevm.cronos.org/rewards) page, head to the “Yield you earned” section. Please refer to the user guide below for detailed instructions.
**Expiry date of rewards**
Unclaimed rewards will expire 2 years after they have been earned.
**Special case of vETH and vUSD locked in dapps**
If you have deposited vETH or vUSD into a smart contract belonging to a dapp protocol, such as H2 Finance (a DEX), it is the dapp who is entitled to claim the rewards. Each dapp will decide how they redistribute these rewards to their users, and you should expect them to communicate clearly about it.
### How to claim vETH/vUSD rewards
1\. Head to (which currently redirects to /missions) and connect your wallet.
2\. Once you have connected your wallet, you will be able to see the vETH/vUSD yield you have earned. Click “Claim Tokens” to claim the reward.
3\. Under “Claimable Rewards”, click “Claim”. Proceed with the transaction approval on your wallet.
4\. You have successfully claimed your rewards. Click the “History” tab to see the claim history.
### vETH & vUSD deposited into dapps
When any vETH or vUSD are deposited into a dapp’s smart contract, all rewards are earned by the smart contract. Dapps will usually distribute the rewards back to their community. It is up to each dapp and their community to decide on how they distribute the rewards earned.
# Dapps
This page lists dapp projects that have announced an upcoming deployment on Cronos zkEVM, in alphabetical order.
# Cronos zkEVM testnet Tutorials
Here is a set of tutorials that you can use to familiarize yourself with the Cronos zkEVM Sepolia testnet network.
Click below to see the next page.
# Set up a crypto wallet and connect it to Layer 1 and Layer 2
In order to use Cronos zkEVM, you need to have a self-custodial crypto wallet connected to Cronos zkEVM's testnet network.
## Create a crypto wallet
If you do not already have a self-custodial crypto wallet that uses Rabby or MetaMask, you will need to create one. Here are the links to their respective websites where you can download the app or browser extension:
* [Rabby](https://rabby.io) (browser extension for desktop)
* [MetaMask](https://metamask.io) (either the mobile app or the browser extension for desktop).
You can either create a new wallet (in this case, the seed phrase will be generated by the wallet), or import an existing wallet (using the seed phrase or private key of an existing wallet).
## Connect your crypto wallet
In order to complete all the quests, you will need to connect your crypto wallet to:
* Cronos zkEVM testnet network (Layer 2),
* and also, Ethereum Sepolia testnet (Layer 1)
Follow these links on how to connect your crypto wallet to the Cronos zkEVM testnet network:
* For Rabby:
* [Rabby Configuration](/for-users/crypto-wallets/rabby-configuration)
* For MetaMask:
* [MetaMask Configuration](/for-users/crypto-wallets/metamask-configuration)
# Get test tokens on Layer 1
Get ETH on Ethereum Sepolia testnet
On Ethereum Sepolia testnet, the testnet ETH token is called SepoliaETH.
In order to perform cross-chain transactions between Ethereum Sepolia testnet and Cronos zkEVM testnet, you will need a little bit of SepoliaETH.
Here is a list of third party websites where you can request SepoliaETH:
* Google Cloud:
* Alchemy:
* Infura:
* RockX:
* Chainstack:
* Quicknode:
* Other links:
## Get zkTCRO test tokens on Layer 1
Testnet zkCRO (ZKTCRO) is a testnet version of zkCRO, the protocol token used to pay for transaction fees on Cronos zkEVM.
You can get some zkTCRO on Ethereum Sepolia, which can be used to test the bridge from Ethereum Sepolia to Cronos zkEVM testnet.
To get zkTCRO, you need to call the `request` method of the following faucet contract. To avoid abuse, users need to send the same amount of SepoliaETH to the contract as the amount of zkTCRO requests. That amount is limited to 1 zkTCRO. To call the method, enter the amount in the text box, connect your Rabby or MetaMask wallet with the "Connect to Web3" Tab, fill in the amount the and click `Write`:
{% embed url="" %}
**Looking for an easier way?**
While the Cronos Testnet quests are underway, you can alternatively visit the page below which has an easier to user interface to request zkTCRO on Ethereum Sepolia:
{% embed url="" %}
When you see the transaction request in your wallet, you may see a significant number of warnings. This is because you are calling a testnet contract.
# Bridge test tokens to Cronos zkEVM testnet
## How to deposit tokens from L1 to L2 (testnet)
In order to complete this step, you need the following:
* Your crypto wallet must be set-up and connected to Ethereum Sepolia testnet
* You must have some SepoliaETH as well as some test ERC20 tokens (zkTCRO or other) in your wallet, on the Ethereum Sepolia testnet network.
See this page on how to acquire test tokens: [Get test tokens on Layer 1](/for-users/cronos-zkevm-testnet-tutorials/get-test-tokens-on-layer-1)
Visit the temporary testnet bridge at:
Your wallet may request 3 to 4 signatures consecutively to complete the transaction. Be patient.
Sometimes, transactions fail if Sepolia is too busy. As Sepolia is a testnet, its gas price varies suddently, which can cause transactions to fail. There is not much that we can do. You may need to try multiple times.
The Cronos zkEVM testnet bridge displays the following tokens by default:
* Test CRO (8 decimals)
* Address on L1: 0x4B7DFE9381149fA0E6738930fB24d015929C3926
* Address on L2: 0x9Fa683be5BFC78524995617f953cCDa22C688EC2
* zkTCRO (Test zkCRO) (18 decimals) - This is the gas token of Cronos zkEVM
* Address on L1: 0x49cE7551514f3c2Bf44B50442765Bb112d0e8204. The L1 token can be minted here:
* Address on L2: 0x000000000000000000000000000000000000800a. The L2 token can be minted here:
* ZKTT ("Cronos zkEVM Test Token") (18 decimals)
* Address on L1: 0x9048dBdA54CAb39fCAfDDfFC2e85b0b4E64B29e8
* Address on L2: 0x301B4a48c5b2a097f1634997DBcf29C7A8d6008c
* Note: The L1 token can be minted here:
* Test USDC (6 decimals)
* Address on L1: 0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238. The L1 Test USDC can be minted at this URL: (only available daily while there is available stock)
* Address on L2: 0x6d591768aAf861c40b2BbAe69C685a24DbB0Bab7
* Test DAI (18 decimals)
* Address on L1: 0x68194a729c2450ad26072b3d33adacbcef39d574
* Address on L2: 0xAD571981E923f8F97377Be1a4e032A6af470eDB0
In addition to the default tokens, you can deposit any other ERC20 token simply by entering the address of the smart contract.
# Get test tokens on Cronos zkEVM
## Introducing the testnet faucet
Testnet zkCRO (ZKTCRO) is a testnet version of zkCRO, the protocol token used to pay for transaction fees on Cronos zkEVM.
If you needs some ZKTCRO, you can get them for free from the faucet at .
Enter your EVM crypto wallet address (starting with `0x..`), confirm that you are not a robot, and click "get zkTCRO".
# Make transfers on Cronos zkEVM testnet
## Use the simple temporary web interface
On a temporary basis during the first weeks of the Cronos zkEVM Tethys testnet, you can use the following links to send zkTCRO or any other ERC20 token on the zkEVM network:
Transfer zkTCRO:
Transfer another ERC20 token:
## Use your wallet to transfer Testnet zkCRO (ZKTCRO)
In order to transfer ZKTCRO to another address, make sure that your crypto wallet is connected to Cronos zkEVM testnet.
Then, you can simply click" Send" together with the amount and recipient's address.
Here is an example with Rabby wallet:
## Use the blockchain explorer to transfer any ERC20 token
This method is more suitable for developers.
If you have any ERC20 tokens in your wallet, you can usually use the [Cronos zkEVM testnet explorer](https://explorer.zkevm.cronos.org/testnet/) to transfer them to another address, if the smart contract has been verified in the explorer. Visit the token's page on the [blockchain explorer](https://explorer.zkevm.cronos.org/testnet/) look for the Contract tab and the "Write" sub tab, and use the Transfer method, paying attention to the number of decimals.
# Create your own ERC20 token on Cronos zkEVM testnet
## Use the simple temporary web interface
If you are looking for a no-code tool to create your own coin on Cronos zkEVM testnet, you can visit the following page:
Just enter the token name, symbol and amount that you'd like to mint for yourself, and you are all set.
If other no-code platforms are deployed on Cronos zkEVM testnet, let us know and we'll list them here too.
## Use hardhat (suitable for developer)
Visit this page for details:
[Develop Smart Contracts and Dapps](/for-developers/develop-smart-contracts-and-dapps)
# Cronos zkEVM Tethys Testnet Quests
Quests powered Galxe between June 10 and June 30, 2024
These quests were powered by Galxe between June 10 and June 30, 2024. **The Tethys testnet quests are now ended.**
Users will be able to consult accumulated points on the Cronos zkEVM Pioneer Program website when it goes live in the coming weeks.
## About Cronos zkEVM Tethys testnet quests (for reference)
Starting on June 10, 2024, Cronos community members are invited to participate in the first phase of Cronos zkEVM quests.
This first phase of Cronos zkEVM activities takes place on the Cronos zkEVM Tethys testnet network.
Here is the link to the Galxe page with the quests:
## What is Cronos zkEVM Tethys testnet?
Cronos zkEVM is a zero-knowledge (ZK) layer-2 blockchain network secured by Ethereum, that represents a significant milestone on Cronos’ journey towards scalability and mainstream adoption.
The Cronos zkEVM project is a ZK Chain using ZK Stack, launched in a partnership between Cronos Labs and engineering teams from Matter Labs (the team behind zkSync), [Crypto.com](http://Crypto.com), VVS Finance, Fulcrom Finance and Veno Finance.
Cronos zkEVM is currently in testnet: none of the cryptocurrencies acquired or exchanged on the network have any monetary value.
**There will be some kinks to be ironed out, and potential outages for short durations as the testnet is constantly upgraded.**
The documentation of Cronos zkEVM is available here:
## Why quests?
The main goal of the quests is to get #CROFam familiar with the Cronos zkEVM (Layer 2) network and its interactions with the underlying Ethereum (Layer 1) network.
## What tasks do the quests involve?
The quests are be powered by [Galxe](https://galxe.com/cronos). On Galxe’s Cronos page, you will be able to retrieve the “Cronos zkEVM Tethys Testnet Quests” quest collection which lays out links to the various activities.
The quests involve a wide range of tasks, including:
* Amplify quest-related communications on social media.
* Learn how to connect a crypto wallet to Cronos zkEVM testnet.
* Register for the quests.
* Increase your CRO balance on Ethereum mainnet.
* Obtain test tokens on Ethereum Sepolia testnet and bridge them to Cronos zkEVM testnet.
* Acquire test tokens from the Cronos zkEVM faucet, and complete transactions on Cronos zkEVM testnet.
* Deploy your own coin on Cronos zkEVM and find users for it.
These tasks involve multiple blockchain networks: Ethereum mainnet, Ethereum Sepolia testnet, Cronos zkEVM testnet. Pay attention to all the details that are laid out on the quest pages, so that you don't mix up these blockchain networks!
## Are there rewards?
Quests are rewarded by Galxe points.
Users who complete all quests will be eligible for an original commemorative Cronos zkEVM NFT.
Preliminary plans are being drawn out so that these points can be transferred into a future Cronos zkEVM user reward program to be announced in the near future.
## Are there mechanisms in place to keep bots / sybil users away?
Yes. Thanks to various AI-based systems, users who are suspected of creating multiple wallets to collect points will eventually be excluded from the reward program.
## Where to find help?
To find out what the quests are about, the first port of call is the [Cronos page on Galxe](https://galxe.com/cronos).
You should also definitely check out the [Cronos zkEVM documentation](https://docs-zkevm.cronos.org/), as well as the specific documentation pages set out to explain [how to complete activities on Cronos zkEVM testnet](https://docs-zkevm.cronos.org/for-users/tethys-testnet-tutorials).
If you have unanswered questions, do not hesitate to head to the [Cronos server on Discord](https://discord.com/invite/cronos).
# FAQs
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-users/cronos-zkevm-bridge) **before the network is fully decommissioned.**
{% endhint %}
{% hint style="info" %}
Please be aware that some projects listed below are third-party services. We recommend conducting your own research (DYOR) before engaging with any third-party projects.
{% endhint %}
#### **Where can I find the list of applications available on Cronos zkEVM chain?**
In the Crypto.com Onchain Wallet, you can check the "browser" tab where you can see a selection of apps. \
You can also visit [https://discover.cronos.org](https://discover.cronos.org/) to browse a database of available DApps (decentralized apps) under `zkEVM` category:
**How can I bridge funds from CRO to zkCRO?**
There are several options for bridging funds from CRO to zkCRO. \
*Option 1:* \
*1)* Deposit $CRO (Cronos EVM) \
2\)Withdraw $CRO (Cronos zkEVM) \
3\) Exchange $CRO for $zkCRO on decentralized exchange (DEX) such as [H2 finance](https://h2.finance/swap) (gas fees can be paid in CRO on the zkEVM network).
*Option 2:* \
*1)* Hold CRO on the Ethereum (obtain CRO by swapping on Uniswap or purchasing from a centralized exchange (CEX), then withdrawing it to the Ethereum, as [shared in this guide](https://docs.cronos.org/for-users/bridge/app_n_ex)). \
2\) Use [Cronos zkEVM Bridge](https://zkevm.cronos.org/bridge) to swap CRO for zkCRO.
#### **How can I bridge funds from LCRO to zkCRO?**
*Option 1:* \
Unstake your LCRO on [Veno Finance](https://veno.finance/dashboard/) for CRO (on Cronos). Use [H2 Finance](https://h2.finance/swap) to swap for zkCRO. \
Note: Unstaking LCRO takes 28 days.
*Option 2:* \
Sell/Swap your LCRO for CRO on [VVS Finance](https://vvs.finance/limit-orders). Transfer the CRO to a centralized Exchange, withdraw CRO (on the Ethereum) network, then use the [Cronos zkEVM Bridge](https://zkevm.cronos.org/bridge/) to get zkCRO.
#### **How can I obtain zkCRO and how can I redeem zkCRO for CRO?**
Please refer to [zkCRO page](https://docs-zkevm.cronos.org/getting-started/about-zkcro-veth-vusd/zkcro#how-to-obtain-zkcro) for details.
#### **I claimed ybETH and requested for ETH, but I haven't seen ETH on Etherscan yet. What should I do?**
The bridging process can take more than 24 hours (plus time for the batch to settle). The stated period of "1-10 days" on bridge refers to the time required for ybETH to unstake, as it represents staked ETH. We recommend checking back after a few days, meanwhile you can also check your transaction status on Etherscan and Cronos zkEVM Explorer to make sure your transactions were successfully performed. We appreciate your patience during this process.
If you do not receive it within 10+ days, please open a ticket on [Cronos Discord](https://discord.gg/cronos) with your transaction details, and we'll be happy to assist you further.
# Resources for Developers
## Reference documentation
ZKsync documentation:
Relevant Github repositories:
*
*
* (Ethers library for Javascript)
## Cronos zkEVM Mainnet URLs
* Chain ID: `388`
* Token: zkCRO ("Cronos zkEVM CRO")
* JSON RPC API (rate limited):
* WebSocket (rate limited): `wss://ws.zkevm.cronos.org`
* Blockchain explorer:
* Gas price: :warning: The gas price of is currently fixed at `2500gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
* Developer portal:
* Contract verification interface:
* Bridge for ERC-20 tokens (Ethereum <=> Cronos zkEVM):
***
## Cronos zkEVM Sepolia Testnet URLs
* Chain ID: `240`
* Token: zkTCRO
* JSON RPC API (rate limited): [https://testnet.zkevm.cronos.org](https://testnet.zkevm.cronos.org/)
* WebSocket (rate limited): `wss://ws.testnet.zkevm.cronos.org`
* Blockchain explorer:
* Gas price: :warning: The gas price of is currently fixed at 1250`gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
* Developer portal:
* Contract verification interface:
* zkTCRO faucet:
* [Demo project repository](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate) for smart contract developers
* Testnet bridge for ERC-20 tokens (zkEVM testnet <=> Ethereum Sepolia):
***
#### Remix Plugin for zkEVM development
Remix users can leverage the `zksync` Remix plugin for their development. The plugin simplifies writing and deploying zkEVM smart contracts, making it accessible to both newcomers and experienced users. The plugin can be activated by searching with the keywords `zksync`
Read more:
# Develop Smart Contracts and Dapps
## Overview
Considering that Cronos zkEVM is based on zkSync technology, the zkSync docs at apply to Cronos zkEVM as well.
## Cronos zkEVM Mainnet
As far as the Cronos zkEVM testnet is concerned, the main differences with zkSync Era are:
* The JSON RPC URL:
* The Chain ID: `388`
* The blockchain explorer URL:
* WebSocket (rate limited): `wss://ws.zkevm.cronos.org`
{% hint style="info" %}
Please expect the JSON-RPC and WebSocket URLs to be rate limited. Rate limits will change over time.
{% endhint %}
* The denomination of the L2 protocol token: zkCRO
* Gas price: :warning: The gas price of is currently fixed at `1250gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
{% hint style="warning" %}
Whereas zkSync Era uses ETH as the token to pay for transaction fees on the Layer 2, Cronos zkEVM uses zkCRO. This means that the gas token of Cronos zkEVM (zkCRO) is different from the gas token on the Layer 1 (Ethereum). This is a major difference that developers need to take into account when they create cross-chain transactions.
{% endhint %}
***
## Cronos zkEVM Sepolia Testnet
As far as the Cronos zkEVM Sepolia testnet is concerned, the main differences with zkSync Era are:
* The JSON RPC URL:
* The Chain ID: `240`
* The blockchain explorer URL:
* WebSocket (rate limited): `wss://ws.testnet.zkevm.cronos.org`
{% hint style="info" %}
Please expect the JSON-RPC and WebSocket URLs to be rate limited. Rate limits will change over time
{% endhint %}
* Gas price: :warning: The gas price of is currently fixed at `1250gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
* The denomination of the L2 protocol token: zkTCRO
# Contract Deployment and Verification
## Contract Deployment
Like zkSync Era, Cronos zkEVM recommends the use of:
* Hardhat for smart contract development
* Node Typescript with the ethers library for backend and frontend development
While the [zkSync docs](https://docs.zksync.io/) are the most comprehensive and up to date source of information, you can also refer to [this linked repository](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate), created especially for Cronos zkEVM Chain, which shows how to read the blockchain, write on the blockchain, and develop smart contracts:
* Refer to the [README.md](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate/blob/main/README.md) file for a list of frequently used commands.
* The typical network configuration parameters are shown in the [hardhat.config.ts](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate/blob/main/hardhat.config.ts) file.
* The scripts directories contain some useful examples of scripts and functions that you may need to execute calls and transactions.
## Contract Verification
In order to enable users and fellow developers to do their own research, it is imperative that you publish your smart contract code on Cronos zkEVM Explorer.
The Cronos zkEVM Explorer supports smart contract verification either through the web interface or programmatically via Hardhat (**we recommend to use Hardhat**).
#### **Contract Verification Via Hardhat:**
Cronos zkEVM is supported by Hardhat out of the box, to verify contract using Hardhat, we will need:
1. **Configure the network parameters in `hardhat.config.js`**, referring to this [guide](https://explorer-api-doc.zkevm.cronos.org/mainnet/index.html#post-https-//explorer-api.zkevm.cronos.org/api/v1/contract/verify/hardhat). As an example, the `verifyURL` for mainnet should be set as
{% tabs %}
{% tab title="Mainnet" %}
```
verifyURL: "https://explorer-api.zkevm.cronos.org/api/v1/contract/verify/hardhat?apikey={apikey}"
```
{% endtab %}
{% tab title="Testnet" %}
```
verifyURL: "https://explorer-api.testnet.zkevm.cronos.org/api/v1/contract/verify/hardhat?apikey={apikey}"
```
{% endtab %}
{% endtabs %}
2. **A "Developers Portal" API key**, refer to below guides on how to register and obtain one.
* Cronos zkEVM Mainnet:
* Cronos zkEVM Testnet:
**We can also refer to the example provided in** [**this boilerplate repository**](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate/blob/main/README.md#compilation-and-deployment)**.**
{% hint style="warning" %}
Note: During the contract verification Via Hardhat **-** Please install and use **`@matterlabs/hardhat-zksync-verify`** version 1.7.1+ instead of *hardhat-etherscan*
{% endhint %}
After the contract verification is complete, the [Cronos zkEVM Explorer](https://explorer.zkevm.cronos.org/) will display details about your smart contract code.
#### **Contract Verification Via Explorer interface:**
For verification via the web interface, visit the following URLs:
* Mainnet:
* Testnet:
{% hint style="warning" %}
Note that when using contract verification via the explorer interface, `Standard-Json-Input` method is required. Reference for the JSON file format:
{% endhint %}
***
## Important note about tokens
If you are planning to deploy a ERC20 token on Cronos zkEVM, keep in mind that there are two ways to do this:
* Deploy directly on the L2: this approach is simple to implement, but in that case, the ERC20 token won’t be supported natively by the hyperbridge between L1 and L2, and between hyperchains. A custom bridge will be required to withdraw or transfer tokens from the L2.
* Deploy first on the L1, then deposit to the L2: this approach requires two steps, but its advantage is that the tokens will be natively supported by the hyperbridge between L1 and L2. They can be deposited into the L2, or withdrawn from the L2, at will. When the first token is deposited from L1 to L2, the hyberbridge automatically creates a ERC20 smart contract on L2, which is the representation of the L1 token on the L2.
After deploying your smart contract, you will need to publish and verify its code in the block explorer:
* If you have deployed directly on the L2, the deployment script included in the boilerplate project performs the contract code publication and verification automatically.
* If you deploy first on the L1 (Ethereum Sepolia), you can publish and verify the contract code on the Etherscan Sepolia block explorer as usual. With respect to publishing and verifying the code of the L2 smart contract created by the hyperbridge, this is not yet supported.
# Contract Verification Guide for the Cronos zkEVM Explorer
This guide provides explanations for input fields used in the contract verification process on [Cronos zkEVM explorer](https://explorer.zkevm.cronos.org/verifyContract) and [Developer Portal](https://developers.zkevm.cronos.org/verifyContract).
\
Input fields
------------
### Contract Name
Contract name refers to the defined entry point contract of the contract deployment, or the name of the contract in the `.sol` file. \
\
Taking a simple ERC20 token contract as an example, the contract entry point is `MyERC20Token` contract:
...
contract MyERC20Token is ERC20Burnable, ERC20Pausable, AccessControl {
...
}
This contract's entry point is `MyERC20Token` contract.
### Contract Path
Relative path to the file which contains the defined entry point contract. In simpler terms, this is the path to contact specified on `Contract name` .
### Contract Address
* The address of the contract deployed on chain.
* If you are unsure about the `Constructor Arguments` value you used, you can click the `Get Suggested Constructor Arguments` button.
### Compiler Type
1. `Solidity Standard-Json-Input` (Recommended)
* Supports complex or customized compiler setups. Refer to [Solidity Standard-Json-Input](https://docs.zksync.io/build/tooling/hardhat/plugins/hardhat-zksync-solc#configuration) for more details.
* A JSON file shall be specified as input JSON. More details in Contract Files section.
2. `Harthat Build-Map-Json` (Not the default option, but recommended)
* Supports complex or customized compiler setups.
* Prefill the corresponding `zkSync Compiler Version`, `Compiler Version` and `Era Version` during contract compilation.
* The build map JSON file generated by Hardhat during contract compilation.
3. `Solidity Files`
* Only applicable to simple contract setup. If you cannot verify the contract with `Solidity Files` compiler type, we recommend you to try with the `Solidity Standard-Json-Input` Compiler Type.
* You need to upload the `.sol` file(s) to the Explorer.
### Contract Files
| Option | Contract Files to be Provided |
| ------------------------------ | ----------------------------- |
| `Solidity Standard-Json-input` | JSON file |
| `Hardhat Build-Map-Json` | JSON file |
| `Solidity Files` | Contract file(s) |
Here are some suggestion to get the corresponding file(s):
* For `Solidity Standard-Json-input`, only single JSON file is required.
1. Look for the hash-named JSON file, i.e. `{hash}.json`, under the `artifacts-zk/build-info/` directory if using hardhat
2. Look for `input` field inside the JSON file
```
...
"input" : {
"language": "Solidity",
"sources": {
...
},
"settings": {
"optimizer": {
"enabled": true,
"mode": "3"
},
"outputSelection": {
"*": {
"*": [
"abi",
"evm.methodIdentifiers",
"metadata"
],
"": [
"ast"
]
}
},
...
}
}
...
```
3. Copy the field value as a separated JSON file
4. Select the separated JSON file i.e. `solidity.JSON` in above example
* For `Hardhat Build-Map-Json`, only single JSON file is required.
* Look for the hash-named JSON file, i.e. `{hash}.json`, under the `artifacts-zk/build-info/` directory if using hardhat
* Select the hash-named JSON file directly
* For `Solidity Files` compiler type, you can select multiple Solidity file(s).
* Finally, agree to the terms and conditions, complete the "I'm not a robot" verification, and submit.
### zkSync Compiler Version
zkSync Compiler is a modified version of solc that operates on IR and metadata received from underlying solc compiler, refer to [zkSync documentation](https://docs.zksync.io/zk-stack/components/compiler/toolchain/solidity) for more details.
* This is the zkSync Compiler version chosen during compilation.
* For `zkSync Compiler Version` >= `v1.5.0`, an additional EraVM compiler is introduced and you will have to select the right EraVM compiler version during verification. More details in [Compiler Version](https://github.com/crypto-com/evm-chain-contract-verification-server/blob/cca89016d28cb4cbc514147d4739afb5a41de54f/verify-contract.md#compiler-version) section.
### Compiler Version and Era Version
Solidity Compiler version and Era Version is usually set automatically, but it's possible to define it manually. Please refer to [this documentation](https://docs.zksync.io/build/tooling/hardhat/plugins/hardhat-zksync-solc#zksync-era-solidity-compiler) about ZKsync Era Solidity Compiler for setup details.
1. After `zkSync Compiler Version` >= `v1.5.0`, EraVM compiler version is introduced on Solidity Compiler.
* Version format: `zkVM-{solidity_version}-{era_version}`
* `Compiler Version` consists of two parts, `solidity_version` and `era_version`. Both version values are available from the `hardhat.config.ts` if using hardhat
* **Example 1**
```
solidity: {
version: "0.8.24", // solidity_version
eraVersion: "1.0.0" // era_version (use latest available version if not specified)
},
```
In this example:
* `Compiler Version` is `zkVM-0.8.24`.
* `Era Version` is `1.0.0`.
* **Example 2**
```
solidity: {
version: "0.8.24", // solidity_version
},
```
At the time of writing, the latest EraVM version is `1.0.1`, hence in this example:
* `Compiler Version` is `zkVM-0.8.24`.
* `Era Version` is `1.0.1`.
2. Before `zkSync Compiler Version` < `v1.5.0`, only Solidity Compiler Version exist during compilation.
* Version format: `{solidity_version}`
* `Compiler Version` only has one part `solidity_version`. Its value is available from the `hardhat.config.ts` if using hardhat
```
solidity: {
version: "0.8.24", // solidity_version
},
```
In this example:
* `Compiler version` is `0.8.24`
* There is no `Era Version`
**Recovering Compiler Version from Build Metadata**
Compiler Version is also available in the build map JSON file located under `artifacts-zk/build-info/` directory. Look for the build map JSON file with your target contract under the `input` field key, the Compiler Version is specified at under the field key `solcVersion`.
* **Example 1** \
After `zkSync Compiler Version` >= `v1.5.0`
```
{
"id": "6af880e028e122ca242ea4337bd9b9e8",
"_format": "hh-sol-build-info-1",
"solcVersion": "zkVM-0.8.20-1.0.1",
"solcLongVersion": "0.8.24+commit.e11b9ed9",
"input": ...,
"output": ...
}
```
In this example:
* `Compiler Version` is `zkVM-0.8.20`.
* `Era Version` is `1.0.1`.
* **Example 2** \
Before `zkSync Compiler Version` < `v1.5.0`
```
{
"id": "b02558cd8ed94e8b0de42c4345fdc761",
"_format": "hh-sol-build-info-1",
"solcVersion": "0.8.24",
"solcLongVersion": "0.8.24+commit.e11b9ed9",
"input": ...,
"output": ...
}
```
In this example:
* `Compiler Version` is `0.8.24`.
* There is no `Era Version`
**Compiler Version Dependency List**
Here is a list of possible compiler version combinations list based on different ZkSolc versions.
| ZkSolc version | Solc version | EraVM version |
| ----------------- | ------------ | ------------- |
| v1.5.3 - v1.5.0 | <= 0.8.26 | Existed |
| v1.4.1 | <= 0.8.25 | None |
| v1.4.0 | <= 0.8.24 | None |
| v1.3.23 - v1.3.15 | <= 0.8.23 | None |
| v1.3.14 | <= 0.8.21 | None |
| v1.3.13 - v1.3.11 | <= 0.8.20 | None |
| v1.3.10 - v1.3.6 | <= 0.8.19 | None |
| v1.3.5 | <= 0.8.18 | None |
| <= v1.3.4 | <= 0.8.17 | None |
### **Constructor Arguments**
Arguments that passed to the constructor when deploying the contract. This option applies ONLY to contracts that accept constructor arguments. If you're unsure, you can leave this field empty initially. Also, constructor arguments should be in ABI-ENCODED values WITHOUT `0x`.
### Contract Verification Example
We will use this smart contract on [Github](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate) as an example. It is deployed on Cronos zkEVM Testnet at [0x8fc3246677f359f0c89c2c8103244b8256cdef5e](https://explorer.zkevm.cronos.org/testnet/address/0x8fc3246677f359f0c89c2c8103244b8256cdef5e#code).
Here are the parameters to be used for verifying the `MyERC20Token` contract.
* Contract Name: `"MyERC20Token"`
* Contract Path: `"contracts/MyERC20Token.sol"`
* Contract Address: `"0x8fc3246677f359f0c89c2c8103244b8256cdef5e"`
* Compiler Type: `"Standard-Json-Input compiler"`
* Compiler Version: `"0.8.24"`
* ZKSync Compiler Version: `"v1.4.1"`
* Constructor Arguments: `""`
* Contract Files
Sample Standard-Json-Input file
````
```
{
"language": "Solidity",
"sources": {
"@openzeppelin/contracts/access/AccessControl.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (access/AccessControl.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./IAccessControl.sol\";\nimport \"../utils/Context.sol\";\nimport \"../utils/Strings.sol\";\nimport \"../utils/introspection/ERC165.sol\";\n\n/**\n * @dev Contract module that allows children to implement role-based access\n * control mechanisms. This is a lightweight version that doesn't allow enumerating role\n * members except through off-chain means by accessing the contract event logs. Some\n * applications may benefit from on-chain enumerability, for those cases see\n * {AccessControlEnumerable}.\n *\n * Roles are referred to by their `bytes32` identifier. These should be exposed\n * in the external API and be unique. The best way to achieve this is by\n * using `public constant` hash digests:\n *\n * ```solidity\n * bytes32 public constant MY_ROLE = keccak256(\"MY_ROLE\");\n * ```\n *\n * Roles can be used to represent a set of permissions. To restrict access to a\n * function call, use {hasRole}:\n *\n * ```solidity\n * function foo() public {\n * require(hasRole(MY_ROLE, msg.sender));\n * ...\n * }\n * ```\n *\n * Roles can be granted and revoked dynamically via the {grantRole} and\n * {revokeRole} functions. Each role has an associated admin role, and only\n * accounts that have a role's admin role can call {grantRole} and {revokeRole}.\n *\n * By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means\n * that only accounts with this role will be able to grant or revoke other\n * roles. More complex role relationships can be created by using\n * {_setRoleAdmin}.\n *\n * WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to\n * grant and revoke this role. Extra precautions should be taken to secure\n * accounts that have been granted it. We recommend using {AccessControlDefaultAdminRules}\n * to enforce additional security measures for this role.\n */\nabstract contract AccessControl is Context, IAccessControl, ERC165 {\n struct RoleData {\n mapping(address => bool) members;\n bytes32 adminRole;\n }\n\n mapping(bytes32 => RoleData) private _roles;\n\n bytes32 public constant DEFAULT_ADMIN_ROLE = 0x00;\n\n /**\n * @dev Modifier that checks that an account has a specific role. Reverts\n * with a standardized message including the required role.\n *\n * The format of the revert reason is given by the following regular expression:\n *\n * /^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/\n *\n * _Available since v4.1._\n */\n modifier onlyRole(bytes32 role) {\n _checkRole(role);\n _;\n }\n\n /**\n * @dev See {IERC165-supportsInterface}.\n */\n function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {\n return interfaceId == type(IAccessControl).interfaceId || super.supportsInterface(interfaceId);\n }\n\n /**\n * @dev Returns `true` if `account` has been granted `role`.\n */\n function hasRole(bytes32 role, address account) public view virtual override returns (bool) {\n return _roles[role].members[account];\n }\n\n /**\n * @dev Revert with a standard message if `_msgSender()` is missing `role`.\n * Overriding this function changes the behavior of the {onlyRole} modifier.\n *\n * Format of the revert message is described in {_checkRole}.\n *\n * _Available since v4.6._\n */\n function _checkRole(bytes32 role) internal view virtual {\n _checkRole(role, _msgSender());\n }\n\n /**\n * @dev Revert with a standard message if `account` is missing `role`.\n *\n * The format of the revert reason is given by the following regular expression:\n *\n * /^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/\n */\n function _checkRole(bytes32 role, address account) internal view virtual {\n if (!hasRole(role, account)) {\n revert(\n string(\n abi.encodePacked(\n \"AccessControl: account \",\n Strings.toHexString(account),\n \" is missing role \",\n Strings.toHexString(uint256(role), 32)\n )\n )\n );\n }\n }\n\n /**\n * @dev Returns the admin role that controls `role`. See {grantRole} and\n * {revokeRole}.\n *\n * To change a role's admin, use {_setRoleAdmin}.\n */\n function getRoleAdmin(bytes32 role) public view virtual override returns (bytes32) {\n return _roles[role].adminRole;\n }\n\n /**\n * @dev Grants `role` to `account`.\n *\n * If `account` had not been already granted `role`, emits a {RoleGranted}\n * event.\n *\n * Requirements:\n *\n * - the caller must have ``role``'s admin role.\n *\n * May emit a {RoleGranted} event.\n */\n function grantRole(bytes32 role, address account) public virtual override onlyRole(getRoleAdmin(role)) {\n _grantRole(role, account);\n }\n\n /**\n * @dev Revokes `role` from `account`.\n *\n * If `account` had been granted `role`, emits a {RoleRevoked} event.\n *\n * Requirements:\n *\n * - the caller must have ``role``'s admin role.\n *\n * May emit a {RoleRevoked} event.\n */\n function revokeRole(bytes32 role, address account) public virtual override onlyRole(getRoleAdmin(role)) {\n _revokeRole(role, account);\n }\n\n /**\n * @dev Revokes `role` from the calling account.\n *\n * Roles are often managed via {grantRole} and {revokeRole}: this function's\n * purpose is to provide a mechanism for accounts to lose their privileges\n * if they are compromised (such as when a trusted device is misplaced).\n *\n * If the calling account had been revoked `role`, emits a {RoleRevoked}\n * event.\n *\n * Requirements:\n *\n * - the caller must be `account`.\n *\n * May emit a {RoleRevoked} event.\n */\n function renounceRole(bytes32 role, address account) public virtual override {\n require(account == _msgSender(), \"AccessControl: can only renounce roles for self\");\n\n _revokeRole(role, account);\n }\n\n /**\n * @dev Grants `role` to `account`.\n *\n * If `account` had not been already granted `role`, emits a {RoleGranted}\n * event. Note that unlike {grantRole}, this function doesn't perform any\n * checks on the calling account.\n *\n * May emit a {RoleGranted} event.\n *\n * [WARNING]\n * ====\n * This function should only be called from the constructor when setting\n * up the initial roles for the system.\n *\n * Using this function in any other way is effectively circumventing the admin\n * system imposed by {AccessControl}.\n * ====\n *\n * NOTE: This function is deprecated in favor of {_grantRole}.\n */\n function _setupRole(bytes32 role, address account) internal virtual {\n _grantRole(role, account);\n }\n\n /**\n * @dev Sets `adminRole` as ``role``'s admin role.\n *\n * Emits a {RoleAdminChanged} event.\n */\n function _setRoleAdmin(bytes32 role, bytes32 adminRole) internal virtual {\n bytes32 previousAdminRole = getRoleAdmin(role);\n _roles[role].adminRole = adminRole;\n emit RoleAdminChanged(role, previousAdminRole, adminRole);\n }\n\n /**\n * @dev Grants `role` to `account`.\n *\n * Internal function without access restriction.\n *\n * May emit a {RoleGranted} event.\n */\n function _grantRole(bytes32 role, address account) internal virtual {\n if (!hasRole(role, account)) {\n _roles[role].members[account] = true;\n emit RoleGranted(role, account, _msgSender());\n }\n }\n\n /**\n * @dev Revokes `role` from `account`.\n *\n * Internal function without access restriction.\n *\n * May emit a {RoleRevoked} event.\n */\n function _revokeRole(bytes32 role, address account) internal virtual {\n if (hasRole(role, account)) {\n _roles[role].members[account] = false;\n emit RoleRevoked(role, account, _msgSender());\n }\n }\n}\n"
},
"@openzeppelin/contracts/access/IAccessControl.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (access/IAccessControl.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev External interface of AccessControl declared to support ERC165 detection.\n */\ninterface IAccessControl {\n /**\n * @dev Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole`\n *\n * `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite\n * {RoleAdminChanged} not being emitted signaling this.\n *\n * _Available since v3.1._\n */\n event RoleAdminChanged(bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole);\n\n /**\n * @dev Emitted when `account` is granted `role`.\n *\n * `sender` is the account that originated the contract call, an admin role\n * bearer except when using {AccessControl-_setupRole}.\n */\n event RoleGranted(bytes32 indexed role, address indexed account, address indexed sender);\n\n /**\n * @dev Emitted when `account` is revoked `role`.\n *\n * `sender` is the account that originated the contract call:\n * - if using `revokeRole`, it is the admin role bearer\n * - if using `renounceRole`, it is the role bearer (i.e. `account`)\n */\n event RoleRevoked(bytes32 indexed role, address indexed account, address indexed sender);\n\n /**\n * @dev Returns `true` if `account` has been granted `role`.\n */\n function hasRole(bytes32 role, address account) external view returns (bool);\n\n /**\n * @dev Returns the admin role that controls `role`. See {grantRole} and\n * {revokeRole}.\n *\n * To change a role's admin, use {AccessControl-_setRoleAdmin}.\n */\n function getRoleAdmin(bytes32 role) external view returns (bytes32);\n\n /**\n * @dev Grants `role` to `account`.\n *\n * If `account` had not been already granted `role`, emits a {RoleGranted}\n * event.\n *\n * Requirements:\n *\n * - the caller must have ``role``'s admin role.\n */\n function grantRole(bytes32 role, address account) external;\n\n /**\n * @dev Revokes `role` from `account`.\n *\n * If `account` had been granted `role`, emits a {RoleRevoked} event.\n *\n * Requirements:\n *\n * - the caller must have ``role``'s admin role.\n */\n function revokeRole(bytes32 role, address account) external;\n\n /**\n * @dev Revokes `role` from the calling account.\n *\n * Roles are often managed via {grantRole} and {revokeRole}: this function's\n * purpose is to provide a mechanism for accounts to lose their privileges\n * if they are compromised (such as when a trusted device is misplaced).\n *\n * If the calling account had been granted `role`, emits a {RoleRevoked}\n * event.\n *\n * Requirements:\n *\n * - the caller must be `account`.\n */\n function renounceRole(bytes32 role, address account) external;\n}\n"
},
"@openzeppelin/contracts/access/Ownable.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (access/Ownable.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../utils/Context.sol\";\n\n/**\n * @dev Contract module which provides a basic access control mechanism, where\n * there is an account (an owner) that can be granted exclusive access to\n * specific functions.\n *\n * By default, the owner account will be the one that deploys the contract. This\n * can later be changed with {transferOwnership}.\n *\n * This module is used through inheritance. It will make available the modifier\n * `onlyOwner`, which can be applied to your functions to restrict their use to\n * the owner.\n */\nabstract contract Ownable is Context {\n address private _owner;\n\n event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);\n\n /**\n * @dev Initializes the contract setting the deployer as the initial owner.\n */\n constructor() {\n _transferOwnership(_msgSender());\n }\n\n /**\n * @dev Throws if called by any account other than the owner.\n */\n modifier onlyOwner() {\n _checkOwner();\n _;\n }\n\n /**\n * @dev Returns the address of the current owner.\n */\n function owner() public view virtual returns (address) {\n return _owner;\n }\n\n /**\n * @dev Throws if the sender is not the owner.\n */\n function _checkOwner() internal view virtual {\n require(owner() == _msgSender(), \"Ownable: caller is not the owner\");\n }\n\n /**\n * @dev Leaves the contract without owner. It will not be possible to call\n * `onlyOwner` functions. Can only be called by the current owner.\n *\n * NOTE: Renouncing ownership will leave the contract without an owner,\n * thereby disabling any functionality that is only available to the owner.\n */\n function renounceOwnership() public virtual onlyOwner {\n _transferOwnership(address(0));\n }\n\n /**\n * @dev Transfers ownership of the contract to a new account (`newOwner`).\n * Can only be called by the current owner.\n */\n function transferOwnership(address newOwner) public virtual onlyOwner {\n require(newOwner != address(0), \"Ownable: new owner is the zero address\");\n _transferOwnership(newOwner);\n }\n\n /**\n * @dev Transfers ownership of the contract to a new account (`newOwner`).\n * Internal function without access restriction.\n */\n function _transferOwnership(address newOwner) internal virtual {\n address oldOwner = _owner;\n _owner = newOwner;\n emit OwnershipTransferred(oldOwner, newOwner);\n }\n}\n"
},
"@openzeppelin/contracts/interfaces/draft-IERC1822.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.5.0) (interfaces/draft-IERC1822.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev ERC1822: Universal Upgradeable Proxy Standard (UUPS) documents a method for upgradeability through a simplified\n * proxy whose upgrades are fully controlled by the current implementation.\n */\ninterface IERC1822Proxiable {\n /**\n * @dev Returns the storage slot that the proxiable contract assumes is being used to store the implementation\n * address.\n *\n * IMPORTANT: A proxy pointing at a proxiable contract should not be considered proxiable itself, because this risks\n * bricking a proxy that upgrades to it, by delegating to itself until out of gas. Thus it is critical that this\n * function revert if invoked through a proxy.\n */\n function proxiableUUID() external view returns (bytes32);\n}\n"
},
"@openzeppelin/contracts/interfaces/IERC1967.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (interfaces/IERC1967.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev ERC-1967: Proxy Storage Slots. This interface contains the events defined in the ERC.\n *\n * _Available since v4.8.3._\n */\ninterface IERC1967 {\n /**\n * @dev Emitted when the implementation is upgraded.\n */\n event Upgraded(address indexed implementation);\n\n /**\n * @dev Emitted when the admin account has changed.\n */\n event AdminChanged(address previousAdmin, address newAdmin);\n\n /**\n * @dev Emitted when the beacon is changed.\n */\n event BeaconUpgraded(address indexed beacon);\n}\n"
},
"@openzeppelin/contracts/proxy/beacon/BeaconProxy.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.7.0) (proxy/beacon/BeaconProxy.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./IBeacon.sol\";\nimport \"../Proxy.sol\";\nimport \"../ERC1967/ERC1967Upgrade.sol\";\n\n/**\n * @dev This contract implements a proxy that gets the implementation address for each call from an {UpgradeableBeacon}.\n *\n * The beacon address is stored in storage slot `uint256(keccak256('eip1967.proxy.beacon')) - 1`, so that it doesn't\n * conflict with the storage layout of the implementation behind the proxy.\n *\n * _Available since v3.4._\n */\ncontract BeaconProxy is Proxy, ERC1967Upgrade {\n /**\n * @dev Initializes the proxy with `beacon`.\n *\n * If `data` is nonempty, it's used as data in a delegate call to the implementation returned by the beacon. This\n * will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity\n * constructor.\n *\n * Requirements:\n *\n * - `beacon` must be a contract with the interface {IBeacon}.\n */\n constructor(address beacon, bytes memory data) payable {\n _upgradeBeaconToAndCall(beacon, data, false);\n }\n\n /**\n * @dev Returns the current beacon address.\n */\n function _beacon() internal view virtual returns (address) {\n return _getBeacon();\n }\n\n /**\n * @dev Returns the current implementation address of the associated beacon.\n */\n function _implementation() internal view virtual override returns (address) {\n return IBeacon(_getBeacon()).implementation();\n }\n\n /**\n * @dev Changes the proxy to use a new beacon. Deprecated: see {_upgradeBeaconToAndCall}.\n *\n * If `data` is nonempty, it's used as data in a delegate call to the implementation returned by the beacon.\n *\n * Requirements:\n *\n * - `beacon` must be a contract.\n * - The implementation returned by `beacon` must be a contract.\n */\n function _setBeacon(address beacon, bytes memory data) internal virtual {\n _upgradeBeaconToAndCall(beacon, data, false);\n }\n}\n"
},
"@openzeppelin/contracts/proxy/beacon/IBeacon.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (proxy/beacon/IBeacon.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev This is the interface that {BeaconProxy} expects of its beacon.\n */\ninterface IBeacon {\n /**\n * @dev Must return an address that can be used as a delegate call target.\n *\n * {BeaconProxy} will check that this address is a contract.\n */\n function implementation() external view returns (address);\n}\n"
},
"@openzeppelin/contracts/proxy/beacon/UpgradeableBeacon.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (proxy/beacon/UpgradeableBeacon.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./IBeacon.sol\";\nimport \"../../access/Ownable.sol\";\nimport \"../../utils/Address.sol\";\n\n/**\n * @dev This contract is used in conjunction with one or more instances of {BeaconProxy} to determine their\n * implementation contract, which is where they will delegate all function calls.\n *\n * An owner is able to change the implementation the beacon points to, thus upgrading the proxies that use this beacon.\n */\ncontract UpgradeableBeacon is IBeacon, Ownable {\n address private _implementation;\n\n /**\n * @dev Emitted when the implementation returned by the beacon is changed.\n */\n event Upgraded(address indexed implementation);\n\n /**\n * @dev Sets the address of the initial implementation, and the deployer account as the owner who can upgrade the\n * beacon.\n */\n constructor(address implementation_) {\n _setImplementation(implementation_);\n }\n\n /**\n * @dev Returns the current implementation address.\n */\n function implementation() public view virtual override returns (address) {\n return _implementation;\n }\n\n /**\n * @dev Upgrades the beacon to a new implementation.\n *\n * Emits an {Upgraded} event.\n *\n * Requirements:\n *\n * - msg.sender must be the owner of the contract.\n * - `newImplementation` must be a contract.\n */\n function upgradeTo(address newImplementation) public virtual onlyOwner {\n _setImplementation(newImplementation);\n emit Upgraded(newImplementation);\n }\n\n /**\n * @dev Sets the implementation contract address for this beacon\n *\n * Requirements:\n *\n * - `newImplementation` must be a contract.\n */\n function _setImplementation(address newImplementation) private {\n require(Address.isContract(newImplementation), \"UpgradeableBeacon: implementation is not a contract\");\n _implementation = newImplementation;\n }\n}\n"
},
"@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.7.0) (proxy/ERC1967/ERC1967Proxy.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../Proxy.sol\";\nimport \"./ERC1967Upgrade.sol\";\n\n/**\n * @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an\n * implementation address that can be changed. This address is stored in storage in the location specified by\n * https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the\n * implementation behind the proxy.\n */\ncontract ERC1967Proxy is Proxy, ERC1967Upgrade {\n /**\n * @dev Initializes the upgradeable proxy with an initial implementation specified by `_logic`.\n *\n * If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded\n * function call, and allows initializing the storage of the proxy like a Solidity constructor.\n */\n constructor(address _logic, bytes memory _data) payable {\n _upgradeToAndCall(_logic, _data, false);\n }\n\n /**\n * @dev Returns the current implementation address.\n */\n function _implementation() internal view virtual override returns (address impl) {\n return ERC1967Upgrade._getImplementation();\n }\n}\n"
},
"@openzeppelin/contracts/proxy/ERC1967/ERC1967Upgrade.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (proxy/ERC1967/ERC1967Upgrade.sol)\n\npragma solidity ^0.8.2;\n\nimport \"../beacon/IBeacon.sol\";\nimport \"../../interfaces/IERC1967.sol\";\nimport \"../../interfaces/draft-IERC1822.sol\";\nimport \"../../utils/Address.sol\";\nimport \"../../utils/StorageSlot.sol\";\n\n/**\n * @dev This abstract contract provides getters and event emitting update functions for\n * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.\n *\n * _Available since v4.1._\n */\nabstract contract ERC1967Upgrade is IERC1967 {\n // This is the keccak-256 hash of \"eip1967.proxy.rollback\" subtracted by 1\n bytes32 private constant _ROLLBACK_SLOT = 0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143;\n\n /**\n * @dev Storage slot with the address of the current implementation.\n * This is the keccak-256 hash of \"eip1967.proxy.implementation\" subtracted by 1, and is\n * validated in the constructor.\n */\n bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;\n\n /**\n * @dev Returns the current implementation address.\n */\n function _getImplementation() internal view returns (address) {\n return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;\n }\n\n /**\n * @dev Stores a new address in the EIP1967 implementation slot.\n */\n function _setImplementation(address newImplementation) private {\n require(Address.isContract(newImplementation), \"ERC1967: new implementation is not a contract\");\n StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;\n }\n\n /**\n * @dev Perform implementation upgrade\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeTo(address newImplementation) internal {\n _setImplementation(newImplementation);\n emit Upgraded(newImplementation);\n }\n\n /**\n * @dev Perform implementation upgrade with additional setup call.\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeToAndCall(address newImplementation, bytes memory data, bool forceCall) internal {\n _upgradeTo(newImplementation);\n if (data.length > 0 || forceCall) {\n Address.functionDelegateCall(newImplementation, data);\n }\n }\n\n /**\n * @dev Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.\n *\n * Emits an {Upgraded} event.\n */\n function _upgradeToAndCallUUPS(address newImplementation, bytes memory data, bool forceCall) internal {\n // Upgrades from old implementations will perform a rollback test. This test requires the new\n // implementation to upgrade back to the old, non-ERC1822 compliant, implementation. Removing\n // this special case will break upgrade paths from old UUPS implementation to new ones.\n if (StorageSlot.getBooleanSlot(_ROLLBACK_SLOT).value) {\n _setImplementation(newImplementation);\n } else {\n try IERC1822Proxiable(newImplementation).proxiableUUID() returns (bytes32 slot) {\n require(slot == _IMPLEMENTATION_SLOT, \"ERC1967Upgrade: unsupported proxiableUUID\");\n } catch {\n revert(\"ERC1967Upgrade: new implementation is not UUPS\");\n }\n _upgradeToAndCall(newImplementation, data, forceCall);\n }\n }\n\n /**\n * @dev Storage slot with the admin of the contract.\n * This is the keccak-256 hash of \"eip1967.proxy.admin\" subtracted by 1, and is\n * validated in the constructor.\n */\n bytes32 internal constant _ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;\n\n /**\n * @dev Returns the current admin.\n */\n function _getAdmin() internal view returns (address) {\n return StorageSlot.getAddressSlot(_ADMIN_SLOT).value;\n }\n\n /**\n * @dev Stores a new address in the EIP1967 admin slot.\n */\n function _setAdmin(address newAdmin) private {\n require(newAdmin != address(0), \"ERC1967: new admin is the zero address\");\n StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;\n }\n\n /**\n * @dev Changes the admin of the proxy.\n *\n * Emits an {AdminChanged} event.\n */\n function _changeAdmin(address newAdmin) internal {\n emit AdminChanged(_getAdmin(), newAdmin);\n _setAdmin(newAdmin);\n }\n\n /**\n * @dev The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy.\n * This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor.\n */\n bytes32 internal constant _BEACON_SLOT = 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50;\n\n /**\n * @dev Returns the current beacon.\n */\n function _getBeacon() internal view returns (address) {\n return StorageSlot.getAddressSlot(_BEACON_SLOT).value;\n }\n\n /**\n * @dev Stores a new beacon in the EIP1967 beacon slot.\n */\n function _setBeacon(address newBeacon) private {\n require(Address.isContract(newBeacon), \"ERC1967: new beacon is not a contract\");\n require(\n Address.isContract(IBeacon(newBeacon).implementation()),\n \"ERC1967: beacon implementation is not a contract\"\n );\n StorageSlot.getAddressSlot(_BEACON_SLOT).value = newBeacon;\n }\n\n /**\n * @dev Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does\n * not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that).\n *\n * Emits a {BeaconUpgraded} event.\n */\n function _upgradeBeaconToAndCall(address newBeacon, bytes memory data, bool forceCall) internal {\n _setBeacon(newBeacon);\n emit BeaconUpgraded(newBeacon);\n if (data.length > 0 || forceCall) {\n Address.functionDelegateCall(IBeacon(newBeacon).implementation(), data);\n }\n }\n}\n"
},
"@openzeppelin/contracts/proxy/Proxy.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.6.0) (proxy/Proxy.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev This abstract contract provides a fallback function that delegates all calls to another contract using the EVM\n * instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to\n * be specified by overriding the virtual {_implementation} function.\n *\n * Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a\n * different contract through the {_delegate} function.\n *\n * The success and return data of the delegated call will be returned back to the caller of the proxy.\n */\nabstract contract Proxy {\n /**\n * @dev Delegates the current call to `implementation`.\n *\n * This function does not return to its internal call site, it will return directly to the external caller.\n */\n function _delegate(address implementation) internal virtual {\n assembly {\n // Copy msg.data. We take full control of memory in this inline assembly\n // block because it will not return to Solidity code. We overwrite the\n // Solidity scratch pad at memory position 0.\n calldatacopy(0, 0, calldatasize())\n\n // Call the implementation.\n // out and outsize are 0 because we don't know the size yet.\n let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)\n\n // Copy the returned data.\n returndatacopy(0, 0, returndatasize())\n\n switch result\n // delegatecall returns 0 on error.\n case 0 {\n revert(0, returndatasize())\n }\n default {\n return(0, returndatasize())\n }\n }\n }\n\n /**\n * @dev This is a virtual function that should be overridden so it returns the address to which the fallback function\n * and {_fallback} should delegate.\n */\n function _implementation() internal view virtual returns (address);\n\n /**\n * @dev Delegates the current call to the address returned by `_implementation()`.\n *\n * This function does not return to its internal call site, it will return directly to the external caller.\n */\n function _fallback() internal virtual {\n _beforeFallback();\n _delegate(_implementation());\n }\n\n /**\n * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if no other\n * function in the contract matches the call data.\n */\n fallback() external payable virtual {\n _fallback();\n }\n\n /**\n * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if call data\n * is empty.\n */\n receive() external payable virtual {\n _fallback();\n }\n\n /**\n * @dev Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback`\n * call, or as part of the Solidity `fallback` or `receive` functions.\n *\n * If overridden should call `super._beforeFallback()`.\n */\n function _beforeFallback() internal virtual {}\n}\n"
},
"@openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.8.3) (proxy/transparent/ProxyAdmin.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./TransparentUpgradeableProxy.sol\";\nimport \"../../access/Ownable.sol\";\n\n/**\n * @dev This is an auxiliary contract meant to be assigned as the admin of a {TransparentUpgradeableProxy}. For an\n * explanation of why you would want to use this see the documentation for {TransparentUpgradeableProxy}.\n */\ncontract ProxyAdmin is Ownable {\n /**\n * @dev Returns the current implementation of `proxy`.\n *\n * Requirements:\n *\n * - This contract must be the admin of `proxy`.\n */\n function getProxyImplementation(ITransparentUpgradeableProxy proxy) public view virtual returns (address) {\n // We need to manually run the static call since the getter cannot be flagged as view\n // bytes4(keccak256(\"implementation()\")) == 0x5c60da1b\n (bool success, bytes memory returndata) = address(proxy).staticcall(hex\"5c60da1b\");\n require(success);\n return abi.decode(returndata, (address));\n }\n\n /**\n * @dev Returns the current admin of `proxy`.\n *\n * Requirements:\n *\n * - This contract must be the admin of `proxy`.\n */\n function getProxyAdmin(ITransparentUpgradeableProxy proxy) public view virtual returns (address) {\n // We need to manually run the static call since the getter cannot be flagged as view\n // bytes4(keccak256(\"admin()\")) == 0xf851a440\n (bool success, bytes memory returndata) = address(proxy).staticcall(hex\"f851a440\");\n require(success);\n return abi.decode(returndata, (address));\n }\n\n /**\n * @dev Changes the admin of `proxy` to `newAdmin`.\n *\n * Requirements:\n *\n * - This contract must be the current admin of `proxy`.\n */\n function changeProxyAdmin(ITransparentUpgradeableProxy proxy, address newAdmin) public virtual onlyOwner {\n proxy.changeAdmin(newAdmin);\n }\n\n /**\n * @dev Upgrades `proxy` to `implementation`. See {TransparentUpgradeableProxy-upgradeTo}.\n *\n * Requirements:\n *\n * - This contract must be the admin of `proxy`.\n */\n function upgrade(ITransparentUpgradeableProxy proxy, address implementation) public virtual onlyOwner {\n proxy.upgradeTo(implementation);\n }\n\n /**\n * @dev Upgrades `proxy` to `implementation` and calls a function on the new implementation. See\n * {TransparentUpgradeableProxy-upgradeToAndCall}.\n *\n * Requirements:\n *\n * - This contract must be the admin of `proxy`.\n */\n function upgradeAndCall(\n ITransparentUpgradeableProxy proxy,\n address implementation,\n bytes memory data\n ) public payable virtual onlyOwner {\n proxy.upgradeToAndCall{value: msg.value}(implementation, data);\n }\n}\n"
},
"@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (proxy/transparent/TransparentUpgradeableProxy.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../ERC1967/ERC1967Proxy.sol\";\n\n/**\n * @dev Interface for {TransparentUpgradeableProxy}. In order to implement transparency, {TransparentUpgradeableProxy}\n * does not implement this interface directly, and some of its functions are implemented by an internal dispatch\n * mechanism. The compiler is unaware that these functions are implemented by {TransparentUpgradeableProxy} and will not\n * include them in the ABI so this interface must be used to interact with it.\n */\ninterface ITransparentUpgradeableProxy is IERC1967 {\n function admin() external view returns (address);\n\n function implementation() external view returns (address);\n\n function changeAdmin(address) external;\n\n function upgradeTo(address) external;\n\n function upgradeToAndCall(address, bytes memory) external payable;\n}\n\n/**\n * @dev This contract implements a proxy that is upgradeable by an admin.\n *\n * To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector\n * clashing], which can potentially be used in an attack, this contract uses the\n * https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two\n * things that go hand in hand:\n *\n * 1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if\n * that call matches one of the admin functions exposed by the proxy itself.\n * 2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the\n * implementation. If the admin tries to call a function on the implementation it will fail with an error that says\n * \"admin cannot fallback to proxy target\".\n *\n * These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing\n * the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due\n * to sudden errors when trying to call a function from the proxy implementation.\n *\n * Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way,\n * you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy.\n *\n * NOTE: The real interface of this proxy is that defined in `ITransparentUpgradeableProxy`. This contract does not\n * inherit from that interface, and instead the admin functions are implicitly implemented using a custom dispatch\n * mechanism in `_fallback`. Consequently, the compiler will not produce an ABI for this contract. This is necessary to\n * fully implement transparency without decoding reverts caused by selector clashes between the proxy and the\n * implementation.\n *\n * WARNING: It is not recommended to extend this contract to add additional external functions. If you do so, the compiler\n * will not check that there are no selector conflicts, due to the note above. A selector clash between any new function\n * and the functions declared in {ITransparentUpgradeableProxy} will be resolved in favor of the new one. This could\n * render the admin operations inaccessible, which could prevent upgradeability. Transparency may also be compromised.\n */\ncontract TransparentUpgradeableProxy is ERC1967Proxy {\n /**\n * @dev Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and\n * optionally initialized with `_data` as explained in {ERC1967Proxy-constructor}.\n */\n constructor(address _logic, address admin_, bytes memory _data) payable ERC1967Proxy(_logic, _data) {\n _changeAdmin(admin_);\n }\n\n /**\n * @dev Modifier used internally that will delegate the call to the implementation unless the sender is the admin.\n *\n * CAUTION: This modifier is deprecated, as it could cause issues if the modified function has arguments, and the\n * implementation provides a function with the same selector.\n */\n modifier ifAdmin() {\n if (msg.sender == _getAdmin()) {\n _;\n } else {\n _fallback();\n }\n }\n\n /**\n * @dev If caller is the admin process the call internally, otherwise transparently fallback to the proxy behavior\n */\n function _fallback() internal virtual override {\n if (msg.sender == _getAdmin()) {\n bytes memory ret;\n bytes4 selector = msg.sig;\n if (selector == ITransparentUpgradeableProxy.upgradeTo.selector) {\n ret = _dispatchUpgradeTo();\n } else if (selector == ITransparentUpgradeableProxy.upgradeToAndCall.selector) {\n ret = _dispatchUpgradeToAndCall();\n } else if (selector == ITransparentUpgradeableProxy.changeAdmin.selector) {\n ret = _dispatchChangeAdmin();\n } else if (selector == ITransparentUpgradeableProxy.admin.selector) {\n ret = _dispatchAdmin();\n } else if (selector == ITransparentUpgradeableProxy.implementation.selector) {\n ret = _dispatchImplementation();\n } else {\n revert(\"TransparentUpgradeableProxy: admin cannot fallback to proxy target\");\n }\n assembly {\n return(add(ret, 0x20), mload(ret))\n }\n } else {\n super._fallback();\n }\n }\n\n /**\n * @dev Returns the current admin.\n *\n * TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the\n * https://eth.wiki/JSON-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call.\n * `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`\n */\n function _dispatchAdmin() private returns (bytes memory) {\n _requireZeroValue();\n\n address admin = _getAdmin();\n return abi.encode(admin);\n }\n\n /**\n * @dev Returns the current implementation.\n *\n * TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the\n * https://eth.wiki/JSON-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call.\n * `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`\n */\n function _dispatchImplementation() private returns (bytes memory) {\n _requireZeroValue();\n\n address implementation = _implementation();\n return abi.encode(implementation);\n }\n\n /**\n * @dev Changes the admin of the proxy.\n *\n * Emits an {AdminChanged} event.\n */\n function _dispatchChangeAdmin() private returns (bytes memory) {\n _requireZeroValue();\n\n address newAdmin = abi.decode(msg.data[4:], (address));\n _changeAdmin(newAdmin);\n\n return \"\";\n }\n\n /**\n * @dev Upgrade the implementation of the proxy.\n */\n function _dispatchUpgradeTo() private returns (bytes memory) {\n _requireZeroValue();\n\n address newImplementation = abi.decode(msg.data[4:], (address));\n _upgradeToAndCall(newImplementation, bytes(\"\"), false);\n\n return \"\";\n }\n\n /**\n * @dev Upgrade the implementation of the proxy, and then call a function from the new implementation as specified\n * by `data`, which should be an encoded function call. This is useful to initialize new storage variables in the\n * proxied contract.\n */\n function _dispatchUpgradeToAndCall() private returns (bytes memory) {\n (address newImplementation, bytes memory data) = abi.decode(msg.data[4:], (address, bytes));\n _upgradeToAndCall(newImplementation, data, true);\n\n return \"\";\n }\n\n /**\n * @dev Returns the current admin.\n *\n * CAUTION: This function is deprecated. Use {ERC1967Upgrade-_getAdmin} instead.\n */\n function _admin() internal view virtual returns (address) {\n return _getAdmin();\n }\n\n /**\n * @dev To keep this contract fully transparent, all `ifAdmin` functions must be payable. This helper is here to\n * emulate some proxy functions being non-payable while still allowing value to pass through.\n */\n function _requireZeroValue() private {\n require(msg.value == 0);\n }\n}\n"
},
"@openzeppelin/contracts/security/Pausable.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.7.0) (security/Pausable.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../utils/Context.sol\";\n\n/**\n * @dev Contract module which allows children to implement an emergency stop\n * mechanism that can be triggered by an authorized account.\n *\n * This module is used through inheritance. It will make available the\n * modifiers `whenNotPaused` and `whenPaused`, which can be applied to\n * the functions of your contract. Note that they will not be pausable by\n * simply including this module, only once the modifiers are put in place.\n */\nabstract contract Pausable is Context {\n /**\n * @dev Emitted when the pause is triggered by `account`.\n */\n event Paused(address account);\n\n /**\n * @dev Emitted when the pause is lifted by `account`.\n */\n event Unpaused(address account);\n\n bool private _paused;\n\n /**\n * @dev Initializes the contract in unpaused state.\n */\n constructor() {\n _paused = false;\n }\n\n /**\n * @dev Modifier to make a function callable only when the contract is not paused.\n *\n * Requirements:\n *\n * - The contract must not be paused.\n */\n modifier whenNotPaused() {\n _requireNotPaused();\n _;\n }\n\n /**\n * @dev Modifier to make a function callable only when the contract is paused.\n *\n * Requirements:\n *\n * - The contract must be paused.\n */\n modifier whenPaused() {\n _requirePaused();\n _;\n }\n\n /**\n * @dev Returns true if the contract is paused, and false otherwise.\n */\n function paused() public view virtual returns (bool) {\n return _paused;\n }\n\n /**\n * @dev Throws if the contract is paused.\n */\n function _requireNotPaused() internal view virtual {\n require(!paused(), \"Pausable: paused\");\n }\n\n /**\n * @dev Throws if the contract is not paused.\n */\n function _requirePaused() internal view virtual {\n require(paused(), \"Pausable: not paused\");\n }\n\n /**\n * @dev Triggers stopped state.\n *\n * Requirements:\n *\n * - The contract must not be paused.\n */\n function _pause() internal virtual whenNotPaused {\n _paused = true;\n emit Paused(_msgSender());\n }\n\n /**\n * @dev Returns to normal state.\n *\n * Requirements:\n *\n * - The contract must be paused.\n */\n function _unpause() internal virtual whenPaused {\n _paused = false;\n emit Unpaused(_msgSender());\n }\n}\n"
},
"@openzeppelin/contracts/token/ERC20/ERC20.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/ERC20.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./IERC20.sol\";\nimport \"./extensions/IERC20Metadata.sol\";\nimport \"../../utils/Context.sol\";\n\n/**\n * @dev Implementation of the {IERC20} interface.\n *\n * This implementation is agnostic to the way tokens are created. This means\n * that a supply mechanism has to be added in a derived contract using {_mint}.\n * For a generic mechanism see {ERC20PresetMinterPauser}.\n *\n * TIP: For a detailed writeup see our guide\n * https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How\n * to implement supply mechanisms].\n *\n * The default value of {decimals} is 18. To change this, you should override\n * this function so it returns a different value.\n *\n * We have followed general OpenZeppelin Contracts guidelines: functions revert\n * instead returning `false` on failure. This behavior is nonetheless\n * conventional and does not conflict with the expectations of ERC20\n * applications.\n *\n * Additionally, an {Approval} event is emitted on calls to {transferFrom}.\n * This allows applications to reconstruct the allowance for all accounts just\n * by listening to said events. Other implementations of the EIP may not emit\n * these events, as it isn't required by the specification.\n *\n * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}\n * functions have been added to mitigate the well-known issues around setting\n * allowances. See {IERC20-approve}.\n */\ncontract ERC20 is Context, IERC20, IERC20Metadata {\n mapping(address => uint256) private _balances;\n\n mapping(address => mapping(address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n\n string private _name;\n string private _symbol;\n\n /**\n * @dev Sets the values for {name} and {symbol}.\n *\n * All two of these values are immutable: they can only be set once during\n * construction.\n */\n constructor(string memory name_, string memory symbol_) {\n _name = name_;\n _symbol = symbol_;\n }\n\n /**\n * @dev Returns the name of the token.\n */\n function name() public view virtual override returns (string memory) {\n return _name;\n }\n\n /**\n * @dev Returns the symbol of the token, usually a shorter version of the\n * name.\n */\n function symbol() public view virtual override returns (string memory) {\n return _symbol;\n }\n\n /**\n * @dev Returns the number of decimals used to get its user representation.\n * For example, if `decimals` equals `2`, a balance of `505` tokens should\n * be displayed to a user as `5.05` (`505 / 10 ** 2`).\n *\n * Tokens usually opt for a value of 18, imitating the relationship between\n * Ether and Wei. This is the default value returned by this function, unless\n * it's overridden.\n *\n * NOTE: This information is only used for _display_ purposes: it in\n * no way affects any of the arithmetic of the contract, including\n * {IERC20-balanceOf} and {IERC20-transfer}.\n */\n function decimals() public view virtual override returns (uint8) {\n return 18;\n }\n\n /**\n * @dev See {IERC20-totalSupply}.\n */\n function totalSupply() public view virtual override returns (uint256) {\n return _totalSupply;\n }\n\n /**\n * @dev See {IERC20-balanceOf}.\n */\n function balanceOf(address account) public view virtual override returns (uint256) {\n return _balances[account];\n }\n\n /**\n * @dev See {IERC20-transfer}.\n *\n * Requirements:\n *\n * - `to` cannot be the zero address.\n * - the caller must have a balance of at least `amount`.\n */\n function transfer(address to, uint256 amount) public virtual override returns (bool) {\n address owner = _msgSender();\n _transfer(owner, to, amount);\n return true;\n }\n\n /**\n * @dev See {IERC20-allowance}.\n */\n function allowance(address owner, address spender) public view virtual override returns (uint256) {\n return _allowances[owner][spender];\n }\n\n /**\n * @dev See {IERC20-approve}.\n *\n * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on\n * `transferFrom`. This is semantically equivalent to an infinite approval.\n *\n * Requirements:\n *\n * - `spender` cannot be the zero address.\n */\n function approve(address spender, uint256 amount) public virtual override returns (bool) {\n address owner = _msgSender();\n _approve(owner, spender, amount);\n return true;\n }\n\n /**\n * @dev See {IERC20-transferFrom}.\n *\n * Emits an {Approval} event indicating the updated allowance. This is not\n * required by the EIP. See the note at the beginning of {ERC20}.\n *\n * NOTE: Does not update the allowance if the current allowance\n * is the maximum `uint256`.\n *\n * Requirements:\n *\n * - `from` and `to` cannot be the zero address.\n * - `from` must have a balance of at least `amount`.\n * - the caller must have allowance for ``from``'s tokens of at least\n * `amount`.\n */\n function transferFrom(address from, address to, uint256 amount) public virtual override returns (bool) {\n address spender = _msgSender();\n _spendAllowance(from, spender, amount);\n _transfer(from, to, amount);\n return true;\n }\n\n /**\n * @dev Atomically increases the allowance granted to `spender` by the caller.\n *\n * This is an alternative to {approve} that can be used as a mitigation for\n * problems described in {IERC20-approve}.\n *\n * Emits an {Approval} event indicating the updated allowance.\n *\n * Requirements:\n *\n * - `spender` cannot be the zero address.\n */\n function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {\n address owner = _msgSender();\n _approve(owner, spender, allowance(owner, spender) + addedValue);\n return true;\n }\n\n /**\n * @dev Atomically decreases the allowance granted to `spender` by the caller.\n *\n * This is an alternative to {approve} that can be used as a mitigation for\n * problems described in {IERC20-approve}.\n *\n * Emits an {Approval} event indicating the updated allowance.\n *\n * Requirements:\n *\n * - `spender` cannot be the zero address.\n * - `spender` must have allowance for the caller of at least\n * `subtractedValue`.\n */\n function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {\n address owner = _msgSender();\n uint256 currentAllowance = allowance(owner, spender);\n require(currentAllowance >= subtractedValue, \"ERC20: decreased allowance below zero\");\n unchecked {\n _approve(owner, spender, currentAllowance - subtractedValue);\n }\n\n return true;\n }\n\n /**\n * @dev Moves `amount` of tokens from `from` to `to`.\n *\n * This internal function is equivalent to {transfer}, and can be used to\n * e.g. implement automatic token fees, slashing mechanisms, etc.\n *\n * Emits a {Transfer} event.\n *\n * Requirements:\n *\n * - `from` cannot be the zero address.\n * - `to` cannot be the zero address.\n * - `from` must have a balance of at least `amount`.\n */\n function _transfer(address from, address to, uint256 amount) internal virtual {\n require(from != address(0), \"ERC20: transfer from the zero address\");\n require(to != address(0), \"ERC20: transfer to the zero address\");\n\n _beforeTokenTransfer(from, to, amount);\n\n uint256 fromBalance = _balances[from];\n require(fromBalance >= amount, \"ERC20: transfer amount exceeds balance\");\n unchecked {\n _balances[from] = fromBalance - amount;\n // Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by\n // decrementing then incrementing.\n _balances[to] += amount;\n }\n\n emit Transfer(from, to, amount);\n\n _afterTokenTransfer(from, to, amount);\n }\n\n /** @dev Creates `amount` tokens and assigns them to `account`, increasing\n * the total supply.\n *\n * Emits a {Transfer} event with `from` set to the zero address.\n *\n * Requirements:\n *\n * - `account` cannot be the zero address.\n */\n function _mint(address account, uint256 amount) internal virtual {\n require(account != address(0), \"ERC20: mint to the zero address\");\n\n _beforeTokenTransfer(address(0), account, amount);\n\n _totalSupply += amount;\n unchecked {\n // Overflow not possible: balance + amount is at most totalSupply + amount, which is checked above.\n _balances[account] += amount;\n }\n emit Transfer(address(0), account, amount);\n\n _afterTokenTransfer(address(0), account, amount);\n }\n\n /**\n * @dev Destroys `amount` tokens from `account`, reducing the\n * total supply.\n *\n * Emits a {Transfer} event with `to` set to the zero address.\n *\n * Requirements:\n *\n * - `account` cannot be the zero address.\n * - `account` must have at least `amount` tokens.\n */\n function _burn(address account, uint256 amount) internal virtual {\n require(account != address(0), \"ERC20: burn from the zero address\");\n\n _beforeTokenTransfer(account, address(0), amount);\n\n uint256 accountBalance = _balances[account];\n require(accountBalance >= amount, \"ERC20: burn amount exceeds balance\");\n unchecked {\n _balances[account] = accountBalance - amount;\n // Overflow not possible: amount <= accountBalance <= totalSupply.\n _totalSupply -= amount;\n }\n\n emit Transfer(account, address(0), amount);\n\n _afterTokenTransfer(account, address(0), amount);\n }\n\n /**\n * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.\n *\n * This internal function is equivalent to `approve`, and can be used to\n * e.g. set automatic allowances for certain subsystems, etc.\n *\n * Emits an {Approval} event.\n *\n * Requirements:\n *\n * - `owner` cannot be the zero address.\n * - `spender` cannot be the zero address.\n */\n function _approve(address owner, address spender, uint256 amount) internal virtual {\n require(owner != address(0), \"ERC20: approve from the zero address\");\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n emit Approval(owner, spender, amount);\n }\n\n /**\n * @dev Updates `owner` s allowance for `spender` based on spent `amount`.\n *\n * Does not update the allowance amount in case of infinite allowance.\n * Revert if not enough allowance is available.\n *\n * Might emit an {Approval} event.\n */\n function _spendAllowance(address owner, address spender, uint256 amount) internal virtual {\n uint256 currentAllowance = allowance(owner, spender);\n if (currentAllowance != type(uint256).max) {\n require(currentAllowance >= amount, \"ERC20: insufficient allowance\");\n unchecked {\n _approve(owner, spender, currentAllowance - amount);\n }\n }\n }\n\n /**\n * @dev Hook that is called before any transfer of tokens. This includes\n * minting and burning.\n *\n * Calling conditions:\n *\n * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens\n * will be transferred to `to`.\n * - when `from` is zero, `amount` tokens will be minted for `to`.\n * - when `to` is zero, `amount` of ``from``'s tokens will be burned.\n * - `from` and `to` are never both zero.\n *\n * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].\n */\n function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual {}\n\n /**\n * @dev Hook that is called after any transfer of tokens. This includes\n * minting and burning.\n *\n * Calling conditions:\n *\n * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens\n * has been transferred to `to`.\n * - when `from` is zero, `amount` tokens have been minted for `to`.\n * - when `to` is zero, `amount` of ``from``'s tokens have been burned.\n * - `from` and `to` are never both zero.\n *\n * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].\n */\n function _afterTokenTransfer(address from, address to, uint256 amount) internal virtual {}\n}\n"
},
"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.5.0) (token/ERC20/extensions/ERC20Burnable.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../ERC20.sol\";\nimport \"../../../utils/Context.sol\";\n\n/**\n * @dev Extension of {ERC20} that allows token holders to destroy both their own\n * tokens and those that they have an allowance for, in a way that can be\n * recognized off-chain (via event analysis).\n */\nabstract contract ERC20Burnable is Context, ERC20 {\n /**\n * @dev Destroys `amount` tokens from the caller.\n *\n * See {ERC20-_burn}.\n */\n function burn(uint256 amount) public virtual {\n _burn(_msgSender(), amount);\n }\n\n /**\n * @dev Destroys `amount` tokens from `account`, deducting from the caller's\n * allowance.\n *\n * See {ERC20-_burn} and {ERC20-allowance}.\n *\n * Requirements:\n *\n * - the caller must have allowance for ``accounts``'s tokens of at least\n * `amount`.\n */\n function burnFrom(address account, uint256 amount) public virtual {\n _spendAllowance(account, _msgSender(), amount);\n _burn(account, amount);\n }\n}\n"
},
"@openzeppelin/contracts/token/ERC20/extensions/ERC20Pausable.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/extensions/ERC20Pausable.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../ERC20.sol\";\nimport \"../../../security/Pausable.sol\";\n\n/**\n * @dev ERC20 token with pausable token transfers, minting and burning.\n *\n * Useful for scenarios such as preventing trades until the end of an evaluation\n * period, or having an emergency switch for freezing all token transfers in the\n * event of a large bug.\n *\n * IMPORTANT: This contract does not include public pause and unpause functions. In\n * addition to inheriting this contract, you must define both functions, invoking the\n * {Pausable-_pause} and {Pausable-_unpause} internal functions, with appropriate\n * access control, e.g. using {AccessControl} or {Ownable}. Not doing so will\n * make the contract unpausable.\n */\nabstract contract ERC20Pausable is ERC20, Pausable {\n /**\n * @dev See {ERC20-_beforeTokenTransfer}.\n *\n * Requirements:\n *\n * - the contract must not be paused.\n */\n function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {\n super._beforeTokenTransfer(from, to, amount);\n\n require(!paused(), \"ERC20Pausable: token transfer while paused\");\n }\n}\n"
},
"@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (token/ERC20/extensions/IERC20Metadata.sol)\n\npragma solidity ^0.8.0;\n\nimport \"../IERC20.sol\";\n\n/**\n * @dev Interface for the optional metadata functions from the ERC20 standard.\n *\n * _Available since v4.1._\n */\ninterface IERC20Metadata is IERC20 {\n /**\n * @dev Returns the name of the token.\n */\n function name() external view returns (string memory);\n\n /**\n * @dev Returns the symbol of the token.\n */\n function symbol() external view returns (string memory);\n\n /**\n * @dev Returns the decimals places of the token.\n */\n function decimals() external view returns (uint8);\n}\n"
},
"@openzeppelin/contracts/token/ERC20/IERC20.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/IERC20.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Interface of the ERC20 standard as defined in the EIP.\n */\ninterface IERC20 {\n /**\n * @dev Emitted when `value` tokens are moved from one account (`from`) to\n * another (`to`).\n *\n * Note that `value` may be zero.\n */\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n /**\n * @dev Emitted when the allowance of a `spender` for an `owner` is set by\n * a call to {approve}. `value` is the new allowance.\n */\n event Approval(address indexed owner, address indexed spender, uint256 value);\n\n /**\n * @dev Returns the amount of tokens in existence.\n */\n function totalSupply() external view returns (uint256);\n\n /**\n * @dev Returns the amount of tokens owned by `account`.\n */\n function balanceOf(address account) external view returns (uint256);\n\n /**\n * @dev Moves `amount` tokens from the caller's account to `to`.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transfer(address to, uint256 amount) external returns (bool);\n\n /**\n * @dev Returns the remaining number of tokens that `spender` will be\n * allowed to spend on behalf of `owner` through {transferFrom}. This is\n * zero by default.\n *\n * This value changes when {approve} or {transferFrom} are called.\n */\n function allowance(address owner, address spender) external view returns (uint256);\n\n /**\n * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * IMPORTANT: Beware that changing an allowance with this method brings the risk\n * that someone may use both the old and the new allowance by unfortunate\n * transaction ordering. One possible solution to mitigate this race\n * condition is to first reduce the spender's allowance to 0 and set the\n * desired value afterwards:\n * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729\n *\n * Emits an {Approval} event.\n */\n function approve(address spender, uint256 amount) external returns (bool);\n\n /**\n * @dev Moves `amount` tokens from `from` to `to` using the\n * allowance mechanism. `amount` is then deducted from the caller's\n * allowance.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transferFrom(address from, address to, uint256 amount) external returns (bool);\n}\n"
},
"@openzeppelin/contracts/utils/Address.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (utils/Address.sol)\n\npragma solidity ^0.8.1;\n\n/**\n * @dev Collection of functions related to the address type\n */\nlibrary Address {\n /**\n * @dev Returns true if `account` is a contract.\n *\n * [IMPORTANT]\n * ====\n * It is unsafe to assume that an address for which this function returns\n * false is an externally-owned account (EOA) and not a contract.\n *\n * Among others, `isContract` will return false for the following\n * types of addresses:\n *\n * - an externally-owned account\n * - a contract in construction\n * - an address where a contract will be created\n * - an address where a contract lived, but was destroyed\n *\n * Furthermore, `isContract` will also return true if the target contract within\n * the same transaction is already scheduled for destruction by `SELFDESTRUCT`,\n * which only has an effect at the end of a transaction.\n * ====\n *\n * [IMPORTANT]\n * ====\n * You shouldn't rely on `isContract` to protect against flash loan attacks!\n *\n * Preventing calls from contracts is highly discouraged. It breaks composability, breaks support for smart wallets\n * like Gnosis Safe, and does not provide security since it can be circumvented by calling from a contract\n * constructor.\n * ====\n */\n function isContract(address account) internal view returns (bool) {\n // This method relies on extcodesize/address.code.length, which returns 0\n // for contracts in construction, since the code is only stored at the end\n // of the constructor execution.\n\n return account.code.length > 0;\n }\n\n /**\n * @dev Replacement for Solidity's `transfer`: sends `amount` wei to\n * `recipient`, forwarding all available gas and reverting on errors.\n *\n * https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost\n * of certain opcodes, possibly making contracts go over the 2300 gas limit\n * imposed by `transfer`, making them unable to receive funds via\n * `transfer`. {sendValue} removes this limitation.\n *\n * https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/[Learn more].\n *\n * IMPORTANT: because control is transferred to `recipient`, care must be\n * taken to not create reentrancy vulnerabilities. Consider using\n * {ReentrancyGuard} or the\n * https://solidity.readthedocs.io/en/v0.8.0/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern].\n */\n function sendValue(address payable recipient, uint256 amount) internal {\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n (bool success, ) = recipient.call{value: amount}(\"\");\n require(success, \"Address: unable to send value, recipient may have reverted\");\n }\n\n /**\n * @dev Performs a Solidity function call using a low level `call`. A\n * plain `call` is an unsafe replacement for a function call: use this\n * function instead.\n *\n * If `target` reverts with a revert reason, it is bubbled up by this\n * function (like regular Solidity function calls).\n *\n * Returns the raw returned data. To convert to the expected return value,\n * use https://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=abi.decode#abi-encoding-and-decoding-functions[`abi.decode`].\n *\n * Requirements:\n *\n * - `target` must be a contract.\n * - calling `target` with `data` must not revert.\n *\n * _Available since v3.1._\n */\n function functionCall(address target, bytes memory data) internal returns (bytes memory) {\n return functionCallWithValue(target, data, 0, \"Address: low-level call failed\");\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`], but with\n * `errorMessage` as a fallback revert reason when `target` reverts.\n *\n * _Available since v3.1._\n */\n function functionCall(\n address target,\n bytes memory data,\n string memory errorMessage\n ) internal returns (bytes memory) {\n return functionCallWithValue(target, data, 0, errorMessage);\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n * but also transferring `value` wei to `target`.\n *\n * Requirements:\n *\n * - the calling contract must have an ETH balance of at least `value`.\n * - the called Solidity function must be `payable`.\n *\n * _Available since v3.1._\n */\n function functionCallWithValue(address target, bytes memory data, uint256 value) internal returns (bytes memory) {\n return functionCallWithValue(target, data, value, \"Address: low-level call with value failed\");\n }\n\n /**\n * @dev Same as {xref-Address-functionCallWithValue-address-bytes-uint256-}[`functionCallWithValue`], but\n * with `errorMessage` as a fallback revert reason when `target` reverts.\n *\n * _Available since v3.1._\n */\n function functionCallWithValue(\n address target,\n bytes memory data,\n uint256 value,\n string memory errorMessage\n ) internal returns (bytes memory) {\n require(address(this).balance >= value, \"Address: insufficient balance for call\");\n (bool success, bytes memory returndata) = target.call{value: value}(data);\n return verifyCallResultFromTarget(target, success, returndata, errorMessage);\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n * but performing a static call.\n *\n * _Available since v3.3._\n */\n function functionStaticCall(address target, bytes memory data) internal view returns (bytes memory) {\n return functionStaticCall(target, data, \"Address: low-level static call failed\");\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`],\n * but performing a static call.\n *\n * _Available since v3.3._\n */\n function functionStaticCall(\n address target,\n bytes memory data,\n string memory errorMessage\n ) internal view returns (bytes memory) {\n (bool success, bytes memory returndata) = target.staticcall(data);\n return verifyCallResultFromTarget(target, success, returndata, errorMessage);\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-}[`functionCall`],\n * but performing a delegate call.\n *\n * _Available since v3.4._\n */\n function functionDelegateCall(address target, bytes memory data) internal returns (bytes memory) {\n return functionDelegateCall(target, data, \"Address: low-level delegate call failed\");\n }\n\n /**\n * @dev Same as {xref-Address-functionCall-address-bytes-string-}[`functionCall`],\n * but performing a delegate call.\n *\n * _Available since v3.4._\n */\n function functionDelegateCall(\n address target,\n bytes memory data,\n string memory errorMessage\n ) internal returns (bytes memory) {\n (bool success, bytes memory returndata) = target.delegatecall(data);\n return verifyCallResultFromTarget(target, success, returndata, errorMessage);\n }\n\n /**\n * @dev Tool to verify that a low level call to smart-contract was successful, and revert (either by bubbling\n * the revert reason or using the provided one) in case of unsuccessful call or if target was not a contract.\n *\n * _Available since v4.8._\n */\n function verifyCallResultFromTarget(\n address target,\n bool success,\n bytes memory returndata,\n string memory errorMessage\n ) internal view returns (bytes memory) {\n if (success) {\n if (returndata.length == 0) {\n // only check isContract if the call was successful and the return data is empty\n // otherwise we already know that it was a contract\n require(isContract(target), \"Address: call to non-contract\");\n }\n return returndata;\n } else {\n _revert(returndata, errorMessage);\n }\n }\n\n /**\n * @dev Tool to verify that a low level call was successful, and revert if it wasn't, either by bubbling the\n * revert reason or using the provided one.\n *\n * _Available since v4.3._\n */\n function verifyCallResult(\n bool success,\n bytes memory returndata,\n string memory errorMessage\n ) internal pure returns (bytes memory) {\n if (success) {\n return returndata;\n } else {\n _revert(returndata, errorMessage);\n }\n }\n\n function _revert(bytes memory returndata, string memory errorMessage) private pure {\n // Look for revert reason and bubble it up if present\n if (returndata.length > 0) {\n // The easiest way to bubble the revert reason is using memory via assembly\n /// @solidity memory-safe-assembly\n assembly {\n let returndata_size := mload(returndata)\n revert(add(32, returndata), returndata_size)\n }\n } else {\n revert(errorMessage);\n }\n }\n}\n"
},
"@openzeppelin/contracts/utils/Context.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.4) (utils/Context.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Provides information about the current execution context, including the\n * sender of the transaction and its data. While these are generally available\n * via msg.sender and msg.data, they should not be accessed in such a direct\n * manner, since when dealing with meta-transactions the account sending and\n * paying for execution may not be the actual sender (as far as an application\n * is concerned).\n *\n * This contract is only required for intermediate, library-like contracts.\n */\nabstract contract Context {\n function _msgSender() internal view virtual returns (address) {\n return msg.sender;\n }\n\n function _msgData() internal view virtual returns (bytes calldata) {\n return msg.data;\n }\n\n function _contextSuffixLength() internal view virtual returns (uint256) {\n return 0;\n }\n}\n"
},
"@openzeppelin/contracts/utils/introspection/ERC165.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (utils/introspection/ERC165.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./IERC165.sol\";\n\n/**\n * @dev Implementation of the {IERC165} interface.\n *\n * Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check\n * for the additional interface id that will be supported. For example:\n *\n * ```solidity\n * function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {\n * return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId);\n * }\n * ```\n *\n * Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.\n */\nabstract contract ERC165 is IERC165 {\n /**\n * @dev See {IERC165-supportsInterface}.\n */\n function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {\n return interfaceId == type(IERC165).interfaceId;\n }\n}\n"
},
"@openzeppelin/contracts/utils/introspection/IERC165.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts v4.4.1 (utils/introspection/IERC165.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Interface of the ERC165 standard, as defined in the\n * https://eips.ethereum.org/EIPS/eip-165[EIP].\n *\n * Implementers can declare support of contract interfaces, which can then be\n * queried by others ({ERC165Checker}).\n *\n * For an implementation, see {ERC165}.\n */\ninterface IERC165 {\n /**\n * @dev Returns true if this contract implements the interface defined by\n * `interfaceId`. See the corresponding\n * https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section]\n * to learn more about how these ids are created.\n *\n * This function call must use less than 30 000 gas.\n */\n function supportsInterface(bytes4 interfaceId) external view returns (bool);\n}\n"
},
"@openzeppelin/contracts/utils/math/Math.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (utils/math/Math.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Standard math utilities missing in the Solidity language.\n */\nlibrary Math {\n enum Rounding {\n Down, // Toward negative infinity\n Up, // Toward infinity\n Zero // Toward zero\n }\n\n /**\n * @dev Returns the largest of two numbers.\n */\n function max(uint256 a, uint256 b) internal pure returns (uint256) {\n return a > b ? a : b;\n }\n\n /**\n * @dev Returns the smallest of two numbers.\n */\n function min(uint256 a, uint256 b) internal pure returns (uint256) {\n return a < b ? a : b;\n }\n\n /**\n * @dev Returns the average of two numbers. The result is rounded towards\n * zero.\n */\n function average(uint256 a, uint256 b) internal pure returns (uint256) {\n // (a + b) / 2 can overflow.\n return (a & b) + (a ^ b) / 2;\n }\n\n /**\n * @dev Returns the ceiling of the division of two numbers.\n *\n * This differs from standard division with `/` in that it rounds up instead\n * of rounding down.\n */\n function ceilDiv(uint256 a, uint256 b) internal pure returns (uint256) {\n // (a + b - 1) / b can overflow on addition, so we distribute.\n return a == 0 ? 0 : (a - 1) / b + 1;\n }\n\n /**\n * @notice Calculates floor(x * y / denominator) with full precision. Throws if result overflows a uint256 or denominator == 0\n * @dev Original credit to Remco Bloemen under MIT license (https://xn--2-umb.com/21/muldiv)\n * with further edits by Uniswap Labs also under MIT license.\n */\n function mulDiv(uint256 x, uint256 y, uint256 denominator) internal pure returns (uint256 result) {\n unchecked {\n // 512-bit multiply [prod1 prod0] = x * y. Compute the product mod 2^256 and mod 2^256 - 1, then use\n // use the Chinese Remainder Theorem to reconstruct the 512 bit result. The result is stored in two 256\n // variables such that product = prod1 * 2^256 + prod0.\n uint256 prod0; // Least significant 256 bits of the product\n uint256 prod1; // Most significant 256 bits of the product\n assembly {\n let mm := mulmod(x, y, not(0))\n prod0 := mul(x, y)\n prod1 := sub(sub(mm, prod0), lt(mm, prod0))\n }\n\n // Handle non-overflow cases, 256 by 256 division.\n if (prod1 == 0) {\n // Solidity will revert if denominator == 0, unlike the div opcode on its own.\n // The surrounding unchecked block does not change this fact.\n // See https://docs.soliditylang.org/en/latest/control-structures.html#checked-or-unchecked-arithmetic.\n return prod0 / denominator;\n }\n\n // Make sure the result is less than 2^256. Also prevents denominator == 0.\n require(denominator > prod1, \"Math: mulDiv overflow\");\n\n ///////////////////////////////////////////////\n // 512 by 256 division.\n ///////////////////////////////////////////////\n\n // Make division exact by subtracting the remainder from [prod1 prod0].\n uint256 remainder;\n assembly {\n // Compute remainder using mulmod.\n remainder := mulmod(x, y, denominator)\n\n // Subtract 256 bit number from 512 bit number.\n prod1 := sub(prod1, gt(remainder, prod0))\n prod0 := sub(prod0, remainder)\n }\n\n // Factor powers of two out of denominator and compute largest power of two divisor of denominator. Always >= 1.\n // See https://cs.stackexchange.com/q/138556/92363.\n\n // Does not overflow because the denominator cannot be zero at this stage in the function.\n uint256 twos = denominator & (~denominator + 1);\n assembly {\n // Divide denominator by twos.\n denominator := div(denominator, twos)\n\n // Divide [prod1 prod0] by twos.\n prod0 := div(prod0, twos)\n\n // Flip twos such that it is 2^256 / twos. If twos is zero, then it becomes one.\n twos := add(div(sub(0, twos), twos), 1)\n }\n\n // Shift in bits from prod1 into prod0.\n prod0 |= prod1 * twos;\n\n // Invert denominator mod 2^256. Now that denominator is an odd number, it has an inverse modulo 2^256 such\n // that denominator * inv = 1 mod 2^256. Compute the inverse by starting with a seed that is correct for\n // four bits. That is, denominator * inv = 1 mod 2^4.\n uint256 inverse = (3 * denominator) ^ 2;\n\n // Use the Newton-Raphson iteration to improve the precision. Thanks to Hensel's lifting lemma, this also works\n // in modular arithmetic, doubling the correct bits in each step.\n inverse *= 2 - denominator * inverse; // inverse mod 2^8\n inverse *= 2 - denominator * inverse; // inverse mod 2^16\n inverse *= 2 - denominator * inverse; // inverse mod 2^32\n inverse *= 2 - denominator * inverse; // inverse mod 2^64\n inverse *= 2 - denominator * inverse; // inverse mod 2^128\n inverse *= 2 - denominator * inverse; // inverse mod 2^256\n\n // Because the division is now exact we can divide by multiplying with the modular inverse of denominator.\n // This will give us the correct result modulo 2^256. Since the preconditions guarantee that the outcome is\n // less than 2^256, this is the final result. We don't need to compute the high bits of the result and prod1\n // is no longer required.\n result = prod0 * inverse;\n return result;\n }\n }\n\n /**\n * @notice Calculates x * y / denominator with full precision, following the selected rounding direction.\n */\n function mulDiv(uint256 x, uint256 y, uint256 denominator, Rounding rounding) internal pure returns (uint256) {\n uint256 result = mulDiv(x, y, denominator);\n if (rounding == Rounding.Up && mulmod(x, y, denominator) > 0) {\n result += 1;\n }\n return result;\n }\n\n /**\n * @dev Returns the square root of a number. If the number is not a perfect square, the value is rounded down.\n *\n * Inspired by Henry S. Warren, Jr.'s \"Hacker's Delight\" (Chapter 11).\n */\n function sqrt(uint256 a) internal pure returns (uint256) {\n if (a == 0) {\n return 0;\n }\n\n // For our first guess, we get the biggest power of 2 which is smaller than the square root of the target.\n //\n // We know that the \"msb\" (most significant bit) of our target number `a` is a power of 2 such that we have\n // `msb(a) <= a < 2*msb(a)`. This value can be written `msb(a)=2**k` with `k=log2(a)`.\n //\n // This can be rewritten `2**log2(a) <= a < 2**(log2(a) + 1)`\n // → `sqrt(2**k) <= sqrt(a) < sqrt(2**(k+1))`\n // → `2**(k/2) <= sqrt(a) < 2**((k+1)/2) <= 2**(k/2 + 1)`\n //\n // Consequently, `2**(log2(a) / 2)` is a good first approximation of `sqrt(a)` with at least 1 correct bit.\n uint256 result = 1 << (log2(a) >> 1);\n\n // At this point `result` is an estimation with one bit of precision. We know the true value is a uint128,\n // since it is the square root of a uint256. Newton's method converges quadratically (precision doubles at\n // every iteration). We thus need at most 7 iteration to turn our partial result with one bit of precision\n // into the expected uint128 result.\n unchecked {\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n result = (result + a / result) >> 1;\n return min(result, a / result);\n }\n }\n\n /**\n * @notice Calculates sqrt(a), following the selected rounding direction.\n */\n function sqrt(uint256 a, Rounding rounding) internal pure returns (uint256) {\n unchecked {\n uint256 result = sqrt(a);\n return result + (rounding == Rounding.Up && result * result < a ? 1 : 0);\n }\n }\n\n /**\n * @dev Return the log in base 2, rounded down, of a positive value.\n * Returns 0 if given 0.\n */\n function log2(uint256 value) internal pure returns (uint256) {\n uint256 result = 0;\n unchecked {\n if (value >> 128 > 0) {\n value >>= 128;\n result += 128;\n }\n if (value >> 64 > 0) {\n value >>= 64;\n result += 64;\n }\n if (value >> 32 > 0) {\n value >>= 32;\n result += 32;\n }\n if (value >> 16 > 0) {\n value >>= 16;\n result += 16;\n }\n if (value >> 8 > 0) {\n value >>= 8;\n result += 8;\n }\n if (value >> 4 > 0) {\n value >>= 4;\n result += 4;\n }\n if (value >> 2 > 0) {\n value >>= 2;\n result += 2;\n }\n if (value >> 1 > 0) {\n result += 1;\n }\n }\n return result;\n }\n\n /**\n * @dev Return the log in base 2, following the selected rounding direction, of a positive value.\n * Returns 0 if given 0.\n */\n function log2(uint256 value, Rounding rounding) internal pure returns (uint256) {\n unchecked {\n uint256 result = log2(value);\n return result + (rounding == Rounding.Up && 1 << result < value ? 1 : 0);\n }\n }\n\n /**\n * @dev Return the log in base 10, rounded down, of a positive value.\n * Returns 0 if given 0.\n */\n function log10(uint256 value) internal pure returns (uint256) {\n uint256 result = 0;\n unchecked {\n if (value >= 10 ** 64) {\n value /= 10 ** 64;\n result += 64;\n }\n if (value >= 10 ** 32) {\n value /= 10 ** 32;\n result += 32;\n }\n if (value >= 10 ** 16) {\n value /= 10 ** 16;\n result += 16;\n }\n if (value >= 10 ** 8) {\n value /= 10 ** 8;\n result += 8;\n }\n if (value >= 10 ** 4) {\n value /= 10 ** 4;\n result += 4;\n }\n if (value >= 10 ** 2) {\n value /= 10 ** 2;\n result += 2;\n }\n if (value >= 10 ** 1) {\n result += 1;\n }\n }\n return result;\n }\n\n /**\n * @dev Return the log in base 10, following the selected rounding direction, of a positive value.\n * Returns 0 if given 0.\n */\n function log10(uint256 value, Rounding rounding) internal pure returns (uint256) {\n unchecked {\n uint256 result = log10(value);\n return result + (rounding == Rounding.Up && 10 ** result < value ? 1 : 0);\n }\n }\n\n /**\n * @dev Return the log in base 256, rounded down, of a positive value.\n * Returns 0 if given 0.\n *\n * Adding one to the result gives the number of pairs of hex symbols needed to represent `value` as a hex string.\n */\n function log256(uint256 value) internal pure returns (uint256) {\n uint256 result = 0;\n unchecked {\n if (value >> 128 > 0) {\n value >>= 128;\n result += 16;\n }\n if (value >> 64 > 0) {\n value >>= 64;\n result += 8;\n }\n if (value >> 32 > 0) {\n value >>= 32;\n result += 4;\n }\n if (value >> 16 > 0) {\n value >>= 16;\n result += 2;\n }\n if (value >> 8 > 0) {\n result += 1;\n }\n }\n return result;\n }\n\n /**\n * @dev Return the log in base 256, following the selected rounding direction, of a positive value.\n * Returns 0 if given 0.\n */\n function log256(uint256 value, Rounding rounding) internal pure returns (uint256) {\n unchecked {\n uint256 result = log256(value);\n return result + (rounding == Rounding.Up && 1 << (result << 3) < value ? 1 : 0);\n }\n }\n}\n"
},
"@openzeppelin/contracts/utils/math/SignedMath.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.8.0) (utils/math/SignedMath.sol)\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Standard signed math utilities missing in the Solidity language.\n */\nlibrary SignedMath {\n /**\n * @dev Returns the largest of two signed numbers.\n */\n function max(int256 a, int256 b) internal pure returns (int256) {\n return a > b ? a : b;\n }\n\n /**\n * @dev Returns the smallest of two signed numbers.\n */\n function min(int256 a, int256 b) internal pure returns (int256) {\n return a < b ? a : b;\n }\n\n /**\n * @dev Returns the average of two signed numbers without overflow.\n * The result is rounded towards zero.\n */\n function average(int256 a, int256 b) internal pure returns (int256) {\n // Formula from the book \"Hacker's Delight\"\n int256 x = (a & b) + ((a ^ b) >> 1);\n return x + (int256(uint256(x) >> 255) & (a ^ b));\n }\n\n /**\n * @dev Returns the absolute unsigned value of a signed value.\n */\n function abs(int256 n) internal pure returns (uint256) {\n unchecked {\n // must be unchecked in order to support `n = type(int256).min`\n return uint256(n >= 0 ? n : -n);\n }\n }\n}\n"
},
"@openzeppelin/contracts/utils/StorageSlot.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (utils/StorageSlot.sol)\n// This file was procedurally generated from scripts/generate/templates/StorageSlot.js.\n\npragma solidity ^0.8.0;\n\n/**\n * @dev Library for reading and writing primitive types to specific storage slots.\n *\n * Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts.\n * This library helps with reading and writing to such slots without the need for inline assembly.\n *\n * The functions in this library return Slot structs that contain a `value` member that can be used to read or write.\n *\n * Example usage to set ERC1967 implementation slot:\n * ```solidity\n * contract ERC1967 {\n * bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;\n *\n * function _getImplementation() internal view returns (address) {\n * return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;\n * }\n *\n * function _setImplementation(address newImplementation) internal {\n * require(Address.isContract(newImplementation), \"ERC1967: new implementation is not a contract\");\n * StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;\n * }\n * }\n * ```\n *\n * _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._\n * _Available since v4.9 for `string`, `bytes`._\n */\nlibrary StorageSlot {\n struct AddressSlot {\n address value;\n }\n\n struct BooleanSlot {\n bool value;\n }\n\n struct Bytes32Slot {\n bytes32 value;\n }\n\n struct Uint256Slot {\n uint256 value;\n }\n\n struct StringSlot {\n string value;\n }\n\n struct BytesSlot {\n bytes value;\n }\n\n /**\n * @dev Returns an `AddressSlot` with member `value` located at `slot`.\n */\n function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `BooleanSlot` with member `value` located at `slot`.\n */\n function getBooleanSlot(bytes32 slot) internal pure returns (BooleanSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `Bytes32Slot` with member `value` located at `slot`.\n */\n function getBytes32Slot(bytes32 slot) internal pure returns (Bytes32Slot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `Uint256Slot` with member `value` located at `slot`.\n */\n function getUint256Slot(bytes32 slot) internal pure returns (Uint256Slot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `StringSlot` with member `value` located at `slot`.\n */\n function getStringSlot(bytes32 slot) internal pure returns (StringSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `StringSlot` representation of the string storage pointer `store`.\n */\n function getStringSlot(string storage store) internal pure returns (StringSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := store.slot\n }\n }\n\n /**\n * @dev Returns an `BytesSlot` with member `value` located at `slot`.\n */\n function getBytesSlot(bytes32 slot) internal pure returns (BytesSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := slot\n }\n }\n\n /**\n * @dev Returns an `BytesSlot` representation of the bytes storage pointer `store`.\n */\n function getBytesSlot(bytes storage store) internal pure returns (BytesSlot storage r) {\n /// @solidity memory-safe-assembly\n assembly {\n r.slot := store.slot\n }\n }\n}\n"
},
"@openzeppelin/contracts/utils/Strings.sol": {
"content": "// SPDX-License-Identifier: MIT\n// OpenZeppelin Contracts (last updated v4.9.0) (utils/Strings.sol)\n\npragma solidity ^0.8.0;\n\nimport \"./math/Math.sol\";\nimport \"./math/SignedMath.sol\";\n\n/**\n * @dev String operations.\n */\nlibrary Strings {\n bytes16 private constant _SYMBOLS = \"0123456789abcdef\";\n uint8 private constant _ADDRESS_LENGTH = 20;\n\n /**\n * @dev Converts a `uint256` to its ASCII `string` decimal representation.\n */\n function toString(uint256 value) internal pure returns (string memory) {\n unchecked {\n uint256 length = Math.log10(value) + 1;\n string memory buffer = new string(length);\n uint256 ptr;\n /// @solidity memory-safe-assembly\n assembly {\n ptr := add(buffer, add(32, length))\n }\n while (true) {\n ptr--;\n /// @solidity memory-safe-assembly\n assembly {\n mstore8(ptr, byte(mod(value, 10), _SYMBOLS))\n }\n value /= 10;\n if (value == 0) break;\n }\n return buffer;\n }\n }\n\n /**\n * @dev Converts a `int256` to its ASCII `string` decimal representation.\n */\n function toString(int256 value) internal pure returns (string memory) {\n return string(abi.encodePacked(value < 0 ? \"-\" : \"\", toString(SignedMath.abs(value))));\n }\n\n /**\n * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation.\n */\n function toHexString(uint256 value) internal pure returns (string memory) {\n unchecked {\n return toHexString(value, Math.log256(value) + 1);\n }\n }\n\n /**\n * @dev Converts a `uint256` to its ASCII `string` hexadecimal representation with fixed length.\n */\n function toHexString(uint256 value, uint256 length) internal pure returns (string memory) {\n bytes memory buffer = new bytes(2 * length + 2);\n buffer[0] = \"0\";\n buffer[1] = \"x\";\n for (uint256 i = 2 * length + 1; i > 1; --i) {\n buffer[i] = _SYMBOLS[value & 0xf];\n value >>= 4;\n }\n require(value == 0, \"Strings: hex length insufficient\");\n return string(buffer);\n }\n\n /**\n * @dev Converts an `address` with fixed length of 20 bytes to its not checksummed ASCII `string` hexadecimal representation.\n */\n function toHexString(address addr) internal pure returns (string memory) {\n return toHexString(uint256(uint160(addr)), _ADDRESS_LENGTH);\n }\n\n /**\n * @dev Returns true if the two strings are equal.\n */\n function equal(string memory a, string memory b) internal pure returns (bool) {\n return keccak256(bytes(a)) == keccak256(bytes(b));\n }\n}\n"
},
"contracts/MyERC20Token.sol": {
"content": "// SPDX-License-Identifier: MIT\n// This uses v4.9.5 of the OpenZeppelin Contracts\n// https://github.com/OpenZeppelin/openzeppelin-contracts/tree/v4.9.5\n\npragma solidity ^0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Pausable.sol\";\nimport \"@openzeppelin/contracts/access/AccessControl.sol\";\n\n/**\n * @title MyERC20Token\n * @dev This is a basic ERC20 token using OpenZeppelin's templates.\n * You can edit the default values as needed.\n */\ncontract MyERC20Token is ERC20Burnable, ERC20Pausable, AccessControl {\n bytes32 public constant CONTROLLER_ROLE = keccak256(\"CONTROLLER_ROLE\");\n\n /**\n * @dev Constructor to initialize the token with default values.\n * You can edit these values as needed.\n */\n constructor() ERC20(\"My token name5\", \"MyTokenSymbol5\") {\n // Default initial supply of 1 million tokens (with 18 decimals)\n uint256 initialSupply = 1_000_000 * (10 ** 18);\n\n // The initial supply is minted to the deployer's address\n _mint(msg.sender, initialSupply);\n\n // The deployer is granted the default admin role and the controller role\n _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);\n _grantRole(CONTROLLER_ROLE, msg.sender);\n }\n\n // Additional functions or overrides can be added here if needed.\n function pause() public onlyRole(CONTROLLER_ROLE) {\n _pause();\n }\n\n function unpause() public onlyRole(CONTROLLER_ROLE) {\n _unpause();\n }\n\n function mint(address to, uint256 amount) public onlyRole(CONTROLLER_ROLE) {\n _mint(to, amount);\n }\n\n /**\n * @dev Internal functions\n */\n\n function _beforeTokenTransfer(\n address from,\n address to,\n uint256 amount\n ) internal virtual override(ERC20, ERC20Pausable) {\n super._beforeTokenTransfer(from, to, amount);\n }\n}\n"
}
},
"settings": {
"evmVersion": "paris",
"optimizer": {
"enabled": true,
"mode": "3"
},
"outputSelection": {
"*": {
"*": [
"abi",
"evm.methodIdentifiers",
"metadata",
"storageLayout"
],
"": [
"ast"
]
}
},
"libraries": {}
}
}
```
````
### FAQ
How long does contract verification takes ?
Usually, it takes up to 10 minutes to verify a contract after submission.
Where can I check the contract verification result ?
After submitting the contract, a corresponding Contract Verification ID will be provided. Search the result by the Contract Verification ID in [Status Checker Page](https://explorer.zkevm.cronos.org/verifyContract/status).\
\
If you are using the [Developer Portal](https://developers.zkevm.cronos.org/) , the contract verification status is available in the [Contract Page](https://developers.zkevm.cronos.org/user/contracts).\
\
Also the code will be available on the [Address Page](https://explorer.zkevm.cronos.org/address/0x000000000000000000000000000000000000800a#code) if it has been verified. If no contract code appears on the [Address Page](https://explorer.zkevm.cronos.org/address/0x000000000000000000000000000000000000800a#code) after 10 minutes, the contract verification may be failed.
Is there any demonstrations on verifying a contract ?
Yes, here is a sample smart contract Github project: [cronos-zkevm-hardhat-boilerplate](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate), which demonstrates the basic use of Cronos zkEVM to develop smart contract and implement on-chain transactions.
How can I verify a proxy contract ?
Same as a normal contract, you need to submit the proxy contract to our service using [Cronos zkEVM Explorer](https://explorer.zkevm.cronos.org/verifyContract) or [hardhat-zksync](https://explorer-api-doc.zkevm.cronos.org/mainnet/index.html#post-https-//explorer-api.zkevm.cronos.org/api/v1/contract/verify/hardhathttps://explorer-api-doc.zkevm.cronos.org/mainnet/index.html#post-https-//explorer-api.zkevm.cronos.org/api/v1/contract/verify/hardhat).
If I have a proxy contract, how do I update the explorer if the address of the implementation contract has been updated?
The contract verification service will periodically check and update the implementation contract address. It may take up to 1 hour to reflect the new address.
### Troubleshooting
If you are still having issues with contract verification in the Cronos zkEVM explorer, here are a few pointers.
* Make sure that you have registered for an API key and have added the key to the `.env` variables.
* Deploy your smart contract with no constructor arguments (i.e. hard code the constructor values in the `.sol` file), as constructor arguments can sometimes be tricky to encode.
* Delete the `artifacts-zk`, `cache-zk`, `deployments-zk` and `typechain-types` directories every time that you change the smart contract code.
* Check with Cronos Labs that your solidity and zksolc versions are supported.
# Developer Tools
The following developer tools and integrations are available to dapp developers, or are in the process of being onboarded onto Cronos zkEVM.
## Native tools
{% content-ref url="/pages/Th93bkDO98aKuHEeW6xp" %}
[Cronos zkEVM Developer Portal and APIs](/for-developers/developer-tools/cronos-zkevm-developer-portal-and-apis)
{% endcontent-ref %}
## Third-party tools
They are listed in alphabetical order.
{% hint style="info" %}
Please note that these tools and integrations have not been independently audited by Cronos zkEVM for potential security weaknesses. Use at your own risk.
{% endhint %}
{% content-ref url="/pages/ncl0l7xgQyX1GczpfVqN" %}
[Band Protocol (Oracle)](/for-developers/developer-tools/band-protocol-oracle)
{% endcontent-ref %}
{% content-ref url="/pages/cp5bFZXXNCtOM9XcPQMI" %}
[Covalent (Analytics)](/for-developers/developer-tools/covalent-analytics)
{% endcontent-ref %}
{% content-ref url="/pages/B12XwnIE669tVkvP9RvD" %}
[Cronos Safe (Multi-sig)](/for-developers/developer-tools/cronos-safe-multi-sig)
{% endcontent-ref %}
{% content-ref url="/pages/basJxguS2MGpae2vEmqp" %}
[Debank (Analytics)](/for-developers/developer-tools/debank-analytics)
{% endcontent-ref %}
{% content-ref url="/pages/GVvlTZuKgOWvkOb4LlQE" %}
[Broken mention](broken://pages/GVvlTZuKgOWvkOb4LlQE)
{% endcontent-ref %}
{% content-ref url="/pages/qSK2rrvzH3VNrBls8gFy" %}
[Getblock (Node infra)](/for-developers/developer-tools/getblock-node-infra)
{% endcontent-ref %}
{% content-ref url="/pages/byQFb4RHFghiE6jsBWKL" %}
[Goldsky (Subgraph hosting)](/for-developers/developer-tools/goldsky-subgraph-hosting)
{% endcontent-ref %}
{% content-ref url="/pages/XUvLN4BrmO4hJsclFKk6" %}
[Google Bigquery (Analytics)](/for-developers/developer-tools/google-bigquery-analytics)
{% endcontent-ref %}
{% content-ref url="/pages/15ZuVZv4VcQa0bJfJsJ0" %}
[NFTs2Me (No code)](/for-developers/developer-tools/nfts2me-no-code)
{% endcontent-ref %}
{% content-ref url="/pages/qUVC9DovBxEr6tyFmfbQ" %}
[Pyth (Oracle)](/for-developers/developer-tools/pyth-oracle)
{% endcontent-ref %}
{% content-ref url="/pages/8Vzz9CGx4A9jS7uA4Tpv" %}
[Secret Network (Computing)](/for-developers/developer-tools/secret-network-computing)
{% endcontent-ref %}
{% content-ref url="/pages/tA3bNADPA2MiY0Wm1DVg" %}
[Sentio (Analytics)](/for-developers/developer-tools/sentio-analytics)
{% endcontent-ref %}
{% content-ref url="/pages/HwEd3iWPa9pvEJxXbjnA" %}
[Subquery (Analytics)](/for-developers/developer-tools/subquery-analytics)
{% endcontent-ref %}
{% content-ref url="/pages/CzdHW8AMsTbR08lZhYDJ" %}
[txSync (Paymaster)](/for-developers/developer-tools/txsync-paymaster)
{% endcontent-ref %}
{% content-ref url="/pages/gwkz4K8wpdMrZTAhe2e5" %}
[VIA Labs (Bridge)](/for-developers/developer-tools/via-labs-bridge)
{% endcontent-ref %}
{% content-ref url="/pages/j7DVfr9O6V45EG60dApu" %}
[Zyfi (Paymaster)](/for-developers/developer-tools/zyfi-paymaster)
{% endcontent-ref %}
# Cronos zkEVM Developer Portal and APIs
### Introduction
With the Cronos zkEVM Developers Portal, developers gain access to the blockchain explorer's Developer API, contract verification data, and, soon, a SubGraph service.
These resources empower developers to easily access Cronos zkEVM blockchain data, accelerating the development process of decentralized applications.
Website:
### Developer API Access
At the heart of the Cronos zkEVM Developers Portal is the Developer API documentation, which offers access to the blockchain explorer's APIs. These APIs empower developers to efficiently query blockchain data using GET/POST requests. Available data includes:
* Accounts data: Balance, transaction history, internal transactions
* Blocks data: Block details
* Contracts data: ABI, source code, verification submissions, and status
* ETH proxy: Proxy for commonly used zkEVM RPC endpoints
* Logs data: Log details
* Tokens data: Account balance for tokens, total supply for tokens
* Transactions data: Transaction status
The Developer API provides real-time data, ensuring that your applications have access to the most current information. Typically updated within a few minutes, this data enhances the performance and reliability of your dapps.
### Getting Started With the Cronos zkEVM Developer API
To get started with the Cronos zkEVM developer API, simply register an account on the [Account Registration page](https://developers.zkevm.cronos.org/register) in Cronos zkEVM developer portal, where you can access a pair of mainnet and testnet API keys on the user dashboard. You can then access the developer API service and use it to retrieve data from the available endpoints.
The Developer API service is well-documented with comprehensive guides and examples to help you get started quickly. The documentation provides information on making requests, parsing responses, and using the various endpoints, as well as access to a range of data on the Cronos zkEVM, including accounts, blocks, contracts, transactions, logs, tokens, statistics, and more.
\
For more detailed information, refer to the [Cronos zkEVM API documentation](https://explorer-api-doc.zkevm.cronos.org/mainnet).
# Band Protocol (Oracle)
Band Protocol offers oracles to dapp developers, including VRF functionality (verifiable random function).
Band Protocol feeds are primarily available via a "push" model.
Website:
### Deployment status
### :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
#### **Price oracle, supported symbols: $CRO, $ETH and $BTC:**
* Github reference:
***
### :white\_check\_mark: **Cronos zkEVM** Sepolia **Testnet (Chain-id : `240` )**
Price oracle, supported symbols: $CRO, $ETH and $BTC
* Proxy contract address: To be re-deployed
* Github reference:
VRF:
| Contract name | Contract address |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| BridgeImplementation | [0x9cb924A34ac2b5e1fA23522701616D2461BAd851](https://explorer.zkevm.cronos.org/testnet/address/0x9cb924a34ac2b5e1fa23522701616d2461bad851) |
| ProxyAdmin | [0x6ca84b102A240586Cb2cbCe9B113E6314984C126](https://explorer.zkevm.cronos.org/testnet/address/0x6ca84b102A240586Cb2cbCe9B113E6314984C126#code) |
| Bridge | [0x4fc5a465d763cEcc0c0b2CeF4e874aCb5B859dD8](https://explorer.zkevm.cronos.org/testnet/address/0x4fc5a465d763cEcc0c0b2CeF4e874aCb5B859dD8#code) |
| VRFProviderV2 | [0x2b04B94C6fbaC2a4a70fFEC6EFb5bd3521e7D11a](https://explorer.zkevm.cronos.org/testnet/address/0x2b04B94C6fbaC2a4a70fFEC6EFb5bd3521e7D11a#code) |
| VRFLensV2 | [0x83814B902276755cf9c1Fcf7b74633DA49463162](https://explorer.zkevm.cronos.org/testnet/address/0x83814B902276755cf9c1Fcf7b74633DA49463162#code) |
* Github reference:
# Covalent (Analytics)
Covalent's GoldRush is a set of data tools that enable easy web3 development across 200+ blockchains.
The GoldRush API is RESTful and provides a unified approach to fetch blockchain data with a consistent request and response object format. For example, a developer can fetch all token balances for an address across any of the 200+ supported networks by changing the unique network name in the URL.
Docs:
Supported networks:
### Deployment status
* ❌ **Cronos zkEVM Mainnet (Chain-id : `388` )**
Pending integration.
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `240` )**
Integration completed.
# Cronos Safe (Multi-sig)
The [Safe suite](https://gnosis-safe.io/), formerly known as Gnosis Safe, is the gold standard in terms of multi-signature smart contract wallets in the EVM world. The first release dates back to 2018, and Safe multi-signature wallets have been used to store tens of billions of US Dollars in value.
Safe does not support Cronos zkEVM chain officially yet, but dApp developers can consider using [Cronos Safe](https://cronos-safe.org/), an implementation of the Safe user interface and smart contracts on the Cronos chain.
Please note that each Safe is specific to a chain. As Cronos Safe supports both Cronos EVM and Cronos zkEVM, in mainnet and testnet, users are encouraged to keep track of their wallets and signatories.
Read this blog post for more information:
Website:
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment completed.
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `240` )**
Testnet deployment completed.
**Remarks:**
When using Cronos Safe, make sure to select the correct network in the top-right corner, either `Cronos zkEVM` or `Cronos zkEVM testnet` , as follows:
# Crypto.com AI Agent SDK (AI)
*Empower your dApp with AI-driven blockchain interactions*
Crypto.com AI Agent SDK is a powerful tool that enables developers to seamlessly integrate AI capabilities into their Web3 projects.
With the PyPi and NPM packages, you can create AI agents that can create blockchain interactions, opening up a world of possibilities for your applications.
***
### Overview
*Best-in-class AI Blockchain Tool*
* ***Effortlessly Create AI-Driven Features***
Our embedded LLM models serve as an intermediary layer, intelligently matching and executing the right functions and calls for both developers and end-users. This empowers non-technical users to engage with complex blockchain actions seamlessly.
* ***Seamless integration with the Cronos Ecosystem***
The SDK is designed to integrate effortlessly with existing Cronos services, including public RPC endpoints, in-house explorers, and their APIs, providing a comprehensive toolkit for developers.
* ***Simplified Development***\
Our SDK allows for seamless integration with a wide range of client-side applications, including frontend apps, messaging platforms like Telegram and Discord, and even terminal interfaces. This flexibility empowers developers to choose their preferred frontend solution, streamlining the integration process and enabling them to focus on building innovative applications.
### Use Cases
Our AI agent product is revolutionizing the way we interact with blockchain technology. By harnessing the power of natural language processing and machine learning, we're enabling developers to build innovative applications that simplify complex blockchain actions. Here are just a few examples of the exciting use cases our product makes possible:
1. **Blockchain Data Queries**\
Imagine being able to ask questions like "What's the current market capitalization of Ethereum?" or "What's the average transaction fee on the Bitcoin network?" and receiving accurate, up-to-date answers in seconds. Crypto.com AI agent can transform user questions into actionable blockchain queries, generating valuable insights on market trends and implications.
2. **Wallet Management**\
Managing cryptocurrency wallets can be a daunting task, especially for newcomers to the space. Crypto.com AI agent makes it easy to create crypto wallets, execute transfers, and manage addresses using simple text commands. In the future, we'll also be adding support for multi-signature wallets and account abstraction.
3. **Portfolio Management**\
With our SDK, developers can create and deploy smart contracts that interact directly with AI-driven trading insights. This enables automated execution of trades based on real-time market analysis, giving users a significant edge in the market. For example, imagine building a portfolio management application that uses machine learning algorithms to analyze market trends and automatically execute trades when certain conditions are met.
4. ***Content Monetization***\
Our AI agent product also enables developers to extend their current AI functionalities to include blockchain features. Imagine being able to embed crypto payments into shopping, travel services, subscriptions, and more. For instance, a travel booking platform could use our AI agent to accept cryptocurrency payments and automatically convert them into fiat currency, streamlining the booking process for users.
These are just a few examples of the many exciting use cases our AI agent product makes possible. By harnessing the power of AI-driven blockchain interactions, developers can build innovative applications that simplify complex blockchain actions and unlock new possibilities for users.
### Cronos zkEVM Network Resources:
### Explorer API keys
To get started with the Cronos zkEVM developer API, simply register an account on the [Account Registration page](https://developers.zkevm.cronos.org/register) in Cronos zkEVM developer portal, where you can access a pair of mainnet and testnet API keys on the user dashboard. You can then access the developer API service and use it to retrieve data from the available endpoints.
### Documentation
Detailed documentation for Cronos zkEVM Chain:
* Cronos zkEVM -
### Cronos zkEVM Mainnet URLs
* Chain ID: `388`
* Token: zkCRO ("Cronos zkEVM CRO")
* JSON RPC API (rate limited): [https://mainnet.zkevm.cronos.org](https://mainnet.zkevm.cronos.org/)
* WebSocket (rate limited): `wss://ws.zkevm.cronos.org`
* Blockchain explorer:
* Gas price: ⚠️ The gas price is currently fixed at 1250`gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
* Developer portal:
* Contract verification interface:
* Bridge for ERC-20 tokens (Ethereum <=> Cronos zkEVM):
***
### Cronos zkEVM Sepolia Testnet URLs
* Chain ID: `240`
* Token: zkTCRO
* JSON RPC API (rate limited): [https://testnet.zkevm.cronos.org](https://testnet.zkevm.cronos.org/)
* WebSocket (rate limited): `wss://ws.testnet.zkevm.cronos.org`
* Blockchain explorer:
* Gas price: ⚠️ The gas price of is currently fixed at 1250`gwei`
* This is subject to change and is expected to be dynamic in the next major release to be announced.
* Developer portal:
* Contract verification interface:
* zkTCRO faucet:
* [Demo project repository](https://github.com/kentimsit/cronos-zkevm-hardhat-boilerplate) for smart contract developers
* Testnet bridge for ERC-20 tokens (zkEVM testnet <=> Ethereum Sepolia):
### Get Started
To start building with the AI Agent SDK, simply install the NPM/PyPi package and follow our comprehensive documentation [Crypto.com AI Agent Client](https://ai-agent-sdk-docs.crypto.com/crypto.com-ai-agent-client).
Visit the [Crypto.com AI SDK documentation by clicking here](https://ai-agent-sdk-docs.crypto.com/).
# Debank (Analytics)
Debanks is the leading crypto portfolio tracker, enabling users to monitor the crypto assets of an EVM address across the largest number of chains.
Debank is available via the webpage , or via the API at .
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet integration completed.
* ❌ **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Not plans to deploy on Testnet.
# Dextools (Analytics)
DEXtools scans Decentralized Exchange platforms and provides real-time charts, history and token info from Cronos zkEVM.
Website:
If you are a project developer, you can visit the corresponding token page on Dextools in order to update the information associated with the project's token.
## Deployment status
* :white\_check\_mark:❌ **Cronos zkEVM Mainnet (Chain-id : `388` )**
Integration completed.
* ❌ **Cronos zkEVM Sepolia Testnet (Chain-id : `240` )**
Not relevant.
## Cronos zkEVM pairs and token information
CRO
* CRO/wzkCRO pair: [https://www.dextools.io/app/en/cronoszkevm/pair-explorer/0x45e149b212b1c4c2618527de767a5844079f9fde](https://www.dextools.io/app/en/cronoszkevm/pair-explorer/0x45e149b212b1c4c2618527de767a5844079f9fde?t=1731972159746)
* Explorer link:
* Website:
* Twitter:
* Coingecko:
* Discord:
* Telegram:
wzkCRO
* wzkCRO/vUSD pair:
* Explorer link:
* Website:
* Twitter:
* Coingecko:
* Discord:
* Telegram:
# Eliza (AI)
[Eliza](https://elizaos.github.io/eliza/) is an AI agent framework used to deploy autonomous AI agents with consistent personalities across Discord, Twitter, and Telegram. Full support for voice, text, and media interactions.
Capabilities include: Built-in RAG memory system, document processing, media analysis, and autonomous trading capabilities. Supports multiple AI models including Llama, GPT-4, and Claude.
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet integration completed ([see PR](https://github.com/elizaOS/eliza/pull/1464)).
* ❌ **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Not plans to deploy on Testnet.
# Getblock (Node infra)
[Getblock](https://getblock.io/) is a commercial Web3 infratructure provider offering JSON-RPC access to blockchain networks with high rate limits.
Getblock supports both Cronos zkEVM and Cronos EVM (mainnet only).
[Visit Getblock to obtain your API key](https://getblock.io/).
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Available.
* **❌** **Cronos zkEVM Sepolia Testnet (Chain-id : `240` )**
Not available.
# Goldsky (Subgraph hosting)
Goldsky is a platform where dapp developers can deploy and host subgraphs.
Learn more about Indexing Cronos zkEVM with Goldsk:
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment completed. Subgraphs can be deployed under the slug `cronos-zkevm`
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Testnet deployment completed. Subgraphs can be deployed under the slug `cronos-zkevm-sepolia`
# Google Bigquery (Analytics)
The BigQuery Cronos zkEVM dataset makes it possible for anyone to perform complex queries on transactions, blocks, batches and logs.
BigQuery datasets are available for Cronos zkEVM and Cronos EVM on [Google's Web3 product page](https://cloud.google.com/application/web3/discover).
By leveraging datasets in BigQuery, you can access blockchain data as easily as your internal data. You can query the full history of blocks, transactions, logs and receipts for these two chains. By joining chain data with application data, you can get a complete picture of your users and your business.
Developers only need a Google Cloud account with BigQuery enabled.
## Quickstart
1. [Go to Cronos zkEVM dataset](https://console.cloud.google.com/bigquery/analytics-hub/exchanges/projects/596763852542/locations/us/dataExchanges/cronos_zkevm_1922b84ea5e/listings/cronos_zkevm_mainnet_1922b96033f?project=groovy-footing-429219-v8) and click on one of the [samples](https://console.cloud.google.com/bigquery?sq=593585632926:0715bee89d184ba782c1de10dd01399b).
2. You will get to the console and see the Cronos zkEVM dataset on the left in the explorer.
{% hint style="warning" %}
**Please note** BigQuery charges are based on the amount of data processed by your queries, so running the query may incur charges to your account. You can find the consumption estimate in the top right corner similar to the warning of "This query will process 1.37 GB when run."
{% endhint %}
3\. You can see below BigQuery SQL query examples to run in console by click "Run". \
To start developing your own BigQuery SQL code, you can refer to the following [syntax](https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax). \
\
For the Cronos data schema we refer to the [Google Cloud Cronos schema](https://cloud.google.com/blockchain-analytics/docs/schema#cronos_mainnet).
## Example Queries
### 1. Show all Veno USD transfers
This query shows transfers of the Veno USD token on Cronos zkEVM since genesis.
In the Google Cloud console, go to the BigQuery page.
The following query is loaded into the Editor field: \
Replace `your-project-id.cronos_zkevm_mainnet` in the following query with the project ID and the linked dataset name you used when you subscribe to this dataset.
```sql
-- UDF for easier string manipulation.
CREATE TEMP FUNCTION ParseSubStr(hexStr STRING, startIndex INT64, endIndex INT64)
RETURNS STRING
LANGUAGE js
AS r"""
if (hexStr.length < 1) {
return hexStr;
}
return hexStr.substring(startIndex, endIndex);
""";
-- UDF to convert hex to decimal.
CREATE TEMP FUNCTION HexToDecimal(hexStr STRING)
RETURNS BIGNUMERIC
LANGUAGE js
AS r"""
return BigInt(hexStr, 16);
""";
SELECT
t.hash as transaction_hash,
t.from_address AS from_address,
CONCAT("0x", ParseSubStr(l.topic2, 26, LENGTH(l.topic2))) AS to_address,
(HexToDecimal(l.data) / 1000000000000000000) AS veno_usd_transfer_amount
FROM
`your-project-id.cronos_zkevm_mainnet.transactions` AS t
INNER JOIN
`your-project-id.cronos_zkevm_mainnet.logs` AS l
ON
l.transaction_hash = t.hash
WHERE
t.to_address = LOWER("0x5b91e29Ae5A71d9052620Acb813d5aC25eC7a4A2") -- Veno USD
AND
l.topics_count > 0
AND
-- Transfer(address indexed src, address indexed dst, uint wad)
l.topic0 = LOWER("0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef")
;
```
The following shows an example result:
| transaction\_hash | from\_address | to\_address | veno\_usd\_transfer\_amount |
| ------------------------------------------------------------------ | ------------------------------------------ | ------------------------------------------ | --------------------------- |
| 0x1810569dbf9f188abef8a81f71cedc526dc5826185f901bde77a315836e8bb2e | 0xf4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a | 0x2a66ac1167ae3f6c504805f6a72ccddc0d9bb890 | 1.065316917013257903 |
| 0xe3064e01b2d0915373d2134c50bdeb4a0a4bda3e7e3c48c58efe50e84afec0ec | 0xf4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a | 0x2a66ac1167ae3f6c504805f6a72ccddc0d9bb890 | 1.06532400320732326 |
| 0xd872a1f2a89d0c5ffdf8348de232aee2359fee0893504567cf382fbe24fa746e | 0xf4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a | 0x2a66ac1167ae3f6c504805f6a72ccddc0d9bb890 | 1.06532435751826383 |
| 0xbef982225518fcf3dfc2b705dbd1855dd7895f3b12688b1bfff9f69982cd0458 | 0xf4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a | 0x2a66ac1167ae3f6c504805f6a72ccddc0d9bb890 | 1.065326129074734257 |
| 0x851199e970aac6c5a4089edba79eab0c9526a4a9151d4ca27b2494b48cfff3db | 0xf4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a | 0x2a66ac1167ae3f6c504805f6a72ccddc0d9bb890 | 1.065322585964739367 |
### 2. Wrapped zkCRO activity
This query shows the wallets with the most interactions with Wrapped zkCRO in the last 30 days.
In the Google Cloud console, go to the BigQuery page.
The following query is loaded into the Editor field:
Note: Replace `your-project-id.cronos_zkevm_mainnet` in the following query with the project ID and the linked dataset name you used when you subscribe to this dataset.
```sql
SELECT
from_address AS address,
CONCAT("https://explorer.zkevm.cronos.org/address/", from_address) AS explorer_link,
COUNT(from_address) AS num_transactions
FROM
`your-project-id.cronos_zkevm_mainnet.transactions` AS t
WHERE
to_address = LOWER("0xC1bF55EE54E16229d9b369a5502Bfe5fC9F20b6d") -- Wrapped zkCRO
AND
block_timestamp > (CURRENT_TIMESTAMP() - INTERVAL 30 DAY)
GROUP BY
from_address
ORDER BY
COUNT(from_address) DESC
;
```
The following shows an example result:
| address | explorer\_link | num\_transactions |
| ------------------------------------------ | -------------------------------------------------------------------------------------- | ----------------- |
| 0x4712633d145d5c5b5b35b95e1a4fb06bbad4b1ec | | 59 |
| 0x9d6e06ec5c09b09559d65a3e2906b2b1c2ac0b68 | | 37 |
| 0x06556fe0eb119fcfcc0025ab7427e2c9eafd8e98 | | 28 |
| 0xed0598b07faacb711870b58eae40878128928a4b | | 26 |
| 0x3d5bc4222549f7e74d1da14745ab34dec8b2c90c | | 20 |
### Contract Addresses
You can find a list of key contract addresses on [Cronos zkEVM documentation](https://docs-zkevm.cronos.org/for-developers/contract-addresses).
# NFTs2Me (No code)
NFTs2Me is a powerful and intuitive NFT creation tool, allowing you to launch your NFT project and build a new world on web3. Create your collection using our designer, define its metadata, upload your assets, set an optional price and create/deploy your contract (ERC721 or ERC1155).
Visit to create your NFT.
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment completed.
* ❌ **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Not plans to deploy on Testnet.
# Pyth (Oracle)
### Overview
[Pyth Network](https://pyth.network/) is one of the largest first-party Oracle network, delivering real-time data across [a vast number of chains](https://docs.pyth.network/price-feeds/contract-addresses). The network comprises some of the world’s [largest exchanges, market makers, and financial services providers](https://pyth.network/publishers). These publish proprietary data on-chain for aggregation and distribution to smart contract applications.
### Using Pyth Network on Cronos zkEVM
The Pyth introduces an innovative low-latency [pull oracle design](https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand), where users can pull price updates onchain when needed, enabling everyone in the onchain environment to access that data point most efficiently. Pyth network updates the prices every **400ms.**
Developers Cronos zkEVM have permissionless access to any of [Pyth’s price feeds](https://pyth.network/developers/price-feed-ids) for equities, ETFs, commodities, foreign exchange pairs, and cryptocurrencies.
#### Example
Here is a working example of a contract that fetches the latest price of ETH/USD on the Cronos zkEVM. You have to pass [Pyth's contract address](https://docs.pyth.network/price-feeds/contract-addresses/evm) for Cronos zkEVM mainnet/testnet and the desired [price feed id](https://pyth.network/developers/price-feed-ids) to fetch the latest price.
```solidity
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;
import "@pythnetwork/pyth-sdk-solidity/IPyth.sol";
import "@pythnetwork/pyth-sdk-solidity/PythStructs.sol";
contract MyFirstPythContract {
IPyth pyth;
constructor(address _pyth) {
pyth = IPyth(_pyth);
}
function fetchPrice(
bytes[] calldata updateData,
bytes32 priceFeed
) public payable returns (int64) {
// Fetch the priceUpdate from hermes.
uint updateFee = pyth.getUpdateFee(updateData);
pyth.updatePriceFeeds{value: updateFee}(updateData);
// Fetch the latest price
PythStructs.Price memory price = pyth.getPrice(priceFeed);
return price.price;
}
}
```
Here you can fetch the `updateData` from Pyth's [`Hermes`](https://hermes.pyth.network/docs/), which listens to Pythnet and Wormhole for price updates; or you can use the [`pyth-evm-js`](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/js/src/EvmPriceServiceConnection.ts#L15) SDK. Check [How to Fetch Price Updates](https://docs.pyth.network/price-feeds/fetch-price-updates) to pull the latest data.
This [package](https://github.com/pyth-network/pyth-crosschain/tree/main/target_chains/ethereum/sdk/solidity) provides utilities for consuming prices from the Pyth network oracle using Solidity. Also, it contains the [Pyth Interface ABI](https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/ethereum/sdk/solidity/abis/IPyth.json) that you can use in your libraries to communicate with the Pyth contract.
It is generally recommended to follow the [consumer best practices](https://docs.pyth.network/documentation/pythnet-price-feeds/best-practices) when consuming Pyth data.
For more information, check out the official [Pyth documentation](https://docs.pyth.network/price-feeds). There are details on the various functions available for interacting with the Pyth smart contract in the [API Reference section](https://api-reference.pyth.network/price-feeds/evm/getPrice).
### Pyth on Cronos zkEVM
#### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment completed - [0x056f829183ec806a78c26c98961678c24fab71af](https://explorer.zkevm.cronos.org/address/0x056f829183ec806a78c26c98961678c24fab71af)
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Testnet deployment completed - [0xB1DB1498902F08E16E11F1a423ec9CCB9537E1D6](https://explorer.zkevm.cronos.org/testnet/address/0xb1db1498902f08e16e11f1a423ec9ccb9537e1d6)
Additionally, click to access the [Pyth price-feed IDs](https://pyth.network/developers/price-feed-ids).
### Using Pyth as a PUSH Oracle
Pyth Oracle can be used as a Push oracle by running a scheduler which can update the prices in the backend. It will make sure that the your dapp will be updated with latest prices as per your configuration. Checkout the open source [price pusher](https://github.com/pyth-network/pyth-crosschain/tree/main/apps/price_pusher) app to get started with the scheduler.
### Developers and community
The Pyth network provides additional tools to developers, such as [TradingView Integration](https://docs.pyth.network/guides/how-to-create-tradingview-charts), or the [Gelato web3 functions](https://docs.pyth.network/guides/how-to-schedule-price-updates-with-gelato).
Check out the following links to get started with Pyth.
* [Pyth EVM Integration Guide](https://docs.pyth.network/price-feeds/use-real-time-data/evm)
* [Pyth Docs](https://docs.pyth.network/home)
* [Pyth API Reference](https://api-reference.pyth.network/price-feeds/evm/getPrice)
* [Pyth Examples](https://github.com/pyth-network/pyth-examples)
* [Pyth Price Feed Ids](https://pyth.network/developers/price-feed-ids)
* [Website](https://pyth.network/)
* [Twitter](https://x.com/PythNetwork)
# Secret Network (Computing)
## Introduction
On blockchains, all data is public by default.
Decentralized confidential computing (DeCC) enables use cases like private voting for DAOs, secure random number generation for gaming, encrypted databases for various applications, encrypted data tied to NFTs, sealed-bid auctions, and encrypted order books for DeFi applications. All of this can be built on Cronos by utilizing [Secret Network](https://scrt.network/)’s Confidential Computing Layer, as long as these use cases are permitted by your country's laws and regulations.
### Integrating Secret's Confidential Computing Layer[](https://docs.kakarot.org/ecosystem/confidential-computing/secret/#integrating-secrets-confidential-computing-layer)
You can integrate Secret’s CCL into an existing Cronos application, or design a new application from the ground up to take advantage of the unique use-cases it enables. To start, check out Secret Network’s [Confidential Computing Layer](https://scrt.network/confidential-computing-layer) landing page to get an overview of how it works, and example use-cases for inspiration. From there you’ll find multiple links to Secret's CCL documentation:
1. [Basics](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/basics) - explains the cross-chain communication technologies used, and how to connect a MetaMask wallet to Secret Network.
2. [Use-cases](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/usecases) - provides tutorials showing how to build various types of EVM applications using Secret’s CCL. All of these tutorials can be used to deploy a contract on Cronos zkEVM.
3. [Supported Networks](https://docs.scrt.network/secret-network-documentation/confidential-computing-layer/ethereum-evm-developer-toolkit/supported-networks) - provides a list of gateway contract addresses. This is how your Cronos zkEVM application will communicate with Secret.
### Get Support[](https://docs.kakarot.org/ecosystem/confidential-computing/secret/#get-support)
To get CCL development help, you can join the Secret Network [Discord](https://scrt.network/discord) or [Telegram](https://scrt.network/SCRTCommunity). You can also [get in touch](mailto:info@scrt.network) with the Secret Network team directly.
# Sentio (Analytics)
[Sentio](https://www.sentio.xyz/) is a powerful platform for indexing blockchain data and creating no-code data queries and dashboards.
Sentio supports both [Cronos zkEVM and Cronos EVM](https://www.sentio.xyz/status/index.html).
Quickstart: [see here](https://docs.sentio.xyz/docs/quickstart).
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment completed. Use chain ID 388.
* ❌ **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Not plans to deploy on Testnet.
# Subquery (Analytics)
SubQuery's indexing capabilities empower blockchain developers building on Cronos zkEVM to manage and query on-chain data efficiently, speeding up development and iterations.
SubQuery makes it easy to build a custom API for your dApp or smart contracts in minutes, providing clean indexed data to any service.
For more details, visit:
* Website:
* Docs:
* Code repo:
* [Discord community](https://discord.com/invite/subquery?ref=blog.subquery.network) (including technical support)
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Deployment completed. The docs are the same for all chains. Use the Cronos zkEVM chain ID (388).
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Deployment completed. The docs are the same for all chains. Use the Cronos zkEVM testnet chain ID (282).
# Thirdweb (App development)
Thirdweb is a complete development platform for Web3 app developers.
It offers:
* Wallet management
* Account abstraction / paymaster
* And more
Website:
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Available. See
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Available. See
# txSync (Paymaster)
txSync's Tsuko aims to simplify the usage of paymasters on ZK chains by providing a Paymaster as a Service (PaaS) product that can be used out of box.
Tsuko is available for Cronos zkEVM testnet only. Read the testnet integration post for details:
### Deployment status
* **❌ Cronos zkEVM Mainnet (Chain-id : `388` )**
Not available yet.
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Deployment completed.
# VIA Labs (Bridge)
VIA Labs equips developers with tools to scale across multiple blockchain networks, enabling seamless and efficient omni-chain interoperability.
Website:
Docs:
### Deployment status
* ❌ **Cronos zkEVM Mainnet (Chain-id : `388` )**
Mainnet deployment pending.
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Testnet deployment completed.
# Zyfi (Paymaster)
Zyfi is a Paymaster-as-a-Service that focuses on flexibility and ease of integration. It was created as a way to accelerate the adoption of paymasters in the zkSync ecosystem.
DApps can either propose to their users to pay with any ERC-20 traded on zkSync (currently more than 80), or decide to sponsor part or all of the transaction gas cost with their own custom logic.
All is powered by a Paymaster [API](https://docs.zyfi.org/integration-guide/quick-start) that abstracts complexities away from developers, so that they can focus on building their product.
Website:
### Deployment status
* :white\_check\_mark: **Cronos zkEVM Mainnet (Chain-id : `388` )**
Deployment completed. The docs are the same for all chains. Use the Cronos zkEVM chain ID (388).
* :white\_check\_mark: **Cronos zkEVM Sepolia Testnet (Chain-id : `282` )**
Deployment completed. The docs are the same for all chains. Use the Cronos zkEVM testnet chain ID (282).
# Contract Addresses
## Cronos zkEVM mainnet (Chain ID: `388`)
### The base token - `zkCRO`
**"Cronos zkEVM CRO**" **-** zkCRO is the custom L2 base token of Cronos zkEVM, [based on this repository](https://github.com/matter-labs/era-contracts/blob/9e8c28f9034272f05c6f2fb781fb84ff37ec7116/system-contracts/contracts/L2BaseToken.sol).
*Base token contracts on:*
* *Ethereum mainnet (L1):*
* Cronos (CRO - 8 decimals): [0xa0b73e1ff0b80914ab6fe0444e65848c4c34450b](https://etherscan.io/address/0xa0b73e1ff0b80914ab6fe0444e65848c4c34450b)
* Cronos zkEVM CRO (zkCRO - 18 decimals): [0x28Ff2E4dD1B58efEB0fC138602A28D5aE81e44e2](https://etherscan.io/address/0x28Ff2E4dD1B58efEB0fC138602A28D5aE81e44e2)
* *Cronos zkEVM mainnet (L2):*
* Cronos zkEVM CRO (zkCRO - 18 decimals): `0x000000000000000000000000000000000000800a`
{% hint style="info" %}
There is a wrapped, an ERC20 compatible version of `zkCRO`, with token symbol `wzkCRO` at the following contract address (18 decimals too), under the contract address:
`0xC1bF55EE54E16229d9b369a5502Bfe5fC9F20b6d`
{% endhint %}
### Token contract addresses on L1 (***Ethereum*****) and L2 (*****Cronos zkEVM*****)**
### Other key testnet contracts
| Contract name | Network | Contract address |
| --------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Validator timelock contract | L1 (Ethereum Sepolia) | [0xD3876643180A79d0A56d0900C060528395f34453](https://sepolia.etherscan.io/address/0xD3876643180A79d0A56d0900C060528395f34453) |
| Diamond proxy contract | L1 (Ethereum Sepolia) | [0xA3062Ab8D613489D8bA5303123240f7e8E98483a](https://sepolia.etherscan.io/address/0xA3062Ab8D613489D8bA5303123240f7e8E98483a) |
| Bridge hub contract | L1 (Ethereum Sepolia) | [0x35A54c8C757806eB6820629bc82d90E056394C92](https://sepolia.etherscan.io/address/0x35A54c8C757806eB6820629bc82d90E056394C92) |
| Verifier contract | L1 (Ethereum Sepolia) | [0x68a9afFE98Aed0749351e63a9CF95969Cb1EFf08](https://sepolia.etherscan.io/address/0x68a9afFE98Aed0749351e63a9CF95969Cb1EFf08#code) |
| L1 shared bridge | L1 (Ethereum Sepolia) | [0x3E8b2fe58675126ed30d0d12dea2A9bda72D18Ae](https://sepolia.etherscan.io/address/0x3E8b2fe58675126ed30d0d12dea2A9bda72D18Ae) |
| Middleware | L1 (Ethereum Sepolia) | [0x4F1CeDf1BE03F2100206aF843851c9B14210118a](https://sepolia.etherscan.io/address/0x4f1cedf1be03f2100206af843851c9b14210118a) |
{% hint style="info" %}
Note - The `Middleware` contract allows L1 to L2 transfers without having zkTCRO on L1
{% endhint %}
***
# Account abstraction
Cronos zkEVM ecosystem dapps are encouraged to make use of native Account Abstraction to enable users to perform gasless transactions.
Depending on the dapp's design choices, transaction fees can be paid by the users in an eligible ERC20 token instead of zkCRO, or they can be subsidized by the dapp.
In order to make user of Account Abstraction, dapps must deploy their own Paymaster, [as explained in the ZK stack documentation](https://docs.zksync.io/build/developer-reference/account-abstraction).
Over time, Cronos zkEVM will onboard providers of "Paymaster as a service" solution to alleviate the development effort. Please refer to the [Developer tools](/for-developers/developer-tools) section.
# Smart Sign-On
Cronos zkEVM Smart Sign-On is an extension of [ZKsync Smart Sign-On (SSO)](https://docs.zksync.io/zksync-era/unique-features/zksync-sso), a user and developer friendly system designed to simplify authentication, session management, and transaction processing.
Built on the Cronos zkEVM chain, it enables users to interact with decentralized applications using passkeys, secure credentials stored on their devices, eliminating the need for traditional seed phrases. When a user signs up, their device creates a passkey (like a secure login), which links to a smart account on-chain. This smart account holds their assets and lets them interact with dApps. Through the SSO SDK, dApps can create short-term sessions where users can approve transactions using simple methods like biometrics or a PIN, instead of signing each one manually. This helps make the experience faster, safer, and more user-friendly.
### Key Features
* Passkey based authentication
* Modular smart accounts
* Configurable sessions
* No installs required
* No seed phrase or private key exposure
* Accounts can easily be recovered
### Auth Sever
The Cronos zkEVM SSO system simplifies account creation and login by leveraging passkeys and smart accounts, all managed through a secure and privacy-preserving authentication layer.
The authentication server is hosted at .\
This static web page acts as the central hub for managing user passkeys and smart account sessions.
When signing in for the first time, users will:
* Create a passkey, which is stored securely on their device (e.g., in iCloud Keychain or Google Password Manager).
* Automatically deploy a smart account on Cronos zkEVM linked to the passkey. The deployment fee is sponsored by Cronos zkEVM via a paymaster.
Passkeys are bound to the SSO domain (i.e., `sso.zkevm.cronos.org`) due to WebAuthn security constraints. This means:
* Your passkey works across any DApp that integrates with Cronos zkEVM SSO.
* You can use the same account across multiple DApps without re-registering.
### Multi-Device Access
If your device supports passkey sync (e.g., through iCloud or Google Password Manager), your passkey can be securely shared across your other devices, allowing you to sign in with the same SSO account on each device.
Alternatively, if you sign in on a new device without syncing, you'll be prompted to create a new passkey. This also creates a separate smart account, since each passkey is treated as a distinct identity. In other words, registering a new passkey on a different device (without syncing) means starting with a new account.
### Cronos SSO Dashboard
This Cronos zkEVM SSO [dashboard](https://sso.zkevm.cronos.org/dashboard) serves as a unified interface for managing authentication and account operations on the Cronos zkEVM ecosystem. Acting as both an SSO Auth Server and a user dashboard, it enables users to securely interact with the Cronos zkEVM through a simple single-page application.
As a non-custodial intermediary, the Auth Server supports:
* Passkey Creation: Generate and manage passkeys for secure, password-less authentication.
* Session Display: Displays session keys configured with specific access permissions and spending constraints.
The user dashboard extends functionality by allowing users to:
* View asset balances in Cronos zkEVM
* Monitor and terminate active sessions
* Manage passkeys and registered devices (Coming soon)
* Set up account recovery options (Coming soon)
* Review full transaction history (Coming soon)
* Explore the NFT marketplace (Coming soon)
{% hint style="info" %}
**Note:** Cronos zkEVM SSO is under development, and will be released in future updates.
{% endhint %}
### Quick Start
This quick start is based on the [ZKsync SSO Quick Start](https://docs.zksync.io/zksync-era/unique-features/zksync-sso/getting-started), adapted to use Cronos zkEVM blockchain specifications. For more details, please refer to the [ZKsync SSO Quick Start](https://docs.zksync.io/zksync-era/unique-features/zksync-sso/getting-started) and [Session Interface](https://docs.zksync.io/zksync-era/unique-features/zksync-sso/sessions) documentation.
{% tabs %}
{% tab title="Web" %}
#### 1. Install the ZKsync SSO SDK package
```typescript
npm i zksync-sso
# optional peer dependencies
npm i @simplewebauthn/browser @simplewebauthn/server @wagmi/core
```
{% hint style="info" %}
**Note on peer dependencies:**
* @wagmi/core is required when using the ZKsync SSO connector (zksyncSsoConnector) in your app.
* @simplewebauthn/browser and @simplewebauthn/server are required when using SDK passkey functionality directly inside your app.
{% endhint %}
#### 2. Config Cronos zkEVM networks
```typescript
import { defineChain } from "viem/utils";
import { chainConfig } from "viem/zksync";
export const cronoszkEVMTestnet = defineChain({
...chainConfig,
id: 240,
name: "Cronos zkEVM Testnet",
nativeCurrency: {
decimals: 18,
name: "Cronos zkEVM Test Coin",
symbol: "zkTCRO",
},
rpcUrls: {
default: { http: ["https://testnet.zkevm.cronos.org"] },
},
blockExplorers: {
default: {
name: "Cronos zkEVM Testnet Explorer",
url: "https://explorer.zkevm.cronos.org/testnet",
},
native: {
name: "Cronos zkEVM Testnet Explorer",
url: "https://explorer.zkevm.cronos.org/testnet",
},
},
testnet: true,
});
export const cronosZKEVMMainnet = defineChain({
...chainConfig,
id: 388,
name: "Cronos zkEVM",
nativeCurrency: {
decimals: 18,
name: "Cronos zkEVM Coin",
symbol: "zkCRO",
},
rpcUrls: {
default: { http: ["https://seed.zkevm.cronos.org/"] },
},
blockExplorers: {
default: {
name: "Cronos zkEVM Explorer",
url: "https://explorer.zkevm.cronos.org",
},
native: {
name: "Cronos zkEVM Explorer",
url: "https://explorer.zkevm.cronos.org",
},
},
testnet: false,
});
```
#### 3. Add ZKsync SSO connector to your app
```typescript
import { zksyncSsoConnector, callPolicy } from "zksync-sso/connector";
import { createConfig, connect } from "@wagmi/core";
const ssoConnector = zksyncSsoConnector({
metadata: {
name: "YOUR_NAME",
icon: "YOUR_ICON",
configData: {
// YOUR CONFIG DATA
}
},
authServerUrl: "https://sso.zkevm.cronos.org/confirm",
// Optional session configuration, if omitted user will have to sign every transaction via Auth Server
session: {
expiry: "EXPIRY_DURATION",
feeLimit: GAS_FEE_LIMIT,
contractCalls: [
callPolicy({
address: "YOUR_CONTRACT_ADDRESS",
abi: ["YOUR_CONTRACT_ABI"],
functionName: "YOUR_CONTRACT_FUNCTION_NAME",
constraints: [
{
index: FUNCION_ARG_INDEX_START_FROM_0,
value: ARG_VALUE,
limit: {
limit: LIFE_TIME_OR_ALLOWANCE,
period: TIME_DURATION
}
},
...
],
}),
],
transfers: [
{
to: "RECIPIENT_ADDRESS",
maxValuePerUse: MAX_VALUE,
valueLimit: VALUE_LIMIT
},
],
},
});
const wagmiConfig = createConfig({
connectors: [ssoConnector],
chains: [cronosZKEVMMainnet, cronoszkEVMTestnet],
..., // your wagmi config https://wagmi.sh/core/api/createConfig
});
const connectWithSSO = () => {
connect(wagmiConfig, {
connector: ssoConnector,
chainId: cronoszkEVMTestnet.id, // or cronosZKEVMMainnet.id for Mainnet
});
};
```
{% endtab %}
{% tab title="React Native" %}
#### 1. Install the ZKsync SSO SDK package
```typescript
npm i react-native-zksync-sso
```
#### 2. Configure platform-specific settings
The React Native SDK currently supports iOS and Android only. Make sure your application is set up to create passkeys by following the platform-specific guidelines:
* iOS: Refer to [Apple's documentation ](https://developer.apple.com/documentation/authenticationservices/supporting-passkeys)for setting up passkey support in your iOS app.
* Android: Refer to [Google's documentation](https://developer.android.com/identity/sign-in/credential-manager) for implementing passkey support in your Android app.
#### 3. Set up the SDK and register an account
Deployed Contract Information:
{% tabs %}
{% tab title="Mainnet" %}
SessionKeyValidator
0x084035cb30507CB7bF9e908Bd1e4514BcE594801
WebAuthValidator
0x141D9c2b49FdE9E6Ce89eCbdCFFde196D5c06161
AAFactory
0xFC5620d827b262Eb2133A8b64FB7E85682f717AC
AuthServerPaymaster
0xDeA0694F76babC82dc2A04fEB60cdFD17DD389E9
{% endtab %}
{% tab title="Testnet" %}
SessionKeyValidator
0xfebC82bBFC6FB8666AC45fa8a601DfA34Ce30710
WebAuthValidator
0x0A019BD60E42b9d18413C710992B96E69dFFC5A0
AAFactory
0x381539B4FC39eAe0Eb848f52cCA93F168a0e955D
AuthServerPaymaster
0xA7B450E91Bc126aa93C656750f9c940bfdc2f1e9
{% endtab %}
{% endtabs %}
```typescript
import sdk from 'react-native-zksync-sso';
const config = {
contracts: {
accountFactory: "AAFactory_address",
passkey: "WebAuthValidator_address",
session: "SessionKeyValidator_address",
accountPaymaster: "AuthServerPaymaster_address"
},
nodeUrl: "https://...",
deployWallet: {
privateKeyHex: "0x..."
}
};
const accountInfo = {
name: "Jane Doe",
userID: "jdoe@example.com"
};
const rpId = sdk.utils.createRpId(
"example.com",
"android:apk-key-hash:your-app-key-hash"
);
const challenge = sdk.utils.generateRandomChallenge();
const deployedAccount = await sdk.register.registerAccountWithUniqueId(
{
name: accountInfo.name,
userID: accountInfo.userID,
rp: {
name: "example.com",
id: rpId
}
},
challenge,
config
);
```
#### 4. Send a transaction
```typescript
import sdk from 'react-native-zksync-sso';
import { AccountClient } from 'react-native-zksync-sso';
const accountClient = new AccountClient(
{
address: deployedAccount.address,
uniqueAccountId: deployedAccount.uniqueAccountId
},
rpId,
config
);
const transaction = {
to: "0x...", // Recipient address
value: 1000, // Amount in wei
from: deployedAccount.address,
input: undefined // Optional: contract call data
};
const receipt = await accountClient.sendTransaction(tx);
```
{% endtab %}
{% endtabs %}
### More Examples
For more examples on how to build dApps with Cronos zkEVM SSO, please visit our GitHub repository:
# Using zkCRO, vETH and vUSD
This a guide for developers on the contracts and interactions involved in bridging to and from Ethereum (L1 - $CRO, $ETH, $DAI/$USDC/$USDT) and Cronos zkEVM (L2 - $zkCRO, $vETH and $vUSD)
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please bridge out your assets before the network is fully decommissioned.**
{% endhint %}
In particular, it covers
{% content-ref url="/pages/FOasJmYiqz0MloypfRZo" %}
[zkCRO](/for-developers/using-zkcro-veth-and-vusd/zkcro)
{% endcontent-ref %}
* [zkCRO](/for-developers/using-zkcro-veth-and-vusd/zkcro#l1-greater-than-l2-minting-usdzkcro-with-usdcro)
* [zkCRO](/for-developers/using-zkcro-veth-and-vusd/zkcro#l2-greater-than-l1-withdrawing-usdzkcro-from-l2)
* [zkCRO](/for-developers/using-zkcro-veth-and-vusd/zkcro#l2-greater-than-l1-withdraw-eth-from-veth)
{% content-ref url="/pages/VHasYbIPRdkZqmy7SlZN" %}
[vETH](/for-developers/using-zkcro-veth-and-vusd/veth)
{% endcontent-ref %}
* [vETH](/for-developers/using-zkcro-veth-and-vusd/veth#l1-greater-than-l2-minting-usdveth-with-usdeth)
* [vETH](/for-developers/using-zkcro-veth-and-vusd/veth#l2-greater-than-l1-withdrawing-usdeth-from-usdveth)
{% content-ref url="/pages/mYyQ1iJkFbLSTAqYlUk8" %}
[vUSD](/for-developers/using-zkcro-veth-and-vusd/vusd)
{% endcontent-ref %}
* [vUSD](/for-developers/using-zkcro-veth-and-vusd/vusd#l1-greater-than-l2-minting-usdvusd-with-usddai-usdusdc-usdusdt)
* [vUSD](/for-developers/using-zkcro-veth-and-vusd/vusd#l2-greater-than-l1-withdrawing-usddai-from-usdvusd)
# zkCRO
On this page, you can find the contracts and their interactions involved when bridging $CRO and $zkCRO to and from Ethereum (L1) and Cronos zkEVM (L2) and unbonding $zkCRO, it includes:
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-developers/using-zkcro-veth-and-vusd/zkcro#l2-greater-than-l1-withdrawing-usdzkcro-from-l2) **before the network is fully decommissioned.**
{% endhint %}
[#l2-greater-than-l1-withdrawing-usdzkcro-from-l2](#l2-greater-than-l1-withdrawing-usdzkcro-from-l2 "mention")
[#l2-greater-than-l1-withdraw-eth-from-veth](#l2-greater-than-l1-withdraw-eth-from-veth "mention")
***
## \[L2 -> L1] Withdrawing $zkCRO from L2
*From Cronos zkEVM mainnet (L2) -> Ethereum mainnet (L1)*
To withdraw $zkCRO from`Cronos zkEVM mainnet -> Ethereum mainnet`, we would need to interact with the following contract:
* $zkCRO token contract:
* Cronos zkEVM: [`0x000000000000000000000000000000000000800a`](https://explorer.zkevm.cronos.org/address/0x000000000000000000000000000000000000800a)
* zkChain Shared Bridge:
* Ethereum : [0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB](https://etherscan.io/address/0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB)
### Step 1) Initiating a withdrawal transaction
On Cronos zkEvm, call the `withdraw` function of zkCRO token contract:
```
function withdraw(address _l1Receiver) external payable;
```
| Parameters | Comments |
| ------------- | ------------------------------------------------ |
| `_l1Receiver` | The address to recieve zkCRO on Ethereum mainnet |
| `payable` | The amount of $zkCRO to be transfer. |
It will take at least 24 hours before the withdrawal can be finalized on Ethereum. Store the transaction hash from the withdrawal transaction for later steps.
### Step 2) Gathering information for $zkCRO withdrawal on L1
Extra information for the L2 -> L1 transaction is required for the next step in claiming the $zkCRO on L1. This information can be gathered by [finalizeWithdrawalParams](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#finalizewithdrawalparams), using `zksync-ethers` package
```
finalizeWithdrawalParams(withdrawalHash)
```
This takes the L2 withdrawal hash as parameters and returns the parameters required for finalizing a withdrawal in the next step.
Example outputs:
```
{
l1BatchNumber: 18,
l2MessageIndex: 59,
l2TxNumberInBlock: 2919,
message: '0x6c0960f935f448644c86dbda241ecb57f18a15c80f35a066000000000000000000000000000000000000000000000a2a15d09519be000000',
sender: '0x000000000000000000000000000000000000800a',
proof: [
'0x23ff0fb003a6a6e111f87cff02afc8680944c711abbe792f07ab4206e9efb9a3',
'0x09fece9c46307f2a0976a3a9b57873e453cf0f4773c2377dcd19f054166aef22',
'0x33c106ae5601983b53c751129d1921c17e40b69aa3fdbfaf07b7a0e0750d35e4',
'0x952ffa5de22d99815d9513dd7454949edb2a1cbcf86008f6fa8b169ffe9b4aee',
'0x8f10560a0b5412ca2e0578fb9266f55411f357d52c8fc3b2cad43b9877a559a6',
'0x8e70b93d3c90798df26473a3ad32a86170e8d52023a4044cf1d4c2d645471b14',
'0xdfaacb39891bbbf4509af408239b97a6f5ef715a5c299ba1f3625c20aec4ef8f',
'0xb04e5ee349086985f74b73971ce9dfe76bbed95c84906c5dffd96504e1e5396c',
'0xac506ecb5465659b3a927143f6d724f91d8d9c4bdb2463aee111d9aa869874db',
'0x124b05ec272cecd7538fdafe53b6628d31188ffb6f345139aac3c3c1fd2e470f',
'0xc3be9cbd19304d84cca3d045e06b8db3acd68c304fc9cd4cbffe6d18036cb13f',
'0xfef7bd9f889811e59e4076a0174087135f080177302763019adaf531257e3a87',
'0xa707d1c62d8be699d34cb74804fdd7b4c568b6c1a821066f126c680d4b83e00b',
'0xf6e093070e0389d2e529d60fadb855fdded54976ec50ac709e3a36ceaa64c291'
]
}
```
### Step 3) Claiming the $zkCRO on L1
Once the transaction in Step 1 has been finalized on L1, we can claim the withdrawn $zkCRO from the zk Chain Shared Bridge contract by calling its `finalizeWithdrawal` function. The inputs can be found in Step 2,
```
function finalizeWithdrawal(
uint256 _chainId,
uint256 _l2BatchNumber,
uint256 _l2MessageIndex,
uint16 _l2TxNumberInBatch,
bytes calldata _message,
bytes32 calldata _merkleProof
)
```
| Parameters | Comments |
| -------------------- | -------------------------------------------------------------------------------------------------------- |
| `_chainId` | Chain id for Cronos zkEVM, which is `388` |
| `_l2BatchNumber` | The L2 batch number where the withdrawal was processed, obtained in Step 2. |
| `_l2MessageIndex` | The position in the L2 logs Merkle tree of the l2Log that was sent with the message, obtained in Step 2. |
| `_l2TxNumberInBatch` | The L2 transaction number in the batch, in which the log was sent, obtained in Step 2. |
| `_message` | The L2 withdraw data, stored in an L2 -> L1 message, obtained in Step 2. |
| `_merkleProof` | The Merkle Proof, obtained in Step 2. |
Once `finalizeWithdrawal` is completed, the withdrawn amount of $zkCRO will go into the receiver's wallet on Ethereum.
We can use `zksync-ethers` package [`isWithdrawalFinalized`](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#iswithdrawalfinalized) call to confirm whether the withdrawal transaction is finalized on the L1 network.
```
isWithdrawalFinalized(withdrawalHash)
```
| Parameters | Comments |
| ---------------- | ------------------------------------------------------------------------------------------- |
| `withdrawalHash` | The transaction hash of the L2 transaction includes the withdrawal transaction from Step 1. |
{% hint style="info" %}
Note - If you would like to convert $zkCRO on Ethereum to $CRO, you can do so by unstaking it to obtain the underlying $CRO staked and receive the $CRO on "Cronos EVM Mainnet" . Please refer to the following guide [#l2-greater-than-l1-withdraw-eth-from-veth](#l2-greater-than-l1-withdraw-eth-from-veth "mention") to complete the process.
{% endhint %}
***
## Unstaking $zkCRO for $CRO
To redeem $zkCRO from`Ethereum mainnet` and receive the underlying unstaked $CRO ( on "[Cronos EVM Mainnet](https://docs.cronos.org/)"), we would need to interact with the following contracts:
* $zkCRO token contract
* Ethereum: [0x28ff2e4dd1b58efeb0fc138602a28d5ae81e44e2](https://etherscan.io/address/0x28ff2e4dd1b58efeb0fc138602a28d5ae81e44e2)
* $LCRO token contract
* Cronos EVM Mainnet: [0x9fae23a2700feecd5b93e43fdbc03c76aa7c08a6](https://cronoscan.com/address/0x9fae23a2700feecd5b93e43fdbc03c76aa7c08a6)
* `vnoNFT`
* Cronos EVM Mainnet: [0xb15533a0bc7c530d692a9660785226dfd3633965](https://cronoscan.com/address/0xb15533a0bc7c530d692a9660785226dfd3633965)
### Step 1) Approving $zkCRO to be spend by zkCRO token contract
On Ethereum, approve $zkCRO to be spent by zkCRO contract with appropriate amount.
### Step 2) Unstaking $zkCRO to recieve $LCRO
On Ethereum, call the `unstake` function on the zkCRO token contract:
```
function unstake(
address _receiver,
uint256 _shareAmount
)
```
| Parameters | Comments |
| -------------- | ------------------------------------------------ |
| `_receiver` | The Cronos EVM mainnet address to receive $LCRO. |
| `_shareAmount` | The amount of $zkCRO to unstake. |
Once done, $LCRO token will be automatically released within 24 hours and transfer to the `_receiver` address of "**Cronos EVM mainnet".**
### Step 3) Approving $LCRO spent
On Cronos EVM mainnet, approve $LCRO to be spent by $LCRO contract with appropriate amount
### Step 4) Unbonding $LCRO
On Cronos EVM mainnet, call `requestUnbond` on the LCRO token contract,
```
function requestUnbond(
uint256 _shareAmount,
address _receiver
)
```
| Parameters | Comments |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `_shareAmount` | The amount of $LCRO that is to be burned to unbond |
| `_receiver` | The wallet address on ethereum to receive the receipt NFT. This NFT is needed to withdraw $CRO once the unbond period has ended |
Once done you will receive an NFT (`vnoNFT`) in return. Wait for batch of unbonding to be processed which takes 28-32 days.
### Step 5) Approving NFT to be spend by LCRO contract
On Cronos EVM mainnet, call `setApprovalForAll` on the [vnoNFT contract](https://cronoscan.com/address/0xb15533a0bc7c530d692a9660785226dfd3633965#writeProxyContract), to approve to transfer of the vnoNFT obtained in Step 4)
```
setApprovalForAll(
address operator,
bool _approved
)
```
| Parameters | Comments |
| ----------- | ---------------------------------- |
| `operator` | $LCRO contract address on ethereum |
| `_approved` | Set to "True" to grant approval. |
### Step 6) Withdrawing $CRO
On Cronos EVM mainnet, call `unbond` function on the LCRO token contract to burn the receipt NFT and receive the underlying unstaked $CRO.
```
function unbond(
uint256 _tokenId,
address _receiver
)
```
| Parameters | Comments |
| ----------- | -------------------------------------------------- |
| `_tokenId` | The tokenId of the receipt NFT, recieved in Step 4 |
| `_receiver` | The address on Cronos EVM mainnet to receive $CRO |
This transaction burns the receipt NFT and sends the unstaked $CRO to the specified receiver.
# vETH
On this page, you can find the contracts and their interactions involved when bridging to and from Ethereum (L1 - $ETH) and Cronos zkEVM (L2 - $vETH ), it includes:
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-developers/using-zkcro-veth-and-vusd/veth#l2-greater-than-l1-withdrawing-usdeth-from-usdveth) **before the network is fully decommissioned.**
{% endhint %}
[#l2-greater-than-l1-withdrawing-usdeth-from-usdveth](#l2-greater-than-l1-withdrawing-usdeth-from-usdveth "mention")
***
## \[L2 -> L1] Withdrawing $ETH from $vETH
*From Cronos zkEVM mainnet (L2) -> Ethereum mainnet (L1)*
{% hint style="info" %}
For withdrawing $vETH (Cronos zkEVM Mainnet) and get $ETH (Ethereum Mainnet) , we would need to:
1. \[On Cronos zkEVM] Use $vETH to redeem $ybETH;
2. \[On Cronos zkEVM] Bridge $ybETH to Ethereum;
3. \[On Ethereum] Obtain `vnoNFT` by burning $ybETH
4. \[On Ethereum] Withdraw $ETH by buring`vnoNFT`.
{% endhint %}
To redeem $vETH from `Cronos zkEVM mainnet`, and withdraw $ETH on `Ethereum mainnet` we would need to interact with the following contracts:
* vETH
* Cronos zkEVM: [`0x271602A97027ee1dd03b1E6e5dB153eB659A80b1`](https://explorer.zkevm.cronos.org/address/0x271602A97027ee1dd03b1E6e5dB153eB659A80b1)
* l2Bridge
* Cronos zkEVM: [0x309429DE3621992Cb0ab8982A448c9Cc5c38405b](https://explorer.zkevm.cronos.org/address/0x309429DE3621992Cb0ab8982A448c9Cc5c38405b)
* zk Chain Shared Bridge
* Ethereum: [0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB](https://etherscan.io/address/0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB)
* ybETH
* Ethereum: [0x76bf2D1e6dFda645c0c17440B17Eccc181dfC351](https://etherscan.io/address/0x76bf2D1e6dFda645c0c17440B17Eccc181dfC351)
* Cronos zkEVM: [`0xf226a595b83056ff3D26b827e3d5b0896E4392a9`](https://explorer.zkevm.cronos.org/address/0xf226a595b83056ff3D26b827e3d5b0896E4392a9)
* vnoNFT
* Ethereum: [0x8f6b0512e63a644631694178b83419fecd90762d](https://etherscan.io/token/0x8f6b0512e63a644631694178b83419fecd90762d)
### Step 1) Approving $vETH to be spend by vETH contract
On Cronos zkEVM, call `approve` on the $vETH contract to approve $vETH spend with appropriate amount.
### Step 2) Redeeming $vETH for $ybETH
On Cronos zkEVM, call `redeem` on the vETH contract, to burn $vETH and redeem $ybETH
```
function redeem(
address _receiver,
uint256 _vethAmount
)
```
| Parameters | Comments |
| ------------- | -------------------------------------------------- |
| `_receiver` | Address to receive $ybETH on Cronos zkEVM |
| `_vethAmount` | Amount of vETH that will be burned to redeem ybETH |
Once done, corresponding $ybETH will be transfer to the `_reciever` address
### Step 3) Approving $ybETH to be spend by the L2Bridge
On Cronos zkEVM, call `approve` on the ybETH contract, to approve `L2Bridge` to spend $ybETH.
### Step 4) Withdrawing $ybETH and store withdrawal hash
On Cronos zkEVM, call withdraw on the L2Bridge contract
```
function withdraw(
address _l1Receiver,
address _l2Token,
uint256 _amount)
```
| Parameters | Comments |
| ------------- | --------------------------------------------------------------------------------- |
| `_l1Receiver` | Address on Ethereum to receive the token |
| `_l2Token` | The token to be withdrawn, the Cronos zkEVM contract address $ybETH in this case. |
| `_amount` | amount of tokens to be withdrawn, note $ybETH has `18` decimals |
Keep the transaction hash for later use in Step 5. This withdraws $ybETH from Cronos zkEVM to Ethereum. It takes at least 24 hours before the withdrawal can be finalized on Ethereum. Store the transaction hash from the withdrawal transaction; you will need it to finalize the withdrawal.
### Step 5) Gathering information for $ybETH withdrawal on L1
Extra information for the L2 -> L1 transaction is required for the next step in claiming the $ybETH on L1. This information can be gathered by [finalizeWithdrawalParams](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#finalizewithdrawalparams), using `zksync-ethers` package
```
finalizeWithdrawalParams(withdrawalHash)
```
This takes the L2 withdrawal hash as parameters and returns the parameters required for finalizing a withdrawal in the next step.
Example outputs:
```
{
l1BatchNumber: 18,
l2MessageIndex: 59,
l2TxNumberInBlock: 2919,
message: '0x6c0960f935f448644c86dbda241ecb57f18a15c80f35a066000000000000000000000000000000000000000000000a2a15d09519be000000',
sender: '0x000000000000000000000000000000000000800a',
proof: [
'0x23ff0fb003a6a6e111f87cff02afc8680944c711abbe792f07ab4206e9efb9a3',
'0x09fece9c46307f2a0976a3a9b57873e453cf0f4773c2377dcd19f054166aef22',
'0x33c106ae5601983b53c751129d1921c17e40b69aa3fdbfaf07b7a0e0750d35e4',
'0x952ffa5de22d99815d9513dd7454949edb2a1cbcf86008f6fa8b169ffe9b4aee',
'0x8f10560a0b5412ca2e0578fb9266f55411f357d52c8fc3b2cad43b9877a559a6',
'0x8e70b93d3c90798df26473a3ad32a86170e8d52023a4044cf1d4c2d645471b14',
'0xdfaacb39891bbbf4509af408239b97a6f5ef715a5c299ba1f3625c20aec4ef8f',
'0xb04e5ee349086985f74b73971ce9dfe76bbed95c84906c5dffd96504e1e5396c',
'0xac506ecb5465659b3a927143f6d724f91d8d9c4bdb2463aee111d9aa869874db',
'0x124b05ec272cecd7538fdafe53b6628d31188ffb6f345139aac3c3c1fd2e470f',
'0xc3be9cbd19304d84cca3d045e06b8db3acd68c304fc9cd4cbffe6d18036cb13f',
'0xfef7bd9f889811e59e4076a0174087135f080177302763019adaf531257e3a87',
'0xa707d1c62d8be699d34cb74804fdd7b4c568b6c1a821066f126c680d4b83e00b',
'0xf6e093070e0389d2e529d60fadb855fdded54976ec50ac709e3a36ceaa64c291'
]
}
```
### Step 6) Claiming the $ybETH on L1
Once the transaction in Step 4 has been finalized on L1, we can claim the withdrawn $ybETH from the Shared Bridge contract by calling its `finalizeWithdrawal` function. The inputs can be found in Step 5,
```
function finalizeWithdrawal(
uint256 _chainId,
uint256 _l2BatchNumber,
uint256 _l2MessageIndex,
uint16 _l2TxNumberInBatch,
bytes calldata _message,
bytes32 calldata _merkleProof
)
```
| Parameters | Comments |
| -------------------- | -------------------------------------------------------------------------------------------------------- |
| `_chainId` | Chain id for Cronos zkEVM, which is `388` |
| `_l2BatchNumber` | The L2 batch number where the withdrawal was processed, obtained in Step 5. |
| `_l2MessageIndex` | The position in the L2 logs Merkle tree of the l2Log that was sent with the message, obtained in Step 5. |
| `_l2TxNumberInBatch` | The L2 transaction number in the batch, in which the log was sent, obtained in Step 5. |
| `_message` | The L2 withdraw data, stored in an L2 -> L1 message, obtained in Step 5. |
| `_merkleProof` | The Merkle Proof, obtained in Step 5. |
Once `finalizeWithdrawal` is completed, the withdrawn amount of $ybETH will go into the receiver's wallet on Ethereum.
We can use `zksync-ethers` package [`isWithdrawalFinalized`](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#iswithdrawalfinalized) call to confirm whether the withdrawal transaction is finalized on the L1 network.
```
isWithdrawalFinalized(withdrawalHash)
```
| Parameters | Comments |
| ---------------- | ------------------------------------------------------------------------------------------ |
| `withdrawalHash` | The transaction hash of the L2 transaction includes the withdrawal transaction from Step 4 |
### Step 7) Approving $ybETH to be spend by ybETH contract
On Ethereum, call `approve` on the $ybETH contract, to approve the contract to spend $ybETH.
### Step 8) Requesting $ETH withdrawal
On Ethereum, call `requestUnbond` to request a unbonding of the staked $ETH.
```
function requestUnbond(
uint256 _shareAmount,
address _receiver
)
```
| Parameters | Comments |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `_shareAmount` | The amount of $ybETH that is to be burned to unbond $ETH |
| `_receiver` | The wallet address on ethereum to receive the receipt NFT. This NFT is needed to withdraw the $ETH once the unbond period has ended |
This will burn $ybETH and mint a receipt NFT - Veno Unstaked ETH (vnoNFT) to the `_receiver` address. The unbonding procress takes 1\~10 days, hold on to the NFT to claim the $ETH once it's ready. Store the tokenId of the received NFT; it is needed to withdraw the $ETH in the next steps.
### Step 9) Approving NFT to be spend by ybETH contract
On Ethereum, call `setApprovalForAll` on the vnoNFT contract, to approve $ybETH to transfer your vnoNFT obtained in Step 8).
```
setApprovalForAll(address operator, bool _approved)
```
| Parameters | Comments |
| ----------- | ----------------------------------- |
| `operator` | $ybETH contract address on Ethereum |
| `_approved` | Set to "True" to grant approval. |
### Step 10) Withdrawing $ETH
On Ethereum, call `unbond`function on the ybETH contract to burn the receipt NFT and receive the underlying unstaked $ETH.
```
function unbond(
uint256 _tokenId,
address _receiver
)
```
| Parameters | Comments |
| ----------- | -------------------------------------------------- |
| `_tokenId` | The tokenId of the receipt NFT, recieved in Step 7 |
| `_receiver` | The address on Ethereum to receive $ETH |
This transaction burns the receipt NFT and sends the unstaked $ETH to the specified receiver.
# vUSD
On this page, you can find the contracts and their interactions involved when bridging to and from Ethereum (L1 - $DAI/$USDC/$USDT) and Cronos zkEVM (L2 - $vUSD ), it includes:
{% hint style="danger" %}
**Notice: Cronos zkEVM is being sunset, please** [**bridge out your assets**](/for-developers/using-zkcro-veth-and-vusd/vusd#l2-greater-than-l1-withdrawing-usddai-from-usdvusd) **before the network is fully decommissioned.**
{% endhint %}
[#l2-greater-than-l1-withdrawing-usddai-from-usdvusd](#l2-greater-than-l1-withdrawing-usddai-from-usdvusd "mention")
## \[L2 -> L1] Withdrawing $DAI from $vUSD
*From Cronos zkEVM mainnet (L2) -> Ethereum mainnet (L1)*
{% hint style="info" %}
For withdrawing $vUSD (Cronos zkEVM Mainnet) and get $DAI (Ethereum Mainnet) , we would need to:
1. \[On Cronos zkEVM] Use $vUSD to redeem $ybUSD;
2. \[On Cronos zkEVM] Bridge $ybUSD to Ethereum;
3. \[On Ethereum] Redeem $ybUSD for $DAI
{% endhint %}
To redeem $vUSD from `Cronos zkEVM mainnet -> Ethereum mainnet`, and withdraw $DAI we would need to interact with the following contracts:
* $vUSD token contract
* Cronos zkEVM: [`0x5b91e29Ae5A71d9052620Acb813d5aC25eC7a4A2`](https://explorer.zkevm.cronos.org/address/0x5b91e29Ae5A71d9052620Acb813d5aC25eC7a4A2)
* `L2Bridge`
* Cronos zkEVM: [0x309429DE3621992Cb0ab8982A448c9Cc5c38405b](https://explorer.zkevm.cronos.org/address/0x309429DE3621992Cb0ab8982A448c9Cc5c38405b)
* zk Chain Shared Bridge
* Ethereum: [0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB](https://etherscan.io/address/0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB)
* $ybUSD token contract
* Ethereum: [0xFA59075DfCE274E028b58BdDFcC3D709960F594a](https://etherscan.io/address/0xFA59075DfCE274E028b58BdDFcC3D709960F594a)
* Cronos zkEVM: [`0xb1Ece5b548766215272BAFCfa36396B06Cd9e4C9`](https://explorer.zkevm.cronos.org/address/0xb1Ece5b548766215272BAFCfa36396B06Cd9e4C9)
### Step 1) Approving $vUSD to be spend by vUSD contract
On Cronos zkEVM, call `approve` on the $vUSD contract to approve $vUSD spend with appropriate amount.
### Step 2) Redeeming $vUSD for $ybUSD
On Cronos zkEVM, call `redeem` on the vUSD contract, to burn $vUSD and redeem $ybUSD
```
function redeem(
address _receiver,
uint256 _vUsdAmount
)
```
| Parameters | Comments |
| ------------- | --------------------------------------------------- |
| `_receiver` | Address to receive $ybUSD on Cronos zkEVM |
| `_vUsdAmount` | Amount of vUSD that will be burned to redeem $ybUSD |
Once done, corresponding $ybUSD will be transfer to the `_reciever` address
### Step 3) Approving $ybUSD to be spend by the L2Bridge
On Cronos zkEVM, call `approve` on the ybUSD contract, to approve L2Bridge contract to spend $ybUSD.
### Step 4) Withdrawing $ybUSD and store withdrawal hash
On Cronos zkEVM, call `withdraw` on the L2Bridge contract
```
function withdraw(
address _l1Receiver,
address _l2Token,
uint256 _amount
)
```
| Parameters | Comments |
| ------------- | --------------------------------------------------------------------------------- |
| `_l1Receiver` | Address on Ethereum to receive the token |
| `_l2Token` | The token to be withdrawn, the Cronos zkEVM contract address $ybUSD in this case. |
| `_amount` | amount of tokens to be withdrawn, note $ybUSD has `18` decimals |
Keep the transaction hash for later use in Step 5. This withdraws $ybUSD from Cronos zkEVM to Ethereum. It takes 24 hours before the withdrawal can be finalized on Ethereum. Store the transaction hash from the withdrawal transaction; it will be needed to finalize the withdrawal.
### Step 5) Gathering information for $ybUSD withdrawal on L1
Extra information for the L2 -> L1 transaction is required for the next step in claiming the $ybUSD. This information can be gathered by [finalizeWithdrawalParams](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#finalizewithdrawalparams), using `zksync-ethers` package
```
finalizeWithdrawalParams(withdrawalHash)
```
This takes the L2 withdrawal hash as parameters and returns the parameters required for finalizing a withdrawal in the next step.
Example outputs
```
{
l1BatchNumber: 18,
l2MessageIndex: 59,
l2TxNumberInBlock: 2919,
message: '0x6c0960f935f448644c86dbda241ecb57f18a15c80f35a066000000000000000000000000000000000000000000000a2a15d09519be000000',
sender: '0x000000000000000000000000000000000000800a',
proof: [
'0x23ff0fb003a6a6e111f87cff02afc8680944c711abbe792f07ab4206e9efb9a3',
'0x09fece9c46307f2a0976a3a9b57873e453cf0f4773c2377dcd19f054166aef22',
'0x33c106ae5601983b53c751129d1921c17e40b69aa3fdbfaf07b7a0e0750d35e4',
'0x952ffa5de22d99815d9513dd7454949edb2a1cbcf86008f6fa8b169ffe9b4aee',
'0x8f10560a0b5412ca2e0578fb9266f55411f357d52c8fc3b2cad43b9877a559a6',
'0x8e70b93d3c90798df26473a3ad32a86170e8d52023a4044cf1d4c2d645471b14',
'0xdfaacb39891bbbf4509af408239b97a6f5ef715a5c299ba1f3625c20aec4ef8f',
'0xb04e5ee349086985f74b73971ce9dfe76bbed95c84906c5dffd96504e1e5396c',
'0xac506ecb5465659b3a927143f6d724f91d8d9c4bdb2463aee111d9aa869874db',
'0x124b05ec272cecd7538fdafe53b6628d31188ffb6f345139aac3c3c1fd2e470f',
'0xc3be9cbd19304d84cca3d045e06b8db3acd68c304fc9cd4cbffe6d18036cb13f',
'0xfef7bd9f889811e59e4076a0174087135f080177302763019adaf531257e3a87',
'0xa707d1c62d8be699d34cb74804fdd7b4c568b6c1a821066f126c680d4b83e00b',
'0xf6e093070e0389d2e529d60fadb855fdded54976ec50ac709e3a36ceaa64c291'
]
}
```
### Step 6) Claiming the $ybUSD on L1
Once the transaction in Step 4 has been finalized, we can claim the withdrawn $ybUSD from the L2Bridge contract by calling its `finalizeWithdrawal` function. The inputs can be found in Step 5,
```
function finalizeWithdrawal(
uint256 _chainId,
uint256 _l2BatchNumber,
uint256 _l2MessageIndex,
uint16 _l2TxNumberInBatch,
bytes calldata _message,
bytes32 calldata _merkleProof
)
```
| Parameters | Comments |
| -------------------- | -------------------------------------------------------------------------------------------------------- |
| `_chainId` | Chain id for Cronos zkEVM, which is `388` |
| `_l2BatchNumber` | The L2 batch number where the withdrawal was processed, obtained in Step 5. |
| `_l2MessageIndex` | The position in the L2 logs Merkle tree of the l2Log that was sent with the message, obtained in Step 5. |
| `_l2TxNumberInBatch` | The L2 transaction number in the batch, in which the log was sent, obtained in Step 5. |
| `_message` | The L2 withdraw data, stored in an L2 -> L1 message, obtained in Step 5. |
| `_merkleProof` | The Merkle Proof, obtained in Step 5. |
Once `finalizeWithdrawal` is completed, the withdrawn amount of $ybUSD will go into the receiver's wallet on Ethereum.
We can use `zksync-ethers` package [`isWithdrawalFinalized`](https://docs.zksync.io/sdk/js/ethers/api/v5/accounts/wallet#iswithdrawalfinalized) call to whether the withdrawal transaction is finalized on the L1 network.
```
isWithdrawalFinalized(withdrawalHash)
```
| Parameters | Comments |
| ---------------- | ------------------------------------------------------------------------------------------ |
| `withdrawalHash` | The transaction hash of the L2 transaction includes the withdrawal transaction from Step 4 |
### Step 7) Approving $ybUSD to be spend by ybUSD contract
On Ethereum, call `approve` on the $ybUSD contract, to approve the contract to spend $ybUSD
### Step 8) Redeem $ybUSD for $DAI
On Ethereum, call `redeem` on the the $ybUSD contract
```
function redeem(
uint256 _amount
)
```
| Parameters | Comments |
| ---------- | ---------------------------------------------- |
| `_amount` | The amount of $ybUSD tokens to redeem for $DAI |
Once `redeem` is completed, the withdrawn amount of $DAI will go into the receiver's wallet on Ethereum.
# Yield rewards
How to claim vETH and vUSD yield rewards accumulated by your project's smart contracts
vETH and vUSD rewards are distributed through rewarder contracts.
Read on to learn how to claim vETH and vUSD from those contracts.
## Step 1. Query Proof for a given address
Call the rewards claim API under \/\.
You need to replace \ with the account address for which you are claiming for, in the URLs listed below:
* For vETH
* [https://token-rewards-api.zkevm.cronos.org/claim/\/0x271602a97027ee1dd03b1e6e5db153eb659a80b1](https://token-rewards-api.zkevm.cronos.org/claim/0x79CFC29830DC4cBcF47807b77Bbb5896a900864c/0x271602a97027ee1dd03b1e6e5db153eb659a80b1)
* For vUSD:
* [https://token-rewards-api.zkevm.cronos.org/claim/\/0x5b91e29ae5a71d9052620acb813d5ac25ec7a4a2](https://token-rewards-api.zkevm.cronos.org/claim//0x5b91e29ae5a71d9052620acb813d5ac25ec7a4a2)
Example response:
Response explained:
* pending\_amount: The amount of the token in wei that the address has earned, but cannot be claimed yet.
* claimable\_amount: The amount of the token in that the address has earned, is ready to claim and has not been claimed yet
* earliest\_expiration\_time: When the first unclaimed rewards will expire
* next\_claimable\_time: When the pending\_amount will become claimable
* claim: the data needed to claim rewards from the rewarder contract
* recipient: The address that will receive the rewards, this is the same as the provided wallet address in the URL.
* total\_earned: the amount that has been tracked in the rewarder contract. The rewarder contract keeps track of the amount that is already claimed.
* total\_expired: the amount that has already been expired.
* merkle\_proof: The merkle proof needed to claim rewards
## Step 2. Claim the rewards using the proof
There are 2 rewarder contracts, one for each token:
* vETHRewarder:
* [0x5F254945A318f7ca93496320767E6b640aB9f730](https://explorer.zkevm.cronos.org/address/0x5f254945a318f7ca93496320767e6b640ab9f730)
* vUSD:
* [0xfcd9ca1968af3274a5e327dbfa7c80a99a0c0f52](https://explorer.zkevm.cronos.org/address/0xfcd9ca1968af3274a5e327dbfa7c80a99a0c0f52)
Once you have obtained all the necessary claim information from the claim API, use the \ account to call the claim method on the rewarder contract for the given token:
{% code overflow="wrap" lineNumbers="true" %}
```
function claim(address _recipient, uint256 _reward, uint256 _expired, bytes32[] calldata _proof)
```
{% endcode %}
\
Parameters explained:
* \_recipient: Recipient that will receive the rewards, should be the same as returned in the claim object by the claim API
* \_reward: the total\_earned as returned by the claim API
* \_expired: the total\_expired as returned by the claim API
* \_proof: the merkle\_proof as returned by the claim API
If the call is successful, the unclaimed rewards are transferred from the rewarder contract to the \_recipient.
Make sure that the \_recipient can access the rewards transferred to them.
## Important note for app developers
If your app is designed in such way that rewards are accumulated by a smart contract address, this smart contract can probably not call the claim function.
In that case, please [contact Cronos Labs](https://crofam.me/contact) for assistance.
# JSON-RPC API Overview
Explore the detailed guide to the Cronos zkEVM JSON-RPC API, providing Ethereum integration and advanced Layer 2 features tailored for developers.
## Overview
Welcome to Cronos zkEVM JSON-RPC API reference documentation. This page provides a comprehensive overview of our API capabilities and key information. We support the standard [Ethereum JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) while also offering Layer 2-specific features to enhance functionality.
To ensure a seamless experience, we impose rate limits on both JSON-RPC and WebSocket APIs. Rate limits will change over time.
### Mainnet
* Network Name: Cronos zkEVM Mainnet
* RPC URL: `https://mainnet.zkevm.cronos.org/`
* Chain ID: `388`
* Currency Symbol: zkCRO
* Block Explorer URL: `https://explorer.zkevm.cronos.org/`
* WebSocket (rate limited): `wss://ws.zkevm.cronos.org`
### Testnet
* Network Name: Cronos zkEVM Testnet
* RPC URL: `https://testnet.zkevm.cronos.org`
* Chain ID: `240`
* Currency Symbol: zkTCRO
* Block Explorer URL: `https://explorer.zkevm.cronos.org/testnet/`
* WebSocket (rate limited): `wss://ws.testnet.zkevm.cronos.org`
### Commercial infrastructure providers
* **Getblock:**
* [Visit Getblock to obtain your API key](https://getblock.io/)
### API Collections
Explore our curated API endpoint collections to meet a range of needs from seamless Ethereum integrations to advanced ZK integrations. Unlock the full potential of Cronos zkEVM to elevate your dApps. Discover, integrate, and innovate with our powerful API offerings.
{% embed url="" fullWidth="false" %}
{% embed url="" fullWidth="false" %}
# ZKs specific JSON-RPC API
Overview of the JSON-RPC API methods specific to Cronos zkEVM, detailing operations and functionalities within the Cronos zkEVM ecosystem.
## Overview
Based on ZK Stack - besides stand Ethereum JSON-RPCs, Cronos zkEVM provides a suite of JSON-RPC API methods designed for seamless interaction with its ecosystem. These methods offer developers the tools needed to integrate their applications with Cronos zkEVM's features, enhancing the capability to perform transactions, query network data, and interact with smart contracts efficiently. This guide builds on the [zkSync Era documentation](https://docs.zksync.io/build/api-reference/zks-rpc), adapting it to the features and requirements of the Cronos zkEVM chain environment.
## ZK Stack specific API Methods
### `zk_estimateFee`
Estimates the fee for a given call request.
#### **Parameters**
**CallRequest** - object
* **from**: DATA, 20 bytes - Sender address. Arbitrary if not provided.
* **to**: DATA, 20 bytes - Recipient address. Required for `eth_call`.
* **gas**: QUANTITY - Gas limit for the transaction. Defaults if not provided.
* **gas\_price**: QUANTITY - Gas price for the transaction. Defaults if not provided.
* **max\_fee\_per\_gas**: QUANTITY - Maximum fee per unit of gas.
* **max\_priority\_fee\_per\_gas**: QUANTITY - Maximum priority fee per unit of gas.
* **value**: QUANTITY - Value transferred in the transaction. None for no transfer.
* **data / input**: DATA - Data sent with the transaction. Empty if not provided.
* **nonce**: DATA, 32 bytes - Transaction nonce.
* **transaction\_type**: QUANTITY, 8 bytes - Type of the transaction.
* **access\_list**: AccessList - EIP-2930 access list.
* **customData**: OBJECT - Extra parameters for EIP712 transactions, like `paymasterParams` or `customSignature`.
#### **Returns**
The method returns an object containing the estimated gas and fee details for the given call request.
* **gas\_limit**: QUANTITY, 32 bytes - The maximum amount of gas that can be used.
* **max\_fee\_per\_gas**: QUANTITY, 32 bytes - The maximum fee per unit of gas that the sender is willing to pay.
* **max\_priority\_fee\_per\_gas**: QUANTITY, 32 bytes - The maximum priority fee per unit of gas to incentivize miners.
* **gas\_per\_pubdata\_limit**: QUANTITY, 32 bytes - The gas limit per unit of public data.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "zks_estimateFee",
"params": [
{
"from": "0x1111111111111111111111111111111111111111",
"to": "0x2222222222222222222222222222222222222222",
"data": "0xffffffff"
}
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"gas_limit": "0x2301d",
"max_fee_per_gas": "0x12309ce5400",
"max_priority_fee_per_gas": "0x0",
"gas_per_pubdata_limit": "0x0"
},
"id": 2
}
```
***
### `zks_estimateGasL1ToL2`
Estimates the gas required for an L1 to L2 transaction.
#### **Parameters**
**CallRequest** - object
* **from**: DATA, 20 bytes - Sender address. Arbitrary if not provided.
* **to**: DATA, 20 bytes - Recipient address. Required for `eth_call`.
* **gas**: QUANTITY - Gas limit for the transaction. Defaults if not provided.
* **gas\_price**: QUANTITY - Gas price for the transaction. Defaults if not provided.
* **max\_fee\_per\_gas**: QUANTITY - Maximum fee per unit of gas.
* **max\_priority\_fee\_per\_gas**: QUANTITY - Maximum priority fee per unit of gas.
* **value**: QUANTITY - Value transferred in the transaction. None for no transfer.
* **data / input**: DATA - Data sent with the transaction. Empty if not provided.
* **nonce**: DATA, 32 bytes - Transaction nonce.
* **transaction\_type**: QUANTITY, 8 bytes - Type of the transaction.
* **access\_list**: AccessList - EIP-2930 access list.
* **customData**: OBJECT - Extra parameters for EIP712 transactions, like `paymasterParams` or `customSignature`.
#### **Returns**
**QUANTITY, 32 bytes** - The estimated gas amount in hexadecimal format, representing the number of gas units required.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "zks_estimateGasL1ToL2",
"params": [
{
"from": "0x1111111111111111111111111111111111111111",
"to": "0x2222222222222222222222222222222222222222",
"data": "0xffffffff"
}
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x5b7d40",
"id": 2
}
```
***
### `zks_getBridgehubContract`
Retrieves the bridge hub contract address.
#### **Parameters**
None
#### **Returns**
**DATA, 20 bytes** - a single string value representing the bridge hub contract address.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getBridgehubContract",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x303a465b659cbb0ab36ee643ea362c509eeb5213",
"id": 1
}
```
***
### `zks_getMainContract`
Retrieves the main contract address.
#### **Parameters**
None
#### **Returns**
**DATA, 20 bytes** - address of the main contract.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getMainContract",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x7b2da4e77bae0e0d23c53c3be6650497d0576cfc",
"id": 1
}
```
***
### `zks_getTestnetPaymaster`
Retrieves the testnet paymaster address, specifically for interactions within the Cronos zkEVM Testnet environment. \
**Note: This method is only applicable for Cronos zkEVM Testnet.**
#### **Parameters**
None
#### **Returns**
**DATA, 20 bytes** - address of the testnet paymaster.
#### **Example Request**
```bash
curl --request POST \
--url https://testnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getTestnetPaymaster",
"params": []
}'
```
[**Example Response**](https://docs.zksync.io/build/api-reference/zks-rpc#example-response-4)
```bash
{
"jsonrpc": "2.0",
"result": "0x123a22806120ad451b98c49d06f2c96bbee91e36",
"id": 1
}
```
***
### `zks_getBridgeContracts`
Retrieves the addresses of canonical bridge contracts for Cronos zkEVM.
#### **Parameters**
None
#### **Returns**
Object containing the addresses of bridge contracts.
* **l1Erc20DefaultBridge**: DATA, 20 bytes - address of the default ERC-20 bridge on Layer 1.
* **l2Erc20DefaultBridge**: DATA, 20 bytes - address of the default ERC-20 bridge on Layer 2.
* **l1WethBridge**: DATA, 20 bytes - address of the Wrapped Ethereum (WETH) bridge on Layer 1.
* **l2WethBridge**: DATA, 20 bytes - address of the Wrapped Ethereum (WETH) bridge on Layer 2.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getBridgeContracts",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"l1SharedDefaultBridge": "0xd7f9f54194c633f36ccd5f3da84ad4a1c38cb2cb",
"l2SharedDefaultBridge": "0x309429de3621992cb0ab8982a448c9cc5c38405b",
"l1Erc20DefaultBridge": "0x57891966931eb4bb6fb81430e6ce0a03aabde063",
"l2Erc20DefaultBridge": "0x309429de3621992cb0ab8982a448c9cc5c38405b",
"l1WethBridge": "0x0000000000000000000000000000000000000000",
"l2WethBridge": "0x0000000000000000000000000000000000000000"
},
"id": 1
}
```
***
### `zks_L1ChainId`
Retrieves the L1 chain ID.
#### **Parameters**
None
#### **Returns**
**QUANTITY, 8 bytes** - The hexadecimal representation of the L1 chain ID.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_L1ChainId",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x1",
"id": 1
}
```
***
### `zks_getBaseTokenL1Address`
Retrieves the L1 base token address.
#### **Parameters**
None
#### **Returns**
**DATA, 20 bytes** - Layer 1 Ethereum address of base token.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getBaseTokenL1Address",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x28ff2e4dd1b58efeb0fc138602a28d5ae81e44e2",
"id": 1
}
```
***
### `zks_getConfirmedTokens`
Lists confirmed tokens. **Confirmed** in the method name means any token bridged to Cronos zkEVM via the official bridge.
The tokens are returned in alphabetical order by their symbol. This means the token id is its position in an alphabetically sorted array of tokens.
#### **Parameters**
**uint32** - token id from which to start.
**uint8** - maximum number of tokens to list.
#### **Returns**
**Array** of token objects, each containing details about a specific confirmed token.
* **l1Address**: DATA, 20 bytes - Layer 1 Ethereum address of the token.
* **l2Address**: DATA, 20 bytes - Layer 2 Cronos zkEVM address of the token.
* **name**: String - name of the token.
* **symbol**: String - symbol of the token.
* **decimals**: uint8 - number of decimals the token uses.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org/ \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getConfirmedTokens",
"params": [0,1]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{
"l1Address": "0x0000000000000000000000000000000000000000",
"l2Address": "0x0000000000000000000000000000000000000000",
"name": "Ether",
"symbol": "ETH",
"decimals": 18
}
],
"id": 1
}
```
***
### `zks_getAllAccountBalances`
Gets all account balances for a given address.
#### **Parameters**
**DATA, 20 bytes** - account address.
#### **Returns**
The method returns an object with token addresses as keys and their corresponding balances as values. Each key-value pair represents the balance of a specific token held by the account.
* **\**: QUANTITY, 32 bytes - The token address is the key, and its value is the balance of that token held by the account, represented in the smallest unit of the token (e.g., wei for ETH).
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getAllAccountBalances",
"params": ["0x271602a97027ee1dd03b1e6e5db153eb659a80b1"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"0xf226a595b83056ff3d26b827e3d5b0896e4392a9": "0x55d166a12174488855"
},
"id": 1
}
```
***
### `zks_getL2ToL1MsgProof`
Retrieves the proof for an L2 to L1 message.
#### **Parameters**
**uint32** - L2 block number.
**DATA, 20 bytes** - sender's address.
**DATA, 32 bytes** - message hash.
**number** - Optional. The log position in L2.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getL2ToL1MsgProof",
"params": []
}'
```
#### **Example Response**
```
...
```
***
### `zks_getL2ToL1LogProof`
Retrieves the log proof for an L2 to L1 transaction.
#### **Parameters**
**DATA, 32 bytes** - transaction hash.
**integer** - Optional. Index of the log.
#### **Returns**
* **proof**: Array of DATA, 32 bytes - array of strings, each representing a piece of the proof for the specified log.
* **id**: integer - identifier of the log within the transaction.
* **root**: DATA, 32 bytes - root hash of the proof, anchoring it to a specific state in the blockchain.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getL2ToL1LogProof",
"params": [
"0xdba49ca01eba2281556896d8ebb9a3db846bc852afe0113916d4f78f2f658946"
]
}'
```
**Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"proof": [
"0xaa6de2d561e4583f7f2d8dd0b5df6cbff96b689b435d40c515f90e1b2a3a50a9",
"0x93ea63c2f255ee08ff74d63fc442b1a6a6797dff3ce863520255216404918ff9",
"0xb7188e225c78aaf9002f8dd825e96389504324dc4b6ecf3ded35329ee7899d52",
"0x8e13cf0dfcb9649dc34f0095941da419143c7e6df7fcc31cbcc90b413efdacd2",
"0x8a2be504f2c242fac995e2e46caa09ba1849453e8ae031a6d51ecb76f43fe849",
"0x8639d3c7e2aaaa4b6795859be623182e30201c6ee0fb71b6b8b42417cbb54ea6",
"0x574c090e614f11a2dbc3041bc0edf84763bceb8d2637f1d9d1b76483e98ec921",
"0x553479372351c5f3648bd1289f38fe73e82963835bfa086665f14cf65288c775",
"0xac506ecb5465659b3a927143f6d724f91d8d9c4bdb2463aee111d9aa869874db",
"0x124b05ec272cecd7538fdafe53b6628d31188ffb6f345139aac3c3c1fd2e470f",
"0xc3be9cbd19304d84cca3d045e06b8db3acd68c304fc9cd4cbffe6d18036cb13f",
"0xfef7bd9f889811e59e4076a0174087135f080177302763019adaf531257e3a87",
"0xa707d1c62d8be699d34cb74804fdd7b4c568b6c1a821066f126c680d4b83e00b",
"0xf6e093070e0389d2e529d60fadb855fdded54976ec50ac709e3a36ceaa64c291"
],
"id": 60,
"root": "0xbe63c30b864e0c763b37ea274a479e132c422f0e938ca50d20fb01be2fe8e620"
},
"id": 1
}
```
***
### `zks_L1BatchNumber`
Retrieves the current L1 batch number.
#### **Parameters**
None
#### **Returns**
**QUANTITY, 8 bytes** - hexadecimal representation of the current L1 batch number.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_L1BatchNumber",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x20",
"id": 1
}
```
***
### `zks_getBlockDetails`
Retrieves details for a given block.
* `committed`: The batch is closed and the state transition it creates exists on layer 1.
* `proven`: The batch proof has been created, submitted, and accepted on layer 1.
* `executed`: The batch state transition has been executed on L1; meaning the root state has been updated.
#### **Parameters**
The method requires a single parameter to specify the block whose details are to be retrieved.
**uint32** - number of the block.
#### **Returns**
Object containing detailed information about the specified block.
* **number**: uint32 - number of the block.
* **l1BatchNumber**: uint32 - corresponding L1 batch number.
* **timestamp**: uint32 - Unix timestamp when the block was committed.
* **l1TxCount**: uint32 - number of L1 transactions included in the block.
* **l2TxCount**: uint32 - number of L2 transactions included in the block.
* **rootHash**: DATA, 32 bytes - root hash of the block's state after execution.
* **status**: String - current status of the block (e.g., verified, executed).
* **commitTxHash**: DATA, 32 bytes - transaction hash of the commit operation on L1.
* **committedAt**: String - timestamp when the block was committed on L1.
* **proveTxHash**: DATA, 32 bytes - transaction hash of the proof submission on L1.
* **provenAt**: String - timestamp when the proof was submitted on L1.
* **executeTxHash**: DATA, 32 bytes - transaction hash of the execution on L1.
* **executedAt**: String - timestamp when the block execution was completed on L1.
* **l1GasPrice**: uint64 - L1 gas price at the time of the block's execution.
* **l2FairGasPrice**: uint64 - fair gas price on L2 at the time of the block's execution.
* **baseSystemContractsHashes**: Object - A collection of hashes for the base system contracts.
* **operatorAddress**: DATA, 20 bytes - address of the operator who committed the block.
* **protocolVersion**: String - version of the protocol the block was committed under.
#### **Example Request**
```
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getBlockDetails",
"params": [91513]
}'
```
#### **Example Response**
```bash
{
"jsonrpc":"2.0",
"result":{
"number":91513,
"l1BatchNumber":33,
"timestamp":1724195097,
"l1TxCount":0,
"l2TxCount":1,
"rootHash":"0x7af242a8bdbe28f5b21816b741aeb4cf5f6193db4be63139d27530c226bddaf3","status":"sealed",
"commitTxHash":null,
"committedAt":null,
"proveTxHash":null,
"provenAt":null,
"executeTxHash":null,
"executedAt":null,
"l1GasPrice":1768937160,
"l2FairGasPrice":2500000000000,
"fairPubdataPrice":0,
"baseSystemContractsHashes":{
"bootloader":"0x010008e742608b21bf7eb23c1a9d0602047e3618b464c9b59c0fba3b3d7ab66e",
"default_aa":"0x01000563374c277a2c1e34659a2a1e87371bb6d852ce142022d497bfb50b9e32"
},
"operatorAddress":"0xa34e3001b04ac693daa6d915060e9bf0b97baf47",
"protocolVersion":"Version24"
},
"id":1
}
```
***
### `zks_getTransactionDetails`
Retrieves details for a given transaction.
#### **Parameters**
**DATA, 32 bytes** - hash of the transaction.
#### **Returns**
Object containing detailed information about the specified transaction.
* **isL1Originated**: Boolean - Indicates whether the transaction originated on Layer 1.
* **status**: String - current status of the transaction (e.g., verified).
* **fee**: QUANTITY, 32 bytes - transaction fee.
* **gasPerPubdata**: QUANTITY, 32 bytes - gas amount per unit of public data for this transaction.
* **initiatorAddress**: DATA, 20 bytes - address of the transaction initiator.
* **receivedAt**: String - timestamp when the transaction was received.
* **ethCommitTxHash**: DATA, 32 bytes - transaction hash of the commit operation.
* **ethProveTxHash**: DATA, 32 bytes - transaction hash of the proof submission.
* **ethExecuteTxHash**: DATA, 32 bytes - transaction hash of the execution.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getTransactionDetails",
"params": [
"0xdba49ca01eba2281556896d8ebb9a3db846bc852afe0113916d4f78f2f658946"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"isL1Originated": true,
"status": "verified",
"fee": "0x0",
"gasPerPubdata": "0x320",
"initiatorAddress": "0x09a2422550281f058db80f224dcfda975cd3aff5",
"receivedAt": "2023-03-03T23:52:24.169Z",
"ethCommitTxHash": "0x90ac50e40a3b7f090d780e82a4d46615cd6858790ed9c1c1b5069aae68bb1025",
"ethProveTxHash": "0x5243af1324bff0b4dfef755d1a2f655e8ada1e6f3cea3d7fcd522cd6ddb446d8",
"ethExecuteTxHash": "0x31dcab2df135044d8f9b1d576636169de3ff36475a897e32228656d0e5982450"
},
"id": 1
}
```
***
### `zks_getRawBlockTransactions`
Lists transactions in a block without processing them.
#### **Parameters**
**uint32** - number of the block.
#### **Returns**
Array of objects, each representing a raw transaction within the specified block. Each transaction object includes common data, execution details, a timestamp, and the raw transaction bytes.
* **common\_data**: Object - general information about the L2 transaction, such as nonce, fees, initiator address, signature, transaction type, input data, and paymaster parameters.
* **execute**: Object - Details regarding the execution of the transaction, including the contract address, calldata, value, and any factory dependencies.
* **received\_timestamp\_ms**: Number - timestamp when the transaction was received, in milliseconds.
* **raw\_bytes**: DATA, 32 bytes - raw bytes of the transaction as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getRawBlockTransactions",
"params": [99083]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{
"common_data": {
"L2": {
"nonce": 41,
"fee": {
"gas_limit": "0x729b1",
"max_fee_per_gas": "0x2632e314a00",
"max_priority_fee_per_gas": "0x2632e314a00",
"gas_per_pubdata_limit": "0xc350"
},
"initiatorAddress": "0x1791e7a4378d44a5f0aa43095f828c7ef3f88196",
"signature": [52,145,129,230,119,80,115,128,182,4,234,186...],
"transactionType": "LegacyTransaction",
"input": {
"hash": "0x5bb47835a196291545ef31c0dccd03112650db893a18fc63bfa2124ca1fb5b8b",
"data": [249,2,46,41,134,2,99,46,49,74,0,131,7...]
},
"paymasterParams": {
"paymaster": "0x0000000000000000000000000000000000000000",
"paymasterInput": []
}
}
},
"execute": {
"contractAddress": "0x4e792b8c9bcb9e200c3713810c4d6ea8c4230e7c",
"calldata": "0x5ae401dc000000000000000000000000000000000000000...",
"value": "0x0",
"factoryDeps": null
},
"received_timestamp_ms": 1724268831091,
"raw_bytes": "0xf9022e298602632e314a00830729.."
}
// Additional transactions
],
"id": 1
}
```
***
### `zks_getL1BatchDetails`
Retrieves details for a given L1 batch.
#### **Parameters**
**uint32** - L1 batch number.
#### **Returns**
Object of details for L1 batch.
* **number**: uint32 - L1 batch number.
* **timestamp**: uint64 - Unix timestamp when the batch was processed.
* **l1TxCount**: uint32 - number of L1 transactions included in the batch.
* **l2TxCount**: uint32 - number of L2 transactions associated with this batch.
* **rootHash**: DATA, 32 bytes - root hash of the state after processing the batch.
* **status**: String - current status of the batch (e.g., verified).
* **commitTxHash**: DATA, 32 bytes - Ethereum transaction hash for the commit operation.
* **committedAt**: String - timestamp when the batch was committed on Ethereum.
* **proveTxHash**: DATA, 32 bytes - Ethereum transaction hash for the proof submission.
* **provenAt**: String - timestamp when the proof was submitted.
* **executeTxHash**: DATA, 32 bytes - Ethereum transaction hash for the execution.
* **executedAt**: String - timestamp when the execution was completed.
* **l1GasPrice**: uint64 - gas price on L1 at the time of batch processing.
* **l2FairGasPrice**: uint64 - fair gas price on L2 at the time of batch processing.
* **baseSystemContractsHashes**: Object - Hashes of the base system contracts involved in the batch.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getL1BatchDetails",
"params": [28]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"baseSystemContractsHashes": {
"bootloader": "0x0100038581be3d0e201b3cc45d151ef5cc59eb3a0f146ad44f0f72abf00b594c",
"default_aa": "0x0100038dc66b69be75ec31653c64cb931678299b9b659472772b2550b703f41c"
},
"commitTxHash": "0x0dcaca926bdd167490dba5a3fd5a9827ee91be985b09d69d7ed1e7bd3897604f",
"committedAt": "2023-02-17T02:13:38.908944Z",
"executeTxHash": "0x156e7ea92b74b4fb73746bcc1b4d64189fa4048a5139793ace91f1c0d01393ca",
"executedAt": "2023-02-17T05:13:17.762256Z",
"fairPubdataPrice": null,
"l1GasPrice": 47683924811,
"l1TxCount": 1,
"l2FairGasPrice": 250000000,
"l2TxCount": 1,
"number": 28,
"proveTxHash": "0x83dcb7d938bc2e47e5dc46c2bffc5211679af1af7d83386148229e6d84ae5e99",
"provenAt": "2023-02-17T02:13:38.950091Z",
"rootHash": "0xf7876070f823962eb7ca7bd5496f85daf7a13481db2ce47d78baf1e04375038a",
"status": "verified",
"timestamp": 1676592735
},
"id": 1
}
```
***
### `zks_getL1BatchBlockRange`
Returns the range of blocks contained within a batch given by the batch number.
The range is provided by the beginning and end block numbers in hexadecimal.
#### **Parameters**
**L1BatchNumber** - the layer 1 batch number.
#### **Returns**
**Array of Hex Strings** - array containing the beginning and end block numbers in hexadecimal.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getL1BatchBlockRange",
"params": [28]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
"0x105ab",
"0x118ac"
],
"id": 1
}
```
***
### `zks_getL1GasPrice`
Retrieves the current L1 gas price.
#### **Parameters**
None
#### **Returns**
**QUANTITY, 8 bytes** - current L1 gas price in hexadecimal format, representing the amount of wei per unit of gas.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getL1GasPrice",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x65f9e7f7",
"id": 1
}
```
***
### `zks_getFeeParams`
Retrieves the current fee parameters.
#### **Parameters**
None
#### **Returns**
Object
* **V2**: Object - fee parameter configuration for the current version of the Cronos zkEVM protocol.
* **config**: Object - settings related to transaction fee computation.
* **minimal\_l2\_gas\_price**: uint64 - minimal gas price on L2.
* **compute\_overhead\_part**: float64 - compute overhead part in fee calculation.
* **pubdata\_overhead\_part**: float64 - public data overhead part in fee calculation.
* **batch\_overhead\_l1\_gas**: uint64 - overhead in L1 gas for a batch of transactions.
* **max\_gas\_per\_batch**: uint64 - maximum gas allowed per batch.
* **max\_pubdata\_per\_batch**: uint64 - maximum amount of public data allowed per batch.
* **l1\_gas\_price**: uint64 - current L1 gas price.
* **l1\_pubdata\_price**: uint64 - price of storing public data on L1.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getFeeParams",
"params": ["0x53fb3c6e14ff461f30382f5dc8f648286559cd1f58e75e12ce51db33da7bc6e0"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"V2": {
"config": {
"minimal_l2_gas_price": 1250000000000,
"compute_overhead_part": 0.0,
"pubdata_overhead_part": 0.001,
"batch_overhead_l1_gas": 800000,
"max_gas_per_batch": 200000000,
"max_pubdata_per_batch": 500000
},
"l1_gas_price": 1691140420,
"l1_pubdata_price": 0,
"conversion_ratio": {
"numerator": 1,
"denominator": 1
}
}
},
"id": 1
}
```
***
### `zks_getProtocolVersion`
Gets the protocol version.
#### **Parameter**
**uint16** - Optional. Specific version ID.
#### **Returns**
Object
* **version\_id**: uint16 - protocol version ID.
* **timestamp**: uint64 - Unix timestamp of the version's activation.
* **verification\_keys\_hashes**: Object - Contains the hashes of various verification keys used in the protocol.
* **base\_system\_contracts**: Object - Hashes of the base system contracts, like the bootloader and default account abstraction (AA).
* **l2\_system\_upgrade\_tx\_hash**: DATA, 32 bytes - hash of the transaction used for the system upgrade, if any.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "zks_getProtocolVersion",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"version_id": 24,
"minorVersion": 24,
"timestamp": 0,
"verification_keys_hashes": {
"params": {
"recursion_node_level_vk_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"recursion_leaf_level_vk_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"recursion_circuits_set_vks_hash": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"recursion_scheduler_level_vk_hash": "0x0000000000000000000000000000000000000000000000000000000000000000"
},
"base_system_contracts": {
"bootloader": "0x010008e742608b21bf7eb23c1a9d0602047e3618b464c9b59c0fba3b3d7ab66e",
"default_aa": "0x01000563374c277a2c1e34659a2a1e87371bb6d852ce142022d497bfb50b9e32"
},
"bootloaderCodeHash": "0x010008e742608b21bf7eb23c1a9d0602047e3618b464c9b59c0fba3b3d7ab66e",
"defaultAccountCodeHash": "0x01000563374c277a2c1e34659a2a1e87371bb6d852ce142022d497bfb50b9e32",
"l2_system_upgrade_tx_hash": "0xd05d194051ec55ccc2207d19499a7959c87327586d85b0914684b0f3319cbeff",
"l2SystemUpgradeTxHash": "0xd05d194051ec55ccc2207d19499a7959c87327586d85b0914684b0f3319cbeff"
},
"id": 1
}
```
***
# Ethereum JSON-RPC API
JSON-RPC API methods for the eth\_ namespace for Cronos zkEVM.
Cronos zkEVM supports the standard [Ethereum JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/).
### Important Differences for Developers
When working with Cronos zkEVM, there are specific differences you should be aware of:
1. **Block Data Retrieval Methods**:
* Methods that return data about a block, such as `eth_getBlockByHash`, `eth_getBlockByNumber`, and Geth’s pubsub API `eth_subscribe` with the `newHeads` parameter, do not provide the actual `receiptsRoot`, `transactionsRoot`, and `stateRoot` values.
* Instead, these fields contain zero values because Cronos zkEVM’s L2 blocks do not include the concept of a state root; only L1 batches have this concept.
2. **Unsupported Method**:
* The method `eth_sendTransaction` is intentionally not supported in Cronos zkEVM.
### `eth_chainId`
Gets the current chain ID.
#### **Parameters**
None
#### **Returns**
**QUANTITY** - hexadecimal representation of the current blockchain network's chain ID.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_chainId",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x184",
"id": 1
}
```
***
### `eth_call`
Executes a new message call immediately without creating a transaction on the block chain.
#### **Parameters**
**CallRequest** - object
* **from**: DATA, 20 bytes - Sender address. Arbitrary if not provided.
* **to**: DATA, 20 bytes - Recipient address. Required for `eth_call`.
* **gas**: QUANTITY - Gas limit for the transaction. Defaults if not provided.
* **gas\_price**: QUANTITY - Gas price for the transaction. Defaults if not provided.
* **max\_fee\_per\_gas**: QUANTITY - Maximum fee per unit of gas.
* **max\_priority\_fee\_per\_gas**: QUANTITY - Maximum priority fee per unit of gas.
* **value**: QUANTITY - Value transferred in the transaction. None for no transfer.
* **data / input**: DATA - Data sent with the transaction. Empty if not provided.
* **nonce**: DATA, 32 bytes - Transaction nonce.
* **transaction\_type**: QUANTITY, 8 bytes - Type of the transaction.
* **access\_list**: AccessList - EIP-2930 access list.
* **customData**: OBJECT - Extra parameters for EIP712 transactions, like `paymasterParams` or `customSignature`.
**BlockIdVariant** - Optional.
#### **Returns**
**DATA** - The data returned by the smart contract function, encoded in hexadecimal format.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_call",
"params": [
{
"to": "0xc94770007dda54cF92009BFF0dE90c06F603a09f"
},
"latest"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x",
"id": 1
}
```
***
### `eth_estimateGas`
Estimates the amount of gas needed to execute a call. The `from` field cannot be a smart contract that is not a `SmartAccount` if so an exception is hit.
#### **Parameters**
**CallRequest** - object
* **from**: DATA, 20 bytes - Sender address. Arbitrary if not provided.
* **to**: DATA, 20 bytes - Recipient address. Required for `eth_call`.
* **gas**: QUANTITY - Gas limit for the transaction. Defaults if not provided.
* **gas\_price**: QUANTITY - Gas price for the transaction. Defaults if not provided.
* **max\_fee\_per\_gas**: QUANTITY - Maximum fee per unit of gas.
* **max\_priority\_fee\_per\_gas**: QUANTITY - Maximum priority fee per unit of gas.
* **value**: QUANTITY - Value transferred in the transaction. None for no transfer.
* **data / input**: DATA - Data sent with the transaction. Empty if not provided.
* **nonce**: DATA, 32 bytes - Transaction nonce.
* **transaction\_type**: QUANTITY, 8 bytes - Type of the transaction.
* **access\_list**: AccessList - EIP-2930 access list.
* **customData**: OBJECT - Extra parameters for EIP712 transactions, like `paymasterParams` or `customSignature`.
**uint32** - Optional block number.
#### **Returns**
**QUANTITY** - The estimated amount of gas in hexadecimal format.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_estimateGas",
"params": [
{
"from" :"0xf29b18cb786a045178c8ee9131e0ff69567bdd2b",
"to": "0x415254a14a3369884c2ea93dae8cd92a014a8603"
}
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x2930e",
"id": 1
}
```
***
### `eth_gasPrice`
Retrieves the current average gas price in the network, expressed in `gwei`. This value provides an estimate of how much each unit of gas would cost for transactions on the network at the time of the query. It's particularly useful for dynamically adjusting transaction fees to current network conditions.
#### **Parameters**
None
#### **Returns**
**QUANTITY** - The current average gas price on the network, represented in `gwei` and encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_gasPrice",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x12309ce5400",
"id": 1
}
```
***
### `eth_newFilter`
Initiates a new filter for listening to specific events emitted by smart contracts or other blockchain actions. This feature enables applications to react to events and updates in real-time by setting criteria for the events they're interested in.
{% hint style="warning" %}
**Remark**
Developers may encounter the `Filter Not Found` error when using filter-related methods due to the system failing to locate the specified filter ID. \
Common causes include:
* Filters expire after a period of inactivity (e.g., 5 minutes) and are not permanent.
* If the chain node is restarted, the filters created before the restart might be lost, leading to errors in subsequent queries.
* Filters can be manually removed using specific methods like \`\`. If a filter is uninstalled and then queried, it will naturally result in the error.
* Some nodes might prune or remove older states including filters. This can also lead to an error when querying a pruned filter.
Identifying the cause of the this error allow developers to take corrective actions such as recreating filters, adjusting filter lifespans, or ensuring node stability.
{% endhint %}
#### **Parameters**
**Filter** - Object containing various fields to specify the criteria for filtering events
* **fromBlock**: QUANTITY | TAG - The starting block (inclusive) to filter events from. Default is `"latest"`.
* **toBlock**: QUANTITY | TAG - The ending block (inclusive) to filter events up to. Default is `"latest"`.
* **address**: DATA | Array, 20 bytes - The contract address(s) to filter events from.
* **topics**: Array of Data - An array of topics to filter events by. Each element can be a topic to match, or `null` to match any topic in that position.
* **blockHash**: DATA, 32 bytes - Filters events from a specific block hash, only allowing a single block to be specified. Note that using `blockHash` will override any specified `fromBlock` and `toBlock` fields.
#### **Returns**
**QUANTITY** - unique identifier of the newly created filter, encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_newFilter",
"params": [
{
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
]
}
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x612772db7168e9e1b3af62478e9433d06e05e9861289cace5043644842456ae7",
"id": 1
}
```
***
### `eth_newBlockFilter`
Creates a filter to notify when a new block arrives.
#### **Parameters**
None
#### **Returns**
**QUANTITY** - unique identifier of the newly created block filter, encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_newBlockFilter",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x3f65fa831975663ab121046eca6013ed8eb007c821fa1445998648f3a5d2fee6",
"id": 1
}
```
***
### `eth_uninstallFilter`
Removes a filter that was previously created using `eth_newFilter`, `eth_newBlockFilter`, or `eth_newPendingTransactionFilter`. This method is used to stop receiving updates for the specified filter and to clean up resources associated with it on the node.
#### **Parameters**
**QUANTITY, 32 bytes** - unique identifier of the filter to be removed, originally returned by the filter creation method.
#### **Returns**
**Boolean** - `true` if the filter was successfully uninstalled; otherwise, `false`.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_uninstallFilter",
"params": ["0xb825a38f6350ff4d75d806e6f83a42a31d39fc7ef4fde02b404e8edeef6799b"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": false,
"id": 1
}
```
### `eth_newPendingTransactionFilter`
Sets up a new filter to provide notifications for transactions that enter the pending state, which means they are broadcast to the network but not yet included in a block. This filter is useful for tracking transactions that are awaiting confirmation.
#### **Parameters**
None
#### **Returns**
**QUANTITY, 32 bytes** - unique identifier of the new filter for pending transactions, encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_newPendingTransactionFilter",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0xed2778f35e03a63859f9c7812452bf8ab335afa67299b4c37dcbabea0ce09cdf",
"id": 1
}
```
***
### `eth_getLogs`
Retrieves the logs matching a filter object.
#### **Parameters**
**Filter** - Object containing various fields to specify the criteria for filtering events
* **fromBlock**: QUANTITY | TAG - The starting block (inclusive) to filter events from. Default is `"latest"`.
* **toBlock**: QUANTITY | TAG - The ending block (inclusive) to filter events up to. Default is `"latest"`.
* **address**: DATA | Array, 20 bytes - The contract address(s) to filter events from.
* **topics**: Array of Data - An array of topics to filter events by. Each element can be a topic to match, or `null` to match any topic in that position.
* **blockHash**: DATA, 32 bytes - Filters events from a specific block hash, only allowing a single block to be specified. Note that using `blockHash` will override any specified `fromBlock` and `toBlock` fields.
#### **Returns**
Array of log objects that match the filter criteria. Each log object contains detailed information about a single log entry.
* **address**: Data, 20 bytes - address of the contract that generated the log.
* **topics**: Array of Data - Topics are indexed event parameters stored in the log.
* **data**: DATA - The data contained in the log.
* **blockHash**: DATA, 32 bytes - Hash of the block where this log was in.
* **blockNumber**: QUANTITY - block number where this log was in.
* **transactionHash**: DATA, 32 bytes - Hash of the transaction that generated this log.
* **transactionIndex**: QUANTITY - Integer of the transaction's index position in the block.
* **logIndex**: QUANTITY - Integer of the log's index position in the block.
* **transactionIndex**: QUANTITY - Integer of the log's index position in the transaction.
* **logType**: String - The type of log (can be `null`).
* **removed**: Boolean - Indicates if the log was removed due to a chain reorganization.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getLogs",
"params": [
{
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
],
"fromBlock": "latest"
}
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x000000000000000000000000f4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a",
"0x0000000000000000000000000000000000000000000000000000000000008001"
],
"data": "0x0000000000000000000000000000000000000000000000001bc38f19b1a58000",
"blockHash": "0x5675b3b9966bc3bc3dd4d275b913dabae3e1a009298caf9ea22fadcdff37a202",
"blockNumber": "0x24bfd",
"l1BatchNumber": null,
"transactionHash": "0xb313c78e59fe3807fe6245ff293435c57887b560779061309f83db576888ccf2",
"transactionIndex": "0x0",
"logIndex": "0x0",
"transactionLogIndex": "0x0",
"logType": null,
"removed": false,
"blockTimestamp": "0x66ceca21"
},
...
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000008001",
"0x000000000000000000000000f4b5e4e82f425154dc7c2eeaac7cbb3c0b70c43a"
],
"data": "0x0000000000000000000000000000000000000000000000000ab59a3d7a554800",
"blockHash": "0x5675b3b9966bc3bc3dd4d275b913dabae3e1a009298caf9ea22fadcdff37a202",
"blockNumber": "0x24bfd",
"l1BatchNumber": null,
"transactionHash": "0xb313c78e59fe3807fe6245ff293435c57887b560779061309f83db576888ccf2",
"transactionIndex": "0x0",
"logIndex": "0x5",
"transactionLogIndex": "0x5",
"logType": null,
"removed": false,
"blockTimestamp": "0x66ceca21"
}
],
"id": 1
}
```
***
### `eth_getFilterLogs`
Retrieves the logs for a filter created with `eth_newFilter`.
#### **Parameters**
**QUANTITY, 32 bytes** - the filter id.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getFilterLogs",
"params": [
"0x612772db7168e9e1b3af62478e9433d06e05e9861289cace5043644842456ae7"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000004c9bd0ce4ed1e0efbaa65dce1e2928841a4406ce",
"0x0000000000000000000000000000000000000000000000000000000000008001"
],
"data": "0x00000000000000000000000000000000000000000000000011e4e33e49c61400",
"blockHash": "0x8082e072b41af3ea86555e1b6f7ce05532c4b72bf614cd55a65109830a0ea829",
"blockNumber": "0x26488",
"l1BatchNumber": null,
"transactionHash": "0x442b2272e5b18af5cad6a747e432f4942455947a7ebf997c0c335d952d8e5458",
"transactionIndex": "0x0",
"logIndex": "0x0",
"transactionLogIndex": "0x0",
"logType": null,
"removed": false,
"blockTimestamp": "0x66cf747c"
},
...
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000008001",
"0x0000000000000000000000004c9bd0ce4ed1e0efbaa65dce1e2928841a4406ce"
],
"data": "0x00000000000000000000000000000000000000000000000007de5ef2cc6c3000",
"blockHash": "0x8082e072b41af3ea86555e1b6f7ce05532c4b72bf614cd55a65109830a0ea829",
"blockNumber": "0x26488",
"l1BatchNumber": null,
"transactionHash": "0x442b2272e5b18af5cad6a747e432f4942455947a7ebf997c0c335d952d8e5458",
"transactionIndex": "0x0",
"logIndex": "0x8",
"transactionLogIndex": "0x8",
"logType": null,
"removed": false,
"blockTimestamp": "0x66cf747c"
}
],
"id": 1
}
```
***
### `eth_getFilterChanges`
Retrieves the logs since the last poll for a filter created with `eth_newFilter`.
#### **Parameters**
**QUANTITY, 32 bytes** - the filter id.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getFilterChanges",
"params": [
"0x612772db7168e9e1b3af62478e9433d06e05e9861289cace5043644842456ae7"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{...}
],
"id": 1
}
```
***
### `eth_getBalance`
Gets the balance of an account at a specific block.
#### **Parameters**
**DATA, 20 bytes** - address of the account whose balance is being queried.
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
**QUANTITY** - The balance of the account at the specified block, encoded as a hexadecimal string representing the value in gwei.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBalance",
"params": [
"0x39D3daeB55FE01b3F10A002DAdaEa6c79B098f1E",
"latest"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"id":1,
"result": "0x47b13063b2c33ef82"
}
```
***
### `eth_getBlockByNumber`
Retrieves a block by its number.
#### **Parameters**
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
**Boolean** - A boolean flag indicating whether to return full transaction objects (`true`) or just their hashes (`false`).
#### **Returns**
Object representing the requested block, including various metadata fields and either a list of transaction hashes or full transaction objects, based on the `full_transactions` parameter.
* **hash**: DATA, 32 bytes - hash of the block.
* **parentHash**: DATA, 32 bytes - hash of the block's parent.
* **sha3Uncles**: DATA, 32 bytes - SHA3 of the uncles data in the block.
* **miner**: DATA, 20 bytes - address of the miner who mined the block.
* **stateRoot**: DATA, 32 bytes - root of the final state trie of the block.
* **transactionsRoot**: DATA, 32 bytes - root of the trie of the transactions in the block.
* **receiptsRoot**: Data, 32 bytes - root of the receipts trie of the block.
* **number**: QUANTITY - block number.
* **l1BatchNumber**: QUANTITY - (Optional) The L1 batch number associated with the block.
* **gasUsed**: QUANTITY - total gas used by all transactions in this block.
* **gasLimit**: QUANTITY - gas limit of the block.
* **baseFeePerGas**: QUANTITY - (Optional) base fee per gas in the block.
* **extraData**: DATA - Extra data attached to the block.
* **logsBloom**: DATA, 256 bytes - The bloom filter for the logs contained in the block.
* **timestamp**: QUANTITY - timestamp for when the block was collated.
* **l1BatchTimestamp**: QUANTITY - (Optional) L1 batch timestamp associated with the block.
* **difficulty**: QUANTITY - difficulty of the block.
* **totalDifficulty**: QUANTITY - total difficulty of the chain up to this block.
* **uncles**: Array - An array of uncle hashes.
* **transactions**: Array - An array of transaction hashes or transaction objects, depending on the `full_transactions` parameter.
* **size**: QUANTITY - size of the block in bytes.
* **mixHash**: DATA - mix hash of the block.
* **nonce**: DATA, 8 bytes - nonce of the block.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBlockByNumber",
"params": ["0x24C57", false]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"hash": "0x1e59fe199a76acac718e5154de14994837fd95bd9a407f4dca9927ffb2cf59bb",
"parentHash": "0xad33990c8173b76b93c4cef22a6fef8bad9bce55498a61dcee30d0246d496b52",
"sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"miner": "0x0000000000000000000000000000000000000000",
"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"transactionsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"receiptsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"number": "0x24c57",
"l1BatchNumber": null,
"gasUsed": "0x2c3d0",
"gasLimit": "0x4000000000000",
"baseFeePerGas": "0x246139ca800",
"extraData": "0x",
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"timestamp": "0x66cece0e",
"l1BatchTimestamp": null,
"difficulty": "0x0",
"totalDifficulty": "0x0",
"sealFields": [],
"uncles": [],
"transactions": [
"0xb775bcd79414a4fbeda71c9e4c55340dfb88156ef42c82d94e9f3680a124d5c9"
],
"size": "0x0",
"mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"nonce": "0x0000000000000000"
},
"id": 1
}
```
***
### `eth_getBlockByHash`
Retrieves a block by its hash.
#### **Parameters**
**DATA, 32 bytes** - hexadecimal string representing the hash of the block.
**Boolean** - A boolean flag indicating whether to return full transaction objects (`true`) or just their hashes (`false`).
#### **Returns**
Object containing detailed information about the block and its transactions.
* **hash**: DATA, 32 bytes - hash of the block.
* **parentHash**: DATA, 32 bytes - hash of the block's parent.
* **sha3Uncles**: DATA, 32 bytes - SHA3 of the uncles data in the block.
* **miner**: DATA, 20 bytes - address of the miner who mined the block.
* **stateRoot**: DATA, 32 bytes - root of the final state trie of the block.
* **transactionsRoot**: DATA, 32 bytes - root of the trie of the transactions in the block.
* **receiptsRoot**: Data, 32 bytes - root of the receipts trie of the block.
* **number**: QUANTITY - block number.
* **l1BatchNumber**: QUANTITY - (Optional) The L1 batch number associated with the block.
* **gasUsed**: QUANTITY - total gas used by all transactions in this block.
* **gasLimit**: QUANTITY - gas limit of the block.
* **baseFeePerGas**: QUANTITY - (Optional) base fee per gas in the block.
* **extraData**: DATA - Extra data attached to the block.
* **logsBloom**: DATA, 256 bytes - The bloom filter for the logs contained in the block.
* **timestamp**: QUANTITY - timestamp for when the block was collated.
* **l1BatchTimestamp**: QUANTITY - (Optional) L1 batch timestamp associated with the block.
* **difficulty**: QUANTITY - difficulty of the block.
* **totalDifficulty**: QUANTITY - total difficulty of the chain up to this block.
* **uncles**: Array - An array of uncle hashes.
* **transactions**: Array - An array of transaction hashes or transaction objects, depending on the `full_transactions` parameter.
* **size**: QUANTITY - size of the block in bytes.
* **mixHash**: DATA - mix hash of the block.
* **nonce**: DATA, 8 bytes - nonce of the block.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBlockByHash",
"params": [
"0x1e59fe199a76acac718e5154de14994837fd95bd9a407f4dca9927ffb2cf59bb",
false
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"hash": "0x1e59fe199a76acac718e5154de14994837fd95bd9a407f4dca9927ffb2cf59bb",
"parentHash": "0xad33990c8173b76b93c4cef22a6fef8bad9bce55498a61dcee30d0246d496b52",
"sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"miner": "0x0000000000000000000000000000000000000000",
"stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"transactionsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"receiptsRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
"number": "0x24c57",
"l1BatchNumber": null,
"gasUsed": "0x2c3d0",
"gasLimit": "0x4000000000000",
"baseFeePerGas": "0x246139ca800",
"extraData": "0x",
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"timestamp": "0x66cece0e",
"l1BatchTimestamp": null,
"difficulty": "0x0",
"totalDifficulty": "0x0",
"sealFields": [],
"uncles": [],
"transactions": [
"0xb775bcd79414a4fbeda71c9e4c55340dfb88156ef42c82d94e9f3680a124d5c9"
],
"size": "0x0",
"mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"nonce": "0x0000000000000000"
},
"id": 1
}
```
***
### `eth_getBlockTransactionCountByNumber`
This method provides the total number of transactions included in a specific block, identified by its block number. It's a useful query for understanding the volume of transactions processed in a particular block.
#### **Parameters**
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
**QUANTITY** - number of transactions in the specified block, encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBlockTransactionCountByNumber",
"params": ["0x24C53"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x1",
"id": 2
}
```
***
### `eth_getBlockReceipts`
Fetches transaction receipts for all transactions in a specified block, offering comprehensive details such as the transaction status, gas used, and event logs.
#### **Parameters**
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
Array of transaction receipt objects, each containing detailed information about a transaction included in the specified block.
* **transactionHash**: DATA, 32 bytes - hash of the transaction.
* **transactionIndex**: QUANTITY - index of the transaction in the block.
* **blockHash**: DATA, 32 bytes - hash of the block containing the transaction.
* **blockNumber**: QUANTITY - block number.
* **from**: DATA, 20 bytes - address of the sender.
* **to**: DATA, 20 bytes - address of the receiver. Can be `null` for contract creation transactions.
* **cumulativeGasUsed**: QUANTITY - total amount of gas used when this transaction was executed in the block.
* **gasUsed**: QUANTITY - amount of gas used by this specific transaction.
* **contractAddress**: DATA, 20 bytes - contract address created, if the transaction was a contract creation, otherwise `null`.
* **logs**: Array\ - An array of log objects generated by this transaction.
* **status**: QUANTITY - status of the transaction, where `"0x1"` indicates success and `"0x0"` indicates failure.
* **logsBloom**: DATA - bloom filter for the logs of the block.
* **type**: QUANTITY - type of the transaction.
* **effectiveGasPrice**: QUANTITY - effective gas price paid per unit of gas.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_getBlockReceipts",
"params": ["0x1d1551e"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [
{
"transactionHash": "0x3326f0dbc0243fad28edcee91a71cc0c095dcc3a3d73f11bfc95a31a67ba9493",
"transactionIndex": "0x0",
"blockHash": "0xeba5890696185de9887239fea3aef3798a77a57e69137efbbd32886e2ee878ec",
"blockNumber": "0x24c53",
"l1BatchTxIndex": null,
"l1BatchNumber": null,
"from": "0x8fd82243f70caf79c5993a1a6d9e5c04b5c688b1",
"to": "0xbcaa34ff9d5bfd0d948b18cf6bf39a882f4a1cbd",
"cumulativeGasUsed": "0x0",
"gasUsed": "0x26a27",
"contractAddress": null,
"logs": [
{
"address": "0xbcaa34ff9d5bfd0d948b18cf6bf39a882f4a1cbd",
"topics": [
"0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
"0x0000000000000000000000008fd82243f70caf79c5993a1a6d9e5c04b5c688b1",
"0x000000000000000000000000f809566a93cb882e5055a815bebe57f8aa6ed9f9"
],
"data": "0x0000000000000000000000000000000000000000000000000000000000000000",
"blockHash": "0xeba5890696185de9887239fea3aef3798a77a57e69137efbbd32886e2ee878ec",
"blockNumber": "0x24c53",
"l1BatchNumber": null,
"transactionHash": "0x3326f0dbc0243fad28edcee91a71cc0c095dcc3a3d73f11bfc95a31a67ba9493",
"transactionIndex": "0x0",
"logIndex": "0x0",
"transactionLogIndex": "0x0",
"logType": null,
"removed": false,
"blockTimestamp": "0x66cecdee"
},
...
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x000000000000000000000000f809566a93cb882e5055a815bebe57f8aa6ed9f9",
"0x0000000000000000000000008fd82243f70caf79c5993a1a6d9e5c04b5c688b1"
],
"data": "0x00000000000000000000000000000000000000000000000002e5f9b1d9ba7800",
"blockHash": "0xeba5890696185de9887239fea3aef3798a77a57e69137efbbd32886e2ee878ec",
"blockNumber": "0x24c53",
"l1BatchNumber": null,
"transactionHash": "0x3326f0dbc0243fad28edcee91a71cc0c095dcc3a3d73f11bfc95a31a67ba9493",
"transactionIndex": "0x0",
"logIndex": "0x5",
"transactionLogIndex": "0x5",
"logType": null,
"removed": false,
"blockTimestamp": "0x66cecdee"
},
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000000008001",
"0x000000000000000000000000000f809566a93cb882e5055a815bebe57f8aa6ed9f9"
],
"data": "0x000000000000000000000000000000000000000000000000000000000000..."
```
***
### `eth_getBlockTransactionCountByHash`
This method returns the number of transactions included in a block, identified by the block's hash. It's particularly useful for determining the transaction volume within a specific block without retrieving the transactions themselves.
#### **Parameters**
**DATA, 32 bytes** - hash of the block for which the transaction count is requested. This should be provided as a hexadecimal string.
#### **Returns**
**QUANTITY** - number of transactions in the block, encoded as a hexadecimal string.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getBlockTransactionCountByHash",
"params": ["0x8422c3e796bf4aaa157f0881cd30a26281ee842a799b5f88cb8f486c47695025"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x1",
"id": 2
}
```
***
### `eth_getCode`
Retrieves the code at a specific address at an optional block.
#### **Parameters**
**DATA, 20 bytes** - The Ethereum address in hexadecimal format from which to retrieve the code.
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
**DATA** - The code at the given address in the specified block, returned as a hexadecimal string. If the address is not a contract a `0x` is returned.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getCode",
"params": [
"0xdfe68fb100c074c838d6e2c5a2d248308dcf090d"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": ""0x0004000000000002002600000000000200000000030100190000006003300270000003230430019700030000004103550002000000010355000003230030019d0000000102200190000000900000c13d0000008008000039000000400080043f000000040240008c000007730000413d000000000201043b000000e0052002700000032a0250009c00000024021003700000000403100370000000da0000613d0000032b0650009c000001770000613d0000032c0650009c000001890000613d0000032d0650009c000001980000613d0000032e0650009c000001b70000613d0000032f0650009c000001bf0000613d000003300650009c0000024b0000613d000003310650009c000002580000613d000003320650009c000002610000613d000003330650009c000002740000613d000003340650009c000002790000613d000003350650009c0000028c0000613d000003360650009c0000029f0000613d000003370650009c000002f90000613d000003380650009c000003020000613d000003390650009c0000031e0000613d0000033a0650009c0000032c0000613d0000033b0150009c000003540000613d0000033c0150009c0000036d0000613d0000033d0150009c000003d70000613d0000033e0150009c0000040d0000613d0000033f0150009c000004200000613d000003400150009c000007730000c13d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000103043b000e00000001001d000000000202043b000000000102004b0000000001000019000000010100c039001000000002001d000000000112004b000007730000c13d0c880a2d0000040f000000100100006b000004780000c13d000000400200043d0000035a01000041000100550000003d00000c6d0000013d002600000001001d002500000000001d000100590000003d00000c060000013d000000260440008a000000050440021000000344020000410c880ba10000040f000000000201001900000000010004140000032502200197000000040320008c000000670000613d00000024040000390000008006000039000100660000003d00000c680000013d000002ed0000613d0000000105000031000000800250008c00000080050080390000001f02500039000001e00320018f00000010010000290000000002130019000100700000003d00000c600000013d000003410420009c000004720000213d0000000103300190000004720000c13d000000400020043f00000000021500190c8808290000040f0000000e02000029000000000020043500000003020000390001007c0000003d00000c7b0000013d0000032502200197000000000301041a0000032603300197000000000323019f000000000031041b000000400100043d000000000021043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c0001008a0000003d00000c100000013d0000034c011001c70000800d0200003900000002030000390000036a040000410000000e05000029000004db0000013d0000000002000416000000000202004b000007730000c13d0000001f024000390000032402200197000000a002200039000000400020043f0000001f0240018f0000000503400272000000a30000613d00000000050000190000000506500210000000000761034f000000000707043b000000a00660003900000000007604350000000105500039000000000635004b0000009b0000413d000000000502004b000000b20000613d0000000503300210000000000131034f0000000302200210000000a003300039000000000503043300000000052501cf000000000525022f000000000101043b0000010002200089000000000121022f00000000012101cf000000000151019f0000000000130435000000200140008c000007730000413d000000a00100043d001000000001001d000003250110009c000007730000213d000000000200041a00000326012001970000000006000411000000000161019f000000000010041b00000323010000410000000003000414000003230430009c0000000003018019000000c00130021000000327011001c700000325052001970000800d02000039000000030300003900000328040000410c880bbb0000040f0000000101200190000007730000613d0000000101000039000000000011041b0000000202000039000000000302041a000001000400008a000000000343016f000000000032041b0000001002000029000000800020043f00000140000004430000016000200443000000200200003900000100002004430000012000100443000003290100004100000c890001042e0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000202043b000003250120009c000007730000213d000c00000002001d000000000103043b000100e60000003d00000c820000013d000500000002001d0c880b8c0000040f000000e002000039000000400020043f001000000001001d000000000201041a0000032502200197000000800020043f00000001011000390c88083a0000040f000000a00010043f00000010020000290000000202200039000000000202041a000000c00020043f0000000001010433000000010110003a0000000002000019000000010200603900000001022001900000046c0000c13d000003410210009c000004720000213d00000005041002100000003f024000390000034205200197000000400a00043d00000000025a00190000000003a2004b00000000030000190000000103004039000003410620009c000004720000213d0000000103300190000004720000c13d000000400020043f00000000091a04360000001f0240018f000000000300003100000002033003670000000504400272000001190000613d000000000600001900000005076002100000000008790019000000000773034f000000000707043b00000000007804350000000106600039000000000746004b000001110000413d000000000602004b0000011b0000613d000000400800043d0000000005580019000000000685004b00000000060000190000000106004039000003410750009c000004720000213d0000000106600190000004720000c13d000000400050043f0000000007180436000000000104004b000001310000613d000000000100001900000005051002100000000006570019000000000553034f000000000505043b00000000005604350000000101100039000000000541004b000001290000413d000800000008001d000900000007001d000a0000000a001d000b00000009001d000000000102004b000001370000613d000000400200043d0000034301000041001000000002001d00000000001204350000000001000412001200000001001d001100000000001d000101400000003d00000c060000013d000000120440008a000000050440021000000344020000410c880ba10000040f000000000201001900000000010004140000032502200197000000040320008c0000014e0000613d000000040400003900000020060000390001014d0000003d00000c680000013d000002ed0000613d000101500000003d00000c740000013d00000010070000290000001005300029000000000335004b00000000030000190000000103004039000003410450009c0000000c020000290000000b040000290000000a06000029000004720000213d0000000103300190000004720000c13d000000400050043f000000200110008c000007730000413d0000000001070433000003250310009c000007730000213d0000000003060433000000000303004b000001730000613d00000000001404350000000401000039001000000001001d0000000201100367000000000101043b0c88095a0000040f000000080900002900000009080000290000000a070000290000000b060000290000000c050000290000000002090433000000000202004b000007200000c13d000003460100004100000000001004350000003201000039000004750000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b00000000001004350000000301000039000000200010043f0000004002000039001000000002001d00000000010000190c880b8c0000040f0000000202100039000000000202041a000000000101041a0000032501100197000003190000013d0000000001000416000000000101004b000007730000c13d0c880a2d0000040f000000400100043d0000000202000039000000000302041a000000ff043001900000043c0000c13d00000044021000390000036903000041000000000032043500000024021000390000001403000039000004b90000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000102043b000700000001001d000101a10000003d00000be90000013d000600000001001d000000000100001900000010020000290c880b8c0000040f0000000002000411000500000002001d000101a90000003d00000c3f0000013d0000000002010019000000000102041a000000070110006c0000044d0000813d000000400100043d00000064021000390000036603000041000000000032043500000044021000390000036703000041000000000032043500000024021000390000002503000039000004360000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b0c8808640000040f000004de0000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b001000000001001d0c880a4e0000040f000000100100002900000000001004350000000301000039000000200010043f0000004002000039000f00000002001d00000000010000190c880b8c0000040f0000000502000039000000200020043f000d00000001001d00000000010000190000000f020000290c880b8c0000040f0000000002000411000e00000002001d0000000000200435000000200010043f00000000010000190000000f020000290c880b8c0000040f000000000301041a000000000001041b0000000101100039000000000001041b0000000201000039000000000101041a000000ff01100190000f00000003001d000006c20000c13d0000000001000412002000000001001d001f00000000001d000101ea0000003d00000c060000013d000000200440008a000000050440021000000344020000410c880ba10000040f0000036102000041000000400300043d0000000000230435000000040230003900000010050000290000000000520435000000000200041000000325042001970000002402300039000b00000004001d0000000000420435000000000201001900000000010004140000032502200197000000040420008c000002080000613d000000440400003900000020060000390000000005030019000c00000002001d000a00000003001d0c8807d90000040f0000000a030000290000000c02000029000000000101004b000002ed0000613d0000000101000031000000200410008c000000000401001900000020040080390000001f04400039000000600640018f0000000004360019000000000664004b00000000060000190000000106004039000003410740009c000004720000213d0000000106600190000004720000c13d000c00000002001d000a00000004001d000000400040043f000000200110008c000007730000413d0000000001030433000900000001001d001e000c0000002d000102200000003d00000c640000013d0000001e0440008a000000050440021000000352020000410c880ba10000040f000000000101004b000007730000613d00000362010000410000000a05000029000000000015043500000024065000390000000f01000029000000000016043500000004075000390000001003000029000000000037043500000000010004140000000c02000029000000040420008c000002400000613d00000044040000390000000003050019000800000006001d0000000006000019000700000007001d0c8807b50000040f000000070700002900000008060000290000000c020000290000000a050000290000001003000029000000000101004b000002ed0000613d000000400050043f0000036301000041000000000015043500000000003704350000000b0100002900000000001604350000000001000414000000040320008c000006540000c13d0000000102000031000006a30000013d0000000001000416000000000101004b000007730000c13d0000000001000412001d00000001001d001c00000000001d000102530000003d00000c060000013d0000001d0440008a000000050440021000000344020000410c880ba10000040f000002fd0000013d0000000001000416000000000101004b000007730000c13d0000000201000039000000000101041a000000ff011001900000000001000019000000010100c039000002fe0000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000202043b000003250120009c000007730000213d000000000103043b0c88091c0000040f000000400300043d00000020043000390000000000240435000000000101004b0000000001000019000000010100c039000000000013043500000040020000390000041d0000013d0000000001000416000000000101004b000007730000c13d0c88094c0000040f000004de0000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b0000000402000039000000000202041a000000000221004b000007730000813d0c8807fd0000040f0000000302200210000000000101041a000000000321022f000000ff0120008c0000000003002019000000400100043d0000000000310435000003000000013d0000000001000416000000000101004b000007730000c13d0c880a2d0000040f000000000200041a0000032601200197000000000010041b00000323010000410000000003000414000003230430009c0000000003018019000000c00130021000000327011001c700000325052001970000800d02000039000000030300003900000328040000410000000006000019000004db0000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b001000000001001d0c880a2d0000040f0000000201000039000f00000001001d000000000101041a000000ff02100190000002c60000c13d000001000200008a000000000121016f000e0001001001c30c880a400000040f0000000f010000290000000e02000029000000000021041b0000000001000411000000400200043d000000000012043500000323010000410000000003000414000003230430009c0000000003018019000003230420009c00000000020180190000004001200210000000c002300210000000000112019f0000034c011001c70000800d0200003900000001030000390000035e040000410c880bbb0000040f0000000101200190000007730000613d0000000001000412001b00000001001d001a00000000001d000102cb0000003d00000c060000013d0000001b0440008a000000050440021000000344020000410c880ba10000040f000f00000001001d001903250010019b000102d30000003d00000c640000013d000000190440008a000000050440021000000352020000410c880ba10000040f0000000f020000290000032502200197000000000101004b000007730000613d000000400500043d0000035f0100004100000000001504350000000401500039000000100300002900000000003104350000000001000414000000040320008c000004700000613d00000024040000390000000003050019000f00000005001d0000000f0500002900000000060000190c8807b50000040f0000000f05000029000000000101004b000004700000c13d000102ef0000003d00000c150000013d000002f40000613d0000000006000019000102f30000003d00000bd30000013d000002f10000413d000000000604004b000002f80000613d000102f80000003d00000bc50000013d0c880b780000040f0000000001000416000000000101004b000007730000c13d000000000100041a0000032501100197000000800010043f000000800100003900000020020000390000041e0000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000102043b000f00000001001d000003250110009c000007730000213d000000000103043b00000000001004350000000501000039000000200010043f0000004002000039001000000002001d00000000010000190c880b8c0000040f0000000f02000029000103160000003d00000c3f0000013d0000000102100039000000000202041a000000000101041a000000800010043f000000a00020043f000000800100003900000010020000290000041e0000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000202043b000003250120009c000007730000213d000000000103043b0c88095a0000040f000000400300043d000000000013043500000020020000390000041d0000013d0000000005000416000000640640008c000007730000413d000000000505004b000007730000c13d000000000303043b000e00000003001d000000000202043b000003410320009c000007730000213d0000002303200039000000000343004b000007730000813d0000000403200039000000000331034f000000000303043b000003410530009c000004720000213d00000005053002100000003f065000390000034206600197000003580760009c000004720000213d0000008006600039000000400060043f000000800030043f00000024022000390000000003250019000000000443004b000007730000213d000000a004000039000000000532004b000005620000813d000000000521034f000000000505043b000003250650009c000007730000213d000000000454043600000020022000390000034b0000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000103043b000a00000001001d000000000102043b000900000001001d000003250110009c000007730000213d0c880a2d0000040f0000000a0100002900000009020000290c88091c0000040f0000000003020019000000000101004b000004840000c13d000000400100043d00000044021000390000035703000041000000000032043500000024021000390000001103000039000004b90000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000102043b000500000001001d000103760000003d00000be90000013d000700000001001d000000000100001900000010020000290c880b8c0000040f0000000002000411000400000002001d0001037e0000003d00000c3f0000013d000600000001001d0000000e010000290c8808640000040f000000060600002900000007010000290000000207100039000000000307041a000000000106041a00000000421300a9000000000401004b0000038c0000613d00000000541200d9000000000334004b0000046c0000c13d0000034e3220012a0000000105600039000000000305041a000000000432004b0000046c0000413d000000000432004b000300000007001d000200000005001d0000039a0000613d000000000232004900000004010000290c880a5e0000040f0000000606000029000000000106041a000d00050010002d0000000d0110006b0000000001000019000000010100403900000001011001900000046c0000c13d000000070100002900000001011000390c88083a0000040f0000000402000029000803250020019b000c00000001001d000b00200010003d000a80020000003d000900240000003d00000000020000190000000c010000290000000001010433000000000112004b0000053b0000813d000f00000002001d00000005012002100000000b011000290000000001010433001000000001001d001603250010019b0000000004000415000000160440008a00000005044002100000000a01000029000003520200004100000009030000290c880ba10000040f00000010020000290000032502200197000000000101004b000007730000613d000000400500043d00000044015000390000000d0300002900000000003104350000002401500039000000080300002900000000003104350000035501000041000000000015043500000004015000390000000e0300002900000000003104350000000001000414000000040320008c000003d10000613d000103d00000003d00000c260000013d000002ed0000613d000003410150009c000004720000213d000000400050043f0000000f020000290000000102200039000003aa0000013d0000000001000416000000440440008c000007730000413d000000000101004b000007730000c13d000000000103043b001000000001001d000000000102043b000f00000001001d000003250110009c000007730000213d0c880a2d0000040f00000010010000290000000f020000290c88091c0000040f000000000101004b000004b30000c13d0000001001000029000103eb0000003d00000c510000013d000000000201041a000003410320009c000004720000213d0000000103200039000000000031041b0c88080b0000040f0000000302200210000003250320021f000000010400008a000000000343013f000000ff0520008c000000000403a0190000000f0500002900000000022501cf0000000002002019000000000301041a000000000334016f000000000223019f000000000021041b000000400100043d000000000051043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c000104070000003d00000c100000013d0000034c011001c70000800d0200003900000002030000390000034d040000410000001005000029000004db0000013d0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b000104150000003d00000c510000013d0c88083a0000040f0000002002000039000000400300043d001000000003001d00000000022304360c88081b0000040f00000010030000290000000002310049000000000103001900000000030000190c880b810000040f0000000001000416000000240240008c000007730000413d000000000101004b000007730000c13d000000000103043b001003250010019b000003250110009c000007730000213d0c880a2d0000040f0000001006000029000000000106004b000004bc0000c13d000000400100043d0000006402100039000003480300004100000000003204350000004402100039000003490300004100000000003204350000002402100039000000260300003900000000003204350000034a0200004100000000002104350000000402100039000000200300003900000c5d0000013d000001000400008a000000000343016f000000000032041b0000000002000411000000000021043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c000104480000003d00000c100000013d0000034c011001c70000800d0200003900000001030000390000036804000041000004db0000013d0000000e01000029000400000002001d0c8808640000040f000000040600002900000006050000290000000207500039000000000207041a000000000806041a00000000318200a9000000000308004b0000045b0000613d00000000438100d9000000000223004b0000046c0000c13d0000034e2110012a0000000104600039000000000204041a000000000321004b0000046c0000413d000000000321004b000300000007001d000200000004001d0000046a0000613d000000000221004900000005010000290c880a5e0000040f00000006050000290000000401000029000000000801041a000000070180006c000005020000813d000003460100004100000000001004350000001101000039000004750000013d000003410150009c000004cb0000a13d000003460100004100000000001004350000004101000039000000040010043f000003470100004100000c8a000104300000000401000039000000000101041a000f00000001001d00000000020000190000000f0120006c000000510000813d0000000001020019001000000002001d0c8808640000040f000000100200002900000001022000390000047c0000013d0000000a01000029000104870000003d00000c820000013d001000000003001d0c880b8c0000040f00000010040000290000000103100039000b000100000092000f00000003001d000000000103041a000000000201004b0000046c0000613d000000010210008a000000000124004b000004e00000813d0000000102400039000e00000002001d0000000001030019001000000004001d0c88080b0000040f000d00000002001d000000000101041a000c00000001001d0000000f0100002900000010020000290c88080b0000040f0000000302200210000003250320021f0000000b0330014f000000ff0420008c0000000b030020290000000d0400002900000003044002100000000c0540024f0000032505500197000000ff0440008c000000000500201900000000042501cf000000ff0220008c0000000004002019000000000201041a000000000223016f0000000f03000029000000000242019f000000000021041b0000000e040000290000048d0000013d000000400100043d00000044021000390000034b03000041000000000032043500000024021000390000000e0300003900000000003204350000034a0200004100000c0a0000013d000000000200041a0000032601200197000000000161019f000000000010041b00000323010000410000000003000414000003230430009c0000000003018019000000c00130021000000327011001c700000325052001970000800d0200003900000003030000390000032804000041000004db0000013d000000400050043f0000001001000029000000000015043500000323010000410000000002000414000003230320009c0000000002018019000003230350009c00000000050180190000004001500210000000c002200210000000000112019f0000034c011001c70000800d02000039000000010300003900000360040000410c880bbb0000040f0000000101200190000007730000613d000000000100001900000c890001042e0000000001030019001000000002001d0c88080b0000040f0000000302200210000003250320021f0000000b0330014f000000ff0220008c00000000040300190000000b04002029000000000201041a000000000224016f000000000021041b00000010010000290000000f02000029000000000012041b00000009010000290000032501100197000000400200043d000000000012043500000323010000410000000003000414000003230430009c0000000003018019000003230420009c00000000020180190000004001200210000000c002300210000000000112019f0000034c011001c70000800d02000039000000020300003900000356040000410000000a05000029000004db0000013d0000000101500039001000000008001d0c88083a0000040f000000100300002900090007003000720000000502000029000803250020019b000d00000001001d000c00200010003d000b80020000003d000a00240000003d00000000020000190000000d010000290000000001010433000000000112004b000005bf0000813d000f00000002001d00000005012002100000000c011000290000000001010433001000000001001d002403250010019b0000000004000415000000240440008a00000005044002100000000b0100002900000352020000410000000a030000290c880ba10000040f00000010020000290000032502200197000000000101004b000007730000613d000000400500043d0000004401500039000000090300002900000000003104350000002401500039000000080300002900000000003104350000035501000041000000000015043500000004015000390000000e0300002900000000003104350000000001000414000000040320008c000005350000613d000105340000003d00000c260000013d000002ed0000613d000003410150009c000004720000213d000000400050043f0000000f0200002900000001022000390000050e0000013d0000000505000029000000000105004b000005df0000c13d0000000603000029000000000203041a0000000001520019000000000221004b000000000200001900000001020040390000000102200190000000030200002900000002050000290000046c0000c13d000000000013041b000000000302041a00000000421300a9000000000401004b000005500000613d00000000411200d9000000000131004b0000046c0000c13d0000034e2120012a000000000015041b000000400100043d0000000502000029000000000021043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c0001055c0000003d00000c100000013d0000034c011001c70000800d02000039000000030300003900000354040000410000000405000029000005dd0000013d0000004401100370000000000201043b000000000102004b0000000001000019000000010100c039000d00000002001d000000000112004b000007730000c13d000b00000008001d0c880a2d0000040f0000000e0100002900000000001004350000000301000039000c00000001001d000000200010043f000000400200003900000000010000190c880b8c0000040f000000000101041a0000032501100198000006dd0000c13d0000000d0100006b000006e40000c13d000000400200043d0000035a010000410001057d0000003d00000c6d0000013d001800000001001d001700000000001d000105810000003d00000c060000013d000000180440008a000000050440021000000344020000410c880ba10000040f000000000201001900000000010004140000032502200197000000040320008c0000058f0000613d000000240400003900000080060000390001058e0000003d00000c680000013d000002ed0000613d0000000105000031000000800250008c00000080050080390000001f02500039000001e00320018f0000001002300029000105970000003d00000c600000013d000003410420009c000004720000213d0000000103300190000004720000c13d000000400020043f000000100100002900000000021500190c8808290000040f0000000e0200002900000000002004350000000c02000029000105a40000003d00000c7b0000013d000f03250020019b000000000201041a00000326022001970000000f022001af000000000021041b000000800200043d001000000002001d0000035b0220009c0000071c0000813d0000000102100039000000000302041a0000001001000029000c00000002001d000000000012041b000a00000003001d000000000131004b000006f00000813d0000000c01000029000105b80000003d00000c380000013d00000010021000290000000a01100029000000000312004b000006f00000813d000000000002041b0000000102200039000005ba0000013d000000070100006b000006670000c13d0000000301000029000000000201041a0000000401000029000000000301041a00000000413200a9000000000403004b0000000205000029000005cc0000613d00000000433100d9000000000223004b0000046c0000c13d0000034e2110012a000000000015041b000000400100043d0000000702000029000000000021043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c000105d80000003d00000c100000013d0000034c011001c70000800d020000390000000303000039000003650400004100000005050000290000000e06000029000006d70000013d0000000701000029000000000101041a000000400200043d00000020032000390000034f0400004100000000004304350000006403200039000000000053043500000044032000390000000004000410000000000043043500000024032000390000000404000029000000000043043500000064030000390000000000320435000003500320009c000004720000213d000000a003200039000000400030043f00000325011001970c880ab90000040f0000000701000029000000000101041a000f00000001001d0000000001000412001500000001001d001400000000001d000105fd0000003d00000c060000013d000000150440008a000000050440021000000344020000410c880ba10000040f000000400400043d000000240240003900000005030000290000000000320435000003510200004100000000002404350000032502100197001000000004001d0000000401400039000d00000002001d000000000021043500000000010004140000000f020000290000032502200197000000040320008c000006180000613d00000044040000390000002006000039000000100300002900000000050300190c8807b50000040f000000000101004b000002ed0000613d0000000101000031000000200210008c000000000201001900000020020080390000001f02200039000000600220018f00000010040000290000001003200029000000000223004b00000000020000190000000102004039000f00000003001d000003410330009c000004720000213d0000000102200190000004720000c13d0000000f02000029000000400020043f000000200110008c000007730000413d0000000001040433000000000201004b0000000002000019000000010200c039000000000121004b000007730000c13d0013000d0000002d000106350000003d00000c640000013d000000130440008a000000050440021000000352020000410c880ba10000040f000000000101004b000007730000613d0000000f030000290000002401300039000000050200002900000000002104350000035301000041000000000013043500000004013000390000000e02000029000000000021043500000000010004140000000d02000029000000040220008c000006500000613d00000044040000390000000d020000290000000f03000029000000000503001900000000060000190c8807b50000040f000000000101004b000002ed0000613d0000000f01000029000000400010043f00000005050000290000053e0000013d0000004404000039000000400600003900000000030500190c8807d90000040f0000000102000031000000000101004b000006a20000c13d0001065d0000003d00000c1b0000013d000006620000613d0000000006000019000106610000003d00000bd30000013d0000065f0000413d000000000604004b000006660000613d000106660000003d00000bc50000013d0c880b780000040f0000000403000029000000000103041a000000070210006c0000046c0000413d000000070110006a000000000013041b0000000001000412002300000001001d002200000000001d000106720000003d00000c060000013d000000230440008a000000050440021000000344020000410c880ba10000040f001000000001001d002103250010019b0001067a0000003d00000c640000013d000000210440008a000000050440021000000352020000410c880ba10000040f00000010020000290000032502200197000000000101004b000007730000613d000000400400043d00000024014000390000000703000029000000000031043500000362010000410000000000140435001000000004001d00000004014000390000000e0300002900000000003104350000000001000414000000040320008c000006960000613d00000044040000390000001003000029000000000503001900000000060000190c8807b50000040f000000000101004b000002ed0000613d0000001001000029000003410110009c000004720000213d0000001001000029000000400010043f0000000601000029000000000101041a0000032501100197000000050200002900000007030000290c880aa10000040f000005c10000013d0000000a05000029000106a50000003d00000c200000013d0000000001510019000003410310009c000004720000213d000000400010043f000000400120008c000007730000413d000000090100006b0000000f03000029000006c20000613d0000000a010000290000000001010433000000000201004b000006c20000613d00000009040000290000034e324000d100000000434200d90000034e0330009c0000046c0000c13d00000000121200d90000000d010000290000000201100039000000000301041a0000000002230019000106be0000003d00000c600000013d00000001033001900000046c0000c13d000000000021041b0000000f030000290000000d01000029000000000101041a00000325011001970000000e020000290c880aa10000040f000000400100043d0000000f02000029000000000021043500000323020000410000000003000414000003230430009c0000000003028019000003230410009c000106d10000003d00000c100000013d0000034c011001c70000800d02000039000000030300003900000364040000410000000e0500002900000010060000290c880bbb0000040f0000000101200190000007730000613d0000000101000039000000000011041b000004de0000013d000000400100043d00000044021000390000035903000041000000000032043500000024021000390000001303000039000004b90000013d0000000401000039000000000101041a000f00000001001d00000000020000190000000f0120006c000005790000813d0000000001020019001000000002001d0c8808640000040f00000010020000290000000102200039000006e80000013d0000000c01000029000106f30000003d00000c380000013d000000a00200003900000000030000190000001006000029000000000463004b000006fe0000813d000000000413001900000000250204340000032505500197000000000054041b0000000103300039000006f60000013d0000000402000039000000000102041a000003410310009c0000071c0000213d0000000103100039000000000032041b00000000002004350000035c011000410000000e02000029000000000021041b000000400100043d0000002002100039000000600300003900000000003204350000000f0200002900000000002104350000006002100039000000800300043d000000000032043500000000040000190000000b060000290000002002200039000000000534004b000007740000813d00000020066000390000000005060433000003250550019700000000005204350000000104400039000007130000013d00000346010000410000000000100435000000410100003900000c590000013d0000000000180435000000a00c00043d000000200dc00039000003450e000041000000000f00001900070000000c001d00060000000d001d000000400300043d00000000010c043300000000011f004b000000200b3000390000078a0000813d0000000501f0021000000000011d001900000000020104330000000000e3043500000010010000290000000201100367000000000101043b000000240430003900000000005404350000000404300039000000000014043500000000010004140000032502200197000000040420008c0000073d0000c13d0000000102000031000007520000013d000d0000000f001d000e0000000b001d00000044040000390000004006000039000f00000003001d00000000050300190c8807d90000040f0000000102000031000000000101004b000007a90000613d0000000c050000290000000b060000290000000a07000029000000090800002900000008090000290000000f030000290000000e0b000029000000070c000029000000060d000029000003450e0000410000000d0f000029000000400120008c000000000102001900000040010080390000001f01100039000000e00410018f0000000001340019000000000441004b000000000a000019000000010a004039000003410410009c000004720000213d0000000104a00190000004720000c13d000000400010043f000000400120008c000007730000413d0000000001030433000003250210009c000007730000213d000000010ff0003900000000020704330000000002f2004b000001730000a13d00000000020b04330000000503f002100000000004630019000000000014043500000000010904330000000001f1004b000001730000a13d00000000018300190000000000210435000007270000013d00000c3d0000013d00000040031000390000000d04000029000000000043043500000000021200490000032303000041000003230410009c00000000010380190000004001100210000003230420009c00000000020380190000006002200210000000000112019f0000000002000414000003230420009c0000000002038019000000c002200210000000000112019f00000327011001c70000800d0200003900000002030000390000035d040000410000008e0000013d00000005010000290000000000130435000000000207043300000040013000390000000000210435000000000103001900000060073000390000000003000019000000000423004b000007990000813d0000000064060434000003250440019700000000074704360000000103300039000007920000013d000000000217004900000000002b0435000000080200002900000000020204330000000000270435000000000300001900000009050000290000002007700039000000000423004b000007a70000813d000000005405043400000000004704350000000103300039000007a00000013d00000000021700490000041e0000013d000107ab0000003d00000c1b0000013d000007b00000613d0000000006000019000107af0000003d00000bd30000013d000007ad0000413d000000000604004b000007b40000613d000107b40000003d00000bc50000013d0c880b780000040f0003000000000002000300000006001d000200000005001d0000032305000041000003230630009c00000000030580190000004003300210000003230640009c00000000040580190000006004400210000000000334019f000003230410009c0000000001058019000000c001100210000000000113019f0c880bbb0000040f0000000209000029000000000301001900000060033002700000032303300197000000030430006c000000030500002900000000050340190000001f0450018f0000000505500272000007d30000613d0000000006000019000107d20000003d00000c450000013d000007d00000413d000000010220018f000000000604004b000007d80000613d000107d80000003d00000bf80000013d00000c4d0000013d0003000000000002000300000006001d000200000005001d0000032305000041000003230630009c00000000030580190000004003300210000003230640009c00000000040580190000006004400210000000000334019f000003230410009c0000000001058019000000c001100210000000000113019f0c880bc00000040f0000000209000029000000000301001900000060033002700000032303300197000000030430006c000000030500002900000000050340190000001f0450018f0000000505500272000007f70000613d0000000006000019000107f60000003d00000c450000013d000007f40000413d000000010220018f000000000604004b000007fc0000613d000107fc0000003d00000bf80000013d00000c4d0000013d0000000402000039000000000302041a000000000313004b000008050000a13d00000000002004350000035c011000410000000002000019000000000001042d000003460100004100000000001004350000003201000039000000040010043f000003470100004100000c8a000104300002000000000002000000000301041a000200000002001d000000000223004b000008150000a13d000108120000003d00000c380000013d00000002011000290000000002000019000000000001042d000003460100004100000000001004350000003201000039000000040010043f000003470100004100000c8a000104300000000003010433000000000032043500000000040000190000002002200039000000000534004b000008270000813d000000200110003900000000050104330000032505500197000000000052043500000001044000390000081e0000013d0000000001020019000000000001042d00000000021200490000036b030000410000007f0420008c000000000400001900000000040320190000036b02200197000000000502004b00000000030080190000036b0220009c000000000304c019000000000203004b000008390000613d0000000001010433000003250210009c000008390000213d000000000001042d00000c3d0000013d0003000000000002000000000201041a000200000002001d000000400300043d000300000003001d0000000000230435000108420000003d00000c380000013d0000000206000029000000030500002900000000020500190000000003000019000000000463004b0000084f0000813d0000002002200039000000000401041a0000032504400197000000000042043500000001033000390000000101100039000008460000013d00000000015200490000003f01100039000000200200008a000000000221016f0000000001520019000000000221004b00000000020000190000000102004039000003410310009c0000085e0000213d00000001022001900000085e0000c13d000000400010043f0000000001050019000000000001042d000003460100004100000000001004350000004101000039000000040010043f000003470100004100000c8a000104300009000000000002000600000001001d0000000001000412000900000001001d000800000000001d0001086b0000003d00000c060000013d000000090440008a000000050440021000000344020000410c880ba10000040f0000036302000041000000400300043d00000000002304350000000402300039000000060400002900000000004204350000000002000410000003250420019700000024023000390000000000420435000000000201001900000000010004140000032505200197000000040250008c000500000005001d0000088b0000613d000400000004001d0000004404000039000000400600003900000000020500190000000005030019000300000003001d0c8807d90000040f000000030300002900000004040000290000000505000029000000000101004b000008fc0000613d00000001020000310001088e0000003d00000c200000013d0000000007310019000000000117004b00000000010000190000000101004039000003410670009c000008f40000213d0000000101100190000008f40000c13d000000400070043f0000003f0120008c000008fb0000a13d0000000003030433000000000103004b000008f30000613d000300000003001d00000024017000390000000000410435000003610100004100000000001704350000000401700039000000060300002900000000003104350000000001000414000000040350008c000008b30000613d0000004404000039000000200600003900000000020500190000000003070019000400000007001d00000000050700190c8807d90000040f0000000102000031000000000101004b000009100000613d00000005050000290000000407000029000000200120008c000000000102001900000020010080390000001f01100039000000600110018f0000000003710019000003410130009c000008f40000213d000400000003001d000000400030043f000000200120008c000008f80000413d0000000001070433000200000001001d000700000005001d000108c40000003d00000c640000013d000000070440008a000000050440021000000352020000410c880ba10000040f0000000503000029000000000101004b000008f80000613d000003530100004100000004050000290000000000150435000000040150003900000006020000290000000000210435000000240150003900000000000104350000000001000414000000040230008c000008de0000613d00000044040000390000000002030019000000000305001900000000060000190c8807b50000040f0000000405000029000000000101004b000008fc0000613d000000400050043f0000000601000029000108e20000003d00000c820000013d0c880b8c0000040f00000002040000290000034e324000d1000000000304004b000008ea0000613d00000000434200d90000034e0330009c0000090c0000c13d00000003322000fa0000000201100039000000000301041a0000000002230019000108f00000003d00000c600000013d000000010330008c000009060000613d000000000021041b000000000001042d000003460100004100000000001004350000004101000039000009090000013d000000000100001900000000020000190c880b780000040f00000c3d0000013d000108fe0000003d00000c150000013d000009030000613d0000000006000019000109020000003d00000bd30000013d000009000000413d000000000604004b0000091b0000613d00000bdb0000013d000003460100004100000000001004350000001101000039000000040010043f000003470100004100000c8a0001043000000346010000410000000000100435000000110100003900000c590000013d000109120000003d00000c1b0000013d000009170000613d0000000006000019000109160000003d00000bd30000013d000009140000413d000000000604004b0000091b0000613d0001091b0000003d00000bc50000013d0c880b780000040f0005000000000002000500000002001d000109200000003d00000c2f0000013d0000036c0130009c000009460000813d0000006001300039000000400010043f000000000102041a00000325011001970000000001130436000400000001001d0000000101200039000300000002001d000200000003001d0c88083a0000040f000000040200002900000000001204350000000202000029000000400220003900000003030000290000000203300039000000000303041a000000000032043500000020031000390000000004010433000000010100003900000000020000190000000506000029000000000542004b000009430000813d000000050520021000000000055300190000000005050433000000000565013f0000032505500198000009450000613d0000000102200039000009390000013d00000000010000190000000002000019000000000001042d000003460100004100000000001004350000004101000039000000040010043f000003470100004100000c8a0001043000020000000000020000000401000039000000000101041a000100000001001d0000000002000019000000010120006c000009590000813d0000000001020019000200000002001d0c8808640000040f00000002020000290000000102200039000009510000013d000000000001042d000b000000000002000700000002001d000900000001001d0001095f0000003d00000c2f0000013d0000036c0130009c00000a0c0000813d0000006001300039000000400010043f000000000102041a00000325011001970000000001130436000800000001001d0000000101200039000600000002001d000500000003001d0c88083a0000040f000000080200002900000000001204350000000501000029000000400210003900000006010000290000000201100039000000000101041a000800000002001d0000000000120435000000090100002900000000001004350000000501000039000000200010043f0000004002000039000600000002001d00000000010000190c880b8c0000040f000000070200002900000325022001970000000000200435000000200010043f000000000100001900000006020000290c880b8c0000040f000000400300043d0000036d0230009c00000a0c0000213d0000004002300039000000400020043f000000000201041a000700000003001d00000000022304360000000101100039000000000101041a000500000002001d000000000012043500000008010000290000000001010433000600...",
"id": 2
}
```
***
### `eth_getStorageAt`
Retrieves the value from a storage position at a given address.
#### **Parameters**
**DATA, 20 bytes** - address
**QUANTITY** - index position of the storage slot in hexadecimal format, starting from `0x0`.
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
**DATA** - the value at this storage position.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getStorageAt",
"params": ["0xdfe68fb100c074c838d6e2c5a2d248308dcf090d", "0x0", "latest"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x00000000000000000000000035dd7b546b18aba0ec2a3e8d197c943745598385",
"id": 2
}
```
***
### `eth_getTransactionCount`
Gets the number of transactions sent from an address.
#### **Parameters**
**DATA, 20 bytes** - address
**QUANTITY | TAG** - integer block number, or the string "latest", "earliest", "pending", "safe" or "finalized".
#### **Returns**
**QUANTITY** - integer of the number of transactions sent from this address.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getTransactionCount",
"params": [
"0x22b758c7fada124b429f1b971e4c84e417ca6f58",
"latest"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x1b",
"id": 2
}
```
***
### `eth_getTransactionByHash`
Retrieves a transaction by its hash.
#### **Parameters**
**DATA, 32 bytes** - hash of a transaction.
#### **Returns**
Object - A transaction object, or null when no transaction was found:
* **blockHash**: DATA, 32 Bytes - hash of the block where this transaction was in. null when its pending.
* **blockNumber**: QUANTITY - block number where this transaction was in. null when its pending.
* from: DATA, 20 Bytes - address of the sender.
* **gas**: QUANTITY - gas provided by the sender.
* **gasPrice**: QUANTITY - gas price provided by the sender in Wei.
* **hash**: DATA, 32 Bytes - hash of the transaction.
* **input**: DATA - the data send along with the transaction.
* **nonce**: QUANTITY - the number of transactions made by the sender prior to this one.
* **to**: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.
* **transactionIndex**: QUANTITY - integer of the transactions index position in the block. null when its pending. value: QUANTITY - value transferred in Wei.
* **v**: QUANTITY - ECDSA recovery id
* **r**: QUANTITY - ECDSA signature r
* **s**: QUANTITY - ECDSA signature s
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getTransactionByHash",
"params": [
"0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"hash": "0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d",
"nonce": "0x1a",
"blockHash": "0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"blockNumber": "0x24ce3",
"transactionIndex": "0x0",
"from": "0x22b758c7fada124b429f1b971e4c84e417ca6f58",
"to": "0x4e792b8c9bcb9e200c3713810c4d6ea8c4230e7c",
"value": "0x0",
"gasPrice": "0x246139ca800",
"gas": "0x9c47d",
"input": "0x5ae401dc0000000000000000000000000000000000000000000000000000000066cedb6c0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000104472b43f3000000000000000000000000000000000000000000003ad8396379db5620e0000000000000000000000000000000000000000000000001a3e8310b01b9384000000000000000000000000000000000000000000000000000000000000008000000000000000000000000022b758c7fada124b429f1b971e4c84e417ca6f580000000000000000000000000000000000000000000000000000000000000003000000000000000000000000caf2fd3f47e7f46e99f74be579b2cc2233f33ef800000000000000000000000c1bf55ee54e16229d9b369a5502bfe5fc9f20b6d0000000000000000000000005b91e29ae5a71d9052620acb813d5ac25ec7a4a200000000000000000000000000000000000000000000000000000000",
"v": "0x32b",
"r": "0x1a525b1f2a322be504a9c317892573a9f6640512d6de9c97ed860777a8063449",
"s": "0x58344160546fe590a8d7305f26504ae99d534bd0cc778f380008658127f62c97",
"type": "0x0",
"maxFeePerGas": "0x2464f377200",
"maxPriorityFeePerGas": "0x2464f377200",
"chainId": "0x184"
},
"id": 2
}
```
***
### `eth_getTransactionByBlockHashAndIndex`
Retrieves a transaction by block hash and transaction index position.
#### **Parameters**
**DATA, 32 bytes** - hash of a block.
**QUANTITY** - integer of the transaction index position, starting from `0x0`.
#### **Returns**
The response contains detailed information about the transaction, see `eth_getTransactionByHash`.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getTransactionByBlockHashAndIndex",
"params": [
"0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"0x0"
]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"hash": "0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d",
"nonce": "0x1a",
"blockHash": "0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"blockNumber": "0x24ce3",
"transactionIndex": "0x0",
"from": "0x22b758c7fada124b429f1b971e4c84e417ca6f58",
"to": "0x4e792b8c9bcb9e200c3713810c4d6ea8c4230e7c",
"value": "0x0",
"gasPrice": "0x246139ca800",
"gas": "0x9c47d",
"input": "0x5ae401dc0000000000000000000000000000000000000000000000000000000066cedb6c0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000104472b43f3000000000000000000000000000000000000000000003ad8396379db5620e0000000000000000000000000000000000000000000000001a3e8310b01b9384000000000000000000000000000000000000000000000000000000000000008000000000000000000000000022b758c7fada124b429f1b971e4c84e417ca6f580000000000000000000000000000000000000000000000000000000000000003000000000000000000000000caf2fd3f47e7f46e99f74be579b2cc2233f33ef800000000000000000000000c1bf55ee54e16229d9b369a5502bfe5fc9f20b6d0000000000000000000000005b91e29ae5a71d9052620acb813d5ac25ec7a4a200000000000000000000000000000000000000000000000000000000",
"v": "0x32b",
"r": "0x1a525b1f2a322be504a9c317892573a9f6640512d6de9c97ed860777a8063449",
"s": "0x58344160546fe590a8d7305f26504ae99d534bd0cc778f380008658127f62c97",
"type": "0x0",
"maxFeePerGas": "0x2464f377200",
"maxPriorityFeePerGas": "0x2464f377200",
"chainId": "0x184"
},
"id": 2
}
```
***
### `eth_getTransactionReceipt`
Retrieves the receipt of a transaction by transaction hash.
#### **Parameters**
**DATA, 32 bytes** - unique hash of the transaction.
#### **Returns**
Object - A transaction receipt object, or null when no receipt was found:
* **transactionHash** : DATA, 32 Bytes - hash of the transaction.
* **transactionIndex**: QUANTITY - integer of the transactions index position in the block.
* **blockHash**: DATA, 32 Bytes - hash of the block where this transaction was in.
* blockNumber: QUANTITY - block number where this transaction was in.
* **from**: DATA, 20 Bytes - address of the sender.
* **to**: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.
* **cumulativeGasUsed** : QUANTITY - The total amount of gas used when this transaction was executed in the block.
* **effectiveGasPrice** : QUANTITY - The sum of the base fee and tip paid per unit of gas.
* **gasUsed** : QUANTITY - The amount of gas used by this specific transaction alone. contractAddress : DATA, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise null.
* **logs**: Array - Array of log objects, which this transaction generated.
* **logsBloom**: DATA, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs.
* **type**: QUANTITY - integer of the transaction type, 0x0 for legacy transactions, 0x1 for access list types, 0x2 for dynamic fees.
It also returns either:
* **root**: DATA 32 - bytes of post-transaction stateroot (pre Byzantium)
* **status**: QUANTITY - either `0x1` (success) or `0x0` (failure)
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_getTransactionReceipt",
"params": ["0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d"]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"transactionHash": "0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d",
"transactionIndex": "0x0",
"blockHash": "0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"blockNumber": "0x24ce3",
"l1BatchTxIndex": null,
"l1BatchNumber": null,
"from": "0x22b758c7fada124b429f1b971e4c84e417ca6f58",
"to": "0x4e792b8c9bcb9e200c3713810c4d6ea8c4230e7c",
"cumulativeGasUsed": "0x0",
"gasUsed": "0x2da41",
"contractAddress": null,
"logs": [
{
"address": "0x000000000000000000000000000000000000800a",
"topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x00000000000000000000000022b758c7fada124b429f1b971e4c84e417ca6f58",
"0x0000000000000000000000000000000000000000000000000000000000008001"
],
"data": "0x0000000000000000000000000000000000000000000000001637b9ee235aaa00",
"blockHash": "0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"blockNumber": "0x24ce3",
"l1BatchNumber": null,
"transactionHash": "0xba8058c4fc73f488d7fcaaa6b3d8c71290458d1d9fd3091204547eb50cd71a4d",
"transactionIndex": "0x0",
"logIndex": "0x0",
"transactionLogIndex": "0x0",
"logType": null,
"removed": false,
"blockTimestamp": "0x66ced6ec"
},
...
],
"l2ToL1Logs": [],
"status": "0x1",
"root": "0x5f86ad83c06d90c0922f9c829c9f8642fc37466eae84ef64c19d8392451a0276",
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"type": "0x0",
"effectiveGasPrice": "0x246139ca800"
},
"id": 2
}
```
***
### `eth_protocolVersion`
Returns the current Ethereum protocol version.
#### **Parameters**
None
#### **Returns**
**String** - A single string indicating the protocol version. The version is prefixed with an identifier (e.g. "zks" for ZKsync) followed by a version number.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_protocolVersion",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "zks/1",
"id": 2
}
```
***
### `eth_sendRawTransaction`
Submits a pre-signed transaction for broadcast to the network.
#### **Parameters**
**DATA** - The complete, signed transaction data.
#### **Returns**
**DATA, 32 bytes** - A single string that is the hash of the transaction if it has been successfully submitted to the network. This hash can be used to track the transaction's inclusion in a block and subsequent execution status.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_sendRawTransaction",
"params": ["0xf86c808504a817c80082520894095e7baea6a6c7c4c2dfeb977efac326af552d870a868e8..."]
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "0x2f5d6a8af654c249bc487e7c7b926a3f3f165b575a6485a487f12c7a9e3c8e45",
"id": 2
}
```
***
### `eth_accounts`
Returns a list of addresses owned by the client.
#### **Parameters**
None
#### **Returns**
**Array of DATA, 20 bytes** - An array of account addresses owned by the client.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_accounts",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": [],
"id": 2
}
```
***
### `eth_feeHistory`
Retrieves the fee history for the requested blocks.
#### **Parameters**
**uint64** - the number of the blocks to check.
**QUANTITY** - the latest block number.
**Array of float32** - The percentiles of transaction fees to return.
#### **Returns**
Object containing the following fields:
* **oldestBlock**: QUANTITY - block number in hex of the oldest block queried.
* **baseFeePerGas**: Array of QUANTITY - An array of base fees per gas, represented in hex, for each block.
* **gasUsedRatio**: Array of Float - An array of ratios of gas used by each block, represented as floats.
* **reward**: Array of Array\ - An array of arrays containing the transaction fee rewards at specified percentiles, each represented in hex.
#### **Example Request**
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": {
"oldestBlock": "0x24d8e",
"baseFeePerGas": [
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800",
"0x246139ca800"
],
"gasUsedRatio": [
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0
],
"reward": [
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"],
["0x0", "0x0", "0x0"]
],
"baseFeePerBlobGas": [
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0",
"0x0"
],
"blobGasUsedRatio": [
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0,
0.0
]
},
"id": 1
}
```
### `web3_clientVersion`
**Note:** The `sha3` method is intentionally omitted from the main server implementation, as it can be readily implemented on the client side if necessary.
Retrieves the version of the client software.
#### **Parameters**
None
#### **Returns**
**String** - The client version supported by the node. The version is prefixed with an identifier (e.g. "ZKsync" for ZKsync) followed by a version number.
#### **Example Request**
```bash
curl --request POST \
--url https://mainnet.zkevm.cronos.org \
--header 'Content-Type: application/json' \
--data '{
"id": 1,
"jsonrpc": "2.0",
"method": "web3_clientVersion",
"params": []
}'
```
#### **Example Response**
```bash
{
"jsonrpc": "2.0",
"result": "ZKsync/v2.0",
"id": 1
}
```
***
[ ](https://docs.zksync.io/build/api-reference/debug-rpc)
# Running nodes
Read this section on how to set up a node on Cronos zkEVM Mainnet and Testnet.
# Cronos zkEVM Mainnet
This guide covers running a node for Cronos zkEVM mainnet (Chain ID: 388) with external-node v24.23.0 on docker.
## Pre-requisites
* [Docker](https://www.docker.com/get-started) and [Docker-compose](https://docs.docker.com/compose/install/)
### Prepare your machine
This configuration is approximate and should be considered as minimal requirements for:
{% tabs %}
{% tab title="Full Node" %}
{% hint style="info" %}
**Full Node** - is configured to build and store the last 7 days of data for Cronos zkEVM mainnet by default. Check [here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/08_pruning.md#configuration) for details on the pruning setting.
{% endhint %}
Minimal requirements:
* 4-core of CPU
* 16GB of RAM
* 100G of SSD storage
{% endtab %}
{% tab title="Archive Node" %}
{% hint style="info" %}
**Archive Node** - is configured to build an archive of ***all historical data*** of Cronos zkEVM mainnet;
{% endhint %}
Minimal requirements:
* 4-core of CPU
* 32GB of RAM
* 500G of SSD storage
{% endtab %}
{% endtabs %}
## **Step 1: Download the DB Dump**
### 1.1 - Download the pgdump
Create a new folder and download the dump file into it:
### 1.2 - Extract the data from dump
After extracting the file, locate the `dump` folder and the `pg_restore.list` file. Put both to the main directory, instead of default under “external\_node”.
## Step 2: Docker Preparations
### 2.1 - Pull Docker Image
Under the same directory, pull docker image from [Github Container Registry](https://github.com/cronos-labs/cronos-zkevm/pkgs/container/external-node):
```bash
docker pull ghcr.io/cronos-labs/external-node:mainnet-v24.23.0
```
### 2.2 - Create Docker Compose Configuration
Inside that directory, create and edit `docker-compose.yml` :
```bash
nano docker-compose.yml
```
Add the following configuration to `docker-compose.yml`:
{% tabs %}
{% tab title="Full Node" %}
```yaml
services:
cronoszk:
image: "ghcr.io/cronos-labs/external-node:mainnet-v24.23.0"
network_mode: host
restart: unless-stopped
stop_grace_period: "120s"
user: 0:0
volumes:
- "${PWD}:/db"
environment:
DATABASE_POOL_SIZE: 10
DATABASE_URL: "postgresql://zksync:password@localhost:5432/zksync"
EN_ETH_CLIENT_URL: "https://ethereum-rpc.publicnode.com"
EN_HEALTHCHECK_PORT: 3081
EN_HTTP_PORT: 3060
EN_L1_BATCH_COMMIT_DATA_GENERATOR_MODE: "Validium"
EN_L1_CHAIN_ID: 1
EN_L2_CHAIN_ID: 388
EN_MAIN_NODE_URL: "https://seed.zkevm.cronos.org"
EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"
EN_PROMETHEUS_PORT: 3312
EN_PRUNING_ENABLED: "true" #Note: Default value is false, i.e. no purning
EN_REQ_ENTITIES_LIMIT: 1000
EN_SNAPSHOTS_RECOVERY_ENABLED: "true"
EN_SNAPSHOTS_OBJECT_STORE_BUCKET_BASE_URL: "cronos-zkevm-mainnet-en-snapshot"
EN_SNAPSHOTS_OBJECT_STORE_MODE: 'GCSAnonymousReadOnly'
EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
EN_WS_PORT: 3061
RUST_LOG: "warn,zksync=info,zksync_core::metadata_calculator=debug,zksync_state=debug,zksync_utils=debug,zksync_web3_decl::client=error"
postgres:
image: postgres:16
restart: unless-stopped
stop_grace_period: "120s"
network_mode: host
environment:
POSTGRES_DB: zksync
POSTGRES_USER: zksync
POSTGRES_PASSWORD: password
ulimits:
nofile: 60000
nproc: 60000
memlock: -1
volumes:
- "${PWD}/pgsql_data:/var/lib/postgresql/data/"
- "${PWD}:/dump"
```
{% endtab %}
{% tab title="Archive Node" %}
```yaml
services:
cronoszk:
image: "ghcr.io/cronos-labs/external-node:mainnet-v24.23.0"
network_mode: host
restart: unless-stopped
stop_grace_period: "120s"
user: 0:0
volumes:
- "${PWD}:/db"
environment:
DATABASE_POOL_SIZE: 10
DATABASE_URL: "postgresql://zksync:password@localhost:5432/zksync"
EN_ETH_CLIENT_URL: "https://ethereum-rpc.publicnode.com"
EN_HEALTHCHECK_PORT: 3081
EN_HTTP_PORT: 3060
EN_L1_BATCH_COMMIT_DATA_GENERATOR_MODE: "Validium"
EN_L1_CHAIN_ID: 1
EN_L2_CHAIN_ID: 388
EN_MAIN_NODE_URL: "https://seed.zkevm.cronos.org"
EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"
EN_PROMETHEUS_PORT: 3312
EN_PRUNING_ENABLED: "false" #Note: Default value is false, i.e. no purning
EN_REQ_ENTITIES_LIMIT: 1000
EN_SNAPSHOTS_RECOVERY_ENABLED: "false"
EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
EN_WS_PORT: 3061
RUST_LOG: "warn,zksync=info,zksync_core::metadata_calculator=debug,zksync_state=debug,zksync_utils=debug,zksync_web3_decl::client=error"
postgres:
image: postgres:16
restart: unless-stopped
stop_grace_period: "120s"
network_mode: host
environment:
POSTGRES_DB: zksync
POSTGRES_USER: zksync
POSTGRES_PASSWORD: password
ulimits:
nofile: 60000
nproc: 60000
memlock: -1
volumes:
- "${PWD}/pgsql_data:/var/lib/postgresql/data/"
- "${PWD}:/dump"
```
{% endtab %}
{% endtabs %}
{% hint style="warning" %}
**Important**
Make sure you have the correct vars, volume attachment under the correct path.
{% endhint %}
{% hint style="info" %}
**Note**
* **`EN_PRUNING_ENABLED`**: Determines whether the node is set to pruning mode. When enabled, the node retains only recent chain data and discards older data to conserve storage space.
* **`EN_SNAPSHOTS_RECOVERY_ENABLED`**, **`EN_SNAPSHOTS_OBJECT_STORE_BUCKET_BASE_URL`**, and **`EN_SNAPSHOTS_OBJECT_STORE_MODE`**: Enable snapshots recovery (similar to state-sync) and allows the node to recover from the latest batch without containing the full historical data.
* **Add** **`debug`** to namespaces: Enables debug tracing and saves debug data.`EN_API_NAMESPACES:`Defines the enabled API namespaces, including `eth`, `net, web3, zks, pubsub, and debug`.
* Read more on Snapshots Recovery [here](https://github.com/matter-labs/zksync-era/blob/c83cca8fe7fa105ec6b1491e4efb9f9e4bd66d41/docs/guides/external-node/07_snapshots_recovery.md).
{% endhint %}
## Step 3: Database Restoration
### 3.1 - Start PostgreSQL Container:
```bash
docker compose up -d postgres
```
Please note `postgres` was named in docker-compose.
When container is running, list containers to find the container ID:
```bash
docker ps
```
Below is the example output:
```bash
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e29741123132 postgres:16 "docker-entrypoint.s…" 31 seconds ago Up 30 seconds zkevm_mainnet-postgres-1
```
### 3.2 - Restore Database from Dump
Run the following and docker retrieve and manipulate the data from data dump:
```bash
docker exec -it pg_restore -x -O -j2 -L -d -U
```
Example:
```bash
docker exec -it e29741123132 pg_restore -x -O -j2 -L /dump/pg_restore.list -d zksync -U zksync /dump/dump
```
{% hint style="info" %}
**NOTE**
The `username` and `database` names were defined in the`docker-compose`; in this example, they are `zksync` and `zksync`, respectively.
{% endhint %}
During the process, on the docker side, you should see:
The duration of the process may vary depending on the specifications, potentially taking several hours.
## Step 4: Run Everything
Once the pg restore completed, start the cronoszk node service:
```bash
docker compose up -d
```
Example output should be like:
```bash
[+] Running 2/2
✔ Container zkevm_mainnet-cronoszk-1 Started 0.1s
✔ Container zkevm_mainnet-postgres-1 Running
```
You should see in the Docker logs that the node is fetching block data from the RPCs.
For example:
Once the node is synchronized, you may use `EN_HTTP_PORT: 3060` as defined for ETH-JSON RPC calls.
# Cronos zkEVM Sepolia Testnet
This guide covers running a node for Cronos zkEVM testnet (Chain ID: 240) with external-node v24.23.0 on docker.
Pre-requisites
* [Docker](https://www.docker.com/get-started) and [Docker-compose](https://docs.docker.com/compose/install/)
### Prepare your machine
This configuration is approximate and should be considered as minimal requirements:
{% tabs %}
{% tab title="Full Node" %}
{% hint style="info" %}
**Full Node** - is configured to build and store the last 7 days of data for Cronos zkEVM Sepolia Testnet by default. Check [here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/external-node/08_pruning.md#configuration) for details on the pruning setting.
{% endhint %}
* 4-core of CPU
* 16GB of RAM
* 100G of SSD storage
{% endtab %}
{% tab title="Archive Node" %}
{% hint style="info" %}
**Archive Node** - is configured to build an archive of ***all historical data*** of Cronos zkEVM Sepolia Testnet;
{% endhint %}
* 4-core of CPU
* 32GB of RAM
* 500G of SSD storage
{% endtab %}
{% endtabs %}
## **Step 1: Download the DB Dump**
### 1.1 - Download the pgdump
Create a new folder and download the dump file into it by:
```bash
wget https://storage.googleapis.com/cronos-zkevm-testnet-en-pgdump/external_node.tar.gz
```
### 1.2 - Extract the data from dump
After extracting the file, locate the `dump` folder and the `pg_restore.list` file. Put both to the main directory, instead of default under “external\_node”.
## Step 2: Docker Preparations
### 2.1 - Pull Docker Image
Under the same directory, pull docker image from[ Github Container Registry](https://github.com/cronos-labs/cronos-zkevm/pkgs/container/external-node):
```bash
docker pull http://ghcr.io/cronos-labs/external-node:v26.2.1-20250213
```
### 2.2 - Create Docker Compose Configuration
Inside that directory, create and edit `docker-compose.yml` :
```bash
nano docker-compose.yml
```
Add the following configuration to `docker-compose.yml`:
{% tabs %}
{% tab title="Full Node" %}
```yaml
services:
cronoszk:
image: "ghcr.io/cronos-labs/external-node:testnet-v24.23.0"
network_mode: host
restart: unless-stopped
stop_grace_period: "120s"
user: 0:0
volumes:
- "${PWD}:/db" # Path to the rocksdb you unzipped
environment:
DATABASE_POOL_SIZE: 10
DATABASE_URL: "postgresql://zksync:password@localhost:5432/mydb"
EN_ETH_CLIENT_URL: "https://ethereum-sepolia-rpc.publicnode.com"
EN_HEALTHCHECK_PORT: 3081
EN_HTTP_PORT: 3060
EN_L1_BATCH_COMMIT_DATA_GENERATOR_MODE: "Validium"
EN_L1_CHAIN_ID: 11155111
EN_L2_CHAIN_ID: 240
EN_MAIN_NODE_URL: "https://seed.testnet.zkevm.cronos.org/"
EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"
EN_PROMETHEUS_PORT: 3312
EN_PRUNING_ENABLED: "true" #Note: Default value is false, i.e. no purning
EN_REQ_ENTITIES_LIMIT: 1000
EN_SNAPSHOTS_RECOVERY_ENABLED: "true"
EN_SNAPSHOTS_OBJECT_STORE_BUCKET_BASE_URL: "cronos-zkevm-testnet-en-snapshot"
EN_SNAPSHOTS_OBJECT_STORE_MODE: "GCSAnonymousReadOnly"
EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
EN_WS_PORT: 3061
RUST_LOG: "warn,zksync=info,zksync_core::metadata_calculator=debug,zksync_state=debug,zksync_utils=debug,zksync_web3_decl::client=error"
postgres:
image: postgres:16
restart: unless-stopped
stop_grace_period: "120s"
network_mode: host
environment:
POSTGRES_DB: mydb
POSTGRES_USER: zksync
POSTGRES_PASSWORD: password
ulimits:
nofile: 60000
nproc: 60000
memlock: -1
volumes:
- "${PWD}/pgsql_data:/var/lib/postgresql/data/"
- "${PWD}:/dump" # This is the location of where the dump is.
```
{% endtab %}
{% tab title="Archive Node" %}
```yaml
services:
cronoszk:
image: "ghcr.io/cronos-labs/external-node:testnet-v24.23.0"
network_mode: host
restart: unless-stopped
stop_grace_period: "120s"
user: 0:0
volumes:
- "${PWD}:/db" # Path to the rocksdb you unzipped
environment:
DATABASE_POOL_SIZE: 10
DATABASE_URL: "postgresql://zksync:password@localhost:5432/mydb"
EN_ETH_CLIENT_URL: "https://ethereum-sepolia-rpc.publicnode.com"
EN_HEALTHCHECK_PORT: 3081
EN_HTTP_PORT: 3060
EN_L1_BATCH_COMMIT_DATA_GENERATOR_MODE: "Validium"
EN_L1_CHAIN_ID: 11155111
EN_L2_CHAIN_ID: 282
EN_MAIN_NODE_URL: "https://seed.testnet.zkevm.cronos.org/"
EN_MERKLE_TREE_PATH: "./db/ext-node/lightweight"
EN_PROMETHEUS_PORT: 3312
EN_PRUNING_ENABLED: "false" #Note: Default value is false, i.e. no purning
EN_REQ_ENTITIES_LIMIT: 1000
EN_SNAPSHOTS_RECOVERY_ENABLED: "false"
EN_SNAPSHOTS_OBJECT_STORE_BUCKET_BASE_URL: "cronos-zkevm-testnet-en-snapshot"
EN_SNAPSHOTS_OBJECT_STORE_MODE: "GCSAnonymousReadOnly"
EN_STATE_CACHE_PATH: "./db/ext-node/state_keeper"
EN_WS_PORT: 3061
RUST_LOG: "warn,zksync=info,zksync_core::metadata_calculator=debug,zksync_state=debug,zksync_utils=debug,zksync_web3_decl::client=error"
postgres:
image: postgres:16
restart: unless-stopped
stop_grace_period: "120s"
network_mode: host
environment:
POSTGRES_DB: mydb
POSTGRES_USER: zksync
POSTGRES_PASSWORD: password
ulimits:
nofile: 60000
nproc: 60000
memlock: -1
volumes:
- "${PWD}/pgsql_data:/var/lib/postgresql/data/"
- "${PWD}:/dump" # This is the location of where the dump is.
```
{% endtab %}
{% endtabs %}
{% hint style="warning" %}
**Important**
Make sure you have the correct vars, volume attachment under the correct path.
{% endhint %}
{% hint style="info" %}
**Note**
* **`EN_PRUNING_ENABLED`**: Determines whether the node is set to pruning mode. When enabled, the node retains only recent chain data and discards older data to conserve storage space.
* **`EN_SNAPSHOTS_RECOVERY_ENABLED`**, **`EN_SNAPSHOTS_OBJECT_STORE_BUCKET_BASE_URL`**, and **`EN_SNAPSHOTS_OBJECT_STORE_MODE`**: Enable snapshots recovery (similar to state-sync) and allows the node to recover from the latest batch without containing the full historical data.
* **Add** **`debug`** to namespaces: Enables debug tracing and saves debug data.`EN_API_NAMESPACES:`Defines the enabled API namespaces, including `eth`, `net, web3, zks, pubsub, and debug`.
* Read more on Snapshots Recovery [here](https://github.com/matter-labs/zksync-era/blob/c83cca8fe7fa105ec6b1491e4efb9f9e4bd66d41/docs/guides/external-node/07_snapshots_recovery.md).
{% endhint %}
## Step 3: Database Restoration
### 3.1 - Start PostgreSQL Container:
```bash
docker compose up -d postgres
```
Please note `postgres` was named in docker-compose.
When container is running, list containers to find the container ID:
```bash
docker ps
```
Below is the example output:
```bash
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e0955341a0dd postgres:16 "docker-entrypoint.s…" 5 hours ago Up 4 hours zkevmtest-postgres-1
```
### 3.2 - Restore Database from Dump
Run the following and docker retrieve and manipulate the data from data dump:
```bash
docker exec -it pg_restore -x -O -j2 -L -d -U
```
Example:
```bash
docker exec -it ad4c924d075a pg_restore -x -O -j2 -L /dump/pg_restore.list -d mydb -U zksync /dump/dump
```
{% hint style="info" %}
**NOTE**
The `username` and `database` names were defined in the`docker-compose`; in this example, they are `zksync` and `mydb`, respectively.
{% endhint %}
During the process, on the docker side, you should see:
Depending on the specs, the process might take several hours.
## Step 4: Run everything
Once the pg restore completed, start the cronoszk node service:
```bash
docker compose up -d
```
Example output should be like:
```bash
[+] Running 2/2
✔ Container zkevmtest-cronoszk-1 Started 0.1s
✔ Container zkevmtest-postgres-1 Started 0.1s
```
You should see in the Docker logs that the node is fetching block data from the RPCs.
For example:
Once the node is synchronized, you may use `EN_HTTP_PORT: 3060` as defined for ETH-JSON RPC calls.
# Media/Brand Kit
Cronos zkEVM logos
{% file src="/files/s6Lq3wPNpGWSZRs9L4AR" %}
