[ANN][ZCD] Zycord | A P2P network of self-certifying state | Launching today! ✅

[thesimstoshi]

B — Pool-friendly, but only if the pool path is publicly tested and available before genesis.

I can add one real-world data point from last night’s launch.

I was running a small independent Windows miner built from the v0.5.0 source, with RandomX enabled and just one mining thread.

I saw essentially the same bootstrap problem reported in #36: seed.zycord.com worked, while seed2 and seed3 were not resolving. Before genesis I generally had only 1–2 outbound peers.

The node eventually recovered and followed the chain normally. When I stopped it after the relaunch announcement, it had reached height 795 with ahead_peers=0. I did not observe a block or reward from my miner.

From my perspective as a small miner, I prefer option B because it keeps both possibilities open. I can mine solo when it makes sense, but if network hashrate grows to the point where solo mining means running small machines for hours or days without seeing any reward, I would also have the option to join a pool and receive smaller but more regular payouts.

I don’t expect a small miner to earn the same as a large miner. I just think small miners should have a realistic way to participate and receive proportional rewards over time, rather than mining becoming an all-or-nothing lottery.

My only concern with option B would be avoiding a situation where one validated pool has a head start at genesis while other miners are still trying to connect or configure their setup.

Ideally, the reference pool, Stratum/XMRig path and solo-mining path should all be publicly available and testable before genesis, so everyone interested has a reasonable opportunity to prepare.

I also like the three-seed fix, the bootstrap load test and especially the proposed reward ramp. I think those measures address a different but equally important fairness problem: reducing the economic importance of the first minutes while nodes are still discovering peers and the network is stabilizing.

So my vote is B, provided that the pool path is openly testable before launch and doesn’t create a privileged starting position at genesis.

I’d be happy to participate in the pre-launch testing from Windows and repeat the DNS/node connectivity tests before Oct 3 if that would be useful.

Thank you, this is exactly the kind of report that helps. Your node saw the same thing everyone did: only seed.zycord.com resolving and one or two outbound peers. That is the bootstrap failure that the relaunch fixes first.

Your condition for B is the correct one, and I agree with it: no pool, validated or not, should start ahead of anyone else. Concretely:

When I was building Zycord, I always thought about allowing pools. It's just that this has to be done the right way.

I made many mistakes in this launch and I own that.

If the pool path is chosen, the Stratum/XMRig path and solo mining will all be published and testable before genesis, in the same release, so that everyone prepares with the same information.

I will do my best to release the binary further in advance this time.

The reward ramp covers the rest: even if someone is set up a few minutes early, the first days pay a small fraction of the full reward, so an early advantage is worth little. It also allows the hashrate to stabilize as miners join.

I think it's worth hearing more opinions. But I agree with you on everything.

[thesimstoshi]

Relaunch moves to October 7, 00:00 UTC

Three days is too little to build and properly test the reward ramp, stand up the three seeds and run the bootstrap load test. Launching on time with something untested is how the first launch failed, and I am not repeating it.

New genesis: 2026-10-07 00:00 UTC.

The extra days also give the pool test (if option B wins) and the independent connectivity checks offered here a real window before genesis. The vote stays open.

[ecofreeman]

