A verifiable data layer for Zcash
Zylem separates who serves Zcash data from who you trust. History travels as portable Ring files, each about a day of blocks, that anyone can host, and every client checks what it receives before using it. Wallets are the first application.
Testnet prototypeWorks with ZakuraHeader proofs in SP1
What it rejects
Conventional light wallets rely on their server for their view of the chain. Pick a manipulation to see what a wallet shows today and what happens through Zylem.
Adds a note paying you to the compact data of a real block.
Shows funds that were never sent.
Rejected
The altered transaction's rebuilt ID no longer matches what the block header committed to.
REJECT Ring 4518274..=4522369 rejected: transaction 4 at height 4521980: rebuilt ID does not matchThese are the manipulations Zylem's demo runs against an unmodified testnet wallet. Error lines follow Zylem's real format; the heights are illustrative.
Where Zylem sits
A light wallet trusts its server; a full node checks everything and needs a server's worth of resources. Zylem checks every block you use on your own device, with one small proof standing in for every historical header.
| Light wallet today | Zylem, light Rings + proof | Full node | |
|---|---|---|---|
| Block data authentic and complete | Server's word | Checked on your side | Yes |
| Proof of work and difficulty | Not checked | Proven once; the proof checks in 50 to 350 ms | Yes |
| Transaction validity (proofs, signatures) | Not checked | Not yet; planned for transactions that touch you | Every transaction |
| Double spends and supply | Not checked | Not yet; planned supply guard and proven nullifier set | Yes |
| Served by any static host | No: each server runs a node | Yes | It is the source |
| Header data to download | None, unverified | One proof: 356 bytes, or 1.27 MB without a trusted setup | Everything, hundreds of GB unpruned |
| Runs on | Phones and browsers | Phones, browsers and, through the 356-byte proof, other chains | Servers and desktops |
| What you trust | The server | A checkpoint, honest-majority hashpower, SP1 and Zylem's proving programs | Its own software |
One verified history, many consumers
Zylem separates data availability from verification. Anyone can build Rings and proofs, any host can serve them, and every consumer checks them itself. Wallets are the first consumer, not the last.
Authenticate Zcash data independently: every transaction ID, Merkle root and tree state in a block, checked against the headers and the proof of work.
Fetch only the history you need, from any provider: Rings by height range today, then verified range queries and transaction-inclusion receipts.
Bring verified Zcash facts into other applications and other chains, through a wrapped history proof and inclusion evidence. SP1's verifier contract already accepts Zylem's 356-byte proof in a local EVM for about 304,000 gas; nothing is deployed on a chain yet.
How it works
Two ways to verify
Every Ring can be checked without a proof. A shared history proof replaces the heavy part, the headers, for clients that cannot afford it.
Each Ring carries its blocks' headers, so the client checks every header's Equihash, difficulty and link itself, from a checkpoint. No proof system to trust.
Rings carry 104-byte block records instead of headers, and one SP1 proof shows every header followed Zcash's rules, Equihash included.
Where it applies
| Who | What Zylem gives them | Status |
|---|---|---|
| Wallets | Verified sync without a full node or a trusted server | Testnet |
| Light-server operators | Serve history as Ring files from a CDN, backed by a pruned node | Testnet |
| Channel and DLC watchers | Complete, verified spend monitoring: a server cannot hide a close or a spend | Next |
| Payment processors and agents | Verified payment and confirmation evidence, as inclusion receipts | Next |
| Explorers and analytics | Historical queries whose answers can be checked | Planned |
| Bridges and contracts on other chains | Proof-backed Zcash facts under stated assumptions: a proven block hash today, inclusion facts next | Tested locally |
Benchmarks
Each figure comes from a recorded run. The measurements list names the file behind each one.
Developer quickstart
Point an existing light wallet at the Zylem proxy instead of its usual server. It speaks the same protocol, so the wallet only needs a new server address.
./target/release/zylem-proxy --rings http://127.0.0.1:8090 \
--headers-rpc http://user:pass@127.0.0.1:18232/ \
--upstream https://testnet.zec.rocks:443 \
--checkpoint "$(jq -r .checkpoint checkpoints/testnet.json)"
zcash-devtool wallet -w my-wallet sync --server 127.0.0.1:9067
WARN zylem: REJECT Ring 4518274..=4522369 rejected: transaction 4 at height 4521980: rebuilt ID does not match WARN zylem_proxy: serving only the verified range up to 4518273
Testnet only, from the Zylem repository. The proxy reads Rings from a host such as zylem-build serve --out data/testnet --rpc http://127.0.0.1:18232/, and zylem-build probe --lwd http://127.0.0.1:9067 shows whether it accepts its current tip.
Status · October 2026