Bitcoin Forum
September 27, 2026, 03:43:12 PM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: [ANN][ZCD] Zycord | A P2P network of self-certifying state | Mainnet Oct 1  (Read 616 times)
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
August 30, 2026, 02:34:28 AM
Last edit: Today at 02:50:27 AM by thesimstoshi
 #1

ZYCORD

A peer-to-peer network of self-certifying state transitions

RandomX CPU proof of work · zero premine · zero admin keys · mainnet 1 October 2026

Website | Source | Whitepaper | Explorer | Downloads

Subscribe | Discord | Telegram

🟡 Mainnet: 1 October 2026, 00:00 UTC
🟢 Testnet: live since 15 September 2026, 00:00 UTC



⚡ REAL SCALABILITY
Born doing 90 transactions per second and grows, with real usage, past 1,000,000. No architecture swap along the way, no "sharding in 2029", no committee deciding. The engine that carries the top of that curve already runs today on an ordinary desktop — measured, and re-measurable by you.

⚙ PARALLEL cEVM — the first real one, in the genesis binary
Other chains parallelize execution inside each computer, but every computer still re-executes everything, all of them at once. Here the network itself is parallel: each machine verifies a share, none has to redo the others' work. Your Solidity contracts port with few changes — and the machine turns on at height 80,640, about four weeks after block 0, with no fork and no new binary.

🔒 PRIVACY AND FREEDOM
Payments with hidden value and a disposable address every transaction. Censorship resistance. A cEVM where heavy cryptography is usable in a way never seen before — ZKPs, post-quantum algorithms, schemes not yet invented. The network where the next decade's cryptography already has its seat reserved.

⚖ FAIR LAUNCH — actually, not as marketing
Zero premine, zero founder allocation, zero ICO, zero admin keys. Not one coin exists before block 0, and the only way to get one is to mine it on an ordinary CPU.



WHY MINE ZYCORD

▸ You enter at block 0 — and nobody entered before you. No premine, no allocation, no ICO, no admin key. The fairest launch a network can have: the only way to hold the coin is the same work that is open to you today.

▸ The computer you already own is competitive. RandomX mining — the same algorithm securing Monero — built for ordinary CPUs. No ASIC farm to crush you, no top-shelf GPU as the price of entry.

▸ 97% of every block goes to whoever secures the network. No halving cliffs: emission steps down smoothly, a tiny fraction per day, and after ~12 years becomes a perpetual tail — mining never stops paying. (The other 3% sits sealed in a treasury with no owner and no key, which only a future community can open — or nobody ever does.)

▸ Miners are not disposable here. When the network evolves to proof of stake, whoever mined and bonded their rewards from Era 0 gets priority in the first operator slots. On every other chain the miner is discarded at the transition. Here he becomes the backbone of the next phase.

▸ You are mining the right network early. The value of a chain that scales 12,000x without choking, runs the first genuinely parallel cEVM, and ships private payments is not in what it does today at 90 TPS — it is in who showed up before the rest of the world noticed. Block 0 is the earliest "before" there is.



HOW IT WORKS

Every fast blockchain today has a hidden ceiling. The more people use it, the bigger the machine every node has to be — until only a datacenter can keep up, and the "decentralized network" is half a dozen servers. That is not an engineering failure; it is the model. As long as every computer on the network must redo the work of all the others, growing means evicting the small.

What Zycord fixes: it breaks that coupling. Every transaction arrives with its own receipt stapled to it — it declares "I read this, I wrote that" and carries the proof. Checking whether it is valid never requires consulting the network's history: the transaction's own bytes are enough. And whatever depends on nothing else can be checked in parallel — a thousand transactions, a thousand cores, each checking its own, and it can even be accelerated on a GPU. The more machines join the network, the more verification capacity exists. For free.

Only one thing has to happen in a queue: writing the result into the ledger. After the parallel checking, one sequential step remains — walk the list and apply whatever still holds, skipping whatever conflicted. No signatures, no code execution, no cryptography: comparing and adding numbers in memory. A single core of an ordinary desktop handles the equivalent of 294,000 transactions per second at that step — 9.9 milliseconds against the ~2 seconds the parallel check takes, inside a 30-second block. The bottleneck that stalls every other chain measures under 1% of block time here.

And because checking and writing are different jobs, they carry different prices: two gas markets. Writing to the ledger — scarce, sequential — has one price. Verifying — abundant, growing with every core that joins — has another, far cheaper one. That is where everything in the pillars above comes from: the scaling without a choke point, the parallel cEVM, and cheap heavy cryptography. They are not four loose features — they are four consequences of a single decision.

Conflicts stall nothing: the late transaction is skipped and its insurance pays the bill — spam is expensive by construction. And the network is born proof-of-work so the launch is fair, migrating gradually to proof of stake with the first-hour miners at the front of the queue.



MEASURED ON AN ORDINARY DESKTOP

Code:
Sequential fold       883,000 ops/sec on ONE core (~294K certs/sec)
Block of 2,900 certs  ~470 ms to verify on 1 core, ~110 ms on 6 cores | 9.9 ms to apply
Parallel share        ~98% of block time

Reference implementation, ten-core x86, source published. Rebuild it, re-run it, and post your figures in this thread — including if they are worse.

The genesis network ships that capacity throttled to ~90 certificates/second on purpose. The ceiling is a consensus function of measured demand: it can at most double per year of full, healthy blocks, toward the structural ~1.1M/sec. No vote, no governance event, no lever for anyone to pull — and no way to raise it except sustained real usage.



SPECIFICATIONS

Code:
Ticker                  ZCD
Distribution            100% proof-of-work mined. Nothing else.
Algorithm               RandomX v2 (CPU)
Consensus               Proof of work, Nakamoto rules
Block time              30 seconds
Epoch                   2,880 blocks (~1 day)
Genesis block reward    21 ZCD
Emission                E(n) = max(tail, E(n-1) - E(n-1)/1054) per epoch
                        Rate halves every 2 years - exactly, no cliffs
Tail emission           0.33 ZCD/block, perpetual, from ~year 12
                        (height 12,602,880; ~0.55%/yr of supply, falling)
Supply at tail          62,744,838.47 ZCD scheduled
                        62,744,817.47 issued: genesis pays no coinbase
Premine                 None
Founder allocation      None
ICO / investor round    None
Admin keys              None
Treasury                3% of subsidy, sealed until Era 2
                        No key, no address, no quorum at genesis
Block size              2.5 MB at genesis, elastic
Genesis throughput      ~90 certificates/second, elastic
Certificate TTL         240 blocks (~2 hours)
BOND activates          height 40,320 (~day 14)
cEVM activates          height 80,640 (~day 28), same binary

No halving cliffs: the reward steps down once per epoch by a fraction too small for any single block to feel. The tail exists because security is a permanent expense. The 21 ZCD gap between scheduled and issued is the genesis block itself — a reproducible genesis must credit no address, so block 0 pays no one.



THE ERAS

Era 0: RandomX mining. Native assets — ISSUE, MINT, TRANSFER, RETIRE. Tips as a protocol primitive: ten thousand tips to one address in one block are ten thousand commutative additions, zero conflicts, zero skips. Every certificate self-insured, so you can transact with no counterparty from the first block.

Height 40,320 (~day 14): BOND. Stake can be bonded, so underwriters exist before anything needs them.

Height 80,640 (~day 28) — cEVM activated: the parallel cEVM with a delta-first standard library pre-deployed (Solidity ports at source level), bonded underwriters, application sequencers, forced-inclusion queue. Same binary as block 0; the heights are consensus parameters, not a release.

Era 1 — bonded stake ≥ 1% sustained: checkpoint finality.

Era 2 — height AND stake ≥ 10% sustained for 30 epochs: PoS block production; the PoW reward retires on a ~90-day ramp that pauses if finality stalls. Treasury opens under a 3-of-5 pinned by hard fork.

Era S — the shielded rail run on a public testnet with adversarial participation for a full stake window: confidential payments. It does not switch on before it is ready.



ON THE LAUNCH

I am not raising funds. There is no ICO, no sale, no reserved tokens. Nothing stays with the creator — I mine block 0 in the same queue as you. This network is being handed to the world, and what I want to build on top of it is not a treasury: it is a community that takes it further than I can alone.

Genesis is reproducible from the published source — the absence of privilege is not a promise, it is a line you check.

The mainnet date moved from September 15 to October 1. Two reasons, both public: the GitHub ban took the infrastructure and the open issues with it, and the cEVM moved up from six months after genesis to the first month. The date is announced ahead of time so block 0 is reachable by anyone who wants it.

On the treasury: 3% of every block subsidy accrues to a cell sealed until Era 2. At genesis there is no key, no address, no quorum, no emergency path. A premine is coins, an address, and a key that exist at genesis and belong to someone — genesis here contains none of the three. If no community ever arrives to pin a 3-of-5 by hard fork, the cell never opens and those coins are simply never issued. Whether that day comes is not the author's call.



COMMUNITY, DONATIONS, AND A REQUEST

I am an anonymous developer. I will launch this network and maintain it for as long as it takes — but it was designed from day one not to depend on me, and the goal is for the community to take over every part of it.

Donations fund development (Eras 0 and 1 are donation-funded only — public proposals, open budget, unspent amounts returned). I take no allocation and hold no privilege over any other user; these addresses are the only way I am paid for this work:

Code:
BTC: bc1q99k4mfydge2glhwa3wf2nmjwc67xrtfqjvygwc
ETH: 0x14825761bf3F2D53165F3aD6EbEFFECDbb33a097
ZCD: published after mainnet genesis

I am looking for volunteers to run community channels (Telegram, Discord, Reddit — community-run and explicitly unofficial, see the FAQ), translations, documentation, pools, and above all people willing to attack the design and publish what they find. Post in this thread.

Official announcements live here and only here, signed:
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29



SIGNED ATTESTATION

The facts an impersonator would alter — the donation addresses, the two keys and the canonical URLs above all — are pinned below and signed with the project key. Copy the block verbatim (it sits in a code box so the forum preserves it byte for byte) and run gpg --verify on it. If a repost of this announcement anywhere shows different addresses, keys or domains, this block is what proves which set is real.

Code:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ZYCORD — OFFICIAL LAUNCH ATTESTATION
Simstoshi

Ticker: ZCD
Testnet genesis: 2026-09-15T00:00:00Z
Mainnet genesis: 2026-10-01T00:00:00Z

Both instants are the genesis_time in the published parameter file. They are
consensus values, not announcements: a node that disagrees is on a different
chain.

Project key (this thread, every official post, and the signed parameter files
of testnet and mainnet):
E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Release signing key (binaries and their checksums):
2502 9C31 5866 306F 7C6D 4DE6 FAE9 8B03 332F 089A

Canonical locations. Anything outside this list is not this project:
Site: https://zycord.com/
Source: https://zycord.com/source/
Releases: https://zycord.com/releases/
Whitepaper: https://doi.org/10.5281/zenodo.22167490
Explorer, testnet: https://testnet.zycord.com/
Explorer, mainnet: https://explorer.zycord.com/

Donation addresses. These are the only two. There are no others, in any
currency, on any platform:
BTC: bc1q99k4mfydge2glhwa3wf2nmjwc67xrtfqjvygwc
ETH: 0x14825761bf3F2D53165F3aD6EbEFFECDbb33a097

There is no ICO, no presale, no token sale, no premine, no founder allocation,
and no admin key. Nobody is authorised to collect funds on behalf of this
project. Any address that is not one of the two above is fraudulent.

No official chat channel exists on any platform. Community channels are
community property and are not official. Every official announcement is a post
signed with the project key above; anything else is fraudulent regardless of
where it appears or who appears to be saying it.
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTnJDnO3YUR+dYHVQuH/WDV60oLKQUCaqINmwAKCRCH/WDV60oL
KX1bAQCOF9H+9/tgEWWG2MFYZJBIai4t6DmFcRQCWJF5lq46tgD/QBZAUUw2SutU
BB0nH2wakRU+JUhgwZcmzQhDG1AkdgA=
=C0K+
-----END PGP SIGNATURE-----



