Layer 1 blockchain
Zilliqa ticker ZIL
Summary
Zilliqa 2.0 is a proof-of-stake chain whose node software (zq2, written in Rust) implements Pipelined Fast-HotStuff. Validators deposit at least 10 million ZIL in a system deposit contract, directly or through delegated staking pools. For each view one validator leads and proposes a block; validators vote, and votes count by stake. A block and its ancestors become final once it has a child proposed in the next view and a grandchild after that, normally two confirmations. Half of each block reward goes to the proposer and half to the signing validators by stake, paid from a reserve held at the zero address, which also receives fees. The chain replaced the original design, which used proof-of-work only to admit nodes and ran pBFT inside shards and a directory-service committee, on the same mainnet at block 4,770,088 (23 June 2025). 2781011121416
Design
- System
- Layer 1 blockchainIndependent proof-of-stake chain with its own validators; it does not settle to another chain. The current network, Zilliqa 2.0, took over the existing mainnet at block 4,770,088 on 23 June 2025, carrying accounts, balances and contract state across from the original sharded design, which is described here as history. Since block 31,759,109 (16:37 UTC on 20 July 2026) the network no longer executes legacy (non-EVM) transactions, and since block 36,383,379 (22 September 2026) it accepts them only as transfers to a migration escrow contract, so the EVM side is its only production path.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- The deposit contract picks each view's leader pseudo-randomly, weighted by stake; since block 25,905,600 (estimated for 5 May 2026) the randomness comes from RANDAO. Validators that missed too many recent views are jailed: skipped as leaders, they still vote and earn the signer share. The docs say a typical mainnet can run on 32 validator nodes. The certificate on block 31,759,109 (20 July 2026) listed 14 signers at committee positions numbered up to 21, which suggests more than 20 validators then; the current count and operators were not verified.
- Fork choice
- No open weight-based chain selection. Each block carries a quorum certificate, and a certificate needs votes from validators holding more than two-thirds of committee stake. Finality follows the child-and-grandchild rule in the docs, and the legacy API reports balances from the latest finalized block. Jailing is the only penalty found in the reviewed code; no stake is slashed.
Qualifications
- Settlement family · Partial. Recorded as other. Zilliqa's own terms: Zilliqa 2.0, a proof-of-stake network run by its own Rust node software (zq2) with Pipelined Fast-HotStuff consensus, an EVM execution layer (chain ID 32769) and the retained state of Scilla contracts from the original chain.
- Finality · Partial. Recorded as other. Zilliqa's own terms: a block and its ancestors are finalized once the block has a child proposed in the next view and a grandchild in a later view, each carried by a quorum certificate from validators holding more than two-thirds of committee stake; normally two block confirmations. Jailing for missed views is the only penalty; stake is not slashed.
- Legacy transactions · Partial. Since block 31,759,109 (20 July 2026) the network skips legacy (Schnorr-signed, non-EVM) transactions; from block 36,383,379 (22 September 2026) it accepts them only as transfers to the migration escrow. Forks at blocks 34,844,968 and 36,383,378 sweep listed accounts, moving each balance to a destination named in the list and freezing the account; a third list is due at block 37,410,000, not reached on 29 September 2026. Scilla state remains, and 100 listed EVM contract addresses may still call Scilla contracts through the interop precompile.
- Sharding · Not applicable. The original Zilliqa split its miners into shards under a directory-service committee. Zilliqa 2.0 runs one validator committee with no execution shards; the x-shards announced in 2024 are covered in their own entry.
- X shards · Unknown. Zilliqa's June 2024 announcement described sovereign, application-specific x-shards that communicate with mainnet, and the node repository contains shard contracts. No live x-shard on mainnet, or its trust model, was verified, so none is recorded as a scaling layer.
- Slashing · Not applicable. No slashing path was found in the live deposit contract (version 8, since block 25,902,000), in version 9 (scheduled for block 37,411,200, not yet reached on 29 September 2026) or in the node's consensus code. Validators that miss views are jailed, which removes their turns as leader but keeps their vote and signer reward.
- Evm compatibility · Partial. The EVM follows Cancun rules since block 19,486,411 (estimated for 5 February 2026); no later rule set appears in the node code at release v0.21.10. EVM gas has a minimum price of 4,761.9048 Gwei and a block limit of 84 million gas. ZIL shows 18 decimals on the EVM side and 12 decimals (Qa) in the legacy API.
- Tps · Unknown. No current transaction-rate figure with a stated method was found in Zilliqa's documentation, so none is recorded. The 2017 whitepaper's scaling claims describe the retired sharded design.
Tradeoffs
- Emphasizes
- Scalability and Security Contested
- Gives up
- Open, large-scale block production. The docs say a typical mainnet can run on 32 validator nodes, each needing 10 million ZIL of stake (pools let holders share a deposit); a July 2026 block certificate points to a committee of more than 20. In July 2026 a core-team client hotfix and its hard fork took effect about a day and a half after the first theft report and stopped all legacy transactions; later forks swept exchange balances at the protocol level and froze old addresses. Those steps show that the core team and validators can change state rules quickly.Zilliqa's developer portal presents Zilliqa 2.0 as a fast-finality, scalable protocol, and its June 2024 announcement set the aim of a fast, scalable, decentralised and secure chain; reading that as all three corners at once is contested. Stake at risk is limited: the only penalty found is jailing for missed views, and no slashing path was found in the reviewed deposit contract or node code.
- Full node at home
- Practical at home 3456Zilliqa's node guide lists at least 2 cores with 4 threads, 8 GB of RAM and 200 GB of disk, on Ubuntu 22.04 or later with Docker, and an open P2P port; it does not recommend running behind NAT. Zilliqa runs its own nodes on an 8-vCPU cloud machine with a 256 GB SSD. Mainnet nodes must start from a checkpoint file downloaded from Zilliqa's checkpoint bucket, so they trust that checkpoint and hold no history before it; sync then takes about 1 to 2 hours. Validating needs a 10 million ZIL deposit, directly or through a pool.
- Throughput claims
- No classified figure recorded
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | No hash-time-locked or other trust-minimized swap mechanism was documented for Zilliqa. EVM contracts could host one, but none was reviewed. |
| Authenticated data publication | Unknown | Not researched for Zilliqa under this row's definition; no data-publication feature was found in the reviewed docs. |
| Light clients | Unknown | No light client for Zilliqa 2.0 was found in the reviewed docs. Mainnet nodes start from checkpoint files published by Zilliqa, which was not shown to support independent light verification. 4 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel system on Zilliqa was found in the reviewed sources; absence was not verified. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | EVM smart contracts run on the protocol's execution layer, and Scilla contracts from the original chain keep their state. Since July 2026 Scilla contracts can be reached only through the interop precompile from 100 allowlisted EVM contracts. 189 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | No protocol feature to cancel a sent payment was found. The 2026 migration escrow lets owners of retired legacy accounts move funds to a new address by proving ownership with a zero-knowledge proof built from their own seed phrase; it was added by hard fork after an incident, not set up in advance by the owner, and was not assessed here. 1319 |
| Rollups | Unknown | No rollup or validium anchored to Zilliqa was found; absence was not verified. The x-shards announced in 2024 are a separate design whose status is unknown. 15 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinPlunderSwap, ZilSwap (Scilla contracts) | DeFiLlama lists PlunderSwap V2 and V3 as exchanges on Zilliqa EVM, and ZilSwap, an exchange for Scilla tokens from the original chain; Zilliqa's docs point users to PlunderSwap's transfer tool. Whether ZilSwap can still be used after legacy transactions stopped was not verified. Operators, audits and liquidity depth were not reviewed. 22425 |
| Issuer-native stablecoins | None found | Neither Circle's USDC contract list nor Tether's supported-protocol list includes Zilliqa. zUSDC is a USDC representation minted by Zilliqa's own bridge, not by Circle. 202627 |
| Algorithmic stablecoins | Unknown | DeFiLlama lists Pillar, a stablecoin-issuance protocol from the Scilla era, on Zilliqa; its peg, current use and status after legacy transactions stopped were not verified. 25 |
| Bridges | First-partyXBridge (Zilliqa-operated) | Zilliqa runs XBridge and in March 2026 moved USDC liquidity onto it as zUSDC; the same post set 31 March 2026 as the end of deBridge support on Zilliqa. Zilliqa's own post says XBridge settlements are not instant and that automation of bridge transaction processing was still in progress. Risk: zUSDC and other bridged tokens depend on Zilliqa-managed bridge infrastructure. Zilliqa's cross-chain bridge repository says its validator-signed design is not trustless; whether the live XBridge uses that design, and who signs its transfers, was not verified. 202223 |
| Block explorers | First-partyOtterscan (Zilliqa), Zilliqa Blockscout, ViewBlock | Zilliqa's endpoints page lists Otterscan on a Zilliqa domain, a Blockscout instance for Zilliqa 2 mainnet and ViewBlock, a separately run explorer. Listing is not a quality or completeness check, and explorer data is provider-indexed. 3282930 |
| Hardware wallets | ThinLedger (through MetaMask), Trezor (through MetaMask or Rabby) | See custody rows: on the EVM side both vendors' devices sign through third-party wallets, and the legacy signing path through the Zilliqa Ledger app was retired after its 2026 flaw. 172134 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Through an intermediaryMetaMask on the Zilliqa EVM network, signing with the Ledger Ethereum appSame as native: Unknown | Can: Connect a Ledger to MetaMask with the Ethereum app and use that Ledger account on the Zilliqa EVM network, per Zilliqa's July 2025 guide (part one of a series, covering the connection and network setup) Cannot: Send ZIL through the Zilliqa device app, except into the migration escrow: legacy transactions stopped on 20 July 2026 after a nonce flaw in every released version of that app was exploited; since 22 September only escrow transfers run Cannot: Manage ZIL in Ledger Wallet itself: its current code loads no Zilliqa coin module, and Ledger's currency list has no Zilliqa EVM network; its one Zilliqa entry is the legacy 12-decimal account familyLedger's Zilliqa page (modified 2023-12-18) is a generic template that points to managing Zilliqa with Ledger Live and still describes sharding. Zilliqa's post-mortem says a fix written by a Zilliqa engineer was merged into Ledger's Zilliqa app on 27 July 2026, but keys that had already signed stay exposed. Zilliqa's migration guide has holders of legacy accounts created on a Ledger choose a Ledger option in the ZKP Migration App and enter their recovery phrase, which the app uses offline to rebuild the account key. 8181921313233 |
| Trezor | Through an intermediaryMetaMask or Rabby on the Zilliqa EVM networkSame as native: Unknown | Can: Use a Trezor with MetaMask or Rabby, which Trezor's Zilliqa page lists as wallet apps, on the Zilliqa EVM network that the page lists as supported Cannot: Use the Zilliqa EVM network in Trezor Suite itself: the network list in Suite release 26.9.2 has no Zilliqa networkTrezor's page names Trezor Suite, MetaMask and Rabby beside the Zilliqa EVM and BNB Smart Chain networks without tying apps to networks, and its generic text says Trezor Suite works with Zilliqa. Because Suite's released network list has no Zilliqa network, Suite can at most hold a ZIL token on BNB Smart Chain (not verified), which is not custody on Zilliqa. The page still describes Zilliqa as a sharded chain. 3435 |
Public data
iKnow Blockchain has no public-data lookups for Zilliqa yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Reviewed Sep 29, 2026 Next review due Oct 9, 2026, 12:00 UTC.
Publication date · newest first
-
Legacy balances move to EVM addresses by hard fork and zero-knowledge escrow
On 2 September 2026 a hard fork moved the balances of ten exchanges from legacy addresses to their EVM addresses and blocked the old ones. Node v0.21.9 (8 September) scheduled a second account sweep, an escrow contract and an escrow-only rule for legacy transfers; the chain reached that fork height on 22 September, and on 24 September Zilliqa published a guide to its ZKP Migration App for self-custody holders. Zilliqa also said it would put a proposal to mint new ZIL for affected holders to a community vote.
- Proposal:compensation mint proposed for a community vote; not yet posted
- Implementation:exchange sweep forks and escrow contract in the node; migration app released
- Release:zq2 v0.21.9 and ZKP Migration App v0.6.0 released
- Activation:first exchange batch moved 2 September 2026; second sweep and escrow fork reached 22 September 2026 (block 36,383,378); third list (block 37,410,000) not reached by 29 September
Sources: Zilliqa blog — Where We Stand: Migration Progress, the Path to Compensation, and Getting Back to Building (external site) · Zilliqa (GitHub) — zq2 v0.21.9 release notes (external site) · Zilliqa blog — Migrate ZIL from a Legacy account to Zilliqa EVM (external site) · Zilliqa (GitHub) — zkp_recovery_app releases (ZKP Migration App) (external site) · Zilliqa — Zilliqa Governance forum (external site) · Zilliqa — Zilliqa mainnet public API (JSON-RPC read of block 36,383,378 on 2026-09-29) (external site)
-
Legacy transactions disabled after the Zilliqa Ledger app nonce flaw was exploited
Zilliqa released a client hotfix at about 12:59 UTC on 20 July 2026, the day after KuCoin reported drained wallets; its hard fork took effect at block 31,759,109 at 16:37 UTC that day and stopped all legacy (non-EVM) transactions. The flaw in the Zilliqa Ledger app let anyone rebuild a key from four or more public signatures. Zilliqa's post-mortem, published 20 August, records 683,130,969.66 ZIL of proven theft from 51 accounts since 4 March 2026 and 6,772 exposed accounts, and says Zilliqa announced on 30 July that every legacy holder would move to EVM addresses.
- Implementation:client hotfix released about 12:59 UTC on 20 July 2026 (node release v0.21.7 published 12:45 UTC)
- Release:emergency hard fork; validators told to upgrade
- Activation:active since block 31,759,109 (16:37 UTC, 20 July 2026)
Sources: Zilliqa — Ledger Incident Hub (external site) · Zilliqa — Post-mortem: legacy Schnorr nonce bias (external site) · Zilliqa (GitHub) — zq2 v0.21.7 release (external site) · Zilliqa (zq2 repository, GitHub) — zilliqa/src/cfg.rs at tag v0.21.10 (external site) · Zilliqa (zq2 repository, GitHub) — zq2-mainnet chain specification at tag v0.21.10 (external site) · Blockscout (Zilliqa 2 mainnet instance) — Zilliqa Blockscout API: block 31,759,109 (external site)
-
Node v0.21.0 scheduled RANDAO leader randomness and a deposit contract upgrade
Zilliqa released node version 0.21.0 with a mainnet hard fork: the deposit_v8 staking contract upgrade at block 25,902,000 and RANDAO randomness for leader selection at block 25,905,600, both estimated for 5 May 2026. The release also adds state pruning and flexible checkpoint versions.
- Implementation:shipped in zq2 v0.21.0
- Release:required upgrade
- Activation:scheduled for blocks 25,902,000 and 25,905,600 (estimated 2026-05-05); listed in the v0.21.10 mainnet specification
Sources: Zilliqa (GitHub) — zq2 v0.21.0 release notes (external site) · Zilliqa (zq2 repository, GitHub) — zq2-mainnet chain specification at tag v0.21.10 (external site) · Zilliqa (zq2 repository, GitHub) — deposit_v8.sol at tag v0.21.10 (external site)
-
zUSDC via XBridge introduced; deBridge support on Zilliqa set to end 31 March 2026
Zilliqa introduced zUSDC, a USDC representation minted by its own XBridge, after unwinding bridged USDC through Ethereum and re-bridging the liquidity. It asked holders of the older bridged USDC to bridge out through deBridge before 31 March 2026, the date it set for deBridge support on Zilliqa to end.
- Implementation:zUSDC deployed and trading pair launched
- Release:announced as completed phases 1 to 3
- Activation:deBridge sunset set for 2026-03-31; not independently checked
Sources: Zilliqa blog — Strengthening Stablecoin Infrastructure on Zilliqa: Introducing zUSDC via XBridge (external site) · Zilliqa — Zilliqa Bridge (XBridge) (external site) · Circle — USDC contract addresses (external site)
-
Node v0.20.0 scheduled a hard fork activating Cancun EVM rules
Zilliqa released node version 0.20.0 with a hard fork at mainnet block 19,486,411, estimated for 5 February 2026. The notes list Cancun activation for the EVM, a credit-based API rate limiter, faster checkpoint generation and a fix for empty-map Scilla queries.
- Implementation:shipped in zq2 v0.20.0
- Release:required upgrade before block 19,486,411
- Activation:scheduled for block 19,486,411 (estimated 2026-02-05); listed as active in the v0.21.10 mainnet specification
Sources: Zilliqa (GitHub) — zq2 v0.20.0 release notes (external site) · Zilliqa blog — Community Updates and Business Insights (external site) · Zilliqa (zq2 repository, GitHub) — zq2-mainnet chain specification at tag v0.21.10 (external site)
Topics your AI can explain
Your AI can explain these topics for Zilliqa through the connection, with sources.
Known gaps
What this profile's review did not establish:
- The current number of validators, their operators and their stake shares were not verified; the only indication seen is a July 2026 block certificate with 14 signers at committee positions numbered up to 21.
- The maximum number of validators allowed by the mainnet deposit contract was not read; the contract supports a configurable cap.
- The block interval was estimated only from two block timestamps (blocks 31,759,109 and 36,383,378, an average of about 1.19 seconds per block); the configuration and code comments assume one-second blocks, and the interval was not monitored over time.
- No slashing path was found in the deposit contract or consensus code, but the search was not exhaustive.
- Zilliqa's developer docs still describe Scilla as a retained execution layer and the migration from Zilliqa 1.0 as upcoming; this profile follows the July 2026 code and incident record, which retire legacy transactions.
- The second account sweep and the escrow deployment reached their fork height (block 36,383,378) on 22 September 2026, but whether the sweep covered every exchange in the second batch was not confirmed, and the third list at block 37,410,000 had not been reached on 29 September 2026.
- The compensation proposal to mint new ZIL for affected holders had not been posted on the governance forum when it was read on 2026-09-29.
- Which Scilla contracts remain usable through the 100 allowlisted EVM callers, including ZilSwap and Pillar, was not verified.
- No current throughput figure with a method was found, so none is recorded.
- The status of the x-shards announced in 2024 was not verified.
- Who signs XBridge transfers, and whether the live bridge uses the validator-signed design in Zilliqa's repository, were not verified.
- Ledger's support article on Zilliqa could not be read (it renders in the browser only); the Ledger row rests on Ledger Wallet's current code and currency list instead.
- No atomic-swap mechanism, light client, channel system, rollup, reversible-transfer feature or data-publication feature was found; absence was not exhaustively verified.
- Home-node disk growth beyond the documented 200 GB minimum was not measured.
Sources
Oldest dated source check: Source checked Sep 29, 2026 Next check due Oct 29, 2026.
- The Zilliqa 2.0 Developer Portal (external site)
- What's new in Zilliqa 2.0 (external site)
- Endpoints, Block Explorer and Faucet (external site)
- Node setup (external site)
- Staking (solo and delegated) (external site)
- z2 deposit, top-up, unstake and withdraw (z2/docs/staking.md) (external site)
- Jailing (docs/jailing.md) (external site)
- zq2-mainnet chain specification at tag v0.21.10 (fork heights, stake, rewards, gas) (external site)
- zilliqa/src/cfg.rs at tag v0.21.10 (fork flag definitions) (external site)
- zilliqa/src/consensus.rs at tag v0.21.10 (Pipelined Fast-HotStuff, vote weighting, rewards) (external site)
- deposit_v8.sol at tag v0.21.10 (staking deposit contract live since block 25,902,000) (external site)
- zq2 v0.21.0 release notes (RANDAO and deposit_v8 hard fork) (external site)
- zq2 v0.21.9 release notes (blocked recipients v2 and escrow) (external site)
- The ZILLIQA Technical Whitepaper, version 0.1 (10 August 2017) (external site)
- Introducing Zilliqa 2.0: Shaping a Decentralised Future (external site)
- Zilliqa Blockscout API: block 31,759,109, the legacy-shutdown fork height (read 2026-09-29: timestamp 2026-07-20T16:37:01Z, 14 certificate signers) (external site)
- Ledger Incident Hub (external site)
- Post-mortem: legacy Schnorr nonce bias (external site)
- Migrate ZIL from a Legacy account to Zilliqa EVM (external site)
- Strengthening Stablecoin Infrastructure on Zilliqa: Introducing zUSDC via XBridge (external site)
- How to connect Ledger with Metamask (external site)
- Universal Cross-Chain Bridge (UCCB) README (external site)
- Zilliqa Bridge (XBridge) (external site)
- PlunderSwap (external site)
- DeFiLlama protocols API (Zilliqa entries: PlunderSwap V2 and V3, ZilSwap, Avely, Pillar) (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- Otterscan (Zilliqa block explorer) (external site)
- Zilliqa 2 mainnet explorer (external site)
- Zilliqa Explorer (external site)
- Zilliqa wallet (external site)
- @ledgerhq/cryptoassets 13.56.0 currency list (external site)
- ledger-live coin-modules loaders.ts (develop branch; coin families Ledger Wallet registers) (external site)
- Safe and secure Zilliqa wallet (external site)
- trezor-suite wallet-config networksConfig.ts at release v26.9.2 (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding