Ledger anchors · daily on-chain proof

pool.zcd.lol · Zycord mainnet ·

verify me

Every UTC day the pool publishes a canonical copy of its payout ledger here and anchors the file's sha256 into a contract on the Zycord chain. Anyone, on any node, can recompute the hash, compare it to the on-chain cell, and walk the chain day by day — rewriting one day breaks every later link, in plain sight.

—

days anchored

—

total payouts (ZCD)

—

first day

—

last anchor

①Download the day file

One file per day, one payout per line: amount, block, on-chain certificate, per-wallet attribution (plus the few unattributable dust drops). A file never changes once anchored.

# example
curl -sO https://pool.zcd.lol/ledger/2026-11-03.jsonl
sha256sum 2026-11-03.jsonl

②Compare the on-chain cell

The sha256 must equal the dayHash[day] cell in the contract. Any Zycord node can read it (a read-only endpoint) — including a node you run yourself. No need to trust us.

# storage key = keccak256(abi.encode(day, uint256(slot)))   (slot: dayHash=1)
curl -s "http://<node>:9420/storage?addr=&key=0x<key>

③Or: verify everything at once

verify.py is plain stdlib Python: it fetches the file, recomputes both hashes, reads the cells, checks every line's split arithmetic, and walks the day-to-day chain links. Running it yourself beats reading ten slogans.

verify.py  # download, then:
python3 verify.py --day 2026-11-03 --node http://127.0.0.1:9420
ALL CHECKS PASSED: day 2026-11-03's published ledger is byte-for-byte what the chain anchors…

Anchor records

day (UTC)	payouts	amount (ZCD)	day_hash	height
…

machine-readable: /api/v1/ledger/anchors.json

Miner receipts (share receipts)

Every UTC day the pool folds each miner's delivered shares and that day's earnings into one line, builds a Merkle tree over the day and anchors its root in the ShareReceipts contract. Anyone can recompute the root below from the published file and compare it with the chain, day by day — no need to trust a single number on this page.

Miner credential (soulbound on-chain)

Every address that ever delivered a share holds one on-chain credential: cumulative shares, ZCD received, active days and first day. The pool mints it and it cannot be transferred.

Why the chain is tamper-evident

Each day's chain hash folds the previous day's chain hash into its input, and the contract refuses a second write to any day's cell outright. Rewrite one historical day and every later chain hash mismatches — a visible break across the whole chain. The contract holds no keys and no funds; it is a public blackboard, nothing more.

// PoolLedger.sol — storage (standard solc layout)
slot 0  admin                              // deployer, written once
slot 1  mapping(uint => bytes32) dayHash    // sha256 of the day file
slot 2  mapping(uint => bytes32) chainHash  // links D-1
slot 3  mapping(uint => bytes32) dayMeta    // [payouts << 128 | drops]
slot 4  lastDay        slot 5  firstDay

Honest edges

“unattributed”: a few dust drops per line cannot be attributed to a single wallet (remainder of the payout split). The field says so, and every line satisfies split sum + unattributed = amount.

A few early lines carry no on-chain certificate id (cert: null): the pool ledger and the published file agree on this, and we anchor it as-is — no papering over.

If a day's published file ever disagrees with the pool's own internal ledger, the anchor tool refuses to anchor and errors out — better an unanchored day than an anchored lie.

pool.zcd.lol · anchored on the Zycord mainnet ·