My preference is A: pool-resistant mining.
One of Zycord’s most distinctive goals, to me, is a network that can depend on independent miners rather than a few pool operators. I mined solo during the October 1 launch, and I would like to share some observations from my own node that may help with the relaunch. These are local observations, not a measurement of the whole network.
I ran the v0.5.0 node with 26 mining threads. Its logs showed roughly 8,600 H/s over a 60-second window. At around 07:58–08:02, my node was advancing through heights 870–875, but usually showed one outbound peer, briefly zero peers, and listening=false. It also reported reorgs=6 and deepest=9. I mention the last figure because I think it would be useful to test chain stability as well as initial connectivity before the next genesis.
I wrote a small tool to scan canonical blocks paying to my address. It found 8 blocks through height 671, then 11 through height 870 in a later snapshot. A subsequent scan found 2 blocks between heights 873 and 998. Those scans were taken at different chain tips, so I am not presenting their sum as a verified final total. My miner kept hashing and finding blocks after the cancellation announcement; that illustrates why operators need a clear notice and instructions to stop the old chain.
For the relaunch, I would like the team to investigate non-outsourceable proof of work: for example, work tied cryptographically to the miner’s own payout key so that delegating it to an untrusted pool operator is difficult without giving up control of the reward. Please have any design reviewed and tested; requiring a signature alone should not be assumed to make pooling impossible.
Could latency-sensitive work also be evaluated? I would not rely on it unless testing shows that it disadvantages centralized work distribution without unfairly penalizing solo miners with slower connections or distant peers.
If effective pool resistance is not achievable in time, I would still support multiple tested bootstrap seeds, a load test with many cold nodes, and the proposed gradual reward ramp. A special “solo miner bonus” sounds attractive, but it would need a credible defence against pools presenting many addresses or nodes as independent miners.
My priority is not a guarantee that every small miner finds a block quickly. It is that mining independently remains a viable choice and that the launch does not force participants towards a handful of pool operators. Please publish the final algorithm, source, test results and mining instructions early enough for independent miners to prepare.

[thesimstoshi]

You have a great point ecofreeman,

The main premise of Zycord is really to allow small miners to form a scalable and decentralized network using the computational power available today.

Other networks, when they grow, go through a process of centralization where the network becomes "public" but with few nodes under the control of large organizations. The networks are trading scale for centralization.

Zycord seeks the opposite, every computer that joins the network comes to add processing power, both in the phase of building transactions and in the phase of validation and registration.

One of the central ideas of the coin is that you don't need to become a datacenter to contribute to the network.

[thesimstoshi]

Option C: pool-resistant at launch, pool-friendly by schedule

andremangra and ecofreeman both raised points I agree with, and I think they fit together.

The proposal

- At genesis, mining is pool-resistant: every hash is signed with the payout key, so public pools are impractical and everyone mines solo.
- The rule expires at a fixed block height, written in the code from day one, about 3 months after launch. From that block on, Stratum/XMRig pools work. No new hard fork, and no decision from me.
- Solo mining keeps working after that. Whoever has enough hardware mines solo; whoever doesn't can join a pool.

Why

- While the network is small, blocks come every 30 seconds and small miners can still find them on their own. Pools are not needed yet.
- As hashrate grows, solo becomes a lottery for small miners, and pool resistance ends up being bypassed anyway. Other networks went through this. So it should not be permanent.
- The months in between give us time to test the pool path together and to build a relationship with several pools instead of one, without rushing.

What this does not do

To be clear, since some of you questioned the relaunch: this does not limit hashpower. Whoever has more hardware mines more, before and after. Farms that own their machines are not affected. What it avoids is block production sitting with one or two pool operators in the first weeks, while the coin is being distributed.

I believe a wider distribution at the start means a larger community and a healthier market, and that this is what is best for the network in the long run.

The reward ramp, the three seeds and the bootstrap load test stay as proposed.

What do you think? I think it’s a middle ground between the two worlds, and it allows us to create a healthier community.

[andremangra]

Option C actually sounds like a very interesting compromise to me.
I voted for B earlier because, as a small CPU miner, my main concern is having a realistic way to keep participating if the network hashrate grows significantly. I don't mind receiving small rewards, but I would prefer smaller and more regular rewards over running a few modest machines for days without realistically seeing a block.
At the same time, I also understand the concern about having public pools available from block 1, especially after what happened during the first launch.
So C could address both sides quite well: keep the initial launch focused on independent solo miners, while giving small miners a predictable path to pools later if solo mining becomes too much of a lottery.
I especially like the idea that the transition would be defined in consensus from genesis at a fixed block height, rather than being decided manually later. That makes the rules known to everybody in advance.
My main suggestion would be to make the activation height/date and the exact pool-resistant mechanism very clear before launch, and to have the future Stratum/XMRig path publicly available and tested well before it activates.
The ~7 day reward ramp also makes much more sense to me now. If the first hours carry very little economic weight, temporary bootstrap/connectivity differences at genesis become much less important.
So, speaking only as one small Windows CPU miner: if C becomes a real option, I would probably prefer C over my previous B vote.
And I'm still happy to help with Windows connectivity/bootstrap testing before October 7. My little machine survived the first launch, so it deserves another mission. 