Vires in numeris. Strength in numbers, not in name.

— Simstoshi
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 02, 2026, 02:21:47 AM
 #2

Zycord devlog — Aug 29 → Sep 1
Four days since launch:

✅ Mining works on Windows x86-64 and Intel macOS — the RandomX archive was never being published
✅ Miner waits for genesis; testnet seed node is up
✅ Full update mechanism: signed manifest (ed25519, with key rotation), zcd update, atomic binary replacement. The node asks the operator once (default: notify only) and never asks a machine — systemd, Docker and cron are off by construction
✅ Build provenance instead of a release signature
✅ Debian package with a systemd unit (not enabled for you)
✅ We only publish binaries that can join a network — install.sh, Homebrew and Scoop were all handing out a node that refuses mainnet and testnet
✅ Site: full documentation (10 pages) and a downloads page that resolves the newest release in the browser
✅ Issue templates for attack findings and benchmarks

thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 05, 2026, 05:48:41 AM
 #3

Zycord devlog — Sep 2 → Sep 5

⚠️ We took an unfair GitHub ban: our tests compute RandomX hashes to check the result against the expected one, and the platform read that as mining. Account suspended, repositories offline mid-launch. We rebuilt everything at a new home.

✅ Migrated to RandomX v2, on the community's recommendation — and with it the three consensus fixes stock XMRig needed: reading the digest little-endian (the way every pool and every miner in the Monero ecosystem reads it), a 43-byte blob with the nonce at offset 39, and the target compared against the commitment rather than the raw hash
✅ Stratum endpoint — unmodified XMRig mines here as-is. Solo: every share is checked against the full network target, and whoever finds the block is paid by consensus
✅ Testnet relaunched (twice; new genesis at 2026-09-04 13:00 UTC) because of the algorithm change
✅ Desktop wallet rebuilt: new layout, black screen fixed, syncs before showing balances, mines from Settings. It now runs its own node — nobody to choose to trust
✅ Adversarial audit round (consensus, p2p, RandomX, services, transactions), with the defects found fixed and the reasoning published
✅ Explorer: testnet faucet and pagination
✅ Site: a "How the network works" page, a favicon, the faucet, and documentation fixes
✅ Public genesis go/no-go checklist — if a measurement says a genesis value is wrong, the date moves, and that is a signed post

Mainnet genesis: Sep 15. There is no coin yet.
Argenttenir
Newbie
*
Offline

Activity: 9
Merit: 0


View Profile
September 06, 2026, 08:31:49 PM
 #4

I'm looking at mining Zycord from genesis with an EPYC and some gaming rigs, so I'm interested in the project from a miner's perspective.

I understand the technical thesis around self-certifying state, parallel verification, the EVM, privacy, and eventually PoS. But I'm trying to understand the endgame from an economic/user perspective.

What is the reason someone would actually want or need ZCD once the network is live?

In other words, what do you see creating organic demand for the coin beyond miners accumulating it because it is a new fair-launch PoW coin?

I'm also curious about the transition from PoW to PoS. It says early miners who bond their rewards get priority for the first operator slots. What exactly are those operators going to do, and what economic incentive will they have?

I'm asking because I've mined a lot of small/new PoW's, and I've seen the pattern where miners accumulate the coin early, a market eventually appears, and the miners themselves become most of the initial sell pressure. What is Zycord  designed to become beyond the initial mining phase.

Thanks — I'm genuinely interested in the technical side and would like to understand the long-term use case before committing hashpower.
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 07, 2026, 03:36:07 AM
 #5

Thank you for the question.

The focus is on those who currently pay high fees to verify ZK proofs, rollups, bridges, and high-volume applications: streaming payments, reward accounting, high-frequency mints.

I'm particularly eager to build an orderbook DEX. Something that's too complex on EVM and forces simplifications like the pool model.

