[ANN][ZCD] Zycord | A P2P network of self-certifying state | First week PoW! 🔥

[thesimstoshi]

A  note

I spent years studying Zycord's technology: the architecture, the paper, prototypes, validation. What I studied least was the launch and mining, and 1 October showed it. I'm studying it now.

A few things I want to make clear for anyone arriving:

Mining at home is hard. With the attention the project has drawn, an ordinary computer is now a very small share of the network. gabrielesor and shadow_69 measured this here in the thread. You can still find blocks, but the return is small, and a pool makes it steadier.

Part of the network's hashrate probably comes from people renting it on hashrate marketplaces. As a reference, 1 MH/s of RandomX goes for around US$35-40 a day there. Producing the same hashrate at home would take about 300 ordinary machines and cost far more in electricity alone. That is what home mining is up against.

Zcash's launch is also worth studying: price, supply and demand. It's a good case to compare with Zycord.

The emission schedule. The reward rises in a straight line until day 30, so daily emission grows a lot over the month:

Code:

Emission on day 1        ~980 ZCD
Emission on day 30       ~57,800 ZCD
Total at end of ramp     ~882,000 ZCD
Total around day 45      ~1.76 million (2x)
Total around day 60      ~2.6 million (3x)

You don't need many coins to build. The testnet is free and the cEVM is already open there. Deploying a contract on mainnet takes a small amount of ZCD, which home mining covers.

On my side, I'm focused on decisions I still need to study: the community fund, the technical scope of the next stages, and planning. There's a lot of study and planning under way, and I'll bring each proposal here when it's ready.

[gabrielesor]

Thanks. I'm aligned with your framing: this looks like a privacy gap in the wallet, not a consensus issue.
Full investigation and supporting evidence:
https://gitlab.com/-/snippets/6066089
I'll keep contributing constructively when I can.

[winnerwinnerchickendinner]

Zycord devlog — Sep 5 → Sep 10

⚠️ Mainnet genesis moves from September 15 to October 1. Testnet is relaunched on the 15th.

The GitHub ban took the infrastructure and the open issues with it — work that was already mapped out had to be rebuilt from scratch, and that cost us the schedule. We migrated the code to Codeberg, but their policy does not accept crypto projects; we are migrating again, this time to GitLab.

✅ RandomX v2 validated
✅ XMRig mines here, validated and tested end to end
✅ Node sync: problems identified and fixed
✅ Desktop wallet: improved interface
✅ Testnet test round validating the system working as a whole
✅ Explorer: the faucet actually works now (it did not before)
✅ Site: improvements

🔜 cEVM moved up to Era 0. The FAQ in this thread says there would be no contracts at launch, and the reason was the usual one: with no admin key there is no pause button, so everything that ships in genesis has to be auditable in full. That reason has not changed — what changed is that the cEVM came further along than expected, and it came without giving up quality or security. It enters Era 0 because it reached the standard genesis demands, not because the standard was lowered.

In practice: you can write, test and run contracts from the start of the network — real use for the token, and the door open to anyone who wants to build an application in here from day one.

Interested in seeing the use of RandomX v2, is there a plan to write it for academics in a paper?

[thesimstoshi]

Interested in seeing the use of RandomX v2, is there a plan to write it for academics in a paper?

It was a recommendation from the Monero community; I spoke with a few people while implementing it.

I think there is an academic opportunity here.Zycord devlog – Oct 5 → Oct 9

v0.6.2 is out – download it and update: https://zycord.com/download/
Recommended for everyone mining with the built-in miner.