[darkko]

I know nothing about programming or protocol design, so this may be nonsense. I used an LLM to explore the terminology and make the idea less amateurish.

**Brainstorm:** what if Zycord offered two simple native options in the desktop app/CLI?

**SOLO:** 100% of the mining reward.  
**NATIVE POOL:** perhaps 80–95%, but frequent rewards based on contributed work.

If I have an i5, I may gladly sacrifice part of my EV to join the pool and compete collectively against an EPYC farm.

If I own 10 EPYCs, I already find blocks frequently. Why sacrifice 5–20%? I would rationally stay solo.

More importantly, splitting my 10 EPYCs into 1,000 Sybil identities should not help: if pool rewards remain strictly proportional to work, all my pooled hashrate still receives only 80–95% EV.

So instead of identifying “small miners”, could the protocol create **economic self-selection**?

The critical requirement would be: the native pool should be the only practical pooling path, while SOLO remains pool-resistant/non-outsourceable.

Just throwing this out as a possible direction for discussion.

[thesimstoshi]

Thanks, darkko.

Monero has something similar in P2Pool: a pool built into the protocol, where each miner keeps validating and building their own blocks, and there is no operator. And if the native pool is the only practical way to mine as a group, external pools lose their reason to exist.

I have two reservations.

On the 5–20% discount: it raises more problems than it solves. Also, if the pool has no operator, it doesn't matter who joins it.

On the timeline: a native pool is not trivial to implement and test. It isn't possible by the relaunch on the 7th. But it could come into the project's scope if we adopt option C. The timeline would still be tight, but it might improve the network's usability.

[BoozyTalking]

There is only two ways to give small miners a chance:
1) make mining process not depending on hashrate value;
2) make a restriction for mined blocks by one day per wallet address (Dillithion coin, for example).

[gabrielesor]

Option C — pool-resistant at launch, pool-friendly by schedule — works for me.

I think the fixed transition is the strongest part of this option: pool-resistant mining at launch, followed by pool support at a height known from genesis rather than by a discretionary decision later.

It gives independent miners the initial window discussed here, while keeping a predictable path for smaller miners to use pools if solo mining becomes impractical as hashrate grows.

My only requirement would be that both the pool-resistant mechanism and the future Stratum/XMRig path are published and tested well before their respective activation points.

[gabrielesor]

Separately from the launch-policy discussion, I opened a merge request adding a process-local counter for completed native PoW evaluations:

mining_hashes_total / zycord_mining_hashes_total

The goal is to make actual local mining work directly observable instead of inferring it from blocks found.

The change does not modify RandomX, target calculation, nonce traversal, consensus rules, or Stratum behavior. It was tested with package and race tests, real RandomX, an isolated live daemon, and paired 1/3/6-worker benchmarks. No material throughput regression of 1% or more was detected at the experiment's resolution on the tested configuration.

MR:
https://gitlab.com/zycord-group/zycord-node/-/merge_requests/65

I see this as a small observability primitive: miners and maintainers can inspect local native PoW work directly, while external tools can handle polling, persistence, rate windows, correlation with existing node metrics, and optional multi-node aggregation outside the node itself.

[thesimstoshi]

Thank you to everyone who weighed in here: andremangra, ecofreeman, gabrielesor, darkko, BoozyTalking, CiggiesSanz and aria.devcode. And to those who voted on Discord.

I spent these days studying pool resistance, including Option C, which I proposed myself. A technical summary of what I found:

• The problem is not trivial. Non-outsourceable proof of work is an open research topic, and the robust schemes are too complex to design, review and test in a few days.
• The simple schemes can be worked around. A pool that writes its own software can get around per-hash signing, and the literature also documents workarounds through collateralized contracts.
• In practice, the rule becomes a barrier for ordinary users. Those who can program get through; those who can't are left without a pool and without the standard tools.

