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

[shadow_69]

Follow-up from our testnet run (one node + one rx/2 miner, ~1.7 kH/s, solo over Stratum): 15 h 23 min from genesis, 124 blocks delivered, 120 in the canonical chain (4 orphans), 9 rejected shares.
The three RandomX key changes (heights 576, 1088, 1600) were crossed without trouble.
We also checked the published figures against our own node's copy of the chain: 73 blocks in the first 5 minutes, 371 in the first 2 hours and ~32 s average after the first hour all match, and every header target up to height 1617 equals what NextTarget computes.
Nothing odd to report.
One small note: with the ramp ending at 20.41 ZCD we get 10.67 ZCD for the first 300 blocks and 16.30 ZCD for the first 2 hours (11.0 and 16.8 would be a ramp toward 21); the -99.8% conclusion is unchanged.

See you at genesis.

[thesimstoshi]

Excited about today's launch. Best of luck to everyone with the launch.

If anyone wants to know more about the story behind the project, I gave an interview to Hashpower, here is the link https://hashpower.site/2026/09/23/zcd-developer-interview/

[darkko]

Less than 5 hours until the launch.
If you have any questions, the community is available to help:

https://t.me/+ufeCItfHJWU3ZjBl
https://discord.gg/8DXTADJ6Es


countdown: https://lab.zycord.com/tools/network/
twitch community live: https://www.twitch.tv/eliotbez

[thesimstoshi]

Zycord mainnet: the first two hours

Genesis: 2026-10-07 00:00 UTC. The figures come from the chain and the three seeds, compared with the cancelled October 1 launch.

Summary

• Block 1 arrived at 00:00:01, carrying the launch message.
  
• 350 blocks in 2 hours (target 240) from 49 addresses. No address mined more than 15% of the blocks.
  
• 1 orphan block and 2 reorgs of depth 1 (heights 4 and 58), both in the first 10 minutes.
  
• All 3 seeds stayed up. They filled up at around 50 minutes, and inbound capacity was doubled to 512.
  
• Miners earned 13.64 ZCD in the first two hours, against 9,166 ZCD on October 1.
  

Timeline

Time	Height	What happened
00:00:01	1	Launch block
5 min	39	Difficulty already 21x genesis
10 min	72	Estimated hashrate ~0.23 MH/s
30 min	150	Difficulty 76x, ~0.66 MH/s, 41 addresses mining
40 min	185	First block from the first community pool
~50 min	~210	Seeds close to their 256 inbound limit
~1 h	~230	Limit raised to 512, one seed at a time
1 h 24 min	~285	Peak hashrate: 1.26 MH/s
2 h	350	Difficulty 135x, ~1.18 MH/s, reward 0.078 ZCD per block

Blocks and difficulty

Blocks	Average interval
1-100	8.4 s
101-200	18.8 s
201-300	30.3 s (target: 30 s)

The starting difficulty was below the hashrate that showed up, so the first blocks came fast. By around block 200, about an hour after genesis, the difficulty had caught up and blocks were arriving on target. On the testnet the same catch-up took 10 minutes, but there the starting difficulty was deliberately low. The longest gap between blocks was 225 s, at height 296.

Thanks to the 30-day ramp, the fast blocks paid almost nothing. At the end of the second hour the reward was 0.38% of the full reward (20.41 ZCD).

Network and seeds

• Connections across the three seeds: 318 at genesis, peaking at 786 at 73 minutes. This counts connections, not nodes, since one node connects to more than one seed.
  
• About 9 in 10 inbound connections came from nodes that do not accept connections. That is the zycordd default without --listen. Those nodes depend entirely on the seeds.
  
• Seed 1 filled its 256 slots at around 50 minutes and turned connections away until the limit went up. Part of those refusals were the same nodes retrying, including three banned nodes that retried every few seconds.
• Each seed restarted once to apply the new limit. Its connections dropped and came back within minutes: the total went from 782 to 499 and recovered to about 590.

A request to miners: if you can, run your node with --listen 0.0.0.0:9421 and open TCP port 9421. Every node that accepts connections takes load off the seeds and makes the network more resilient.

Compared with October 1 (first two hours)

	Oct 1 (cancelled)	Oct 7
