Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions

Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions.
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

This paper is complete and self-contained. It supersedes v1.0 [0]; §15 states the relation. Launch, issuance, eras and the full parameter table are in the companion document, Zycord: Launch, Eras and Parameters.

Versions. The text below is v2.0 of the paper, unabridged, followed on this page by its companion document, also v2.0. Both are served as PDFs, each with a detached signature made by the project key E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29: the paper (signature) and the companion (signature). Every version is archived under doi:10.5281/zenodo.22167489, which resolves to the latest; the superseded v1.0 is doi:10.5281/zenodo.22167490. The companion is archived under its own doi:10.5281/zenodo.23383987.

1. Introduction#

A blockchain node does three jobs that have nothing in common: it disseminates data, it verifies computation, and it mutates state. Data scales with bandwidth. Verification scales with cores, and is embarrassingly parallel if transactions can be checked independently. State mutation is the only genuinely sequential resource: somewhere, a single authoritative history of writes must exist.

Zycord separates the three. A transaction becomes a certificate that carries its own inputs and outputs, so verifying it is a pure function of its bytes and never touches the ledger. The chain's job shrinks to ordering certificates and running a deterministic fold over them: a loop of comparisons and additions that touches state exactly once per certificate. Conflicts do not invalidate blocks; they cause individual certificates to be skipped, and every skip is charged to a party that accepted the risk. Concurrency is not discovered at runtime; it is declared, slot by slot, by the contract author. The lineage is execute-order-validate [3], deterministic ordering [4], optimistic parallel execution [5] and the separation of dissemination from ordering [6].

Validity runs once per certificate, in parallel, before any block exists. The fold runs once per block, in order, and never executes.

The design rests on two universes that may share an executable but must never be confused:

Consensus rules only verify. Their purpose is that no user loses funds without authorizing it, nobody debits a balance they do not control, and no attacker can drain, block or slow the network. How a sequencer operates, how sequencers talk to each other and what they charge are outside consensus. What is on chain is settlement: a sequencer's payment travels inside the intent the user signed, and is paid only if the certificate applies.

The following sections define the certificate (§2), the fold (§3), typed state access (§4), native assets (§5), the virtual machine (§6), sequencers (§7), the forced path (§8), the two fee markets (§9), the network (§10), proof of stake (§11), the road past full verification (§12), accepted risks (§13), conformance (§14) and the relation to v1.0 (§15).

2. State Transition Certificates#

The certificate is the only transaction type. It is SSZ-encoded, which gives one canonical byte encoding; decoding enforces canonical form, so a decoded certificate is structurally valid by construction and no later rule re-checks shape.

Two digests answer two questions. The certificate id is the hash of the certificate with an empty signature list: it names what the certificate authorizes. The exemplar hash covers the whole encoding, signatures included: it names one set of bytes. Signatures stay outside the id because signing is randomized; every nonce yields another valid signature over the same body, and an id that covered them would give one authorization unboundedly many billable identities. The id keys the seen set, the fold order and all deduplication. A fill and a forced certificate take the hash of their intent as id (§7, §8); a fill's bid is sealed by its sequencer's signature. The exemplar hash is what a block's certificate root commits to, so a block id determines the bytes the block carries. The fee bid is inside the id and is signed: a bid outside the id is a bid anyone in transit could rewrite. Every signature signs a message that binds the chain id and the consensus root of the parameter set, so a certificate cannot be replayed on another network.

Validity is stateless. A certificate is valid when, from its bytes alone:

1. it decodes canonically, names this chain, and every list is within its limit;
2. every signature verifies under strict Ed25519 (canonical encodings, torsion-free keys), and the signature set is minimal as well as sufficient;
3. re-executing the program against the declared reads produces exactly the declared writes;
4. every write that needs authorization has it, and the deposit cell carries a signature unconditionally;
5. the deposit is a native-balance cell of a user address and covers the certificate's worst case;
6. the certificate is self-consistent: no write contradicts a read of the same slot, no debited one-shot address escapes being marked spent, and no value is written to a spent address;
7. it writes no protocol cell;
8. every address it names carries a defined version byte;
9. in a contract whose sequencer key is non-zero, the exact-read path carries that key's signature (§7), except in a forced certificate (§8);
10. a metadata write declares an exact read of every cell it overwrites, at the value the cell held when the certificate was built.

Any machine checks this: a thread pool, another computer, a GPU, with no database and no synchronization. Signature checks are independent of one another, so they can be batched across certificates. This is the property everything else is built on.

Validity is not sufficient for execution. Two valid certificates may declare the same input value for the same slot; at most one can take effect. The classical notion of transaction validity is therefore split in two: valid (stateless, parallel, checked by anyone) and applicable (stateful, sequential, decided only by position in the ledger). An invalid certificate never enters an honest mempool, and one included in a block makes the block invalid.

3. The Ledger as a Fold#

A block is a header, an ordered list of certificate exemplar hashes, and the certificate bodies themselves. Bodies are chain data: a block is valid only if its bodies are available. The producer of a block executes nothing. It orders certificates it has already seen validated, solves the proof of work [13] (or, under proof of stake, signs the slot it was drawn for, §11), and carries the set of certificate ids seen within the TTL window, because including one twice makes the block invalid.

The state of the chain is a fold over the ordered certificates. For each certificate, in order, the fold reserves the deposit, checks every declared read against current state, stages the writes with checked arithmetic, and then commits or skips:

• APPLIED — every declared read holds, so the writes land and the fee settles at actual cost.
• SKIPPED — a read no longer holds (STALE), a delta would leave the range [0, 2²⁵⁶) (OVERFLOW), or a write lands under a spent address (SPENT). Nothing is written. A fixed skip fee is burned from the deposit and the rest is returned.
• FORCED_FAILED — a forced certificate (§8) whose call reverted or broke its bounds. Its payers are debited and burned, change returns to the user, nothing else is written, and the id is marked seen.
• DROPPED — the certificate could not be charged at all (the deposit cell is unfunded or spent), so it is carried, marked seen and not charged. It pays its producer nothing and costs it ceiling space. A fill in the same condition invalidates the block instead (below), because dropping it would consume the user's intent with nobody paid.

Canonical order. The fold orders a block's certificates in three classes and leaves the producer no discretion. First the fills (§7), each taken as soon as every pipeline it is in is ready, ties broken by (sequencer key, contract, seq, id). Then all other certificates by (deposit address, Seq, id). Last the forced certificates (§8), by id. Every node derives an identical state from an identical sequence of blocks.

Writes are checked before any of them lands. A credit to an address whose authority has been burned fails loudly instead of resurrecting the cell; a delta that would overflow fails the whole certificate. The permanent spent registry exists for exactly this.

Skip is semantics, not failure. Inclusion and application are different events. A producer can never produce an invalid block by including a certificate that turned out stale; the certificate is skipped and the depositor pays. The depositor chose the reads, so the depositor answers for them.

