Zycord documentation
Everything published about Zycord, in reading order — the design argument, the engineering specification, and the operator guides for actually running it.
Mainnet has been running since 2026-10-07T00:00:00Z, chain id 1, and that
instant is the genesis_time in the published parameter file rather than an
announcement — a node that disagrees with it is on a different chain. No coin existed before
block 0 and none was sold: anyone offering you a presale, an allocation or an airdrop of
ZCD is scamming you. The public testnet's coins are worth nothing by design. Every official announcement is signed with E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29 and posted to
the forum thread. Nowhere else.
Zycord is a network, mined under proof of work until era 2 passes it to proof of stake, in which every transaction — called a certificate — carries the state it read and the state it wrote. Verifying one is therefore a pure function of its bytes: no disk, no history, no shared state, and no bound on how many machines check it at once. The chain never executes anything. It orders certificates and commits them with a deterministic fold that applies each certificate whose declared inputs still hold, and skips the rest, charging each skip to the deposit the certificate named. A contract with hot state is served by a sequencer, which executes users' signed intents off-chain and publishes the results as certificates; a forced path lets any user reach any contract without one.
These pages are the documentation for that system: the design argument, the engineering specification, and the operational guides for running it. They are written from the same sources the reference implementation is built from, and where any of them disagrees with the repository, the repository is right.
Start here#
Start with the pictureHow the network works
The whole system on one page: a transaction built off-chain, verified in parallel from its bytes alone, and committed by a single sequential fold. The certificate, the fold and its outcomes, typed access, sequencers and the forced path, the two gas markets and the eras — diagrammed.
Run it#
Installation
Getting the binaries onto a machine.
Verifying a download
Checksums, signatures, reproducible builds.
Running a node
Operating zycordd.
Mining
RandomX, payouts, and what it costs to run.
Wallet
Keys, sending, and the eight rules.
Public testnet
Joining the network that is running now.
Reference#
Wire protocol
What nodes say to each other.
Glossary
Certificate, fold, skip, cell, era.
FAQ
The questions that actually get asked.
RPC API
Every route the node answers, with its parameters and fields.
Exchange integration
Deposits, withdrawals, fees and confirmations, for listing ZCD.
The shortest useful path#
If you want to be on the network today rather than read about it, this is the whole of it. The
example joins the public testnet, which runs the same release as mainnet under its own parameter
file and chain id; without --testnet, and with a directory of its own, the same command
joins mainnet.
# Build the binary that can join a RandomX network.
# `make build` produces a devnet-only binary -- see Installation, "Two tiers".
make build-randomx
# A payout address. The node never sees the key behind it.
./bin/zcd-randomx wallet new --out miner.json
# Join, and mine to yourself. Coins come from mining; on testnet there is
# also a faucet at zycord.com/faucet/ for a first, small balance.
./bin/zycordd-randomx --testnet --dir ./testnet \
--mine --payout $(./bin/zcd-randomx wallet address --key miner.json)
Start it whenever you like, including before a network's first block is due: the node refuses to build a block its own clock has not reached, says how long the wait is, and begins mining on its own. There is nothing to schedule and nothing to restart. The full version of this is Public testnet, and what it costs to run is under Mining.
What is authoritative, and what is only explanation#
This matters more here than on most projects, because the network has no admin key and therefore no way to correct a mistake after the fact. The documents are ranked, and the ranking is not a formality:
| Layer | What it is | Where it lives |
|---|---|---|
| The protocol | The parameter files and the golden test vectors. An independent implementation that passes the vectors is a peer, not a fork. | spec/ |
| The peer layer | The normative requirements for what nodes say to each other. | Wire protocol |
| The argument | Why the design is shaped this way, with its accepted risks named. The v2 paper and its companion on launch, eras and parameters. | Whitepaper |
| The implementation | How the reference node realises all of the above. Explanatory, not normative. | Architecture |
| The operator guides | Installing, running, mining, and holding keys. | These pages |
Where any two disagree, the more precise one wins and the disagreement is a bug worth reporting. No number written by hand in the explanatory layers is a source of truth; it is generated from code, asserted by a named test, or an illustration that nothing else may cite.
Check it yourself#
For a project whose author will not vouch for it in person, nothing here is worth more than what you can check without asking. The protocol is a directory of files: the parameter files that are frozen at genesis, and golden vectors giving every fold, block and validity rule its own case. An implementation that passes them is a peer, not a fork.
Parameters and golden vectors
Every rule as a (pre-state, block) → (post-state, fees) case, positive and negative. Run them against this node, or against your own.
Mainnet explorer
Every block since genesis, including the launch message block 1 reveals, and the outcome of every certificate.
LiveTestnet explorer
Watch the running network produce blocks, and see per-certificate outcomes no other chain's explorer can render.
ArchivedWhitepaper, every version
Every version, as a citable deposit: doi:10.5281/zenodo.22167489, which resolves to the latest. v1.0 is superseded by v2.0, which is also on this site.