[ANN][ZCD] Zycord | A P2P network of self-certifying state | Full Reward PoW 🔥

[shadow_69]

Thanks! Both are open:

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

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

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

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

shadow_69

[samurai619]

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

Hello Zycord Community & Miners,

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

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

📌 Quick Links:

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

⚡ Key Features & Data Tracked for Zycord:

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

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

Best regards,
The MiningChamp Team

[darkko]

$ZCD mining pools:

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

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

Follow x.com/zycord_stream to stay updated.

[thesimstoshi]

Why Era 2 is plain proof of stake

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

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

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

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

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

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

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

What changed in the whitepaper

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

Era 2: proof of stake

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

Eras document

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

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

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

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

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

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

Zycord devlog — Oct 10 → Oct 15

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

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

Audit the code and the rules: https://gitlab.com/zycord-group/zycord-node
Issues and MRs on GitLab.Zycord capacity: before and after sampled verification

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


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

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

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

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

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

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

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

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

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

"Saturates" means the resource is fully used.

In short

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

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

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


For reference: real use on other networks today

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

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

[gabrielesor]

Zycord - Reviewing Developer: a focused charter proposal

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

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

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

1. Give a negative review an explicit consequence

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

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

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

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

2. Leave a reasoned, traceable assessment

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

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

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

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

3. Bound responsibility to a defined review scope

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

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

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

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

4. Make independence practical without barring development

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

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

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

5. Define the time-commitment criterion before candidacies open

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

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

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

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

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

[kenyfran]

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

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

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

On the treasury (§5):

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

[thesimstoshi]

Zycord network upgrade: release on Monday, October 26

Hi everyone,

Over the past weeks the testnet has run several real projects. Together with a full code review, that usage showed us a few things we want fixed before the cEVM opens on mainnet.

To be clear up front: the network is running normally, nothing has been exploited, and we have found no flaw that could break the network. We found a few consensus rules that were implemented incorrectly. They cause no problem today, but once the cEVM is active they could, in some situations, lead nodes to different results. We are fixing that before it can happen.

What's in the upgrade

• Consensus rule fixes, so every node validates the cEVM exactly the same way
• More robust p2p networking, sync and mempool, more resistant to resource abuse
• Wallet improvements and fixes
• Block signalling, so future upgrades activate in a coordinated way, with the network's support
• Intent fees can also be paid from permanent addresses when no one-shot address is available

What you need to do
The upgrade is required for everyone running a node: miners, pools, sequencers, explorers, services and users with their own node.

• Mainnet: the new rules take effect at block 77,760 (around November 3), before the cEVM opens at block 80,640 (around November 4). A node not upgraded by block 77,760 will fall out of consensus.
  
• Testnet: upgrades from Monday too. The new rules activate there about a day later, so we validate everything before mainnet.
  

Please upgrade as soon as the release is out.

Technical details
As is common practice on Bitcoin and Ethereum, the full write-up of each fix will be published once most of the network has upgraded. The release notes will list the changes.

Thanks to everyone who tested, ran projects and reported issues on testnet. That is what let us fix all of this before the cEVM.

[gabrielesor]

Miner Seat — Six questions to shape its charter

Summary
The proposed Miner Seat would bring block producers' perspective into Zycord's treasury governance. Before drafting its charter, I suggest clarifying six things: who it represents, what work it should do, how it gathers different views, what results it should report, how its mandate evolves with proof of stake and the conflicts of interest. This is a contribution to defining the role, not a proposed charter.

Starting point
Launch, Eras and Parameters v2.0, §5 describes the Miner mandate as:

An active miner; speaks for block producers.

It also provides for public charters defining duties, deliverables, reporting and pay. Building on that framework, I would find the following clarifications useful.

1. Who does the seat represent?
Does “block producers” include everyone contributing hashrate, including through pools or rented capacity, or specifically operators assembling and submitting blocks? The charter could explicitly cover both, while recognising that contributing computing power and controlling block production are different responsibilities.

2. Representation, operational work, or both?
Beyond participating in treasury decisions, should the seat gather miners' concerns, assess the operational impact of upgrades, coordinate testing, or combine these functions? The charter should distinguish representation from operational duties and clarify the boundaries with the developer and Community seats.