One signature, at most one charge. Applied and skipped certificates alike are marked seen. Including a seen or expired certificate, or one bidding below the block's base fee in either market, makes the block invalid, so no producer can re-include or deliberately delay other people's certificates to harvest their deposits. TTLs are consensus-bounded, so the seen set stays prunable.

Conditions with nobody to charge invalidate the block. Some failures have no culprit: a fill whose sequencer counter is out of order, whose fence counter (§7) has moved, whose payer is already spent or whose deposit cannot be reserved; a forced certificate whose reads do not hold. Including such a certificate makes the block invalid and nothing is charged. The producer, who built the block from state it holds, is the party who could have known.

Exactly one state touch per certificate. The fold performs comparisons, additions and writes on a hot key-value working set: no code execution, no signature verification, no re-execution, no elliptic-curve arithmetic. All of that happened in parallel during the validity check. The certificate id is computed there too and carried into the fold.

Value equality, not versions. Applicability compares declared read values, not version counters. A slot that changed and changed back is still applicable, so the system skips strictly less often than version-based concurrency control.

The fold's own prologue and epilogue. Before the certificates, at an epoch boundary, the fold writes the beacon cells (§4). After them, it splits the block subsidy and rotates the coinbase maturity ring (companion document), records applied gas for the fee controller (§9) and, at an epoch boundary, computes the epoch state root, which must equal the header's. It returns an error only for block invalidity; a problem with a certificate is an outcome, never an error.

4. Cells and Typed State Access#

A cell is the value at a slot (address, word): a 256-bit unsigned integer, big-endian in 32 bytes. Absent cells read as zero. Beside the cells the protocol keeps a spent-address registry, a permanent set of one-shot addresses whose signing authority has been burned.

An address is version ‖ blake3(tag ‖ version ‖ payload)[:31], except the protocol address, which is the version byte 0x00 followed by zeros:

One-shot versus persistent is a wallet policy exposed as a bit of the address, not two ledgers [7]. Wallets default to a fresh one-shot address per incoming payment, so paying a newly derived address is the zero-contention fast path, and a spent cell is compactable once the block that spent it is buried past the undo horizon. Whoever wants an account uses the persistent version. Mining rewards belong at a persistent address: consensus accepts either kind as a payout address, but a one-shot address burns every reward it holds the moment it is spent, and the node refuses one for that reason.

Typed access is where the parallelism comes from. A fold that supported only exact reads would serialize every popular contract: a thousand certificates touching one pool would yield one application and 999 skips. Instead, a read declares how it constrains a cell and a write declares what it does to it:

Only EXACT goes stale. Any number of guarded debits and credits to one slot commute: they apply in any order, and a skip occurs only when a guard genuinely fails (a real overdraft), not when the balance merely changed. One discipline per slot per certificate: a set and a delta do not coexist on the same slot. The rule that keeps the model sound is that guarded values never flow into computation: an assert returns nothing and a delta reads nothing, so re-execution remains a pure function of the declared exact reads. This single discipline covers transfers, supply-capped mints, allowances, tips and vault shares, which is the overwhelming majority of on-chain writes. The lineage is escrow transactions, transactional boosting and CRDTs [8][9][10]; Zycord makes commutativity the concurrency contract between nodes.

One-shot cells. An address that has never appeared on chain is in state ∅; a first write moves it to stored; the certificate that marks it spent, signed by its key, moves it to spent, permanently. The registry entry that records the spend is never compacted: it is what stops the address from being resurrected.

Zero is absence. A slot never written and a slot written to zero are the same slot: writing zero deletes the cell. This is a consensus requirement. It lets a guard or an exact read name 0 without asking whether the slot exists, and it keeps the state root a function of the state and not of the history that produced it.

The epoch beacon. Programs must not read ambient values directly. The protocol writes the height of the header that opened the current epoch, and from the machine era on its time, into reserved cells, once per epoch, and programs read them like any other slot. This gives time-awareness without per-block staleness; both values are constant throughout the epoch, one day on mainnet: 2,880 blocks under proof of work, 17,280 under proof of stake (§11).

5. Assets Without a Machine#

The launch era needs an economy before it needs a computer. Zycord ships native assets as certificate operations from block 0, with no virtual machine involved:

• TRANSFER — up to 32 moves of (asset, from, to, amount) in one certificate, within its limits on reads and writes, each a guard balance ≥ Δ paired with two deltas. A credit aimed at a pure delta or at a fresh one-shot cell is the tip, so tipping needs no opcode of its own. A contract address may be credited only with the native coin, and never a precompile's address (§6), from which nothing could take the value out.
• ISSUE — creates an asset id with a supply cap in a write-once cell.
• MINT — guarded: minted + Δ ≤ cap.
• RETIRE — burns up to 64 one-shot addresses, each authorized by its owner and within the certificate's limits, without moving value: no reads, a pure write that marks each cell spent. Spending proper is automatic inside a transfer. Retirement is the compaction and privacy primitive: the payee erases a one-shot address once it has served.

A streamer receiving ten thousand tips in one block costs the fold ten thousand commutative additions: zero conflicts, zero skips, no sequencer, no machine. The native coin's supply schedule and every issued asset's cap live here, enforced by the checked arithmetic of §3.

A payment settles like this. The sender's wallet picks a one-shot cell it holds, declares a guard on it, debits it, marks it spent, credits the recipient's fresh one-shot address and sends the change to a fresh one-shot address of its own. Two certificates racing to spend the same one-shot cell through two different nodes are both valid; exactly one applies, and the other is skipped and charged to the deposit it named.

6. The Machine: cEVM#

Zycord runs one virtual machine, the cEVM, a dialect of the Ethereum virtual machine [2] adapted to certificates. The choice is deliberate: the project's novelty budget is spent on the state, concurrency and economic model, and the machine should be the most familiar thing in the system. Solidity, its compilers, auditors and tooling carry over. The dialect's whole divergence is a list of removals, two rebindings, six additions and four repricings.

Storage is declared, not discovered. A certificate carries the reads its execution consumed and the writes it produced, and validity compares them with a re-execution. Four opcode families reach a cell: SLOAD and SSTORE in the exact discipline, and the assert and delta families in the commutative one. A called frame may add at most 16 entries to the declared set, so a callee cannot spend the limits its caller needs; the entry that would exceed this aborts that frame and no other.

Added, on bytes no EVM fork has ever assigned: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. The predicate and the sign are in the opcode, never on the stack. A guard returns nothing, so no branch can depend on whether it holds; a delta's net is taken over the integers and never modulo 2²⁵⁶. SETSEQ(key) sets the sequencer cell of the contract whose context is executing and of no other; a zero or malformed key is a derivation failure that invalidates the whole certificate.

Rebound: NUMBER and TIMESTAMP answer from exact reads of the epoch-beacon cells, so both are constant throughout the epoch, and a ported contract that uses block.timestamp for a deadline is deciding against a time up to 24 hours stale.