✅ Release version v0.6.2
✅ Faster built-in miner: the RandomX VM pool now reuses the VM with a warm cache, and the dataset uses huge pages. Measured +47% at 4 threads and +19% at 12 on a 12-thread laptop.
✅ New --mine-large-pages flag, on by default. Linux: reserve pages with vm.nr_hugepages=1100. Windows: grant "Lock pages in memory". The startup log says which memory the miner got
✅ Desktop wallet: live hash rate, your odds of finding a block in 1h / 24h / 7d, and mined rewards shown as "maturing" the moment the block is found, not 240 blocks later (!75)
✅ Matured rewards now appear as one "Mining reward" per block, not merged into a single receipt
✅ Payout address rotation for privacy: now a setting, off by default, and it actually rotates, even while the wallet is locked
✅ Node: mining_hashrate in /metrics and a new /maturing route for pools and explorers
✅ arm64 fix: the difficulty test no longer fails on Apple Silicon (!72). Thanks dario
✅ Mainnet checked across all public seeds: no fork, every seed on the same chain

⚠️ Big rigs (Xeon/EPYC): XMRig with huge pages over the node's Stratum is still the fastest way to mine; the built-in miner now closes much of that gap.

Audit the code and the rules: https://gitlab.com/zycord-group/zycord-node
Issues and MRs on GitLab.

[shadow_69]

A small exchange on the cEVM, running in testnet (with a question for the devs)

After the dev's post about building rather than mining, I took it literally. Over the last two days I built and deployed a small ZCD/credits exchange on the Zycord cEVM, in testnet, with a registered sequencer behind it:

- Two contracts: a delta-first token ("Credito") and a "Mercato" with internal balances (delta cells: two certificates on the same balance in one block both apply, which the tests check), a constant-product pool (0.3 % fee) and a limit order book (price-time priority, 0.1 % taker fee, 6 fills and 12 list steps per certificate to stay under the 64 reads/writes).
- A sequencer registered on the Mercato (the admin form of register-sequencer) and announced in the on-chain directory: https://zycord.dcafrevolution.com (ZSI manifest on /, status on /v1/status).
- Swaps, orders, partial fills and cancels done through `zcd wallet intent`, found via the directory, applied in testnet blocks (10519 to 11676 if you want to look).
- A page that reads the sequencer and composes the wallet commands: https://zycord.dcafrevolution.com/app/ . Paste a persistent address and it shows your internal balances, shares and open orders. It signs nothing.

Testnet addresses:
Mercato 0x05cc436e1e14523fd5797e5dd3634b035a86318a51579a3bc0fc9f48bce96fbb,
Credito 0x057efb1c504e21a9d8d4e31c28b241573496221168d1b46c30e6b36c80c8250f.

Everything runs on v0.6.1; I checked the v0.6.2 diff and it does not touch the sequencer, the ZSI or intents, so nothing above changes. (And thanks for the mention on !72.)

Things I learned that may be useful to others building on the cEVM: one discipline per cell per execution; an exact read on a contract with a registered sequencer makes a plain certificate invalid, so deposits of the token go through the sequencer while ZCD deposits stay free; an intent bound must name a cell the call really writes (a bound on the order-book head only works when your order becomes the head); intents pay from one-shot addresses, and in my runs the wallet twice ended up with none it considered free (one was still held by an earlier attempt) until an ordinary payment left change in fresh ones.
Maybe that is expected; if not, I can describe it in an issue.

The question: the wallet's site connections sign `transfer`, `call` and `deploy`, not intents. So a page can show everything but cannot ask the wallet to sign a swap; the user has to copy a command into a terminal.
Would you accept a merge request adding an `intent` request kind to POST /v1/sign (quote shown on the approval screen instead of a certificate, sequencer URL subject to the same netguard rules as src= fetches, payer holds as in `zcd wallet intent`)? I estimate 700-800 lines in wallet/ plus tests. I would rather ask before writing it. If yes, I will open an issue on GitLab with the details.

As before: I write the code together with Claude (Anthropic), I review and run everything myself, and the sequencer is on a server I operate

Repository : https://gitlab.com/dario/zycord-mercato

shadow_69 (Dario)

[thesimstoshi]