Block 1	+6 min 19 s	+1 s
Blocks in 2 h (target 240)	450	350
Addresses mining at 15 min	12	35
Addresses mining in 2 h	23	49
Blocks from the largest address	35%	15%
Blocks from the top 3	77%	44%
Paid to miners	9,166.50 ZCD	13.64 ZCD
Received by the top 3	7,027.65 ZCD	6.26 ZCD
Orphans	8 (one 4-block reorg)	1

Total issuance in the two hours was ~14.5 ZCD: 94% to miners (13.64), 3% to the community fund (0.44) and 3% to the founder (0.44).

After the first two hours
The hashrate kept rising: ~1.5 MH/s over blocks 301-400, ~3.3 MH/s over blocks 401-533, and ~6.2 MH/s by height 688.

Concentration came back. Over blocks 434 to 533, a single address (027B004B...5542FD, first seen at height 422) mined 50 blocks, and the first community pool mined 33. That is 83% of the blocks from two participants. The ramp caps what that earns for now, at ~0.07 ZCD per block, but it is the main thing to watch. More pools and more small miners are what dilute it.

How this was measured

• Blocks come from the explorer index. Connections and per-minute hashrate come from Network Status.
  
• Hashrate is estimated from difficulty and is noisy over short windows.
• Orphans and reorgs are the ones the seeds observed.
• An address is not a person: a pool puts many miners behind one address, and one person can use several.

[aria.devcode]

⚡ The Zycord (ZCD) pool is online on AriaPool

The Zycord mainnet started on October 7 at 00:00 UTC and our pool has been mining since the very first block. Our first blocks are already unlocked on the chain.

Pool: zcd.ariabrain.com:3343
Statistics, guide and miner: https://pool.ariabrain.com/zcd.html

PPLNS, 3% fees, earnings credited upon block unlock (240 confirmations), minimum payment 1 ZCD. Your ID is your ZCD address, no registration required.

⛏️ Aria Energy ZCD 1.1.0, our CPU miner for Zycord. It integrates the Energy auto-tune engine; it configures itself to your processor at every startup and handles huge pages for you.
https://dl.ariabrain.com/zcd-dl/aria-energy-zcd-v1.1.0-linux-x86_64.tar.gz

⛏️ Happy mining everyone!

Support pool community : https://discord.gg/pw9eBB5J5C

[ocean1223]

What a joke—emissions won't return to normal for a month? They can keep it for themselves. ---Don't delete my post; witness this drop to zero.

[gabrielesor]

Mainnet mining capability snapshot — what does mining Zycord look like on a single reference machine?

I wanted to put some numbers behind a simple question:

What does mining Zycord currently look like for a single, ordinary consumer-class reference machine?

I ran a live measurement against the current mainnet using the node's native mining counter and the public Zycord network data.

The result is published as a reproducible snapshot rather than just a hashrate number.

At the time of observation, the reference machine represented about 0.0723% of the network hashrate, roughly 1 part in 1,383.

One result I found particularly useful for understanding the scale: under the observed network conditions, the statistical probability of finding at least one block exceeded 50% after about 8 hours.

That is not a prediction or a guarantee. It is a probability derived from the measured local/network hashrate ratio and the protocol block interval, assuming that relative hashrate remains approximately constant.

The full report contains the measurement method, formulas, public data sources, exact observation boundary, limitations, provenance information and the SHA-256 of the accompanying raw snapshot.

Open the full Zycord Mining Capability Report + raw snapshot

The raw snapshot is published alongside the report so that the reported calculation can be independently inspected and reproduced.

Snapshot SHA-256:

Code:

77f6788af073f586371c66105676f642f6482b4d76a811c5914547a5e5209707

Comparable measurements from other machines or configurations would also be useful for comparison.

[darkko]

What a joke—emissions won't return to normal for a month? They can keep it for themselves. ---Don't delete my post; witness this drop to zero.

Funny.

Your post wont be deleted. It'll get old very well.

The rules of the relaunch was a community consensus.

Thank you for looking into the Zycord project, doors will always be open.

Darkko
Zycord Community

[thesimstoshi]

The report is excellent gabrielesor.

The hashrate is indeed high for a home computer, but I believe we’ve achieved the goal of broad distribution, given that 24 hours to mine a block is feasible for an ordinary desktop. This will allow small-scale miners to participate in the network during the initial weeks.