Removed (13): BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM have no referent; GASPRICE and BASEFEE name per-block cells whose exact read is stale by construction; BALANCE and SELFBALANCE would force an exact read of a native balance; ORIGIN has no sender to name; SELFDESTRUCT would let a code-hash cell return to zero.

Repriced: SLOAD and SSTORE are flat at the warm-access cost; the cold-access surcharge is deleted everywhere; KECCAK256 rises to 720 gas plus 144 per word, measured against this machine's own implementation, the one repricing that raises a charge. The assert and delta opcodes cost the same warm-access amount as SLOAD.

Precompiles are a closed set of five: sha256, identity, modexp, ed25519_verify and blake3.

Two meters. Sequential gas is derived from the declared read, write and registry counts and is never measured by the machine. The parallel meter is what the interpreter counts, against a budget the certificate declares in derivation units; exceeding it at depth 0 invalidates the certificate.

Code travels in the certificate. Contract code lives in a write-once code-hash cell, so there is no redeploy, and a deploy is a call with a zero target. The runtime image is carried in the certificate and resolved by a declared exact read of the code-hash cell, never by address alone. A blob is at most 24,576 bytes.

A contract's record is five cells: the code hash, the deployer, the sequencer key, the admin and the fence counter (§7). The admin cell holds an address; zero means the deployer is the admin, and 32 bytes of 0xff mean the role has been renounced, irreversibly. The admin sets the sequencer key through a registration certificate and passes on or renounces the role through a set-admin certificate; both declare exact reads of the deployer and admin cells, so a certificate from a replaced or renounced admin is skipped. Contract code never sets an admin; it moves its own sequencer with SETSEQ, which is also how a factory-created contract gets one.

The standard library. A token, a tip jar and an escrow, written delta-first, are pre-deployed at known addresses in the block that activates the machine, together with the delta wrapper they call. A ported Ethereum contract that avoids the removed opcodes and precompiles runs correctly on day one in all-exact mode, serialized by a sequencer if it is hot; parallelism is opt-in per slot, typically a small diff that moves a balance map from load/store to assert/delta.

7. Sequencers#

Guarded deltas dissolve the contention of payments. What remains is exact-read logic on hot state, an order book, an automated market maker, where two honest users building against the same cell will still produce a skip, and where contracts that read state to decide what to write cannot be applied in arbitrary order. The protocol's answer is to let the contract choose its serializer.

Binding. Every contract's record (§6) holds a sequencer key. A contract whose key is non-zero is sequenced: a certificate may read exact, guard by equality or set one of its cells only with that key's signature. A contract whose key is zero is open: anyone may take its exact path with a certificate of their own, and the contract is protected only by its code. The key is set at deploy by the deployer, later by the admin, or by the contract's own code through SETSEQ, which is how a governance replaces a sequencer without an admin. The binding may name any key; a key nobody serves is not a consensus error, the contract is simply unusable until someone serves it or the forced path (§8) changes it. Guarded deltas commute and are never gated, so a sequenced token still accepts every transfer from anyone.

The directory. A sequencer announces where its service answers with a directory certificate: its key and a string of 1 to 256 bytes of printable ASCII, typically a URL, announced from a persistent address. The entry expires 90 days after the announcing certificate's TTL unless renewed, and a withdrawal certificate removes it at once. Consensus stores the string and never interprets it. The directory is discovery, not authorization: wallets read it to learn whom to ask.

Intents. A user does not build a certificate against a sequenced contract. The user signs an intent: the target and calldata, a parallel budget, a nonce, a window from NotBefore to TTL with TTL − NotBefore at most 8 blocks, the sequencer's persistent address, a set of bounds on the result, the payment owed to the sequencer, the payments owed to any co-sequencers, one-shot payers that fund all of it, and change outputs. A bound is a predicate on a cell the call writes, final-at-least, final-at-most, delta-at-least or delta-at-most, and at least one bound must name a slot the call wrote. The intent is the user's whole authorization; the sequencer cannot change what it does, only when.

Fills. The sequencer executes the intent over its own view of the state, the chain tip plus every fill it has already built, and publishes the result as a fill: a certificate whose program is the intent, whose deposit comes from the sequencer's own persistent balance, and whose id is the hash of the intent, so two fills of one intent share an id and only one can be charged. The sequencer is trusted for liveness only, never for safety: if it lies about the inputs, the fill is simply skipped against the canonical fold, and the lie costs the sequencer's deposit, not the user's funds.

Receipts. A sequencer answers a signed intent in milliseconds, long before a block exists: it executes the intent, signs the fill, and returns the fill, or a signed receipt naming the intent id, the pipeline seq and the result, to the wallet. This is a pre-confirmation. It is the sequencer's promise and not the chain's; it becomes final when the fill applies. Because every receipt is signed, misbehaviour is evidence: two receipts from one key that give one seq to different intents, or one intent different results, are a proof anyone can check from the bytes. Consensus does not punish it. The market does. Receipt format, price, identity and reputation are off-chain and free by design, so users choose between a cheaper sequencer, a publicly identified one or an anonymous one, and leave one that is caught equivocating.

Pipelines. The chain keeps, for every pair (sequencer key, contract), the last seq applied. A fill declares a seq for every pipeline it is in and can enter only when the counter stands at seq − 1; counters advance only when the fill applies. A skipped fill therefore leaves its counter where it was: the fills built behind it cannot enter, and the sequencer rebuilds from the same number. Two fills at one seq: the first in fold order enters, the second cannot. A sequencer's pipeline commits in the order it signed, whatever order a producer received it in, and a producer mixing the pipelines of several sequencers has no choice over the result.

The fence counter. Every contract keeps a counter, fid, in its record. A fill declares the fid of every contract it reads exact or sets; a mismatch means the fill cannot enter. The counter advances by one when a forced certificate (§8) that applies sets a cell of the contract, and when the contract's sequencer cell is written. A read or a delta does not advance it: a read changes nothing, and a delta commutes with whatever a fill guards or deltas. A fill that reads exact a cell others move by delta answers for that read like any certificate, and its sequencer pays the skip if the cell moved. This is how the forced path and a sequencer change invalidate every fill built over the state they bypassed, with nobody charged: the sequencer sees the fence move, rebuilds and republishes, losing only latency.

Co-sequencing. A call that crosses contracts bound to different sequencers lands on chain as one fill carrying the signature of every sequencer whose exact path it touches, within the certificate's limit of 16 signatures, each counted against the block's signature ceiling and in parallel gas, each with a seq in its own pipeline, each paid what the intent names for it. Coordination, who leads, how reservations are made, what each charges, is off-chain and free by design; the chain sees one certificate, atomic by construction. A joint fill that is never published blocks only the pipelines it is in; once its window passes, each signer reuses the number it signed.