A small exchange on the cEVM, running in testnet (with a question for the devs)

After the dev's post about building rather than mining, I took it literally. Over the last two days I built and deployed a small ZCD/credits exchange on the Zycord cEVM, in testnet, with a registered sequencer behind it:

- Two contracts: a delta-first token ("Credito") and a "Mercato" with internal balances (delta cells: two certificates on the same balance in one block both apply, which the tests check), a constant-product pool (0.3 % fee) and a limit order book (price-time priority, 0.1 % taker fee, 6 fills and 12 list steps per certificate to stay under the 64 reads/writes).
- A sequencer registered on the Mercato (the admin form of register-sequencer) and announced in the on-chain directory: https://zycord.dcafrevolution.com (ZSI manifest on /, status on /v1/status).
- Swaps, orders, partial fills and cancels done through `zcd wallet intent`, found via the directory, applied in testnet blocks (10519 to 11676 if you want to look).
- A page that reads the sequencer and composes the wallet commands: https://zycord.dcafrevolution.com/app/ . Paste a persistent address and it shows your internal balances, shares and open orders. It signs nothing.

Testnet addresses:
Mercato 0x05cc436e1e14523fd5797e5dd3634b035a86318a51579a3bc0fc9f48bce96fbb,
Credito 0x057efb1c504e21a9d8d4e31c28b241573496221168d1b46c30e6b36c80c8250f.

Everything runs on v0.6.1; I checked the v0.6.2 diff and it does not touch the sequencer, the ZSI or intents, so nothing above changes. (And thanks for the mention on !72.)

Things I learned that may be useful to others building on the cEVM: one discipline per cell per execution; an exact read on a contract with a registered sequencer makes a plain certificate invalid, so deposits of the token go through the sequencer while ZCD deposits stay free; an intent bound must name a cell the call really writes (a bound on the order-book head only works when your order becomes the head); intents pay from one-shot addresses, and in my runs the wallet twice ended up with none it considered free (one was still held by an earlier attempt) until an ordinary payment left change in fresh ones.
Maybe that is expected; if not, I can describe it in an issue.

The question: the wallet's site connections sign `transfer`, `call` and `deploy`, not intents. So a page can show everything but cannot ask the wallet to sign a swap; the user has to copy a command into a terminal.
Would you accept a merge request adding an `intent` request kind to POST /v1/sign (quote shown on the approval screen instead of a certificate, sequencer URL subject to the same netguard rules as src= fetches, payer holds as in `zcd wallet intent`)? I estimate 700-800 lines in wallet/ plus tests. I would rather ask before writing it. If yes, I will open an issue on GitLab with the details.

As before: I write the code together with Claude (Anthropic), I review and run everything myself, and the sequencer is on a server I operate

Repository : https://gitlab.com/dario/zycord-mercato

shadow_69 (Dario)

Thanks Dario, this is a great use of the testnet: a working exchange on the cEVM, through the intent path end to end.

On your question: yes, in principle we'd welcome an `intent` kind for POST /v1/sign. Since it lets a web page ask the wallet to commit funds to a third-party sequencer, please open an issue first with the design: what the approval screen shows (quote, payer, maximum spend, sequencer), how the sequencer URL goes through netguard, and what a hostile page could and couldn't learn or do with it. Once we agree there, the MR is welcome.

The one-shot addresses that stayed held after an earlier attempt don't look expected. Please file that as its own issue with the steps, we'll look at it.

[shadow_69]

Thanks! Both are open:

- Design for an `intent` kind in POST /v1/sign: https://gitlab.com/zycord-group/zycord-node/-/work_items/43
  It covers the approval screen (quote, payers, maximum spend, sequencer), the sequencer URL taken only from the on-chain directory and passed through netguard (no loopback or private addresses for page requests), and what a hostile page can and cannot learn or do. There are three open questions at the end where your view would help.