What makes participation easiest is the opposite: native pool integration from day zero, solo mining in the same release, and ready-made binaries, so anyone can mine without knowing how to program.

[thesimstoshi]

Relaunch on October 7: what changes and why

I spent the last few days studying the academic literature and the track record of other projects before deciding. Here are the decisions and the reasons behind them.


1. Mining: RandomX with pools (option B)

I said the relaunch would use a different algorithm. After studying the question, and after the community vote on Discord and Bitcoin Talk, I changed my mind.

Rewards proportional to hashrate are the ceiling. No protocol rule favors the small miner without being circumvented by those who split themselves into multiple identities. The proportional rule is the only one that is symmetric, budget-balanced, Sybil-proof and collusion-proof [1], and other work reaches the same conclusion by a different path [2].

Pool resistance can be circumvented. The schemes proposed in the literature [3] were bypassed with contracts that lock up a collateral from the miner [4]. Ergo launched with pool resistance and removed it later. Those who know how to code would get around it, and everyone else would be left mining solo. Instead of making the distribution fairer, the rule would favor a few.

Pools do not, by themselves, mean centralization. Larger pools charge higher fees, attract proportionally fewer miners, and grow more slowly [5].

What failed on day 1 was the network, not the algorithm. Propagation delay is the main cause of forks [6], and the largest miners lose fewer orphan blocks relative to their power [7]. That is why the priority is seeds and connectivity. I have already hired more servers.

What actually changes

• 30-day reward ramp, from close to zero up to 21 ZCD. Being first now counts for little, and the network has time to stabilize while more people join.
• Three seeds, a peer list embedded in the binary, and an initial difficulty calibrated to the day 1 hashrate.
• Testnet relaunched between today and tomorrow with the release candidate, so we can test both solo and pool mining.
• Final binary on day 4, before genesis.
• Pools and solo in the same release, with the same instructions. We will open a Discord channel to help each other with pool setup.

2. Founder compensation and community fund

This changes a promise I made, and I want to say it plainly: the original announcement said zero allocation for the founder. That is no longer true. What does not change: there is no premine, and no coin exists before block 0.

When I designed the launch, I pictured 10 or 15 people mining, myself among them. My initial research showed that projects, even those with a strong technical differentiator, took a long time to be discovered. Zycord got far more visibility than I expected. That is all I ever wanted, but day 1 showed a hashrate at which my computer mines nothing. The plan of paying myself for my work through mining ended there.

I will be direct. Era 0 is small on purpose, and most of what the whitepaper describes is still to be built. The project still needs me full time for a few years. I love this work and believe in it with everything I have, but I cannot support myself working for years without pay. Without that, the project dies.

The last month of public progress shows my dedication, and it is small compared to the years of work, study and research that came before. I think a reward for that is fair. I am paid as the network mines: my success is the network's success.

I also reconsidered opening the treasury only in Era 2. I brought cEVM forward because without it we would be just a payments network, with no real demand for the token. Each network opens up types of applications that others cannot support, and Zycord has a strong differentiator there. Without a fund to promote projects that use this potential, we would become yet another EVM-compatible network with no usage. The beginning is the best time to create that demand.

The rule is written into consensus from block 0

• 94% to miners.
• 3% to the founder, block by block, for three years. At height 3,153,600 this ends automatically.
• 3% to the community fund: applications, hackathons and projects that only fit Zycord.

After the three years, my 3% goes to the treasury, which then holds 6%.

In numbers, my reward for committing full time over the next three years comes to less than 2% of the total supply. For comparison: Zcash allocated 20% of each block for four years, and Dash and Decred allocate 10% to the treasury. An academic study of ICOs found that projects whose founders retain a larger stake are more likely to deliver a working product [8]. It is a small amount compared to other projects, and I believe it is fair.

Community fund keys

The community fund keys will not be chosen by me. A key chosen by the founder is the founder. The fund is sealed by consensus until height 259,200 (about 90 days), and until then we will decide together, in this thread, how to choose the signers and how to vote on proposals. I will hold at most one key.