As for operator incentives. Zycord has two fee markets, sequential gas (ledger writes) and parallel gas (verification). The block producer receives the subsidy plus priority fees from both markets, charged only on certificates that apply; base fees are burned.

In Era 1, those who bond with the coinbase can also attest checkpoints and receive a share of the subsidy for that.
In Era 2, miners who have been bonded since Era 0 get priority in the first sequencer rotations, the business of packaging N transactions into one certificate and charging users a margin. It's access to that business, not extra coins.

I've been working on this project alone for years. And I'm finally showing it to the world, so I'm still figuring out how to explain it. If you have any more questions or anything wasn't clear, don't hesitate to ask.
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 10, 2026, 12:53:05 AM
Last edit: September 10, 2026, 11:02:31 PM by thesimstoshi
 #6

Zycord devlog — Sep 5 → Sep 10

⚠️ Mainnet genesis moves from September 15 to October 1. Testnet is relaunched on the 15th.

The GitHub ban took the infrastructure and the open issues with it — work that was already mapped out had to be rebuilt from scratch, and that cost us the schedule. We migrated the code to Codeberg, but their policy does not accept crypto projects; we are migrating again, this time to GitLab.

✅ RandomX v2 validated
✅ XMRig mines here, validated and tested end to end
✅ Node sync: problems identified and fixed
✅ Desktop wallet: improved interface
✅ Testnet test round validating the system working as a whole
✅ Explorer: the faucet actually works now (it did not before)
✅ Site: improvements

🔜 cEVM moved up to Era 0. The FAQ in this thread says there would be no contracts at launch, and the reason was the usual one: with no admin key there is no pause button, so everything that ships in genesis has to be auditable in full. That reason has not changed — what changed is that the cEVM came further along than expected, and it came without giving up quality or security. It enters Era 0 because it reached the standard genesis demands, not because the standard was lowered.

In practice: you can write, test and run contracts from the start of the network — real use for the token, and the door open to anyone who wants to build an application in here from day one.
HashCaliber
Newbie
*
Offline

Activity: 28
Merit: 0


View Profile WWW
September 13, 2026, 07:18:09 PM
 #7

Hello,

I would like to email interview you about Zycord for my website https://hashpower.site. I have a short list of questions and it would appear on the website as an interview with the Developer. Let me know if you're interested.

Thanks!

admin@hashpower.site
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 15, 2026, 03:55:54 AM
Last edit: September 24, 2026, 07:41:22 PM by Welsh
 #8

I'm happy to take part. I'll get in touch.  Smiley
Zycord devlog — Sep 10 → Sep 15: the public testnet is live

The testnet restarted at block 0 on 15 September 2026, 00:00 UTC, and it has been producing blocks every 30 seconds since. Watch it at https://testnet.zycord.com. Coins there are worth nothing, on purpose.

What it is for: this network carries mainnet's consensus rules, gas schedule and emission curve, so what it measures is mainnet's behaviour. It differs only in the values a network with no hashrate on day one needs, and in two heights moved forward so that everything mainnet reaches at day 14 and day 28 runs here first:

Code:
BOND opens        height 2,880  (~16 Sep, 00:00 UTC)
cEVM opens        height 8,640  (~18 Sep, 00:00 UTC)
Mainnet genesis   1 Oct 2026, 00:00 UTC — unchanged

From the 18th you can deploy and call contracts on a public network two weeks before mainnet exists.

Join it

Downloads: https://zycord.com/download/ — release v0.3.1.

The desktop wallet runs its own node and mines from Settings. Testnet coins without mining first: https://zycord.com/faucet/

Shipped since the last devlog