- One-shot addresses held with no intent in flight: https://gitlab.com/zycord-group/zycord-node/-/work_items/44
  Two cases with block heights and addresses. I haven't reproduced it on demand yet; I can run a build with a debug print in pickIntentPayers next time if that helps.

I'll wait for your comments on #43 before writing the MR.

Meanwhile the Mercato on testnet moved to a new contract after an independent review pass (done with ChatGPT, applied and tested here): an arithmetic bound so a first deposit can no longer lock the pool, plus tests for nested withdrawals. New address: Mercato 0x058226d9a839c29714c94600e7581f72a7ee99c47d4475984a077543215ae38c (the one in my previous post is now empty). Same page: https://zycord.dcafrevolution.com/app/ , code: https://gitlab.com/dario/zycord-mercato

shadow_69

[samurai619]

🚀 Zycord (ZCD) is now listed on MiningChamp.com!
Track Network Stats, Active Mining Pools & Market Exchanges

Hello Zycord Community & Miners,

We are pleased to announce that Zycord (ZCD) is now fully tracked on MiningChamp.com!

You can now monitor live network statistics, active mining pools, and check all supported cryptocurrency exchanges with real-time trading pairs and volume.

📌 Quick Links:

• Zycord Profile & Stats: https://miningchamp.com/coin/zycord
  
• All Pools: https://miningchamp.com/pools
  
• All Coins: https://miningchamp.com
  

⚡ Key Features & Data Tracked for Zycord:

• Market Exchanges & Pairs: View listed exchanges, trading pairs, real-time prices, 24h volume, and market liquidity aggregated across exchanges.
  
• Network Difficulty & Hashrate: Live network difficulty adjustments, total network hashrate, and chain growth metrics.
  
• Block Information: Current block height, average block time, and block rewards.
  
• Active Mining Pools: Overview of pools supporting ZCD with their current hashrate and operational status.
  

Are you a pool operator or exchange running ZCD? Feel free to reach out to ensure your stats are actively synced on MiningChamp.

Best regards,
The MiningChamp Team

[darkko]

$ZCD mining pools:

ZCD Pool: https://pool.zcd.lol/
CopperHash: https://zycord.copperhash.com/
AriaPool: https://pool.ariabrain.com/zcd.html
GoZero: https://pool.gozero.trade/?coin=zcd&lang=en
MiningChamp: https://miningchamp.com/coin/zycord

all of them are third parties, do your own due dilligence.

Follow x.com/zycord_stream to stay updated.

[thesimstoshi]

Why Era 2 is plain proof of stake

I spent the last few days specifying the network for Era 2. There was a lot to define, and I spent a long time studying and validating architecture and design, focused on sampled verification, the peak of what this network can do.

After all that work, my conclusion: the design is good and can work very well, but it is a lot of work to implement now, with no tangible gain. Parallel verification already puts Zycord far ahead of any existing network, and its limits are still very far from what the network will actually use.

So I've set that spec aside. Era 2 will focus on a simpler transition from PoW to PoS, with a smaller consensus surface. That means more security.

In a later era, we can move to sampled verification, if and when there is demand for it.

https://lab.zycord.com/news/why-zycord-doesnt-need-its-most-ambitious-design-yet/Whitepaper v2.0 and the eras document are out

I've updated the whitepaper and the website documentation. The most important thing first: nothing changes on the running network. Same consensus, same node, nobody needs to upgrade. v1.0 described the design; v2.0 describes the protocol as it was implemented and runs today.

There are now two documents. The whitepaper covers the mechanisms. Launch, Eras and Parameters covers dates, issuance, the treasury and every value.

What changed in the whitepaper