Who pays a skip. When a fill enters and a read is stale or a write overflows, nothing is written, nobody is paid, and whoever erred pays the skip fee: the first read or write that failed in certificate order decides, and the bill goes to the sequencer that declared itself for that contract if the contract is on the fill's exact path and the chain's record agrees; in every other case it goes to the leader, the sequencer whose deposit the fill names. Each listed sequencer has a reserve taken at the fill's position for exactly this. The user never pays a skip. The user's payment to each sequencer settles only when the fill applies.

What a sequencer is. An ordinary server run by the application team, with whatever machinery it prefers: a single process, a rollup, a federation. It sees its application's order flow first and is therefore the natural venue for that application's extractable value; the design makes this explicit and lets the application capture that value instead of leaking it to block producers, while the forced path bounds the power this implies. Heavy contracts become viable, cryptography, the entire logic of a game, a whole system in one contract, because heavy execution happens off-chain at construction and the chain verifies it in parallel. Construction is a competitive market: a cheaper or more reliable sequencer attracts users, and every node offering construction adds capacity.

8. The Forced Path: Inclusion Is Application#

A contract whose only door is its sequencer is a jail if the sequencer censors, overcharges or disappears. Every user therefore has a slow path that needs no one's permission.

The user signs an open intent: an intent exactly as in §7, with no sequencer named and no co-sequencers, funded by the user's own one-shot payers, and relays it to the network. It travels in the mempool as an intent, not as a certificate. The block producer, who holds the full state and has already settled every ordinary certificate of the block, computes the end-of-block state and executes the open intents it chooses against that state, in intent-id order, appending the resulting forced certificates as the last certificates of the block. A forced certificate's id is the hash of its intent, as a fill's is. Inclusion is application: there is no queue, lease, quota or deadline. A forced certificate whose declared reads do not hold against the state where it was placed cannot enter the block at all; the producer built it, so the producer is the party who could have known.

Bounded by construction. A block carries at most 16 forced certificates, and each declares at most 4,000 derivation units of parallel budget (200,000 machine gas). Every exit a contract offers, withdrawal, cancellation, retirement, transfer, must fit in that budget; the rule for contract authors is that a withdrawal fits the forced budget. At full occupancy the forced path takes one third of the genesis parallel ceiling and ordinary traffic keeps the rest.

A failing call still lands. A forced certificate whose call reverts, breaks its bounds or runs out of gas enters in its failed form, FORCED_FAILED: its payers are debited and burned, change returns to the user, the id is marked seen, and nothing else is written. Validity accepts the failed form only when re-executing the call against the declared reads does fail. This is what makes the path resistant to abuse: an attacker who relays open intents that cannot succeed pays for each one, and a user whose intent is sound cannot be starved by them, because the producer is paid for what it includes and prefers surplus.

The fence. A forced certificate that applies and sets a cell of a contract advances that contract's fence counter (§7), so every fill built over the state it changed cannot enter. A forced certificate that only reads a sequenced contract, exact or through guards, or only moves deltas in it, leaves the fence alone, and so does one that lands in its failed form; pending fills still enter, and only one that read exact a cell the forced certificate moved is skipped (§7). The sequencer loses latency, nothing more, and a user who forces one transaction per block on a hot contract pays the forced price each time.

Payment. The intent's payment covers the certificate's fees at the block's base fees; the base-fee part is burned and the rest joins the producer's tips. The producer receives what a sequencer would.

No state is orphaned. A contract whose sequencer has disappeared stays alive through its delta methods, which need no sequencer, and through the forced path, by which its users withdraw and by which its own code, or the admin, can call SETSEQ or a registration and bind it to a new sequencer. Censorship inverts: it costs the censor, in lost fees and users routing around it, and costs the network nothing. No operator is load-bearing for safety.

9. Two Markets: Sequential and Parallel Gas#

A chain consumes three resources of different scalability classes, data, verification and mutation, and pricing them in one market means a signature check competes at auction with a storage write. Zycord splits the fee into two independent markets, each with its own target, ceiling and base fee held in consensus state:

Sequential gas prices state mutation, the scarce resource, the one loop every node runs in order. Parallel gas prices verification, which grows with every core and GPU that joins the network, and its ceiling is set high and cheap. The consequence is a design goal stated as an invariant: heavy cryptography does not impact the network, by economic construction. A certificate that verifies a large proof but writes two slots pays almost everything in the cheap market.

Both markets have the EIP-1559 shape [12], each in its own unit: the base fee is burned and the priority fee pays the producer, on certificates that apply, and only those. A skipped certificate's fee is burned in full and pays nobody. This is the load-bearing rule of the economic model. Were a skip to tip, the party who chooses a block's contents would be paid for arranging other people's failures. Burning inverts it: a skip consumes ceiling space and yields nothing, so a producer maximizing revenue is maximizing application and is actively against causing skips.

Only applied gas moves the base fees. Three quantities are counted per block: included gas (every certificate, whatever its outcome) bounds the ceilings; applied gas (only what applied) moves the base fees; block bytes bound the byte ceiling. A skip is a failed attempt to use the chain, not evidence of demand for it; if included gas moved the fee, a griefer could fill blocks with self-conflicting certificates at the fixed skip fee and price everyone out at constant cost.

The sequential ceiling is elastic. The sequential target T is consensus state from block 0, not a constant, and an epoch controller moves it:

• Within a block, the soft ceiling is 2T and the hard limit is 4T. A producer that bursts between the two forfeits a quadratic share of its own revenue, part of the subsidy plus the block's fees, and never anyone else's share.
• Across epochs, T follows demand: twice the lower median of applied gas in the epoch, clamped between T − T/1024 and T + T/512, floored at the genesis value and capped at the genesis capacity (companion document). Growth is withheld when the health gate says the network is not healthy: competing headers cited above 2% of the epoch's blocks.
• The certificate count, the signature count and the byte limit scale with T from their genesis values, up to static capacities (2²⁵ certificates, 8 MB).

Skipped certificates burn their fees and register nothing, so the only way to raise the ceiling is to win application: sustained, non-conflicting, base-fee-burning use. Forcing growth costs an attacker exactly what organic adoption costs everyone else. The parallel market needs none of this care: its target and its ceiling are pinned at a constant multiple, 3×, of the sequential target and ceiling, so 3T and 6T, and inherit their growth. The lineage is Monero's penalty median [15] and the adaptive-limit work [16].

The construction margin. The same parallel market pays sequencers for shaping work: a sequencer that aggregates many transactions into one certificate pays one parallel bid for it and charges its users per transaction, inside the intent.

10. Network#

Bodies are chain data. A block's certificate bodies must be retrievable for the block to be valid, so state is always reconstructible from the chain alone and no operator, sequencer included, is ever a data custodian. Certificates are bigger than classical transactions because they carry their reads and writes; the mitigations are structural: fills cut through internal writes, spent one-shot cells compact once buried past the undo horizon, and a node may prune bodies below a floor it announces to peers.