✅ v0.3.1 published, built and signed by the release job rather than by hand.
✅ Engine archives (RandomX) for linux-amd64, linux-arm64 and windows-amd64, beside the Linux packages and the Windows wallet, all of which carry the engine. macOS builds on the Mac, from the signed source tarball, with install-macos.sh.
✅ Wallet: a 24-word recovery phrase; a new one-shot address for every payment received, generated on demand; change returned to fresh one-shots of your own; the mining payout rotates across addresses after a random number of rewards. No address shares a key with another.
✅ Wallet as a signer: a site hands the wallet a zycord: request, the wallet re-derives it against your own node, shows what will move, you approve.
✅ Contracts from the wallet: panels for the standard library (token, tip jar, escrow) and a curated dapp list that opens in your browser.
✅ Network services from the wallet: bond, register as an underwriter, name a sequencer for a contract you deployed. A node started with --underwrite advertises itself over the network and co-signs certificates for a price; a wallet whose address holds too little to pay a fee finds one and pays through it.
✅ Site: the download and releases pages no longer hold a stale copy of the release list.
HashCaliber
Newbie
*
Offline

Activity: 28
Merit: 0


View Profile WWW
September 17, 2026, 10:54:08 PM
 #9

I see you have no Telegram, X, or Discord. Would you like help to set that up?
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 18, 2026, 03:53:47 AM
Last edit: Today at 01:36:18 PM by Welsh
 #10

I see you have no Telegram, X, or Discord. Would you like help to set that up?

Please help me with this. I’ve even tried creating it, but I get blocked because my account is new—due to anonymity rules.
Zycord devlog – Sep 15 → Sep 18

cEVM is open on the testnet since height 8,640. Deploy and call contracts at https://testnet.zycord.com

✅ v0.3.2: https://zycord.com/download/
✅ Contract calls can pay an underwriter from prepaid credit: a plain transfer to the service, spendable two blocks later
✅ Services price by gas (flat + seq rate + par rate) instead of one price per certificate
✅ zcd wallet call --via-underwriter auto picks the cheapest service and tops up your credit when it is short
✅ Desktop wallet can offer the co-signing service from Settings
✅ Wallet: activity log, address names, history rebuilt from your own node

⚠️ Upgrading: --underwrite-price is replaced by --underwrite-flat/-seq-rate/-par-rate, and v0.3.1 nodes do not see v0.3.2 service cards. The desktop wallet starts with fresh settings and a fresh sync; your old folder is left untouched.

🔜 Mainnet genesis: 1 Oct 2026, 00:00 UTC.
darkko
Newbie
*
Offline

Activity: 3
Merit: 0


View Profile
September 19, 2026, 04:28:40 PM
 #11

already installed and mining the testnet.

keep me updated if it possible

darkko
Newbie
*
Offline

Activity: 3
Merit: 0


View Profile
September 19, 2026, 04:37:46 PM
 #12

if you need to test sending coins in the testnet here is my address:

0x010fa389d95646788e210996275087f13c3deca1f43706952c1dfc01b6fe20ea
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 19, 2026, 05:29:32 PM
Last edit: September 24, 2026, 07:40:34 PM by Welsh
 #13

if you need to test sending coins in the testnet here is my address:

0x010fa389d95646788e210996275087f13c3deca1f43706952c1dfc01b6fe20ea

You can receive coins from a faucet on the testnet to test.
https://testnet.zycord.com/faucet/

already installed and mining the testnet.

keep me updated if it possible



I liked the request! I will create an email list for anyone interested in the project. I will send project updates to subscribers.

https://zycord.com/subscribe/
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 21, 2026, 01:22:04 AM
Last edit: September 22, 2026, 03:52:13 AM by thesimstoshi
 #14

Validating the Zycord thesis on testnet

The Zycord whitepaper makes a number of claims that were, until now, only a thesis. We tested all of them on the public testnet: 30-second blocks, third-party miners, nothing staged. We finally got to prove that what is in the whitepaper works. It is a milestone for the project.



1. Payments to the same destination do not conflict

Independent wallets paying the same recipient at the same time. On any other blockchain that turns into a queue; here the credit is declared as a commutative delta, so order does not matter and nothing gets skipped.

Native payments (no virtual machine):

paymentsappliedskipsblock
9999015489
150150015504

Smart contract calls (cEVM, the pre-deployed TipJar):