• The thesis is the same: certificates verified in parallel from their own bytes, a fold that never executes, typed state access, two gas markets.
• Certificate insurance and underwriters are gone. Every certificate names a deposit that answers for it.
• Sequencers: the user signs an intent; the sequencer executes it, confirms in milliseconds and publishes the result on chain. It is trusted to stay online, never with the safety of funds.
• A simpler forced path, with no queue and no leases. If a sequencer disappears or censors, the block producer executes the intent at the end of the block.
• The cEVM is now fully specified.
• Fraud proofs and sampling are gone. A proof-of-stake era takes their place (below).
• Two new sections: the road past full verification, as a direction rather than a specification, and accepted risks, stated plainly.

Era 2: proof of stake

• No verification rule changes. Only who produces the block changes: a draw by stake instead of hashing. The computation that mines hashes today goes to verifying certificates.
• Blocks every 5 seconds. Daily issuance stays the same, because each block pays one sixth.
• A gradual transition. Bonding opens in month 6. Then come 90 epochs in which every block is still mined and co-signed by a staker, with the switch around months 10 to 12. No block is produced by stake alone before stake has proven it is live.
• Delegation without giving up custody: holders with only coins delegate to a pool; those with coins and hardware produce.
• One single punishment: signing two blocks for the same slot.
• It ships as its own release, by hard fork, with a specification, a devnet and review.

Eras document

• Launch and issuance are unchanged: same curve, same tail, same 94/3/3 split.
• The cEVM activates in Era 1, at height 80,640 (around November 4).
• The treasury stays sealed. No key can move it and there is no spending path. One can only be added by an upgrade, not before January 5, 2027, with signers chosen by the community.

Treasury: a proposal for your vote
Section 5 of the eras document is a proposal, not a rule. In short:

• Five seats, each with a public charter: lead developer, reviewing developer, miner, community and public representative.
• A spend needs 3 of 5. Replacing a holder or using the reserve needs 4 of 5 and 7 days' public notice.
• The budget is split as shares of inflow: 40% seats, 20% infrastructure, 25% hackathons and bounties, 15% reserve.
• Seat pay accrues locked and is released every six months against a published report.

Still open: the cap per seat, the legal form for the public representative, and whether the six-month lock lives in an escrow contract.

Please read it and reply here, point by point: approve, adjust or reject. I'll consolidate the answers before any treasury upgrade.

Whitepaper v2.0 · Launch, Eras and Parameters · Blog

Zycord devlog — Oct 10 → Oct 15

v0.6.3 is out – download it and update: https://zycord.com/download/
Recommended for pools and anyone using zcd wallet intent. No consensus change: nodes that don't update stay on the same network.