As the difficulty ramps up, machines with greater computing power will enter the mix; this is expected, and things will become more challenging.

I’d also like to mention that the cEVM has been released on the testnet, so we can already test smart contracts. The mainnet will launch the cEVM in about 28 days.

I’m bringing this up because it’s a great time to start testing dApps.

[shadow_69]

Comparable measurement, as requested in #73: two small machines, one node on a Raspberry Pi.

Setup: Surface laptop (i7-11370H, 7 threads, huge pages) at 2,480 H/s and a Lenovo AMD 3020e (2 threads) at 745 H/s, both pointed at our own node on a Raspberry Pi 4 (wired, outbound only, 4-5 peers). Total 3.2 kH/s, our own RandomX v2 miner, no dev fee.

Solo, first 8 hours after genesis: 3 blocks at heights 42 (00:05 UTC), 263 and 530 (03:06 UTC), all canonical, 0 rejected shares at the node. That is well above expectation and came while the network was still below 1-3 MH/s; after 05:00 nothing more, as the network went to 6-8 MH/s. At the current 4.8 MH/s our share is 0.066% (1 in ~1,500), so the expected time per block in solo is now ~12 h, in line with #73.

At 10:30 UTC+2 we moved both miners to a pool: same expected return minus the fee, but a credit every few minutes instead of a lottery every 12-24 h. For a machine this size that is the realistic way to stay in the network for the whole ramp.

Two observations for the project:
- Our Pi node's peer count dropped from 5 to 1 for a few seconds at 00:18 UTC and recovered on its own; that matches the seed restarts for the 512-slot limit in your report. No reorg seen by our node beyond depth 1.
- The RandomX key the pool sends for the current epoch is identical to the one our node serves, so switching between solo and pool needs no dataset rebuild. Worth stating in the mining docs, since miners with --prewarm-style options will see it as a "new seed" only because of the reconnect.

Thanks to the team for the detailed 2-hour report, and to gabrielesor for the snapshot: having two independent measurements of the same thing is exactly what makes these numbers credible.

Good luck to everyone mining,
shadow_69

[andremangra]

Mainnet looking solid from my side. 
Running RandomX rx/2 on the community pool with a persistent payout address. Mining continued normally across the first mainnet rekey at height 2112, and the worker migration also preserved pool-side pending accounting as expected. 
Accepted shares are flowing with no rejects so far. 
Still watching the first actual pool payout/on-chain settlement before calling the whole payment path fully validated. 
Nice to finally see the network live after following the project through the pre-genesis changes. Keep building. ⛏️

[gabrielesor]

Possible use of the Community Fund for small early miners

An earlier post today raised a point that I think is worth discussing: whether there is room to recognize the contribution of small miners who participated in the earliest phase of the network while receiving only a very small amount of ZCD.

First, I want to make one thing very clear: this is not a criticism of the launch, of the reward schedule, or of other miners.

The information needed to understand how the reward ramp would work was available before genesis. Everyone mined under the same published rules, and in my opinion large, medium and small miners all played fairly.

The ramp also clearly achieved an important objective: the first blocks did not result in a very large concentration of ZCD in a few addresses.

That said, I think there is another question worth discussing:

Could the Community Fund eventually be used to give some additional recognition to the small miners who participated during the earliest and riskiest phase of the network, but obtained only a very small amount of ZCD?

I am not proposing to change past rewards.

I am thinking instead about a separate, transparent and limited early-miner bootstrap program, funded from a small predefined portion of the Community Fund.

A technically simple version could work like this.

Choose an objective early-chain window, for example the first N blocks or the first few days after genesis.

For every payout address that produced at least one canonical block during that period, calculate on-chain:

• number of blocks produced;
• total producer reward received during that window;
• first and last block height produced.

Then define an objective threshold below which an address is considered a small early producer.

For example, eligibility could require both:

early blocks produced <= B

and

total early producer rewards <= T

where B and T would not be chosen arbitrarily, but after looking at the actual distribution of early mining rewards.

Addresses above those limits would receive nothing from this program.

For eligible addresses, instead of giving everybody the same amount, I would prefer a top-up mechanism:

top_up = max(0, target - early_rewards_already_received)

with a maximum cap per address and a fixed maximum budget for the whole program.

This would make the Community Fund act as a small multiplier of scarce early rewards, rather than as a second mining reward.

An address that already received a significant amount would receive little or nothing.

An address that participated early and received only a very small amount could receive a larger top-up.

The total expenditure would be known in advance and could be kept deliberately small.

There is one important technical limitation.

The blockchain can prove that a payout address found a block, but it cannot prove that an address spent hours mining and found zero blocks, because unsuccessful hashes are not recorded on-chain.

For this reason I would not include zero-block miners in an on-chain-only proposal unless a separate, verifiable proof mechanism can be designed.

There are also questions that would need to be studied before such a proposal could become concrete: address splitting/Sybil resistance, the exact early-mining window, the eligibility thresholds, the budget and the distribution formula.

So this is deliberately not a finished proposal.

It is simply an idea for discussion: use a limited part of the Community Fund to recognize small, verifiably early mining participation without creating an additional reward for miners who already obtained substantial early rewards.

For transparency, I should also disclose that I am one of the small early miners who received only a small amount of ZCD, so I would potentially benefit from a mechanism of this kind.

That is precisely why I think the rules, if something like this were ever considered, should be objective, public, reproducible from the blockchain and decided by the community rather than around individual cases.

Any feedback, objections or better mechanisms are very welcome.

[darkko]

@gabrielesor

I believe this proposal is a mistake.

The reward ramp was not designed solely to prevent ZCD from concentrating in a small number of addresses. It was also meant to give smaller miners better chances during the early period of the network.

Given that premise, it was already anticipated that the first 30 days after launch would not require high hashrate, and that this would not be a critical factor for the network's development. On the contrary, earlier posts explicitly advised high-hashrate miners to wait until the optimal moment, when mining would become financially worthwhile, before joining.

Changing this rule now to benefit those who joined early makes no sense. Miners who read the project documentation, understood the rules, and rationally chose to delay powering on their machines would end up losing out on rewards. Meanwhile, the beneficiaries would be miners who found the project through "today's launches" lists, never read the whitepaper, and only the following day realized there was a reward ramp, and are now voicing their frustration on the forum.

I’m not saying you haven’t read the project details—I know you’ve actually contributed to its development.

However, this stems from a reaction by miners who are badmouthing the project; they didn't read the launch rules before firing up their machines.

In fact, the reason you mined practically nothing is precisely because the "clueless" person didn't read the rules and absurdly raised the hashrate at the wrong time.

I’ve been mining since the start and haven’t found a single block—but that’s just how it goes.

Given this, my proposal is: is the reward not feasible for you right now? Turn it off.

That is my view, and I am open to discussion.

Kind regards,

Darkko
Zycord Community

[gabrielesor]

Thanks, Darkko.

I think there are two separate questions here.

1) Whether some miners misunderstood the reward ramp and are now frustrated is one question.

2) Whether a limited use of the Community Fund to support small early participants could make sense for Zycord is another.

I don't think the first answers the second.

My proposal is not meant to correct the mining rules, compensate anyone for having misunderstood them, or establish that early miners were owed more ZCD.

There is also one reason why I would be careful about equating early participation with misunderstanding the rules.

The official messaging itself combined both ideas: that "being first counts for little", but also that "You enter at block 0" and "You are mining the right network early".

I read those statements together as: early participation is welcome, but it does not entitle anyone to a large early mining reward.

That does not make my Community Fund proposal correct.

It should stand or fall on its own merits: benefit to the network, fairness to miners who chose to wait, objective eligibility criteria, Sybil resistance, and an appropriate budget.

If it cannot satisfy those requirements, then it should simply be rejected.

But neither the fact that the proposal might appeal to people who misunderstood the reward schedule, nor the fact that it concerns early participants, is by itself an argument against it.

I am happy to leave my own motivation out of the discussion and evaluate the idea only on those grounds.

[shadow_69]