3. How are different interests represented?
How would the seat collect input from home miners, larger operators, renters and pool participants, without treating its holder's experience as everyone's position? Public consultations, a visible issue log and disclosure of relevant commercial interests are possible safeguards. Disagreements should remain visible rather than be presented as consensus.

4. What would count as useful, verifiable work?
Section 5 already proposes reporting and conditional release of pay. What Miner-specific outputs should support that process? Examples could include operational-impact assessments, documented consultations and follow-up on reported problems. Accountability should concern work the holder can actually deliver, rather than guarantees about network hashrate, mining profitability or independently operated pools.

5. What happens as PoW gives way to PoS?
Whitepaper v2.0, §11 describes the transition to proof of stake, while the stewardship proposal provides for one-year terms. Should the seat evolve into a broader block-producer representative, be redefined at the transition, or remain PoW-specific with a stated endpoint? That choice would affect both its responsibilities and continuity during the transition.

6. How should conflicts of interest be disclosed and managed?
An active miner inevitably has economic interests in mining. The charter should distinguish legitimate participation from conflicts requiring disclosure, recusal, or, in exceptional cases, resignation. The rules should protect independent judgment without making ordinary mining activity incompatible with the seat.

Edit: Added question 6 on conflicts of interest.

I would start by agreeing on representation and scope, then translate those decisions into concrete duties and deliverables. What would you add or change before drafting the charter?

[shadow_69]

Good questions. A view from a home miner (a laptop and two small machines, own nodes, mostly via a pool):

On 3: home miners are the largest group and the quietest. A light, regular channel would help more than occasional consultations: a short public form or thread before each upgrade (“did it work on your setup?”), with the answers summarised as they are, disagreements included.

On 4: useful, verifiable work could be chain-health reporting anyone can reproduce from their own node. For example, block concentration: I read the headers of the last 600 blocks on my node and count blocks per reward address. On Oct 21 one new solo address went from 0 to ~40% of blocks within a day. A periodic note like that (method published, numbers checkable) is the kind of output the seat could own, together with upgrade-readiness checks before each activation height (like the one at block 77,760).

On 5: I’d give the seat a stated endpoint at the PoS transition and let a block-producer seat replace it, rather than stretching a miner mandate over a different job.

On 6: disclosure could be simple and concrete: the holder’s approximate hashrate, pool(s) used, and any commercial mining interest, updated at each report.

[thesimstoshi]

Zycord devlog – Oct 16 → Oct 27

v0.7.1 is out – download it and update: https://zycord.com/download/
Mandatory for every node and miner. The Overture upgrade activates at block 69,120 on testnet and 77,760 on mainnet. A node not upgraded by then falls out of consensus.

✅ Release version v0.7.1
✅ Consensus fixes so every node validates the cEVM the same way, before it opens at block 80,640
✅ Upgrade signalling: future upgrades activate by version bits at 70%
✅ Lower fees: gas priced in micro-drops, skip fee down from 1,000,000 to 1,000 drops
✅ New storage pays: 1,000 drops per new cell a certificate creates; updates cost nothing extra
✅ Spent one-shot addresses expire after 7 days
✅ New cEVM precompiles: p256verify, Ristretto255, ecrecover, bn254, BLS12-381
✅ More robust p2p, sync, mempool and Stratum; mainnet checkpoints
✅ Wallet on an external node with --rpc-token-file (!86). Thanks dario
✅ Proof-of-stake code included but switched off: no schedule on mainnet or testnet

⚠️ The full write-up of each fix follows once most of the network has upgraded.

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

Full report here: https://lab.zycord.com/news/overture-security-upgrade/

🔜 Testnet upgrade: block 69,120 (~Oct 29)
🔜 Mainnet upgrade: block 77,760 (~Nov 3)
🔜 cEVM on mainnet: block 80,640 (~Nov 4)

[thesimstoshi]

Zycord devlog – Oct 27 → Nov 3

Overture is live on mainnet. The hard fork activated at block 77,760 on Nov 2 at 23:24 UTC, and the network crossed it cleanly. Zycord is ready for the cEVM to open at block 80,640.

