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

[darkko]

Hi,
I'm really interested in your project!  

I’m preparing a local Windows RandomX build, without running the node or miner yet. I’ve opened GitLab Issue #36 with specific questions about the supported toolchain and which source snapshot to use:
https://gitlab.com/zycord-group/zycord-node/-/work_items/36

Could you take a look when you have a chance? I also saw that SECURITY.md does not list a private reporting channel. If someone identifies a potentially sensitive security issue, how should they contact you without posting the details publicly?

Thanks,
Andrea

The network starts small and grows on its own. On day one it handles about 90 certificates per second. That is low, and it is on purpose. A high ceiling at launch would be a ceiling the network has not yet proven it can propagate between nodes, and a block that propagates badly is a block that turns into a fork. So it starts with a low ceiling, and that ceiling rises with real demand. The 1 million is not a capacity that exists today.

This also keeps the fee market alive. Because capacity follows measured demand, block space always has a real price, instead of collapsing to the floor the way it does on networks that launch with far more capacity than use.

When the network detects that it needs to grow, it does so automatically, and it can at most double its capacity every year. If demand goes away, idle capacity shrinks back, slowly, and never below the launch value.

year	capacity
0	~90/s
7	~11,000/s
10	~90,000/s
~13.6	~1.1 million/s

The calculation is in the whitepaper, section 8.1, "Capacity across eras". And there is an important detail you caught: there is a deliberate limit inside the current era. No matter how full the network gets, growth stops at around 427 certificates per second. Passing that gate takes a hard fork, which in the project's schedule are the era transitions. It was designed this way because in Era 0 I chose to keep the surface of the blockchain small, so it is easier to program and audit. In the following eras there will be more people to do that safely.

And that limit is more than enough to reach Era 2. Even if the network grows at the maximum rate every single day, it reaches Era 2 at about 255 certificates per second, well below 427. The gate would only be reached some nine months after the era transition, and the era transition is exactly what moves the gate.

One more thing: the number is certificates, not transactions. A certificate can carry a single payment, or several batched by a sequencer. So 1 million certificates per second is the floor in transactions, not the ceiling.

On measuring sustained throughput: today there are few machines mining the testnet, so a test here would measure my setup and not the network. Once mainnet is live we will be able to measure it properly. What we have tested so far is something else: a thousand contract calls to the same recipient, in the same block, and all thousand were applied with zero skips. For comparison, we wrote the same contract the traditional way, which reads the balance, adds, and writes. With two tips at the same time, it already discarded one. With deltas, a thousand did not collide.

What this shows is the core idea of the project: all the heavy logic runs on the sender's machine, before publication. The miner executes nothing. It verifies that each certificate is well formed and signed, which is parallel work, and applies the result, which is a trivial operation: compare, add, write. That is what we have been validating on the testnet. That the mechanism we designed works.

Thanks for the capacity clarification. Keny has already provided a helpful technical reply in GitLab #36, so I won’t repeat the Windows build questions here.

I had one remaining question from my earlier post: is there a preferred private contact for reporting potentially sensitive security findings?

Thanks,
Andrea

I guess your answear is in the SECURITY.md file:

Security
Reporting
There is no private reporting channel, so assume anything filed is
public. For anything critical, do not open a public issue and do not post a
reproduction: open one naming the category and nothing else, and wait to be told
where to send the detail. Anything else belongs in the open. Say which rule is
broken, by id (V4, B3, F7); who does what in what order and what they gain;
and give a reproduction, ideally a test in core/fold or a scenario in sim/.
Critical means one signature billed twice; billing a third party by making their
certificate skip; creating value, whether supply growing other than by
emission(height), an asset over its cap, or a treasury write that is not the
fold's credit; a consensus split; encoding ambiguity that makes a valid block
unprovable or an invalid one pass; or non-determinism in the fold. In scope: this
repository and the parameter sets in spec/.

[kenyfran]

I came from your post in the Monero community. I like the project; I think it has potential.

I can contribute by doing a quick code review. The code seems well-written. I found some tests failing on Windows and macOS due to environment issues; I ran them myself as well.

I ran the project and the benchmark to compare the results against the stated figures.


 Node & wallet (devnet) — macOS Apple Silicon, dev @ 4b00615
 