On the Community Fund top-up idea (#74), one technical point, with a disclosure first.

I came to Zycord out of curiosity and as an experiment. I wanted to watch a proof-of-work network start from block 1, and above all to understand how much AI can help with writing blockchain code. The RandomX v2 miner I mine with was written from scratch, starting from the RandomX specification, working with Claude (Anthropic); measured against XMRig 6.26.0 on the same laptop (i7-11370H, alternated runs, same threads), it is at parity: 3,064 vs 3,065 H/s on v1, and equal within the thermal noise on rx/2. The same goes for the two small merge requests I sent to the repository (a supply test, merged in dev, and a fix to the sawtooth test, still open), both declared as AI-assisted. That is the experiment; mining is the test bench, not the income.

That said, I am also a small early miner (3 canonical blocks in the first three hours, 0.185 ZCD, one payout address), so I would be exactly in the eligible band. I still think the idea has a flaw that the chain cannot fix.

The eligibility test is per payout address, but on Zycord an address does not identify a miner, by design. The official wallet derives a whole ring of persistent addresses from one key and, when mining with the bundled node, rotates the payout address on its own after a random number of rewards between 1 and 6 (wallet/webui/payout.go); the code explains this as a privacy measure, because a fixed number of blocks per address would itself identify the miner. So anyone who mined the first hours with the bundled miner already appears on-chain as several "small early producers", each below the thresholds, and with top_up = max(0, target - received) and a per-address cap would collect the cap several times; someone who used an external miner with a single fixed address, as I did, collects it once. No data in the blocks can tell ten small miners from one miner rotated ten times, and the protocol is built so that this is the case. Unsuccessful hashing is invisible as well, as gabrielesor himself notes, so the honest zero-block miners Darkko mentions would get nothing either way.

Sybil resistance would need an identity layer the protocol deliberately does not have, and a retroactive payout from the fund sets a precedent for every future group that feels short-changed. The ramp was published before genesis and applied to everyone equally; I read it, mined under it, and got what it said.

Thanks to gabrielesor for a carefully argued and transparent proposal; I just don't see a way to make it fair.

[kenyfran]

I found gabrielesor's proposal interesting, but I'm not sure if it's technically feasible.

I’m one of those people who mined on the testnet and mined (or tried to) starting with the very first block. So far, I haven't managed to mine a single block. In that scenario, I’d be one of the ones left out, even though I’ve been involved since the beginning.

There’s no way for me to prove I’ve been trying to mine since block 1; while the idea would be great for those selected, it would leave a lot of people out.

Personally, I’m in that mindset... You know when you’re rooting for the price of Bitcoin to drop so you can buy some? That’s where I’m at—I’m hoping the big miners get frustrated and drop out, making room for me to mine a bit.

[gabrielesor]

Thanks, shadow_69.

Your reply raised a technical objection that I thought was important enough to check against the actual Zycord genesis source rather than continue discussing it by intuition.

I reviewed the v0.6.1 code and, on the main point, I think your objection is correct.

A deterministic per-address top-up cannot reliably distinguish:

1) one large miner using several payout addresses;

from:

2) several genuinely independent small miners using one payout address each.

The canonical chain does not appear to contain a stable miner or wallet identity that would allow those two cases to be distinguished trustlessly.

So the requirement I considered essential — preferentially support genuinely small early miners while excluding large miners — cannot be satisfied by the per-address mechanism I proposed.

There is one technical detail in your explanation that produced an unexpected finding.

The payout-rotation component you referred to does exist.

The v0.6.1 source contains the rotation logic, including the random 1-to-6 observed-reward threshold, and it is covered by tests.

However, when tracing the production entry points of the genesis release, I could not find a normal production path that wired the rotation mechanism end-to-end in the way your post assumed.

In other words, the component existed and was tested, but the production paths I inspected did not appear to assemble all the conditions required for automatic payout rotation during normal bundled mining.

A dedicated review of the v0.6.1 production paths confirmed that the payout-rotation feature was implemented and tested, but not wired end-to-end into any normal production flow.

The browser UI starts the watcher without the mining state required by RotatePayout, while the desktop bundled-mining path has the mining state but never starts the watcher. In addition, normal desktop relaunch omits the payout-file propagation used by the initial solo configuration.

I have a developer-oriented report with the exact files, functions, call paths, tests and a reproduction guide if anyone wants to verify the finding independently.

I want to be precise here: this is a static source-level conclusion about the shipped v0.6.1 production wiring. It is not a claim that payout rotation could never occur under any custom setup or modified client.