✅ Clean crossing: no rejected blocks on the seeds, no banned peers, no reorg deeper than 3 blocks
✅ Steady cadence: about 30 s per block since the fork, on target
✅ Every certificate since the fork applied, none skipped
✅ New fees in force: gas priced in micro-drops (base fee 10 micro-drops per gas in both markets), skip fee 1,000 drops
✅ Testnet has run Overture since block 69,120 (Oct 29). Checked there under real network conditions: the new precompiles (ecrecover, p256verify, bn254 Groth16, Ristretto255, BLS12-381), new-storage fees, a sequencer with intents, sponsored intents and the forced path
✅ Upgrade signalling (version bits) is live on testnet and has started on mainnet

Next: the cEVM opens at block 80,640 (era 1, ~Nov 3, late UTC)
• Smart contracts on mainnet: the cEVM and its standard library
• Contracts with a sequencer and an admin; intents, fills and co-sequencing
• The sequencer directory, and the forced path when a sequencer is down

The full write-up of each fix follows now that the network has upgraded.

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

🔜 cEVM on mainnet: block 80,640 (~Nov 3)

[gabrielesor]

Hi shadow_69,

Thanks for your thoughtful feedback.

On point 4, I agree that reproducible block-production reporting could be one of the useful contributions of the Miner Seat.

Following your suggestion, I've developed and published ZBPO — Zycord Block Production Observatory:

https://zbpo-c698b5.gitlab.io/

It's an independent, open-source tool that reports block production by reward address over different time windows, with downloadable data, published methodology and source code. It doesn't claim to identify individual miners or measure their actual hashrate.

I see this as one possible tool supporting the Miner Seat's activities, certainly not as a complete definition of the role.

I'd be very interested in your opinion.

Beyond my original six questions, there's another issue I consider critical to clarify before finalizing the Seat mandates: the shared responsibility for the Treasury.

I understand why, in a small and emerging community like Zycord, it makes sense for each Seat holder to also act as a Treasury signer.

However, I see two fundamentally distinct responsibilities: the specific skills and duties required by each Seat, and the common responsibilities associated with authorizing and safeguarding Treasury operations.

I believe these shared responsibilities deserve an explicit, common section applicable to all five Seats, rather than being addressed separately in each role's charter. I have some ideas on how to structure it.

On point 5, I also believe the transition toward PoS will significantly change the nature of the Miner Seat. We should clarify how to handle this transition in relation to the proposed 12-month mandate, or the 6-month alternative suggested by kenyfran. In particular, the start of Era 2 and the eventual end of PoW are not necessarily the same event.

On point 6, I like your approach to transparency and disclosure.

On point 3, I like the idea of a lightweight feedback channel, although I think we should consider the needs of all miners, not just home miners. I'd like to think a bit more about the best way to organize it.

[darkko]

zycord explained youtube playlist, new video every week: https://www.youtube.com/watch?v=TRd1zgqqrjU&list=PLKKoLy1Y4l2s
zycord community x profile: https://x.com/zycord_stream

[shadow_69]

Thanks, ZBPO is exactly the kind of reproducible output I had in mind. I checked it against headers read from my own node and the numbers agree (AriaPool 44.7% over 29 Oct - 5 Nov).

One suggestion: add a short rolling window, e.g. the last 600 blocks or 24 h. The 7-day view averages away fast shifts. After rplant's share collapsed (about 19% of blocks a week ago, a few percent now), AriaPool went to 56-62% of the last 600 blocks around block 80,200, above 50%, while the 7-day figure still reads 44.7%. A simple flag when one address passes 40%/50%, or two addresses together pass 66%, would make that visible at a glance. Optional labels for pool addresses, checked against the blocks each pool publishes, would help readers too.

On the Treasury: agreed, a common section for all five Seats is better. It could cover key custody, the signing quorum and response times, recusal when a signer is the payee, and how a signer is replaced.

On point 5: since v0.7.0 ships Era 2 dormant with no schedule, I'd tie the Miner Seat's end to the end of PoW rather than to a date, with a review when bonding opens.

On point 3: agreed, all miners, not only home miners.

shadow_69