[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/

[thesimstoshi]

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

[thesimstoshi]

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.