callsappliedskipsblock(s)
250250014478
500500014483
10001000014489
20002000014493 · 14494 · 14495
40003467*014499 · 14500 · 14501 · 14502

Open block 14489: applied 1000, skipped 0. A thousand contract executions, from a thousand wallets, crediting a single account in a single block.

* 533 never reached a miner. Our measurement node has a single peer; that is a limitation of our setup, not of the network.



2. Two fee markets, priced independently

Blocks 14499, 14500 and 14501 carry identical gas: 1,127,000 sequential (35% of the limit) and 9,599,786 parallel (99.998% of the limit). Since the gas is the same, the variation in the burn is only the base fee:

blockburned (ZCD)sequential baseparallel base
144990.7508750277
145000.8468728878
145010.9428707479

Each step is exactly 9,599,786 drops, the parallel gas. The parallel market was at its ceiling and its price went up; the sequential one was below target and did not move. Heavy verification work filled one lane without making a single simple payment more expensive. A single-market blockchain cannot do that.

The parallel lane has triple the capacity of the sequential one (9.6M against 3.2M gas per block). That is where verification lives, and it does not compete with state mutation.



3. Built off-chain, published on-chain

A Zycord certificate carries its own inputs and outputs. Look at this tip: the declared reads and writes are in the certificate. Execution happened before publication, on the sender's machine. The miner ordered bytes and executed nothing. The 1000 calls in block 14489 were built, signed and submitted from a single laptop in 4.1 seconds.

One transaction, two accounts. Paid by the service:

native paymentcontract call
burn, sequential market13,3008,400
burn, parallel market27,44065,086
priority tip to the miner209,600166,490
network fee250,340239,976
service price276,040263,576
service share+25,700 (+10.3%)+23,600 (+9.8%)

(in drops; 1 ZCD = 100,000,000 drops; base fees 7/7 at the time)

Two markets, one certificate. The registration market belongs to the protocol and is on-chain: burn plus miner, measured in two gases (sequential for state mutation, parallel for verification). The construction market is free and off-chain: whoever builds and co-signs publishes their own price, and the market disciplines it through supply and demand. Registration is scarce by design; construction is abundant because it runs on ordinary servers, outside consensus.

native paymentcontract call
Parallel gas25,700 (9.3%)23,600 (9.0%)
Sequential gas250,340 (90.7%)239,976 (91.0%)
Total paid by the user276,040263,576

The service price is a published formula, "fixed + rate × sequential gas + rate × parallel gas", evaluated over the gas of each certificate and paid out of credit pre-loaded with the service, off-chain. The fold charges the network fee to the service's bond, and the service recovers it plus its own margin. The network fee and the builder's price never share a ledger line. Both are in block 15985, where the explorer lists the service's bond address as underwriter: the contract call and the native payment.



4. The counterpoint: a contract written the traditional way

To show what happens without deltas, we deployed a tip jar written the way it would be on any other blockchain: read the balance, add, write (contract). We sent two tips to the same recipient in the same window. One applied; the other was discarded by the network with the exact reason: expected 0, the cell holds 1,000,000.

That is the whole difference in one line: with exact reads, two certificates already collide. With deltas, a thousand did not.

Then we registered a sequencer for that same contract. The sequencer is an ordinary HTTP server, bonded on the network. The contract writes its key on-chain and, from that point on, every certificate that touches the contract needs the sequencer's co-signature. The service checks each certificate against the state that the certificates already queued will leave behind. If the certificate arrived with stale values, the service does not sign: it returns it to the sender with the correct values, and the sender rebuilds it.

We made four calls in sequence, the first one deliberately with the wrong value:

calldeclared valueservice responseblock
1424,242 (wrong) → 2,000,000stale value; the correct one is this → rebuilt and signed15987
23,000,000signed15989
34,000,001signed15991
45,000,003signed15994

Result: the same contract that discarded one of two tips without a sequencer applied all four with one. None was charged for a collision, and the attempt with the wrong value cost nothing, because it was never signed in the first place. The sequencer turned collision into a queue, and the queue is managed off-chain, on an ordinary server. Certificates: 1 · 2 · 3 · 4.



