ZYCORD docs
English
ZycordDocsHow the network works
Zycord (ZCD) — how the network works

Assembled off-chain.
Verified in parallel.
Committed in order.

Every large blockchain makes every node re-execute every transaction against a global state. Zycord takes execution off the chain: the transaction is assembled between servers outside it, arrives complete with everything it read and wrote, any machine checks it from the bytes alone, and a single loop commits the result.

Three phases: construction between servers, parallel verification, sequential fold Construction — off-chain The transaction bounces between servers until it closes Wallet Sequencer contract A Sequencer contract B Underwriter co-signs Verification — parallel, stateless Many nodes, each checking its slice Fold — sequential One loop, compares and adds 9.9 ms per 2,900-certificate block
Ordinary servers, web2, no consensus Grows with every core that joins the network The only scarce resource

The transaction is a certificate

It does not ask “execute this”. It states “I read this, I wrote that, and here is the proof”. Anyone recomputes and compares.

Certificate { reads: [(slot, access, operand)] // what I read, and how writes: [(slot, op, value)] // what I write program: bytes // code or native operation sigs: [signature] // spending authority underwriter: (id, sig, seq) // who carries the risk ttl: height // expires if not included by here fee: (seq_gas, par_gas) // two markets }
Valid = a pure function of the bytesSignatures ok, underwriter ok, and re-executing program over the reads produces exactly the writes. No disk, no history.
Applicable = decided by positionDo the declared reads still match the state when the certificate reaches its turn in the block?
The ID excludes the signaturesRe-signing with a different nonce gives the same ID. The seen set catches the copy. Nobody is charged twice.
Access types per slotEXACT pins the value. GUARD only states “balance ≥ x”. DELTA adds without reading. Payments and tips commute and never conflict.

Two verbs, two stages

The entire design is separating these two questions — and answering each in the cheapest place.

parallel

Is it valid?

Answered by looking at the certificate alone. Thousands at once, on any machine.

  • Canonical signatures check out
  • Re-execution matches the writes
  • Range proofs close (shielded rail)
  • Invalid: never enters the block
sequential

Is it applicable?

Answered at the certificate's position in the block, comparing bytes against the state table.

  • Reads still match → the writes are committed
  • Stale reads → skip, burns the underwriter's fee
  • Cell already spent → skip
  • The block stays valid in every case

The flow, from birth to ledger

1

Construction between servers

The wallet opens the request. Every hot contract has its own sequencer — an ordinary application server — that keeps a copy of the state, serialises who moves first, and chains each certificate onto the previous one's writes. A transaction touching two contracts is co-built by both sequencers and reaches the chain as a single atomic certificate.

2

The underwriter signs

An underwriter with bonded funds checks against fresh state, co-signs, and takes on the skip risk. It charges the sender out of band and sells, in effect, a pre-confirmation. Anyone who wants no intermediary self-underwrites with their own deposit — always available, without asking permission.

3

The network receives and verifies in parallel

Every node checks validity from the bytes before relaying. With sampling, a VRF-drawn committee verifies each certificate; any node can check anything, and a single message is enough to punish an underwriter who attested to garbage.

Invalid → discarded, never reaches the block
4

The proposer orders

A PoS committee picks valid certificates and assembles the block. It executes nothing and holds no application state. It only remembers the IDs seen within the TTL window. Certificates in the forced queue must be included within F blocks.

5

Sequential fold

Orders by (underwriter, seq, id) — the proposer does not choose the order. For each certificate: do the reads match the state? Checkpoints finalise every 32 blocks.

Applied — writes committed, fee paid to the proposer
Skipped — fee burned, charged to the underwriter, the block stays valid

Who does what

No role is required for the network's security. If they all vanish, the forced queue keeps the system alive.

Wallet

Does
Builds the certificate, declares reads and writes, signs
Sees
The public state it needs to read
Trusts
Nobody

Sequencer

Does
Serialises a hot contract off-chain, packs batches into one certificate
Trusted for
Liveness only. If it lies, the certificate skips and the bond pays
Captures
Its own application's MEV, explicitly

Underwriter

Does
Co-signs and takes on the skip risk with a bond
Sees
Cells live or spent — never the hidden value
Loses
Only for a fault provable in the bytes (equivocation)

Verifying node

Does
Checks validity from the bytes, relays, syncs
Needs
Cores. State only if it is going to commit
Cost
Falls as the network grows, because it verifies a slice

Proposer (PoS)

Does
Orders valid certificates, runs the fold, proposes the block
Sees
Bytes, not meaning
Earns
Subsidy + priority fee from the applied ones

Privacy without touching the sequential path

Confidential Transactions with a throwaway address, over a public graph. It hides the value. It defers the link to the recipient. It is not Monero, and the paper says so.

What stays hidden

  • The value: commitment C = vG + rH
  • The recipient, until the first spend (stealth address)
  • The balance of each hidden cell — only the owner can spend it, nobody can “ask”

What stays public

  • That a payment happened, and who underwrote it
  • Which output was spent, at the moment of spending
  • Every crossing between the public rail and the shielded one, with the value in the open
  • Fees, coinbase, payments to contracts

The shielded pool is a fence, not an alarm

Shielded pool with an exit guard Public rail values in u256, checked arithmetic Shielded pool pool = Σ in − Σ out a public integer, moved by delta shield +v unshield: guard pool ≥ v If the cryptography breaks forged value does not cross the guard. Inflation stays trapped inside the pool.

The fold never does curve arithmetic. It stores 32 bytes of commitment and compares for equality. All the heavy cryptography — range proofs, the balance equation — is verified in the parallel stage and paid for in the cheap market.

Why no ring signatures

A ring references other people's outputs — that makes validity a function of history, and kills stateless verification. Zycord does not give up that property, so its privacy is weaker than Monero's by decision, not by oversight.

The network: two gas markets

A chain that charges for everything in a single auction makes a proof verification compete with a state write. Here each resource has its own price.

Parallel gas

Pays for verification: signatures, re-execution, bytes, heavy proofs, post-quantum schemes.

Supply grows with every core and GPU that joins. High ceiling, low price.

Sequential gas

Pays for the fold: checking reads, writes, leases. The one loop every node runs in order.

Scarce. Elastic ceiling: at most a doubling per year of full, healthy blocks. Nobody votes.

The network from above

Four layers that do not overlap: who serialises, who underwrites, who verifies, who orders. Each scales with a different resource.

off-chain

Per-application sequencers

Ordinary web2: websockets, queues, autoscaling. They serialise hot contracts and pack batches into the shape GPUs verify well. They never custody data — the state is always reconstructible from the chain alone.

off-chain

Underwriter market

Bonded underwriters sell pre-confirmation: “applied in seconds or my bond pays”. Equivocation is punished by a proof in the bytes; slowness only costs reputation. Latency never becomes confiscation.

parallel

Verification committees

Drawn by VRF per certificate, sized so that an invalid certificate escaping is negligible. Any full node can audit anything. One message is enough to punish.

sequential

PoS committee + fold

Proposes blocks, runs the fold, finalises checkpoints. The forced queue compels inclusion within F blocks and guarantees application — the mechanism that makes the network survive any operator, including the author.