The addresses will be in the genesis parameters, and the signed statement will be updated. The code is open source, and I invite everyone to audit it.


References

[1] Chen, Papadimitriou and Roughgarden. "An Axiomatic Approach to Block Rewards". AFT 2019. arXiv:1909.10645.
[2] Leshno and Strack. "Bitcoin: An Axiomatic Approach and an Impossibility Theorem". Cowles Foundation.
[3] Miller, Kosba, Katz and Shi. "Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions". ACM CCS 2015.
[4] Chepurnoy and Saxena. "Bypassing Non-Outsourceable Proof-of-Work Schemes Using Collateralized Smart Contracts". FC Workshops 2020. ePrint 2020/044.
[5] Cong, He and Li. "Decentralized Mining in Centralized Pools". Review of Financial Studies 34(3), 2021.
[6] Decker and Wattenhofer. "Information Propagation in the Bitcoin Network". IEEE P2P 2013.
[7] Gencer, Basu, Eyal, van Renesse and Sirer. "Decentralization in Bitcoin and Ethereum Networks". FC 2018. arXiv:1801.03998.
[8] Davydiuk, Gupta and Rosen. "De-Crypto-ing Signals in Initial Coin Offerings: Evidence of Rational Token Retention". Management Science 69(11), 2023.

[thesimstoshi]

The 30-day ramp has an additional benefit. There is a well-known precedent: Zcash used a ramp of about 34 days at launch.

It also changes the incentive for anyone who only shows up to mine early and sell later: with the reward near zero in the first weeks, renting hardware or pointing a farm at the network earns little.

Those mining on their own computers, without that cost, should face less competition precisely while the network is forming. It is not a guarantee, but the incentive points toward a wider distribution.

[aria.devcode]

Good call on option B. Pools with PPLNS are what gives small and mid-size miners a steady income, and a miner with 10 CPUs is still an independent miner. Refusing them would only have pushed hashrate elsewhere.

One honest remark: three postponements and rules still moving the day before genesis make it hard for people who built tooling for launch day to trust the schedule. A frozen spec a few days ahead would help a lot.

You mentioned pool tests before the relaunch. Our community pool is ready for Stratum tests whenever you publish the relaunch build. Tell us where to report results.

Stefan
https://pool.ariabrain.com/index.html

[thesimstoshi]

Good call on option B. Pools with PPLNS are what gives small and mid-size miners a steady income, and a miner with 10 CPUs is still an independent miner. Refusing them would only have pushed hashrate elsewhere.

One honest remark: three postponements and rules still moving the day before genesis make it hard for people who built tooling for launch day to trust the schedule. A frozen spec a few days ahead would help a lot.

You mentioned pool tests before the relaunch. Our community pool is ready for Stratum tests whenever you publish the relaunch build. Tell us where to report results.

Stefan
https://pool.ariabrain.com/index.html

Thanks, aria.devcode.

Your remark is completely fair. Here is what I am committing to:

• Rules frozen at v0.6.1. The release build for testnet and mainnet is already out, with all consensus rules closed and all parameters locked. Nothing that affects mining or pool software changes after this. https://gitlab.com/zycord-group/zycord-node/-/pipelines/2909211158
• Dress rehearsal on testnet on October 5, 00:00 UTC, with the Stratum/XMRig path and solo mining in the same release. We will validate code, consensus rules, infrastructure and network propagation. Mainnet is only on the 7th.
• If a serious bug shows up, the date moves, not the rules. All the code is already on main. If the audit, mine or the community's, finds a serious security or consensus flaw, I will postpone genesis.
• The main cause of the October 1 failure was my infrastructure, which was undersized. That has been fixed. The emission ramp also gives us time to fix infrastructure problems calmly, because the reward for the first blocks is very low.
• No new relaunch. If mainnet starts without incident, there will not be another one. Later problems will be handled with updates, except for a consensus failure that splits the chain or creates coins outside the emission schedule.