Transport. TCP, then TLS 1.3 with Ed25519 peer identities in self-signed certificates: the channel is bound to a key, and nothing more is claimed. Every message is a 5-byte frame, length and type, and the length is checked against the type's own ceiling before any allocation. A type a newer build added is read and discarded under a small limit instead of closing the connection.

Relay is hash-first. Certificates gossip independently and are validity-checked, statelessly and in parallel, on arrival. A relay node needs no state to bound the cost of filtering spam: stateless validity is checkable from bytes, and a node that holds state also refuses a certificate whose deposit cannot cover it. Relay treats exemplars, not ids: a certificate whose signatures fail costs that exemplar, and nothing is recorded against the id, because a later exemplar of the same authorization may be good. Blocks relay as headers plus hash lists against the mempool [11], so propagation latency does not scale with block contents, and the receiver verifies the header's work before fetching any body.

Sync chooses by verified work. A node catching up prefers the peer whose headers have actually proven the most work over the peer claiming the greatest height. Headers are validated as a chain before bodies are fetched; a competing branch is adopted only when it connects within the undo horizon and carries more work than the chain it replaces (under proof of stake, more slots, §11). Pinned checkpoints, embedded in the release and accepted only when a block is at least one epoch old, refuse a contradicting chain however heavy, as a launch-era defence against history rewriting; an operator can add a pin by flag.

Peers are scored, by identity: an invalid message costs 20, a protocol violation 50, an unserved body 10, an excessive request 5; a useful message earns 1; a peer is banned at −100. Expensive checks, key epochs and proof-of-work evaluations, are budgeted per peer and refunded when the block proves useful, so an attacker cannot make a node grind work on announcements that lead nowhere.

Citations. A header may cite up to four recent competing headers at its parent's height, unpaid: citing needs real proof of work, while suppressing the signal would need nearly every producer to omit it. The cited fork rate is the health signal the fee controller (§9) reads.

The node interface. Reads are served over HTTP, bound to localhost by default; submitting certificates, open intents and signed service cards are the only writes. Reads are rate-limited per client, with a trust token to exempt the operator's own tools. A Stratum endpoint in the dialect common CPU miners speak lets a node mine with external software.

11. Proof of Stake#

This section specifies the consensus of the era in which block production passes from proof of work to stake. The rules of §2 to §10 hold unchanged except where this section says otherwise; the schedule and every value are in the companion document. Constants marked open are fixed by the era's release.

What changes. Two things. The right to produce the next block, which proof of work sells for hashes, is drawn by stake; and the block interval falls from 30 to 5 seconds. Everything else stands: every validity rule of §2 is checked by every node, for every certificate, from the bytes; the fold is the same; the two gas markets are the same; an invalid certificate inside a block makes the block invalid. The citation rule of §10 stands, with the cited header's slot signature in place of its work. The surface this era opens is that of a proof of stake, and no other.

Where the computation goes. A proof-of-work miner spends computation on hashes, which buy security and nothing else. A producer in this era spends the same computation on verification: checking signatures, re-executing programs, deriving certificates, in parallel, before ordering them. The work the network pays for becomes the work the network needs. An ordinary computer verifies thousands of certificates per block; a producer with more cores keeps up as volume grows. Parallel verification puts the ceiling far above what the sequential loop consumes; what lies beyond it is in §12.

Stake. A participant bonds native coin with a native operation, BOND, which moves balance from a persistent address into a stake cell tied to that address. The stake cells are protocol cells: the certificate authorizes the move and the fold performs the write, as it does for the sequencer counters. The key of that address is the key that signs blocks. A stake becomes active one epoch after it is bonded, so stakes cannot be created and discarded in series; UNBOND returns the balance after a delay longer than the undo horizon. The minimum is set by the companion document. One key, one stake.

The draw. Blocks occupy slots of a fixed interval. For each slot, a producer is drawn from the set of stakes active at the opening of the epoch, with probability proportional to stake, from a seed the chain fixed during the previous epoch and wrote into the beacon cells (§4); the seed must not be biasable by the producers of the blocks that fix it. The header carries the slot and the drawn producer's signature in place of the proof of work; a header signed by another key, or outside its slot, is invalid. A slot with no block stays empty, and the next drawn producer builds on the last block it knows. The draw is a function of state fixed before the epoch opens, so every node derives it alone, and no consensus message is exchanged beyond the block itself. The lineage is the slot-leader lottery of Ouroboros [17] and the per-epoch leader schedule of Solana [21]; hiding the leader behind a verifiable random function [31], as Praos does [18], is the alternative if denial of service against known producers becomes a problem.

Chain choice. Where §10 chooses by verified work, this era chooses by length: among valid chains, the one that occupies the most slots [17]; between two of equal length, the one whose first block after the fork sits in the earlier slot. The undo horizon and the pinned checkpoints of §10 remain and are the defence against rewriting with keys since unbonded: a node joining the network accepts the history its release pins, and no longer chain contradicts it.

Reward. The block subsidy and the priority fees go to the drawn producer, as they went to the miner, through the same maturity ring; the burned part stays burned. A participant's expected revenue is proportional to its stake, and the cost of collecting it is the verification of the certificates it includes. An invalid block is rejected and pays nothing to whoever signed it.

Equivocation. One fault alone is punished in consensus: two headers signed by one key for one slot. Like an invalid certificate it is a one-message proof, checkable by anyone from the bytes. A report certificate carries the two headers; the fold burns the signer's own bond, removes the key from the active set and pays the reporter an open fraction. A report is accepted until the stake's exit completes. No other conduct is punished in consensus, and no conduct of a producer reaches anyone else's coin. The precedent is proposer slashing on Ethereum's beacon chain [19].

Pools. A pool is a stake that accepts delegation. Any persistent address may bond and, by a native operation DELEGATE, point its bond at a pool's key; a bond that only delegates has a smaller minimum than one that produces. The balance never leaves the delegator, who redirects or unbonds it under the same exit delay. A pool's weight in the draw is its own bond plus what is delegated to it. The reward of the blocks a pool produces is split by the fold once per epoch, off the per-block path, between the pool, at a margin it declares when it registers, and its delegators, in proportion to stake. On equivocation the pool's own bond is burned and its delegations return to their delegators. How verification is shared inside a pool is the pool's business: each member verifies the share it receives, one certificate may go to more than one member, and the operator collates the answers, assembles the block and signs it with the drawn key. All of this is construction, outside consensus and free by design (§1): the chain sees a table of delegations, a header signed by one key, and a block whose certificates every full node verifies again. A small node contributes the cores it has; a holder with only coin contributes stake. The lineage is Cardano's stake pools [20], which likewise never slash delegators.

The ramp. The era enters in three steps, each a consensus rule.

