zkSYS Update: The Final Ledger Is Taking Shape 

Syscoin's zkSYS testnet has been upgraded to the latest ZKsync OS v31 stack and is now running with Airbender proving and a redesigned Syscoin DA path.

This update is bigger than a testnet version bump.

It is a milestone toward the thing Syscoin has been building for more than a decade: decentralized blockchain scaling that does not abandon the principles that made Bitcoin durable in the first place.

CORE PRINCIPLE: Verify, then trust.

That is the rule.

The broader market keeps rediscovering the same problem. Everyone wants more throughput. Everyone wants faster settlement. Everyone wants better UX. But each time a system scales by weakening verification, outsourcing assumptions, or making only a few actors capable of checking the chain, it moves away from the reason blockchains matter.

Syscoin's direction is different.

The goal is not to create the largest possible throughput number on paper. The goal is to find the maximum viable scale that can still be independently verified by real nodes, rooted in proof of work, protected by finality, and prepared for a post-quantum future.

With zkSYS, that direction is now running on testnet.

What Changed

The zkSYS testnet is now upgraded to the latest ZKsync OS v31 stack with Airbender proving.

Airbender is important because it gives zkSYS a world-class proving path: high-performance, parallelizable zk proving for the ZKsync OS execution environment. This is the proving layer that makes the broader zkSYS roadmap practical instead of theoretical. It does more than 20mhz RISC-V cycles on a single H100 GPU (ELI5 10 X  the speed, faster then anything else out there).

At the same time we improved our  DA and zkSYS unique Gateway design after hitting  a major bottleneck during testnet work.

Earlier, with the native zkSync design, if an edge chain pushed full data through Gateway, Gateway could become the shared bottleneck. As data grew, batches grew. As batches grew, proving became more expensive and slower. As Gateway became heavier, other edge chains could suffer from the load of one chain using too much bandwidth.

The new custom Syscoin DA design changes that.

Edge chains publish data availability to Syscoin. Their zk-proven batches commit to the DA hashes. Gateway receives compact commitments instead of every byte of child-chain data.

Gateway still verifies what matters. It checks local data availability through its own Syscoin node before accepting edge-chain batches. If the referenced data exists locally and hashes correctly, Gateway can admit the compact batch. Final settlement later checks confirmation/finality.

That means Gateway can aggregate many chains without becoming the place every chain dumps all of its data. We will dive into details about our unique gateway design below in the “The Gateway Bottleneck”.

The Principle: Verify, Then Trust

Syscoin's scaling thesis is not simply "use zk proofs."

The thesis is a full stack:

• Bitcoin-aligned proof of work for base security.

• Syscoin finality for fast economic settlement.

• Bounded ChainLocks and Bitcoin AuxPoW to preserve a live proof-of-work recovery path if a finality set is captured.

• zkSYS for EVM-compatible execution and proof-based settlement.

• Airbender for high-performance proving.

• Hash-based Syscoin DA for full local verification.

• Pali smart accounts for normal-user UX and account recovery.

• A post-quantum direction based on hash-based primitives.

Figure 2. One design language: a hash-first stack from proof of work to Pali smart accounts.

This is the same philosophy applied at every layer: do not ask the network to trust what it cannot verify.

That is why hash-based DA matters.

Why Syscoin DA Is Different

In Ethereum-style blob DA, data availability is transactional. Blob data is attached to blob transactions and block consensus. PeerDAS improves the network's ability to scale blob availability through sampling and custody, but it does not turn Ethereum into a global content-addressed DA layer that Gateway can query by hash.

Syscoin's DA path is different.

Syscoin DA is used as a global content-addressed availability layer. Edge chains can publish DA independently. Gateway receives DA hashes in the edge-chain commitment transaction, asks its own local node whether the data exists, retrieves the data, and verifies the hash.

That is deterministic assurance.

Either the data exists locally and hashes correctly, or it does not.

Gateway does not need to rely on probability. It does not need to trust an edge-chain operator. It does not need to ingest every child chain's full data into its own batch.

It verifies, then trusts.

ELI5: Syscoin DA is like checking a package by its tracking code.

Gateway does not need to carry and process the whole package itself. It only checks that the correct data exists and matches the code.

Why it matters: less work for Gateway, no need to trust others, and more chains can use it safely. 

 

The Gateway Bottleneck

Gateway is how many edge chains can coordinate and settle through a shared layer.

But a shared Gateway only scales if it stays light.

The original zkSYS testnet made this clear. As we pushed the edge-chain side harder, the zkSync nativeGateway direction started to show backlog and queuing pressure. Gateway batches grew, proving became more expensive, and the shared settlement layer became heavier as edge-chain data flowed through it.

That testnet feedback led to the current design adjustment. zkSYS now uses Syscoin's unique DA properties directly: edge chains publish their data to Syscoin, commit the resulting DA hashes into their zk-proven batches, and send Gateway compact hashes as the ticket of entry for settlement. Gateway can verify local availability of those hashes and later aggregate the commitments back to Syscoin, without carrying every byte of child-chain data through its own batch.

If every edge chain had to push all of its data to Gateway, Gateway would become the choke point. It would have to carry the data, prove the data, batch the data, and wait on settlement for the data. Under sustained load, that creates a backlog.

The compact Syscoin DA path removes that pressure from Gateway.
 

Instead of:

zkSYS moves toward:

This makes Gateway behave more like a compact zk settlement and aggregation layer, while retaining the safety properties of a full node because the Gateway node still verifies local data availability before accepting the commitment.