What this means

Bitcoin, 2017. One auction for one single block. When the blocks filled up, paying for a coffee competed with an exchange's arbitrage and lost; the fee went past US$50 and the answer was a years-long fight over a constant. The Zycord block has two lanes, and sequential capacity follows measured demand: bounded growth, no voting. Blocks 14499–14501 are the "two lanes" half of that, measured; the elastic ceiling is in genesis and needs epochs of full blocks before it shows up.

Ethereum's open problems. Every node re-executes everything, so the cost of running a node grows with usage. Here execution leaves the consensus path: the sender executes once, the network verifies bytes in parallel, and the fold is a loop over memory. A transaction that fails pays anyway; here a stale certificate is skipped and the sender's balance is never touched (a withdrawal above the balance was refused before it reached a block). Hot contracts serialize; here the author declares, slot by slot, what commutes. MEV leaks to whoever produces the block; here the application registers its own sequencer, and a user who does not like it has a forced path that guarantees application, not just inclusion.

Why it is safer, and not just faster. The producer cannot be induced into an invalid block: a stale certificate is skipped, it is not fatal. Every conflict has a bonded owner, so spam costs the spammer. The security-critical surface is the fold: compare, add, write, specified in a single page. Checked arithmetic: a delta that would overflow the limit is skipped instead of wrapping around.



Where the economy is

In Eras 0 and 1 everyone self-funds; the construction market above is live, but it is priced by whoever operates it, and nobody is paid by the protocol for sequencing. That is deliberate: the market economy starts sustaining the network once verification is sampled (whitepaper §9) and the underwriter's attestation is what lets nodes skip work. We measured the mechanism; the economy belongs to a later era.

The testnet is open: mine, run a node, repeat the test.
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 22, 2026, 04:01:11 AM
 #15

I am very happy with the results of the post above. I am very pleased with the feedback I have been receiving from the people who are analyzing the project. This is very important to me.

And I am even happier with the people who are sharing the project.

For me, this last validation on the testnet was very important because it shows the network really has the potential to be disruptive. I keep working and improving the project every day.

Thank you all!  Grin
andremangra
Newbie
*
Offline

Activity: 4
Merit: 0


View Profile
September 23, 2026, 09:50:30 AM
Last edit: September 23, 2026, 11:25:10 AM by andremangra
 #16

Hi,
I'm really interested in your project!  Smiley

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
HashCaliber
Newbie
*
Offline

Activity: 28
Merit: 0


View Profile WWW
September 23, 2026, 12:06:11 PM
 #17

As requested, by the Developer themselves, here is a link to a Developer Interview that they recently did with my website. Check if out to learn more about this project as well as learn a little bit about who the developer is. A rare opportunity.
https://hashpower.site/2026/09/23/zcd-developer-interview/
andremangra
Newbie
*
Offline

Activity: 4
Merit: 0


View Profile
September 23, 2026, 01:15:35 PM
 #18

As requested, by the Developer themselves, here is a link to a Developer Interview that they recently did with my website. Check if out to learn more about this project as well as learn a little bit about who the developer is. A rare opportunity.
https://hashpower.site/2026/09/23/zcd-developer-interview/

Thanks for sharing this — very interesting interview, especially the background on why Zycord is starting with PoW and the longer-term transition toward PoS.

I've been spending some time going through the documentation and source code as well, trying to better understand the architecture and prepare for mainnet. There are some genuinely interesting ideas in the design, particularly around certificates, parallel verification and scaling.

A few technical questions came up during the review, and I've started raising them on GitLab so they can be discussed in the appropriate place.

Looking forward to following the project and seeing how things develop as we get closer to October 1.
thesimstoshi (OP)
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
September 23, 2026, 07:14:15 PM
 #19

Hi,
I'm really interested in your project!  Smiley

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.
andremangra
Newbie
*
Offline

Activity: 4
Merit: 0


View Profile
September 24, 2026, 07:17:04 AM
 #20

Hi,
I'm really interested in your project!  Smiley

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
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!