• make build and make build-randomx both work. The RandomX binaries run and pass codesign --verify (the fix from !2 holds, no binutils needed).
• zcd vectors: 152/152 passed; genesis ids match.
• Devnet mined normally; created two wallets and sent a transfer (applied at height 16 (APPLIED)); the recipient's balance was confirmed.
• zcd ui serves on loopback only; the API returns 401 without the token.
• Small doc note: the README quickstart runs wallet balance / send without --devnet, which fails against a devnet node with a chain id mismatch.

  Benchmarks vs. your figures — median of 5 runs, -benchtime 2s, idle machine, 8 cores
 
 

Metric	Yours (10-core x86)	Mine (macOS Apple Silicon)
Sequential fold, one core	883,000 ops/s (~294K certs/s)	1,033,091 ops/s (~344K certs/s)
Block of 2,900 certs: verify	1,963 ms	1,416 ms
Block of 2,900 certs: apply	9.9 ms	8.4 ms direct / 11.4 ms by subtraction
Parallel share	99.5%	99.2%
Stateless verification, per core	1,470 certs/s	2,095 certs/s
Stateless verification, all cores	5,220/s (10 cores)	~6,200–7,000/s (8 cores)
Single signature verify	1,500/s	2,226/s

  My numbers are close to yours and mostly faster. The ratio behind the design holds: applying the block is about 1% of block time, and verification is about 99%.

  Two observations:
 

• The "1,963 ms to verify (parallel)" figure appears to be measured on one core: CheckBlockRules lives in core/, where goroutines are not allowed, and 2,900 / 1,470 per core
    ≈ 1.97 s. Through the node/verify pool the same block would take ~410 ms on this machine. It might be worth labelling it "parallelizable stage, single core".