1. Bonding. BOND, UNBOND and DELEGATE are accepted. Proof of work goes on producing every block and receiving the whole producer's share.
2. Ramp, over 90 epochs. Every block is still mined, and carries the signature of the stake drawn for its height, in the header outside the proof-of-work preimage; the block id covers it, so a signed block and its unsigned copy are two blocks, and at equal work the signed one wins. Chain choice is still by work, and two signatures at one height are not equivocation. The producer's share of the subsidy is divided between miner and staker: a counter k starts at 1 and rises by one with each epoch that passes the gate, and the staker takes k/180, so work keeps at least half until the switch. A block carried without the signature is valid and pays nobody: its producer's share of the subsidy and its priority fees are burned, so a miner gains nothing by leaving the staker out, and a staker gains nothing by being absent. An epoch passes the gate when at least 90% of its blocks carried the signature and active stake, delegations included, held at least 10% of supply. The ramp starts when active stake reaches 10% of supply for 30 epochs or, at the latest, at the epoch the companion document fixes, with whatever stake exists. No block is produced by stake alone before stake has signed, in production, nine blocks in ten for 90 epochs. The precedent is Decred's hybrid, in which mined blocks carry stake votes and the subsidy is split between the two [22], and the Merge, in which stake ran its own chain for almost two years before it took over block production [23].
3. Switch. The first block of the epoch after the 90th epoch to pass the gate is slot 0: proof of work ends, the interval becomes 5 seconds and the epoch becomes 17,280 slots. What an epoch pays in subsidy does not change; each block pays one sixth, and an empty slot pays nothing. The per-block ceilings (§9), with their floors and caps, and the forced-path count (§8) divide by six, rounded down, so that capacity per day is the same at the instant of the switch, and the epoch controller continues from there. Every block-counted constant that measures time (maturity, maximum TTL, intent window, undo horizon, median-time window, lifetime of a directory entry) multiplies by six, and a maturity or TTL set before the switch is converted at the switch block.

Finality. A block is final by depth, as under proof of work. Financial services should wait 10 minutes: 120 blocks, where proof of work asked 20. Blocks older than one epoch may be pinned as checkpoints.

12. Past Full Verification#

In the proof-of-work and proof-of-stake eras every node verifies every certificate. Computation is not the limit: verification is parallel, and the ceilings of §9 are re-pinned at era boundaries up to the structural width of the certificate list, 2²⁵ per block. What limits before that wall is data: the bandwidth to receive every body and the storage to keep every body and every entry of the spent registry. This section says what is known of the road past that and leaves it to a later era, activated on demand, when daily volume approaches what an ordinary node verifies. It is a direction, not a specification: the problems have several solutions with different trade-offs, the network serves every demand it will meet for a long time without any of them, and preparing in detail for a far future is not worth more than leaving the road marked for whoever walks it. Nothing that comes before changes. Validity as a function of the bytes, the fold, typed access, the two markets, sequencers and the forced path stay as they are. What changes is only who verifies each certificate.

What the certificate permits. In re-execution chains, Ethereum, Solana and those that derive from them, every validator executes every transaction against the global state, verifying inherits the limits of state, and the historical answer has been bigger machines, which is to say fewer nodes. Parallel execution inside the node, with declared access lists as in Solana [21], makes each machine faster and does not change who needs one. Cardano came closer: in the extended UTXO model validation is deterministic and local [24], but scripts run on every node and shared state contends, which the model resolves by pushing serialization to batchers off chain, unrecognized by the chain. Rollups, optimistic and validity alike [25][26], took execution off the base chain and left it verifying: that is the right division, paid for with a second layer, a bridge, a single sequencer whose forced path waits behind a delay, and, by kind, a week of interactive dispute or a prover that costs orders of magnitude more than executing. A Zycord certificate is a rollup batch that the base chain checks from its own bytes and never executes against its state, and for that reason needs no second layer: there is no bridge because there is one state; no dispute because an invalid certificate is its own fraud proof, in one message; no prover because verifying costs what executing costs; the sequencer is per contract, the forced path lands in the next block, and two contracts under different sequencers compose in one atomic certificate (§7), where two rollups need a bridge. And where the answer to growth is sharding, Ethereum's original trajectory, Near [27], the parachains [28], which partitions state and loses atomicity across partitions, Zycord's partition, when it comes, partitions verification and not state: the state stays one, the fold stays one and every certificate stays atomic, because who verifies a certificate is a free choice when validity is a function of the bytes.

Sampled verification. With bonded stake, the responsibility for verifying a certificate can be drawn to a subset of stakes instead of falling on all of them. A certificate enters a block with the attestations of its committee; any node remains free to verify anything; an invalid certificate remains its own fraud proof, one message, with no state and no interactive game [29]; and what the era adds is the slashing of whoever attested. The size of the committee, the form of the attestation, the challenge window and what happens to what was applied over a voided certificate are the specification of that era, and stay open. The effect is to invert the curve: capacity grows with every node that joins, because each verifies a smaller share, and the committee grows with the set.

The verification cone. Whoever receives a certificate does not need the whole chain to trust it. Reads are declared, so the set of certificates it depends on is enumerable from the chain: for every cell read, the certificates that wrote it since the last epoch state root, and theirs, recursively. That cone, re-verified from the bytes and anchored at an epoch root the header commits to (§3), is a complete verification of what matters to the receiver, done in seconds, in network time, with no circuit and no special proof. An exchange receiving a deposit verifies the cone of the deposit, not the network; under sampled verification what remains is to wait out reorgs and the challenge window, which is what it already does today. A proof that a cell held a given value at the epoch root is the one new object this requires, and its form is open; the lineage is simplified payment verification [1].

Storage. What the network already does: spent one-shot cells compact past the undo horizon (§4), and a node prunes bodies below a floor it announces (§10). What stays as a case for study: a spent registry per epoch, in which one-shot addresses expire and the registry closes; an accumulator in place of the registry [30]; and the keeping of old bodies by a fraction of nodes, with the epoch root as the guarantee that what is kept is what was spent.

Bandwidth. Two routes. The first is the topology the design already has: wallet, sequencer, producer. A fill need not flood the network; it goes from the sequencer to the producers, and everyone else receives the hash, as relay already does with blocks (§10). The second is to separate the head of a certificate from its body. The head is what the fold touches: id, reads, writes, deposit and bid. The body is what verification consumes: program, calldata, signatures. Under sampled verification a producer needs the body only of the certificates it is drawn to verify and the head of all the others, and its bandwidth falls by orders of magnitude. The block goes on committing to the hash of the whole exemplar, and bodies go on being chain data, served by whoever verified them and whoever archives them; how their availability is guaranteed when not every node holds them is the question the era must answer before it exists [29].

13. Accepted Risks#

Consequences of the rules that are accepted as they stand. Each is bounded, or falls on a party that chose it; none lets anyone take a third party's native value.

