Exchange migration FAQ

Yes. This is a 1:1 balance migration. Balances will be migrated from legacy Schnorr-based addresses to the fresh EVM-compatible addresses provided by the exchange. There are no new tokens or token contracts for exchange users, as ZIL remains the network's native coin.

Legacy exchange deposit addresses, hot wallets, and cold wallets will be deny-listed as part of the migration to prevent users from accidentally sending funds to deprecated addresses after the balance migration.

No. The Zilliqa mainnet is not being deprecated. The network is and will continue to operate as usual. The only change is that native ZIL transactions using legacy Schnorr-based signatures will no longer be supported. EVM transactions will continue to function normally. If your exchange has any ZRC-20 tokens listed, please let us know.

Yes. For verified exchange-controlled operational wallets that lost ZIL as a direct result of the exploit, Zilliqa will establish a recovery process under which the verified amount lost will be restored by minting additional ZIL and crediting it to the EVM address provided by the exchange, subject to the agreed verification and audit process.

Legacy exchange deposit addresses, hot wallets, and cold wallets will be deny-listed as part of the migration to prevent users from accidentally sending funds to deprecated addresses after the balance migration.

Please note: The above recovery process applies only to verified exchange-controlled operational wallets. For retail users with self-custodied wallets, we are still finalizing the migration and recovery process, and additional details will be shared once available.

Could you provide more details about your wallet setup? Specifically:

• What type of non-Ledger wallet are you using?
• Are the balances held in the non-Ledger wallet user deposit address?
• Are both wallets exchange-controlled operational wallets?

This information will help us determine the appropriate migration process.

Please email it to enquiry@zilliqa.com from Exchange’s official email address.

There is no new mainnet. Zilliqa will continue to operate on the same mainnet. The only change is that support for legacy Schnorr-based native ZIL will be retired, and exchanges will use EVM-compatible addresses going forward.

There is no new network. The existing Zilliqa mainnet continues to operate. This migration retires the legacy Schnorr-based transaction flow and transitions exchanges to EVM-compatible addresses. Since this is not a new network deployment, there is no separate audit report for a new mainnet.

No. This is not a migration of the entire network. The Zilliqa mainnet will continue to operate as usual. The migration applies only to balances held in legacy Schnorr-based addresses, which will be migrated to newly generated EVM-compatible addresses provided by exchanges. As part of this process, the legacy Schnorr-based address scheme will be retired, while existing EVM functionality will continue to operate unchanged.

Legacy exchange deposit addresses, hot wallets, and cold wallets will be deny-listed as part of the migration to prevent users from accidentally sending funds to deprecated addresses after the balance migration.

• Official Zilliqa 2 GitHub repository: https://github.com/Zilliqa/zq2
• Zilliqa 2 mainnet explorer: https://zilliqa.blockscout.com/

We are currently sharing the migration proposal with exchanges while working internally to finalize the implementation schedule. As this requires preparation from both the exchanges and the Zilliqa team, the hard fork date and snapshot block height have not yet been finalized. We will communicate them as soon as they are confirmed.

The submission deadline is still being finalized. We will communicate it to all exchanges as soon as it is confirmed. In the meantime, could you let us know approximately how many legacy deposit addresses and operational wallets will need to be migrated from your side?

Our goal is to migrate all exchange-managed balances during a single network-wide hard fork. While the preparation, verification, and submission process will be coordinated individually with each exchange, the balance migration itself is intended to occur simultaneously once the required address mappings have been received and verified.

Does this include:

• User deposit addresses
• Hot wallets
• Cold wallets
• Fee wallets
• Other operational wallets

Yes. Exchanges should provide all legacy non-EVM (Schnorr-based) addresses that hold or are used to transfer native ZIL. This includes user deposit addresses, hot wallets, cold wallets, fee wallets, and any other exchange-controlled operational wallets.

If your exchange has any ZRC-20 tokens listed, please provide details of those tokens as well so we can assess whether there are any exchange-specific considerations for the migration.

Could you elaborate on your use case? Based on our understanding, each user is typically assigned a unique deposit address, so we would expect a one-to-one mapping between a legacy user deposit address and its corresponding EVM address. There may be a gap in our understanding of your wallet architecture or operational model, so we'd appreciate it if you could explain your scenario in more detail.

Our understanding is that balances held in user deposit addresses are typically swept into exchange operational wallets as part of your standard operations. As a result, user deposit addresses would generally have a zero balance, except where a balance sweep has not yet occurred.

Could you please confirm whether this understanding is correct for your exchange? If not, could you explain your operational model and the specific use case behind this question?

For auditability and verification purposes, we recommend providing a one-to-one mapping between legacy operational wallets and their destination EVM addresses wherever practical. Once the balances have been migrated, you are free to consolidate or redistribute the funds within your own EVM wallet infrastructure as needed.

Will the migration be conducted through:

• Direct reassignment of balances at the protocol state level during the hard fork;
• On-chain transfers to the designated EVM addresses;
• Minting new ZIL to the destination addresses while retiring the legacy balances; or
• A separate migration or claim contract?

The balance migration will be performed through direct reassignment of balances at the protocol state level during the hard fork. No on-chain transfers or claim contract will be required for the balance migration for exchange accounts migration.

The snapshot block height, balance migration, and hard fork schedule are still being finalized. We will communicate the exact block heights and timeline once they are confirmed.

The balance migration and deny-list activation will occur together during the hard fork. Any transactions sent to legacy Schnorr-based addresses (or their deterministic EVM equivalents) after the hard fork will be rejected by the network.

Please provide all legacy non-EVM (Schnorr-based) addresses associated with your exchange, including user deposit addresses, hot wallets, cold wallets, fee wallets, and any other operational wallets, regardless of whether they currently hold a balance. This ensures that all legacy exchange addresses can be added to the deny-list as part of the migration.

The destination address must not be the deterministic EVM representation of an existing Zilliqa 1 key. If your existing EVM wallet was independently generated and is not derived from any legacy Zilliqa 1 private key, it can be used as the destination. Otherwise, a freshly generated EVM key pair should be used.