• Core scaling of the verify pool: 1→2 workers 1.92x, 1→4 3.08x, 1→8 2.97x. The efficiency cores add nothing past 4 workers.

  Commands used (the docs/BENCHMARKS.md referenced in cevm_era0_bench_test.go isn't in the repo):
 

Code:

go test -run XXX -bench 'BenchmarkFoldLoop|BenchmarkApplyBlock|BenchmarkBlockRules|BenchmarkEra0Baseline' -benchtime 2s -count 5 ./core/fold/
  go test -run XXX -bench . -benchtime 2s -count 5 ./node/verify/

[thesimstoshi]

Zycord devlog – Sep 19 → Sep 24

🔜 v0.4.0 is being tagged in the next day. Everything below is in it.

First week with outside contributors: Windows 11, macOS Apple Silicon and Darwin builds, all passing the 152 RandomX vectors with matching genesis ids. They caught a regression of mine that broke the CI gate on every platform, and two merge requests from the community are already merged. Thank you!

✅ Block-body pruning: zycordd --retain-bodies keeps the last N bodies and reclaims the rest; the handshake advertises the floor (protocol v3), and a pruned block is answered as such instead of timing out
✅ Rule V10 now proves a double spend of a one-shot address as equivocation; before, it was invisible. Loosening only
✅ Co-signing service hardened to match: four paths that would have cost it its bond are closed
✅ Co-signed certificates were not being gossiped, so service-paid sends stayed pending for blocks: fixed
✅ Commit store refuses to continue after a failure in the one window where retrying would corrupt the log
✅ Release artefacts now built by a pipeline on a second machine, on tags only, in the canonical container
✅ Engine archives carry a TOOLCHAIN.txt naming the compilers that built them: a record, not a pin
✅ make test is now expected to pass on every published target, and the tree says so
✅ SECURITY.md: private reporting channels named (details in the next post)

🔜 Windows: file mode 0600 does nothing there, so the trust token and credit ledger rely on inherited ACLs. Decision taken: owner-only on every platform, Windows gets an explicit DACL. Please, anyone with a Windows Intel/AMD machine, help me with the patch.
On private reporting, since it was asked here and darkko quoted the old text: SECURITY.md was wrong on that point and has been updated.

While we are on testnet there is no coin and nothing to exploit for value, so everything can be filed in the open, and a public issue with a reproduction is the fastest route. Once mainnet is live, a finding that could be used against the running network is filed as a confidential issue on GitLab. Anyone who can open an issue can tick "This issue is confidential" when creating it; it is then visible only to the reporter and to project members with Reporter access or above. Put the reproduction in it. That option already works today, for anyone who would rather not disclose in the open.

What a report should contain is unchanged: the rule that breaks, by id, who does what in what order and what they gain, and a reproduction.

[thesimstoshi]

I came from your post in the Monero community. I like the project; I think it has potential.

I can contribute by doing a quick code review. The code seems well-written. I found some tests failing on Windows and macOS due to environment issues; I ran them myself as well.

I ran the project and the benchmark to compare the results against the stated figures.


 Node & wallet (devnet) — macOS Apple Silicon, dev @ 4b00615
 

• make build and make build-randomx both work. The RandomX binaries run and pass codesign --verify (the fix from !2 holds, no binutils needed).
• zcd vectors: 152/152 passed; genesis ids match.
• Devnet mined normally; created two wallets and sent a transfer (applied at height 16 (APPLIED)); the recipient's balance was confirmed.
• zcd ui serves on loopback only; the API returns 401 without the token.
• Small doc note: the README quickstart runs wallet balance / send without --devnet, which fails against a devnet node with a chain id mismatch.

  Benchmarks vs. your figures — median of 5 runs, -benchtime 2s, idle machine, 8 cores
 
 

Metric	Yours (10-core x86)	Mine (macOS Apple Silicon)
Sequential fold, one core	883,000 ops/s (~294K certs/s)	1,033,091 ops/s (~344K certs/s)
Block of 2,900 certs: verify	1,963 ms	1,416 ms
Block of 2,900 certs: apply	9.9 ms	8.4 ms direct / 11.4 ms by subtraction
Parallel share	99.5%	99.2%
Stateless verification, per core	1,470 certs/s	2,095 certs/s
Stateless verification, all cores	5,220/s (10 cores)	~6,200–7,000/s (8 cores)
Single signature verify	1,500/s	2,226/s

  My numbers are close to yours and mostly faster. The ratio behind the design holds: applying the block is about 1% of block time, and verification is about 99%.

  Two observations:
 

• The "1,963 ms to verify (parallel)" figure appears to be measured on one core: CheckBlockRules lives in core/, where goroutines are not allowed, and 2,900 / 1,470 per core
    ≈ 1.97 s. Through the node/verify pool the same block would take ~410 ms on this machine. It might be worth labelling it "parallelizable stage, single core".
• Core scaling of the verify pool: 1→2 workers 1.92x, 1→4 3.08x, 1→8 2.97x. The efficiency cores add nothing past 4 workers.

  Commands used (the docs/BENCHMARKS.md referenced in cevm_era0_bench_test.go isn't in the repo):
 

Code:

go test -run XXX -bench 'BenchmarkFoldLoop|BenchmarkApplyBlock|BenchmarkBlockRules|BenchmarkEra0Baseline' -benchtime 2s -count 5 ./core/fold/
  go test -run XXX -bench . -benchtime 2s -count 5 ./node/verify/

Thanks to kenyfran for running the benchmarks and posting the numbers. They exposed a real problem, and we got two things wrong.

1. The "parallel" label was wrong. The "1,963 ms to verify (parallel)" figure in the first post was measured on a single core. A node spreads that work across all of its cores, so the real time was shorter than what we published.

2. More cores were not helping. As your numbers showed, going from 4 to 8 workers gained almost nothing. The design is not the cause: every transaction can be checked on its own, so the work splits across cores. Our implementation was the cause. One of the extra security checks on signatures was written in a way that ran about 10 times slower than necessary. It also filled memory with temporary data, and cleaning that up kept pausing every core at once. Adding cores therefore did not add throughput.

We fixed it without changing any protocol rule. Every transaction is accepted or rejected exactly as before, and the tests check that on thousands of cases.

Issue: #42
Fix: merge request !48

New numbers for checking a block of 2,900 transactions. These are estimates: we measured with 1 to 6 cores on a machine that was also running other work.

Code:

Cores   Before    After
1       2.35 s    0.47 s
2       1.31 s    0.25 s
4       0.80 s    0.15 s
6       0.78 s    0.11 s

On 6 cores that is about 7x faster: roughly 25,000 transactions checked per second instead of 3,700. Signature checking alone is about 5x faster per core. More cores now help: 6 cores are 4.2x faster than 1, where before it stalled at 3x. There is still some room left, and we are working on it.

We will update the first post with the corrected numbers. If you can re-run the benchmarks after the fix is merged, we'd be glad to see your results.

[kaspa_grin]

I created a Telegram group to make it convenient for everyone to communicate and learn.


https://t.me/+ufeCItfHJWU3ZjBl

[darkko]

https://gitlab.com/users/Thesimstoshi/activity

https://gitlab.com/zycord-group/zycord-node/-/boards#/

[thesimstoshi]

Sorry for the lack of feedback. I ran a heavy battery of tests and evaluation of the network last week, mainly validating the transaction scalability layer with smart contracts.

In these tests I found a usability problem. It would not cause any serious security problem, but it would make the network slow for a high-demand application.

So I worked on an update patch that solved this. I ran several batteries of tests to ensure everything will go well at the mainnet launch on October 1st.

These last 15 days of testnet were very important because they allowed me to deeply test the entire chain.

https://gitlab.com/zycord-group/zycord-node/-/merge_requests/49

I created a Telegram group to make it convenient for everyone to communicate and learn.


https://t.me/+ufeCItfHJWU3ZjBl

Thank you very much for the message and for all the care with the community. I am extremely grateful that you created this space.

This week the user Ultimate Digi created our community on Discord. I have already added the links to the initial post of the thread and to the Zycord website.

https://discord.gg/8DXTADJ6Es

Just one note: since I have little experience and little time to manage social networks, I won't be able to help much with moderation or administration of the server. I am only taking care of Bitcoin Talk, because forums are what is easiest and most habitual for me. But I am very happy to know that you and other people are organizing this. You can count on me for promotion.

I am also grateful to anyone who wants to create a community on Reddit as well. I tried to create one there, but since my IP comes from the TOR network and I am a newly created user, I have several blocks.

[darkko]

https://www.reddit.com/r/zcd_zycord/

the name "zycord" only is banned on reddit.

i'll improve the design and texts soon.

[thesimstoshi]

Zycord devlog – Sep 24 → Sep 28: v0.4.0

✅ Intents: sign once, cross-sequencer calls land as one atomic fill
✅ Forced path rebuilt: an intent with no sequencer is executed by the block producer at the end of the block. No queue, no lease, no quota
✅ Simpler rules: bonds, slashing and every free-drop rule are gone. A certificate applies, skips (billed to the sequencer at fault, never the user), or cannot enter the block
✅ Contract admin: sets or hands off the sequencer; contract code can move its own with the new SETSEQ opcode
✅ Wallet and zcd: intents with paid participants, the forced path, and a warning before calling an open contract that could be sequenced under you
✅ Block verification ~7x faster on 6 cores, and more cores now help (#42). No rule changed
✅ Windows: trust token, credit ledger, peer store and settings are now owner-only through an explicit ACL, and the stores no longer trip over open files (#38). Thanks kenyfran
✅ Windows engine build documented: source tag, Go pin, compiler and how to verify it (#36)
✅ Engine archives' TOOLCHAIN.txt now also names the source commit and the linker
✅ Mainnet parameters: coinbase maturity 240 blocks (2 hours); bonding never opens on mainnet
✅ Plus everything in the Sep 24 devlog: block-body pruning, protocol v3, release pipeline, Rule V10

Internal test, three nodes, three sequencers, 24 users trading at once: 781 of 781 intents applied, 692 of them cross-sequencer fills, median inclusion 4.8 s, up to 48 fills per block. Zero skips, zero chain splits, every sequencer paid exactly. With a sequencer stopped, users got through on the forced path. The reference fold agrees on all 295 golden vectors.

Details: merge request !49

🔜 Mainnet genesis: 1 Oct 2026, 00:00 UTC.

https://www.reddit.com/r/zcd_zycord/

the name "zycord" only is banned on reddit.

i'll improve the design and texts soon.

It was me. Since my IP comes from the TOR network and I am a new user, it already flags me as spam for any comment/community I create. I already contacted Reddit support a few weeks ago, but I got no response. Create it with a variation of the name.

[darkko]

https://www.reddit.com/r/zcd_zycord/

the name "zycord" only is banned on reddit.

i'll improve the design and texts soon.

It was me. Since my IP comes from the TOR network and I am a new user, it already flags me as spam for any comment/community I create. I already contacted Reddit support a few weeks ago, but I got no response. Create it with a variation of the name.

I have already created it with the following name: zcd_zycord

https://www.reddit.com/r/zcd_zycord/

[drywall777]

Hello. Thanks for making this space
 available for people interested in this project.  I just want to make sure I understand how it's going to start.  I've been testing my setup on the testnet.  It is my understanding that we should start the node/wallet a little before the time of the mainnet launch.  My guess is that as soon as it launches, our nodes will be able to connect to available peers and begin mining...Can we use the node and wallet we have already setup just by switching to the mainnet option?  Any feedback would be appreciated.

[thesimstoshi]

We are a few hours away from the mainnet launch! I will upload an update with the mainnet parameters close to the launch time, because I realized that a malicious agent could start mining ahead of time and the network would be born with a large reorg. So about an hour before 0h I will release a new binary.

I will also take the opportunity to make some corrections to the binary and restart the testnet.

Hello. Thanks for making this space
 available for people interested in this project.  I just want to make sure I understand how it's going to start.  I've been testing my setup on the testnet.  It is my understanding that we should start the node/wallet a little before the time of the mainnet launch.  My guess is that as soon as it launches, our nodes will be able to connect to available peers and begin mining...Can we use the node and wallet we have already setup just by switching to the mainnet option?  Any feedback would be appreciated.

That's exactly it, but reviewing the project I saw that someone editing the source code could start mining before the others, causing a reorg on the network. So I will release a version close to the launch time with a salt. This will make everyone start mining together.

In practice, just leave the executable running before 0 hours UTC and as soon as it sees the salt it will start mining together with everyone.Zycord v0.5.0 — the mainnet launch binary

Genesis: 2026-10-01 00:00 UTC
Downloads: https://zycord.com/download/

Desktop wallet

• Download it from the site and create a wallet on Mainnet (already have one? Settings → Network → Mainnet).
• Settings → Network services → tick Mine with this computer, set Mining threads (0 = every core), then Save and lock.

Command line — install or build the binaries:

Code:

zcd wallet new --out miner.json        # skip if you already have a key
zcd wallet address --key miner.json    # copy the "persistent" 0x02... address
zycordd --dir ./mainnet --mine --payout 0x02...

• Start any time before 00:00 UTC and leave it running. Block 1 carries the launch salt, so every node waits for it and then everyone mines together. Until then the log says "waiting for the launch block".
• Mainnet is the default, so there is no network flag.
• Your testnet key file works; the addresses are the same.
• macOS: the site has instructions to build and run it.
• Rewards mature after 240 blocks (~2 h).

Check that you are on v0.5.0 or later.

[andremangra]

v0.5.0 successfully built from source on Windows with RandomX support.

Node is up, peers connected, wallet ready and the miner is waiting for genesis.

It took a bit of work to get everything ready, but we’re finally at the starting line 

Looking forward to the launch. Good luck everyone — see you at block 1!

[thesimstoshi]

It's less than two hours until the launch, let me know here if everything went well, if the software is waiting to mine when the time comes.

Or after the launch, let me know if you are able to mine correctly. Just a feedback

[gabrielesor]

Quick pre-genesis connectivity feedback, checked at approximately 23:27 UTC from one Linux node.
I independently checked DNS resolution and attempted a direct TCP connection to port 9421:
seed.zycord.com:9421 — resolves to 185.165.171.41, TCP connection successful
seed2.zycord.com:9421 — currently does not resolve
seed3.zycord.com:9421 — currently does not resolve
This is only an endpoint reachability observation from one network location, not a broader assessment of mainnet readiness.
My node is otherwise left running and waiting for genesis.

[thesimstoshi]

That's exactly where the problem was. There were few public nodes. 40 addresses per node. A lot of people were unable to mine in the first minutes. Now it seems to have normalized, but it's insane, the hashrate.Mainnet is being relaunched on October 3

Two hours in, we are cancelling this mainnet and relaunching it on October 3. Exact time and details will be posted in this thread.

Why

• For the first 30 minutes the seed turned away almost every node that arrived. Most miners could not sync or mine while a few already-connected machines could.
• By the time it was fixed, three payout addresses had mined over 80% of the blocks.

The whitepaper promises a fair launch that builds a community. A coin that concentrates in a handful of hands in its first hours does neither, and that centralization is what kills a coin over the years that follow. This launch missed its own goal, so we start again.

What changes
The relaunch will use a different mining algorithm and launch setup, designed to give early, small miners a real chance. We will specify it closer to the date.

Next 3 days: your input
Before deciding, we want to hear you, here and on Discord: how to make this launch fairer, and what you ran into tonight. The infrastructure will be ready for the crowd this time.

What to do now

• Stop mining this chain. Its coins will not carry over.
• Keep your wallet and key file: the same keys and addresses will work.
• Wait for the new release before relaunch.

Thank you to everyone who showed up tonight. You are the reason this matters.

Please forgive me for this. I have never done a launch, and it was much more chaotic than I could have imagined.

A signed copy of this notice follows below.

Code:

Zycord mainnet relaunch notice
2026-10-01

The mainnet launched at 2026-10-01T00:00:00Z
(genesis id 0x6971791f3e20b7abbe3e2ce3bf7bc56ad734a98826c302885a454efbcd5df769)
is cancelled. Its blocks and coins will not carry over to any future chain.

Reason: for its first 30 minutes the seed refused most arriving nodes, and
three payout addresses mined over 80% of the blocks. That is not the fair
launch the whitepaper describes.

Mainnet will be relaunched on 2026-10-03 with a different mining algorithm
and launch setup, announced before that date. Existing keys and addresses
remain valid.

Simstoshi

[gabrielesor]

Following up on my pre-genesis connectivity post above, here are the observations I can document from my side and a few suggestions for the relaunch.
Before genesis, at approximately 23:27 UTC, from one Linux host I observed:
- seed.zycord.com:9421 resolved to 185.165.171.41 and accepted a TCP connection.
- seed2.zycord.com:9421 did not resolve.
- seed3.zycord.com:9421 did not resolve.
As stated in my previous post, this was only an endpoint-reachability observation from one network location.
Later, after the bootstrap issue had been addressed, one of my public nodes recorded:
02:20:54 UTC  height=498  peers=39  in=37  out=2
02:21:09 UTC  height=498  peers=40  in=38  out=2
02:22:09 UTC  height=498  peers=39  in=39  out=0
02:22:24 UTC  height=498  peers=40  in=38  out=2

These are local node logs. I can provide the original lines if useful.
For the relaunch, I would treat two properties separately:
1. Bootstrap admission: can a cold node starting around genesis reliably discover peers and become connected?
2. Mining fairness: once connected, does the mining algorithm and launch setup give independent miners a reasonable opportunity to participate?
The failure mode described in the relaunch notice directly affects the first property, so I would test bootstrap admission independently of any change to the mining algorithm.
Some concrete safeguards I would consider:
- multiple bootstrap endpoints, all resolving and accepting connections before launch;
- sufficient inbound capacity for the expected genesis connection burst;
- fallback bootstrap peers so that admission does not depend on a single endpoint;
- a pre-launch load test with many simultaneous cold nodes;
- if compatible with the protocol design, a short connection-only period before the first block can be mined;
- publication of the final mining algorithm, source/release, hashes or signatures, and build/run instructions sufficiently before genesis for operators on different platforms to verify the same release.
I can also repeat the same independent DNS/TCP reachability checks before the October 3 relaunch and post the results.

[thesimstoshi]

Thank you very much for the support. It was a very difficult decision to make on the spot.

Besides the connection problem, the algorithm was friendly to mining pools, so the difficulty is undersized. Most of the community was unable to connect to mine.

And it also wasn't prepared for mining pool entries at block zero. All of this led to reorg errors in addition to an excessive concentration of the coin.

I have a big mission on my hands, which is planning a fair launch in 3 days.

I think the first question is, how do we do this?

Let's be friendly to mining pools, if so the community is born mining in a pool.
Otherwise, we put in an algorithm that is not friendly to pool mining.

Honestly I don't know what you prefer or what is fairer.
More importantly, is that possible, being resistant to pools? I have no idea.Relaunch proposal

Fixed either way

• Three seeds on stronger hardware with far more connection capacity, all resolving and tested before launch. No more nodes turned away at genesis.
• Bootstrap load test before launch, many cold nodes at once, as suggested in this thread. Independent checks welcome.
• Reward ramp (the slow start Zcash used): the block reward starts near zero and rises to the full 21 ZCD over the first ~7 days. Showing up first with the biggest rig earns little; by the time rewards are full, everyone has had time to join. Hashrate may still concentrate. But there is still time for the market to adjust.

Your choice: pools at launch?

🅰️ Pool-resistant mining. Every hash must be signed with the payout key, so a pool can't hand out work without handing out its key. Pools become impractical; everyone mines solo.
Catch: solo means long gaps between blocks for small miners, and a farm that owns its machines is not affected. Stock XMRig stops working.

🅱️ Pool-friendly, tested before launch. We keep Stratum/XMRig compatibility and the community tests a pool together before genesis. On day one there's a validated pool for anyone who wants steady payouts. Solo mining and other pools stay open.
Catch: pools concentrate hashrate in their operators, so pool choice matters.

🅾️  Propose something.

Reply with A, B or O, and why if you can.

[andremangra]

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.

[aria.devcode]

Hello,

We are a community of miners on Discord, and we run a pool.
Join us: https://discord.gg/pw9eBB5J5C

Good luck with the relaunch.