1. A contract whose sequencer, admin and sequencer-changing code have all disappeared can be left only by the forced path: slow and more expensive, but alive.
2. Under empty blocks both base fees come to rest at 7, above their floor of 1: below 8 the downward step rounds to zero. Moving that resting point needs a parameter change at an era boundary.
3. About one block of paid fee griefing on a hot contract: the producer's own forced certificates placed around a user's, bounded by the user's bounds, and one forced certificate per block making the sequencer rebuild its pipeline.
4. An open contract, with a zero sequencer key, is protected only by its code, and the author of a certificate against it pays its own skips: the author chose the reads.
5. A non-native asset credited to a one-shot address by anyone other than the certificate that burns it is frozen by the burn, which moves only the native balance and the cells that certificate writes. Checking an address's asset balances before burning it is a wallet rule, not a protocol rule.
6. A certificate that only moves deltas does not advance the fence (§7); a fill built before it that reads exact a cell it moved is skipped in a later block, charged to the sequencer. A sequencer avoids this by not reading exact a cell its contract lets anyone move by delta.
7. Residual griefing of the forced-path executor: an attacker with many payers can relay open intents that no certificate can carry, such as one whose payer is short of the payment. A call that merely reverts or breaks its bounds is not among them: it lands in its failed form and pays (§8). Each uncarriable intent costs the executor one build; the copy is then evicted and quarantined, and a replacement on the same payer must pay strictly more.
8. A co-signer locks no cell. A joint fill it signed holds a place in its pipeline until the fill is carried or its window passes (§7). A joint fill not carried in time may meet other fills on those cells; whichever enters the fold second is skipped, charged to its own depositor.
9. On an open contract, the certificate whose deposit address sorts first wins a race on exact reads, and addresses are cheap to grind; a contract with contended exact state chooses a sequencer, whose pipeline sets the order.
10. A plain call on an open contract's exact path declares the contract's sequencer cell as exact zero. If the contract gains a key before the certificate lands, the read is stale and the call is skipped, charged to the caller; the wallet warns before building such a call.
11. The skip fee is fixed, so when base fees are high a skip costs less than an application; trying several variants of one certificate is cheap, and every node verifies each of them.
12. Bandwidth and storage at high throughput are a declared open problem, not a solved one: bodies are chain data, every node carries every byte, a machine call carries the code it runs, and the spent registry grows one entry per one-shot spend. The road is in §12.
13. Under proof of stake (§11), the security of the chain is that of a conventional proof of stake: it costs what it costs to gather a majority of the draw weight, delegations included. The ramp starts at its deadline with whatever stake exists, and the gate is what keeps the switch from completing without live stake holding a tenth of the supply; a tenth of the stake, absent, pauses it. A pool's equivocation costs only its own bond, whatever is delegated to it; delegators choose their pool knowing this. Long-range rewriting with keys since unbonded is barred only by the pinned checkpoints (§10), which a joining node accepts from its release and does not derive from the chain.

14. Conformance#

The rules are the architecture specification, the golden vectors are the protocol, and where any two of them disagree the more precise one wins and the disagreement is a bug. The protocol lives in a published spec/ directory: the parameter files, the chain-id ledger, the pinned checkpoints, the images of the pre-deployed library and three vector corpora:

• fold vectors: (pre-state, block) → (post-state | invalid, outcomes, fees); an invalid vector records the single rule it breaks;
• derivation vectors: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), or the rule that refuses the certificate before the machine is reached;
• difficulty vectors: (parameters, headers) → next target, with a verdict on a candidate header; under proof of stake, (stake set, seed, slot) → drawn key.

Vectors are generated, never hand-edited. Regeneration drives the reference fold, replays the result through it, and then replays the committed JSON through a second, deliberately naive fold that shares no code with the first; a regeneration the second fold disagrees with fails. A regeneration that changes an existing vector is a consensus change and is reviewed as one. An implementation is conformant when it reproduces the genesis id and passes the vectors; it is then a peer, not a fork.

15. Relation to v1.0#

This paper replaces v1.0 [0] in full. Where the two differ, this paper is the protocol and v1.0 is not to be read alongside it. The thesis is unchanged: self-certifying certificates, a fold that never executes, typed state access, and two fee markets. The changes below were found while implementing the design; each removed consensus surface and classes of error.

16. Conclusion#

Zycord orders certificates instead of executing transactions: validity checked by anyone, anywhere, in parallel, from bytes alone; state advanced by a fold that only compares and adds; conflicts skipped, priced and charged to the party that chose them; concurrency declared rather than discovered; applications confirmed in milliseconds by sequencers that are trusted for liveness and never for safety; a forced path that keeps every contract reachable; and a consensus that, once the coin is distributed, spends its computation on verification instead of hashes. Verification scales out with hardware the network does not own. Commitment stays sequential, and nearly free.