The result is less bloat risk, less proving overhead, less shared bandwidth pressure, and much better fan-in from edge chains.

Full Data, Short Window

Syscoin is not trying to make light clients act like finality-critical validators.

For the live DA window, full DA nodes should receive and verify the data. That is the decentralized model: every full node can check the data it accepts.

The tradeoff is bandwidth, but it is bounded. Full nodes do not need to store DA forever. Historical data belongs with archivers and PoDA services. Full nodes need to verify and serve the live window.

At an illustrative ceiling of 64 MiB per 2.5 minute Syscoin block, a six-hour live DA window is about:

Bandwidth at that ceiling is:

That is a practical envelope for validator hardware, especially when the alternative is a more complex probabilistic sampling and slashing model.

Syscoin's approach is simpler: receive the data, verify the hash, keep it for the live window, prune, and let archivers preserve history.

Post-Quantum Accounts Are Here

This same hash-first design also points toward a more immediate user-facing goal: post-quantum account protection.

Post-quantum security is often discussed as a distant protocol migration. Syscoin's approach is more practical. Users should be able to protect themselves at the account layer before every chain in the world upgrades its consensus or signature scheme.

We demonstrated this recently with Pali and the new zkSYS testnet upgrade. PQ verification costs as little as 45k gas on zkSYS (through our precompile)!

With the now hardened smart-account specification in our industry, post-quantum signing can work on any EVM-compatible chain. A Pali smart account can verify a hash-based signature through account logic, meaning the user can choose stronger account security without waiting for the base chain to replace ECDSA globally.

zkSYS is where this becomes the most natural and efficient.

The algorithm, the DA design, and the proving environment are aligned around hash-based primitives. A NIST-aligned SLH-DSA/SHA path can be supported directly through zkSYS precompile-style verification, making it far cheaper and cleaner than forcing post-quantum signatures through generic EVM bytecode forever.

This is the practical takeaway:

Users can begin protecting themselves with post-quantum smart accounts on zkSYS, and the same smart-account pattern can extend across EVM chains. It works broadly, but it works best where the chain itself is designed for it.

Proof of work is hash-based. Syscoin DA is hash-based. The post-quantum account direction is hash-based. These are not separate ideas. They are parts of one strategy.

Ethereum blob DA and PeerDAS rely on KZG commitments over pairings. That is efficient today, but it is not post-quantum safe. Moving to a credible post-quantum DA model likely means moving toward hash-based or transparent proof-system commitments.

Syscoin's DA path is already aligned with that future.

Hash choice also changes proving economics. In prior measurements shared by Jagdeep Sidhu, a 9-blob DA workload showed:

Blake2s was measured as over 1,800x cheaper than KZG for that workload. Hash choice is not cosmetic. It changes the economics of modular DA. Syscoin's official testnet has been updated to include Blake2s as the default DA hash of choice with Keccak there as an option. This will allow us to natively integrate the zk stack for higher efficiency which leads to better decentralization characteristics in scaling design for modular blockchains.

Some prior analysis posted around this: https://x.com/realSidhuJag/status/2043835940322652453?s=20

Pali: The User Layer

The base layer can be principled and technical, but users need a wallet experience that feels normal.

That is where Pali fits.

Pali is becoming the convenience layer for zkSYS: smart accounts, recovery, passkeys, and post-quantum signing paths. Account abstraction has matured significantly through ERC-4337, and zkSYS gives Syscoin a path to bring that user experience to a chain rooted in proof of work, finality, and zk settlement.

The current public Pali release line is available here:

https://github.com/syscoin/pali-wallet/releases/tag/v4.0.30

On the research side, the broader ecosystem is exploring SLH-DSA and SPHINCS-style hash-based signatures, including work such as:

https://github.com/nconsigny/SPHINCS-/tree/main

For zkSYS, the goal is practical post-quantum readiness: NIST-aligned, hash-based signing paths that can be made efficient in a zk proving environment. SHA-style hash paths can be much cheaper to prove than Keccak-heavy EVM logic in Airbender, making native/precompile approaches especially attractive.

That means Pali is not only a wallet. It is how normal users can access the security model zkSYS is built for.

For a deep dive see: https://x.com/realSidhuJag/status/2070250363614351415

Mainnet Readiness

The zkSYS testnet has now been running the upgraded path and has had roughly a month of testing without major issues.

That matters.

This is no longer only a thesis. The pieces are coming together:

• zkSYS testnet is live.

• The testnet is upgraded to OS v31.

• Airbender proving is working.

• Gateway bottlenecks have a compact Syscoin DA path.

• Syscoin's next release advances the security model around bounded ChainLocks and Bitcoin AuxPoW.

• Pali is moving toward smart-account UX and PQ safety options for normal users.

For builders, the testnet is available now:

• Portal: https://portal.tanenbaum.io/bridge

• Explorer: https://explorer-zk.tanenbaum.io/

• ChainList / RPC details: https://chainlist.org/chain/57057

The original zkSYS testnet announcement marked the beginning of this phase. This update shows that the stack is maturing into the system Syscoin has been working toward.

Syscoin is not taking shortcuts to scale.

It is building a stack where performance does not come at the cost of verification, security, or decentralization.

Proof of work. Fast finality. zk execution. Hash-based DA. Full local verification. Bounded storage. Post-quantum readiness. Smart accounts built for real users.

Each layer reinforces the same principle: trust should be minimized, and verification should remain open to everyone.

That is the foundation of a blockchain stack built not only to scale, but to endure.
zkSYS is where that vision becomes executable.This is the final stretch before mainnet, and the system Syscoin has spent years building is now becoming real.