Your pool is welcome in the Stratum tests. Join the Discord https://discord.gg/8DXTADJ6Es to report your results and to help others who are also connecting through a pool. A second and a third pool testing alongside you would be even better, so I extend the same invitation to any other operator.

[thesimstoshi]

Zycord devlog – Oct 1 → Oct 4

v0.6.1 is out – download it and test: https://zycord.com/download/
The testnet relaunches on 5 Oct, 00:00 UTC, to rehearse the mainnet launch two days early.

✅ Release version v0.6.1
✅ Stabilization of seed nodes 1 through 4 and increased capacity of seed servers.
✅ 30-day slow start: the block reward starts near zero and ramps up to full
✅ Subsidy split in consensus: 94% miner, 3% founder, 3% community fund
✅ Same binary for testnet and mainnet
✅ Block 1 reveals a message committed in the binary – nobody can start the chain early
✅ Black box, public: a local devnet that runs 105 network tests, happy path and edge cases. Reproduce ours or write your own: https://gitlab.com/zycord-group/zycord-blackbox
✅ Desktop wallet: countdown to genesis, automatic resync from the cancelled chain, pool mining from Settings
✅ Hash counter in /metrics (!65). Thanks gabrielesor
✅ Announcement post and site updated to match the code

⚠️ Review continues until genesis; any fix ships before the 7th.

Audit the code and the rules: https://gitlab.com/zycord-group/zycord-node
Pools: start integrating now – unmodified XMRig mines over Stratum, and the testnet runs mainnet's rules from the 5th. Issues on GitLab.

🔜 Testnet genesis: 5 Oct 2026, 00:00 UTC.
🔜 Mainnet genesis: 7 Oct 2026, 00:00 UTC.

[thesimstoshi]

I created a dashboard so we can monitor network health together in real time during the launch.

https://lab.zycord.com/tools/network/

[shadow_69]

Thanks for the dashboard, handy for comparing against our own node. We have a node and a rx/2 miner running on the testnet, ready for the 05 Oct genesis, and will report anything odd we see after block 1. Good luck with the launch!

[thesimstoshi]

Zycord testnet: the first two hours

The launch rehearsal opened on 5 October at 00:00 UTC, running the same binary (v0.6.1) and the same rules as mainnet.

Summary: the network started on time, the three seeds stayed up and in agreement, difficulty adjusted on its own, and block time settled at the 30-second target.

Launch. Block 1 arrived at 00:00:01 carrying the launch message. No node mined before it. Only the launch node can produce block 1; it also found block 2. Together they paid 0.0007 ZCD.

Pace. The testnet deliberately starts at a low difficulty (~34 H/s), so the first 5 minutes produced 73 blocks. The adjustment raised difficulty about 470x in roughly 10 minutes, and since 01:00 the average block time has been ~32 s.

Code:

Blocks in 2 h      371 (target 240)
Hashrate           peak ~52 kH/s, now ~36 kH/s
Seeds              3/3 up, zero restarts, same state
Connections        peak 19 per seed, 0 refused
Reorgs             3, max depth 2, all in the first 40 min

Reward ramp. The block reward is at 0.090 ZCD, 0.44% of the way up. The first two hours issued 16.8 ZCD in total, against 5,040 ZCD at full reward, and the 73 fast blocks at the start paid 0.66 ZCD between them. Being first is worth almost nothing, as designed. The ramp tops out at 20.41 ZCD rather than 21 because the daily emission step-down already runs during the ramp.

Ready for mainnet? Launch, seeds, consensus, difficulty adjustment and the reward ramp are validated. The testnet did not draw the crowd of 1 October, so heavy simultaneous load, pools and transaction volume remain untested. Expect a fast start on mainnet too: difficulty needs a few minutes to catch up with the real hashrate, so the first blocks will come quickly, and the ramp makes them worth almost nothing.

Until then: keep your nodes and miners on the testnet, test pools over Stratum/XMRig, and report anything unusual here or on GitLab.

Live: https://lab.zycord.com/tools/network/

🔜 Mainnet: 7 October, 00:00 UTC.