References#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Superseded by this paper.
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. 2013.
[3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018.
[4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012.
[5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022.
[6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022.
[7] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Monero Research Lab documentation.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (proposer slashings). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: Launch, Eras and Parameters#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

This document is the companion to Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v2.0 ("the paper"). The paper defines the mechanisms. This document states how the mainnet was launched, how the coin is issued, which era activates what, and the value of every parameter. It replaces §13 and §14 of the v1.0 paper in full; where they differ, this document governs.

1. Launch#

Mainnet genesis: 2026-10-07 00:00 UTC (1791331200), chain id 1.

• Blocks every 30 seconds under proof of work; every 5 seconds from the switch to proof of stake (§6). Proof of work: RandomX v2, CPU-minable. Difficulty: LWMA over a 90-block window.
• Block 0 contains no certificate, no address and no key. No coin exists before block 0. Genesis is reproducible from published sources.
• No investor round and no admin keys. No code path lets any key pause, upgrade, mint, censor or reorganize.

The launch commitment. The parameter set carries a commitment to a secret launch message. Block 1 must open that commitment in its header, so only the holder of the message can produce block 1, and nobody else can accumulate work on a chain that starts before the announced genesis; the issuance ramp makes any head start worth little. From block 2 on, any miner can build.

Chain ids are recorded in a ledger. The ledger, with the genesis id each live network carries, is embedded in every binary and checked at start-up: the node refuses a retired id, and a parameter set that would give a recorded id a different genesis. A node refuses to start with a work engine other than the one the network declares.

2. Issuance#

The subsidy decays smoothly to a perpetual tail. The rate is constant within an epoch of one day and steps down at each epoch boundary, by exact integer arithmetic over four constants:

E(0) = E0
E(n) = max(tail, E(n−1) − floor(E(n−1) / Q))

with E0 = 21 ZCD per block, Q = 1054 and tail = 0.33 ZCD per block, at the proof-of-work interval of 30 seconds. The rate halves about every two years. There are no floats and no table. The genesis block pays no coinbase. The tail begins at epoch 4,376, about year 12, with 61,836,900.03 ZCD scheduled: the 62,744,838.47 the schedule sums to, less the launch ramp and the genesis block. Those figures are whatever the recurrence produces; no node ever computes a closed form. One ZCD is 100,000,000 drops.

A slow start. The first 86,400 blocks (30 days) are a ramp: block h pays E(30) · h / 86,400, the rate of the epoch in which the ramp ends, rounded down, so the reward rises in a straight line from near zero to the schedule. What the ramp withholds, about 907,917 ZCD, is never paid back.

The change of interval. From the switch to proof of stake (§6), the epoch is 17,280 slots and the subsidy per block is E(n)/6, rounded down in drops; the recurrence does not change. What a day of full slots pays is the same under both intervals: 21 ZCD per block on the genesis curve equals 3.5 per 5-second block, and the tail of 0.33 equals 0.055. The tail begins at the same epoch, 4,376. The rounding withholds less than a thousandth of a ZCD per epoch and is never paid back.

The tail pays whoever secures the current era without conscripting the fee markets. Against it run the base-fee burn of both markets and the burn of every skipped certificate (paper §9), so net issuance is tail minus burn and can be negative under load. As a fraction of supply the tail tends to zero.

3. Subsidy Split#

Every block subsidy is split 94 / 3 / 3 by consensus from block 0. The split applies to the subsidy only, never to fees, and identically to every block. During the proof-of-stake ramp (§6) the producer's 94% is itself divided between miner and drawn staker, by the fraction the ramp has reached.

There is no premine: the split is a rule applied to every block mined, not an allocation at genesis. Over its three years the founder's share sums to less than 2% of the pre-tail supply. A producer that bursts the soft ceiling (paper §9) forfeits from its own share only; the treasury and founder shares are taken from the unreduced subsidy.

4. Treasury#

The treasury cell is the native balance of the protocol address. No key hashes to it, no certificate can debit it, and genesis names no quorum. It accrues from block 1, and this release carries no spending path at all. A spending path is defined by an upgrade, not before height 259,200 (about 5 January 2027), with signers chosen by the community and not by the founder. Until then the cell is a public integer anyone can audit and nobody can touch.

5. Stewardship: The First Three Years (proposal)#

Status. This section is a direction for community review. Nothing in it is a consensus rule until the treasury upgrade of §4 pins a key set, and the details are specified only after the direction is accepted.

What the treasury receives. About 533,000 ZCD in year 1, 396,000 in year 2 and 280,000 in year 3: about 1.21 million in total. From year 4 it also takes the founder's 3% (§3), for about 396,000 that year in all. What this buys depends on a price nobody knows, and a thin market cannot absorb large sales, so the plan must work at the low end:

Every amount below is therefore a share of treasury inflow, never a figure in dollars or in ZCD.

Five seats. The seat is defined before its holder. Each seat has a public charter: its duties, its deliverables, how it reports and what it is paid. Anyone may apply. Whoever holds the seat serves the charter, as under a contract.

Decisions.

• A spend needs 3 of 5.
• Replacing a holder, rotating keys, spending the reserve or amending a charter needs 4 of 5, and is public for 7 days before it takes effect.
• Terms last one year and are renewable. Candidacies are public for 30 days. The first five holders are the key set pinned by the upgrade node operators adopt; a later hard fork can re-pin it.

Pay is participation, not salary. A seat's share accrues locked and is released every six months, against a published report and the votes of 3 of the other 4 holders. No holder votes on the release of their own pay. What is not released returns to the reserve. Seat pay is fixed by the charters and is not set by a spending vote. A cap per seat, measured at market price on the release date, sends any excess to the reserve.

Budget, as shares of inflow.

Infrastructure has first claim: nodes, seeds, explorer and build servers cost about US$ 500 per month today. Reimbursement converts at the market price on the day it is paid. The share covers that cost at about US$ 0.06 per ZCD in year 1, US$ 0.08 in year 2 and US$ 0.11 in year 3; below it, the shortfall is carried forward without interest and paid when the share allows.

The founder. The founder's 3% of the subsidy (§3) rewards the work done up to and at launch. It is separate from the lead-developer seat, which is paid like any other seat for ongoing work. The founder holds one key of five and does not vote on the release of that seat's pay.

What consensus enforces. Once the upgrade lands: the 3-of-5 spend and the 4-of-5 rotation with its delay. Everything else in this section is a norm. What enforces a norm is that every spend is an ordinary certificate, public and countable from the chain alone.

Open. The cap per seat. The legal form under which the public representative signs. Whether the six-month lock is enforced by an escrow contract of the standard library once the machine is active.

6. Eras#

Eras are height constants compiled into public releases. A block below a gate that carries a program the gate enables is invalid, and that height check is the only thing separating eras, except era 2's ramp and switch, which are triggered by state within height bounds. A new era may add rules and record types; it never changes what an existing block means below its activation height.

Eras 2 and S each ship as their own release by hard fork, with a specification, an adversarial devnet and review. Era 2 opens bonding by height, starts its ramp by stake with a deadline, and switches when the ramp completes: the earliest the switch can happen is epoch 303 (month 10), and the deadline on the start guarantees the ramp is under way by the end of month 9. For the 10% threshold, stake is active stake with its delegations and supply is the coin issued, both at the opening of the epoch. The gate may pause the switch past epoch 363; what it cannot do is keep it from starting.

Stake. The minimum bond is 1,000 ZCD, and a stake participates one epoch after it is bonded. A bond that only delegates has a smaller minimum, fixed by the era's release, and never leaves the delegator's custody. The minimum is in ZCD and not in dollars because no rule can read a price; it is revised at era boundaries as the block ceiling grows.

Era 0 is deliberately tiny and era 1 is reduced to what the design needs: with no admin keys there is no pause button, so every consensus line is a line that can kill the network without remedy. Unreachable consensus code is unauditable consensus code and is not shipped. An era that does not prove worth its complexity is never triggered.

The transition is tractable because the fold is agnostic to who orders: era 2 changes whose signature is on the header.

Era 1 gate. The gate block writes the era's compiled constants into protocol cells, so the state root commits to them from then on. In the first 240 blocks after the gate, a certificate that runs SETSEQ must carry a TTL at least 240 blocks past the gate and wait for it to come into range.

Era 2 and heights that measure time. After the switch, height advances six times faster. Every genesis constant that is really a duration (the end of the founder's share, the coinbase maturity, the maximum TTL, the intent window, the undo depth, the median-time window, the lifetime of a directory entry) is read by era 2 in the unit it measures: height 3,153,600 is 1,095 epochs of 2,880, and the era ends the founder's share at epoch 1,095. The genesis parameter table does not change, because the consensus root walks every parameter and moving one would move the genesis id of every live network; the era's constants are compiled, like era 1's.

7. Parameters#

The parameter set is frozen at genesis, embedded in every binary at compile time, and mutable only by hard fork. Its consensus root enters every signature. zcd params prints the compiled values of a build; zcd genesis prints the network, chain id, parameter hash, genesis id and state root.

Era 1 constants are compiled, not parameters, because the consensus root walks every parameter and adding one would move the genesis id of every live network.

Era 2 constants are compiled for the same reason.