This finding does not rescue my proposal.

Even without automatic rotation, a miner can deliberately use several payout addresses or wallets, and the chain still cannot prove that they belong to the same actor.

A voluntary proof that several addresses belong to one wallet would not solve the problem either, because it cannot prove that the claimant has disclosed all of their addresses or controls no additional wallets.

The zero-block case is even more fundamental: failed hashing attempts leave no canonical evidence, so a miner that contributed work but found no block cannot retrospectively prove that contribution from the chain alone.

So my conclusion after looking into this is:

your underlying objection to my small-miner top-up proposal is correct, and I consider that proposal closed in its original form.

The only technically clean alternatives I found are mechanisms based on canonical block contribution rather than on identifying "small miners", but that would be a different proposal with a different objective.

The payout-rotation wiring discrepancy is interesting on its own and may be worth investigating separately.

I have the source-level audit with the relevant files, functions and production paths. If you or the maintainer are interested, I can provide the detailed evidence/report so the finding can be independently checked.

Thanks for raising the objection. It materially changed my assessment of the proposal.

[darkko]

I would like to retract my earlier position, as I linked @gabrielesor's proposal to an attempt to compensate those who were raging against the project here and on Discord because of the reward ramp. I'm sorry about that. In any case, I agree with the other opinions. Mining a little is still better than mining nothing (my case, and that of many others), and those miners are left out of the proposal.

Darkko
Zycord Community

[gabrielesor]

Thanks, Darkko,

I appreciate the clarification.

The zero-block case was actually already acknowledged in my original proposal.

What changed my assessment came later.

A deeper technical review showed that even for miners who did produce blocks, a payout address is not a reliable miner identity. One miner can use several addresses or wallets, while several independent small miners can appear in exactly the same way on-chain.

So a rule based on "addresses that mined little" cannot reliably identify genuinely small miners.

That breaks the essential requirement of my proposal — supporting small early miners without allowing large miners to qualify through address splitting — and for that reason I now consider the original proposal technically closed.

[thesimstoshi]

On payout rotation, the community fund, and what comes next

Payout address rotation. Thanks, gabrielesor. I'll look into it. I wrote that feature well before launch, for the privacy of people mining from the wallet. If it isn't wired into the production path, that is a privacy gap in the wallet, not a consensus issue. Please send the report.

Topping up small early miners. You reached the same conclusion that led to my decision in #57. Rewards proportional to hashrate are the only Sybil-proof rule [1], and schemes that favour small miners or resist pools end up circumvented [3][4] (references in #57). Every workaround opens a new path, and the people who take it are the ones with more technical skill and more money. The ramp does not pick winners; it only lowers the value of the start for everyone.

What actually matters now. Keep your machines mining, but mining is not this network's biggest asset. Mining doesn't bring usage; usage brings mining.

What sets Zycord apart is the sequencer: a service that orders a contract's transactions off-chain, in real time, and publishes the result. The network only verifies and records. Thousands of users can work the same contract at the same moment. Applications that need heavy computation, run in real time, or have many users trading nonstop are impossible, or painful to use, on other networks.

That opens room for applications that need a chain of their own elsewhere. Hyperliquid had to build an entire chain to run an order-book exchange in real time. Here it takes a few contracts and a sequencer; the project can be a token or a DAO instead of a new network.

An MMO DeFi game that runs entirely on-chain and stays cheap. Live betting markets. Liquidity pools. A P2P market. Decentralised AI services paid per token through micropayments. Almost everything is still to be built, on a new network with no competition. Right now the bigger opportunity is in building, not mining. The cEVM is already open on testnet and turns on at mainnet height 80,640 (~4 November).

Running a sequencer is a good business too. Anyone can offer the service. An application can run its own sequencer or use one already on the network, with a public track record. Whoever starts operating one now builds that reputation from the beginning.

The community fund. Its purpose is to support exactly this: get what is in the whitepaper running, back the people who build, and keep the project going. I haven't settled the details yet. The direction I see is a few full-time roles, paid in ZCD with public accountability, and incentives for whoever is working to give the network real use. The fund cannot be spent before height 259,200 (~January), and the concrete proposal will be discussed here before then.