✅ Release version v0.6.3
✅ Pool payouts: a payout to many miners could be refused ("no cell among these keys can carry the deposit") while the wallet held plenty. The wallet now tries the next coin until one carries it (!77). Thanks to the community for the report
✅ New --mine-light flag: mine on low-memory machines. It hashes from the 256 MiB cache instead of the ~2 GiB dataset. On a 2 GB VPS: from ~0.8 H/s (dataset in swap) to ~26 H/s per thread. Same blocks, same hashes (!80)
✅ Miner: notices a new block within 250 ms instead of after 512 attempts (up to ~20 s in light mode). It stops at once when a thread fails, and the node shuts down faster (!81)
✅ zcd wallet intent: a third intent in a row no longer fails with "no one-shot address … covers the payment" (#44, !82). Thanks dario
✅ Intents a sequencer accepts but never fills no longer lock the wallet: their change address is reused once the intent's window has passed
✅ Black box: four new scenarios guard these fixes: https://gitlab.com/zycord-group/zycord-blackbox

Audit the code and the rules: https://gitlab.com/zycord-group/zycord-node
Issues and MRs on GitLab.

[thesimstoshi]

Zycord capacity: before and after sampled verification

Simple payments (~850 bytes). Verification measured with the node's own benchmarks. All figures in TPS.


1. Today: every node verifies everything
8-core desktop, 2 TB disk

Resource	Comfortable	Saturates
Bandwidth, global median (~110↓ / 55↑ Mbit/s)	~2,700	~8,000
Bandwidth, 300 Mbit/s plan	~7,300	~22,000
Storage (pruned node)	~5,400	~21,000
Validation	~17,000	~70,000

2. Sampled verification: home node
Simulated network of 1,000 nodes; each carries ~2% of the load

Resource	Comfortable
Bandwidth, global median	~135,000
Storage	~270,000
Validation	~850,000

3. Sampled verification: block producers
The stakers who produce blocks; 1 Gbit/s symmetric, 8 TB NVMe

Producers receive only the part of each certificate the fold uses (~620 bytes) and run the deterministic fold.

Resource	Comfortable	Saturates
Bandwidth	~67,000	~200,000
Storage (recent state)	~52,000	~200,000
Sequential fold	~40,000	~150,000

What "comfortable" means
The node uses only part of each resource. The rest is headroom for peaks, for catching up after downtime, and for anything else the machine runs.

• Bandwidth: up to 1/3 of the link
• Storage: up to 1/4 of the disk
• Validation and fold: up to 1/4 of the CPU

"Saturates" means the resource is fully used.

In short

• Up to ~10,000 TPS, every node verifying everything works.
• With sampled verification, home nodes stop being the limit and the bottleneck moves to block producers: ~40,000 TPS comfortable, ~150,000 at the limit.

Hardware limits, not protocol limits
From ~40,000 TPS onward, today's hardware is what holds the network back, not the protocol. The structural limit of the encoding is over 1 million TPS. Hardware gets faster every year, so by the time demand reaches these levels, these limits will be much higher. More capable producer nodes and architecture improvements, such as a parallel fold and more compact certificates, raise them further.

A conservative baseline
These figures use deliberately modest reference hardware. The network's hashrate is already ~10 MH/s of RandomX, which shows a lot of capable hardware connected today, and that hardware sits well above this baseline.


For reference: real use on other networks today

Network	Real use (TPS)
Solana	~1,360
Tron	~176
BNB Chain	~171
Base (L2)	~85
Ethereum L1	~36
Bitcoin	~4–7
Visa (average)	~8,200

Sources: Chainspect (July 2026), Visa FY2025 annual report.

[gabrielesor]

Zycord - Reviewing Developer: a focused charter proposal

For point-by-point community discussion
Proposed by: gabrielesor
Date: 16 October 2026
Status: Discussion proposal; not an adopted charter or policy

Following the maintainer's 15 October invitation, I propose five clarifications for the Reviewing Developer (RD) charter, regardless of who eventually holds the role.

Section 5 of Launch, Eras and Parameters already proposes the seat and public role charters. The suggestions below are ordered by importance and distinguish the official inputs from the changes I recommend. They do not seek to change the existing maintainer-acknowledgement requirements in CONTRIBUTING.md or recreate Zycord's technical procedures.

1. Give a negative review an explicit consequence

Primary inputs: Companion section 5 proposes independent review of every consensus change. CONTRIBUTING.md requires multiple maintainer acknowledgements. The reviewed sources do not specify the consequence of a negative RD assessment or how persistent disagreements are resolved.

Proposal: A reasoned objection should be addressed through corrections, explanations or additional evidence, rather than silently disregarded. If disagreement persists, the current Zycord maintainer decides how to proceed, records the reasons and preserves the RD's dissent. How the maintainer obtains advice remains their choice.

A decision to proceed despite an objection must not be presented as a positive RD assessment, nor does it waive mandatory technical requirements.

If the RD does not respond, the independent-review requirement remains unmet. The current maintainer decides how to address the situation; silence is not approval. This does not authorize dispensing with the required independent assessment.

2. Leave a reasoned, traceable assessment

Primary inputs: Companion section 5 envisages charters defining duties and deliverables; CONTRIBUTING.md already establishes technical review requirements.

Proposal: The RD should record a reasoned assessment in the existing merge request, tied to the code revision examined, with relevant evidence, findings, limitations and unresolved objections.

Both the depth of review and the explanation should reflect the change's complexity and risk, without reducing mandatory requirements. No separate report, mandatory template or new reporting system is needed.

Findings requiring confidential disclosure must follow SECURITY.md, rather than being published in the merge request.

3. Bound responsibility to a defined review scope

Primary inputs: CONTRIBUTING.md identifies core/ and spec/ as the consensus zone, while companion section 5 describes the RD's mandate as reviewing every consensus change. Detecting possible consensus effects throughout the repository would be a separate monitoring responsibility.

Proposal: The RD should review changes to core/ and spec/, plus changes elsewhere when explicitly requested by the change author or current maintainer.

The RD is not responsible for continuously monitoring the rest of the repository or discovering external changes that have not been referred for review. Failure to refer such a change must not retrospectively become the RD's fault.

This allocates responsibility; it does not assert that consensus effects are confined to those directories. Coverage outside them depends on referral by the author or maintainer.

4. Make independence practical without barring development

Primary input: Companion section 5 expressly requires independent review, without defining a detailed conflict-of-interest process for the RD.

Proposal: The RD may contribute code but must not present a review of their own work as independent. Material conflicts affecting a review should be disclosed. Where independence cannot be maintained, the current maintainer determines how to obtain an independent assessment.

No general disclosure of private relationships or standing substitute-review structure is proposed.

5. Define the time-commitment criterion before candidacies open

Primary input: Companion section 5 proposes renewable one-year terms and public candidacies, without specifying how the RD's time commitment is determined. The duration of an appointment does not establish its working hours.

Proposal: Before candidacies open, the charter should state who determines the RD's time commitment and availability, and on what basis.

I recommend that the RD determine their own working hours and schedule, while remaining accountable for carrying out reviews within the scope in point 3 and promptly informing the current maintainer when unable to undertake or complete an assigned review.

This is autonomy in organizing the work, not discretion to disregard the mandate. No fixed weekly hours, universal completion deadline or standing on-call obligation is proposed.

Source basis: Official material reviewed through 16 October 2026, 09:20 UTC, with repository references fixed to v0.6.3, commit a580df8ccc081a678fd6bee2cf55cbdba48830c6. Later statements are outside this snapshot.

[kenyfran]

Part of the network's hashrate probably comes from people renting it on hashrate marketplaces. As a reference, 1 MH/s of RandomX goes for around US$35-40 a day there.

In my last post I said I hadn't been able to mine. Today I did, on a home desktop, and I'm happy with the reward. I think the ramp did its job: hashrate started near 10 MH/s and now moves between 4 and 6 MH/s, which gives more people a chance. The largest address holds about 12% of the coins, so the launch is well distributed.

On renting hashrate: I tried renting to mine more. I believe the reference price above comes from NiceHash, but NiceHash only offers RandomX v1, not v2, so it doesn't work here. I looked for other ways to rent, but elsewhere it is hard and expensive, and v2 is heavier. I think most of the hashrate comes from miners with their own hardware, not rentals, so a cost per coin based on rental prices is out of date; the real cost is much higher. By my calculations, renting hash to mine ZCD costs roughly US$1.40 per coin.

On the treasury (§5):

• 6-month terms, not 1 year. The start of the network is its most delicate moment. If a choice turns out badly, the community can replace it quickly.
  
• First election: one vote per wallet that mined up to the date of this post. The 10 largest addresses hold ~46% of the coins issued so far. Coin-weighted voting would put the seats in the hands of about ten addresses. And having the most hashpower doesn't mean knowing what is best for the network: mining and the project don't always want the same thing. Bitcoin's block size war (2015–2017) is the best-known example, when large miners and users pulled in different directions.
  
• I like how §5 separates the treasury roles. What the project lacks most today is a public figure promoting it, ideally someone already known in the market. It's worth defining that seat's charter carefully.