myzclthesis.
EnglishEspañol
Mining pool ↗

OUR POOL · ZCLASSIC · PROOF OF WORK

ZCL Thesis
Mining Pool.

Put your GPU to work for Zclassic. Open the pool dashboard for current status and connection details, or try the browser GPU miner.

ZCLASSIC · 2016 VINTAGE

of proof-of-work history. A real L1 with roots.

Why history matters: the Lindy effect ↓

0.8% pool fee20% lower than a 1% pool fee.

Open pool dashboard Open GPU browser miner

Check the dashboard’s live admission status before connecting a miner.

ZCL mined by our pool

Block rewards earned by ZCL Thesis Pool.

Total mined
ZCL

Recorded pool history

Last 24 hours
ZCL

Rolling 24-hour window

Last hour
ZCL

Rolling 60-minute window

Gross block rewards, including transaction fees, before the 0.8% pool fee. Immature rewards are included and shown separately; maturity requires 101 confirmations. Totals are not wallet balances or payouts. Time windows use when the pool recorded each block. Refreshes every 30 seconds while visible.

ZCL MARKET CAP · SINCE SITE LAUNCH

Site launched:

LAUNCH REFERENCE · USDUSD 3,086,200

Reference: September 12, 2026, 03:20 UTC

CURRENT MARKET CAP · USD

Waiting for the source…

GAIN / LOSS SINCE LAUNCH

Change in market capitalization

Fetching the current CoinGecko market cap…

CoinGecko source ↗

The fixed reference is CoinGecko’s last five-minute observation before this site went live at 03:23 UTC. Current data refreshes every five minutes while the page is visible.

LATEST REPORTED BLOCK

Loading explorer data…

Zelcore explorer ↗
NONKYC · ZCL / USDT

Loading NonKYC’s last traded price…

Where to buy ZCL ↓
ZCLASSIC CHAIN AGE

Launched November 6, 2016.

2016 vintage · The Lindy effect ↓
NETWORK & MARKET

Refreshes every minute while this page is visible. USDT is the quote asset; this is one exchange’s last trade, not a guaranteed execution price.

Live ZCL transactions ↗ · Pool stats ↗

Checking sources…

Rich list & dormant coins ↓

ZCL vs Zcash market caps ↓

NONKYC · ZCL / USDT · SINCE SITE LAUNCH

Observed market volume.

Site launched:

TRADED VALUE · USDT
TRADED AMOUNT · ZCL
OBSERVED TRADES

Hourly volume · UTC · USDT

Only exchange-reported NonKYC ZCL/USDT trades we have collected; each trade is counted once. Gaps may understate totals. USDT is the quote asset, not USD. The totals cover activity since this site launched and do not measure activity caused by the site. Refreshes every minute while visible.

AN INDEPENDENT INVESTMENT THESIS

Privacy needs
an exit option.

Zclassic is a native Layer 1 privacy coin with its own proof-of-work blockchain and roots in 2016. I see an overlooked network worth rediscovering as a credible exit option. My case has two independent parts: preserve PoW and make protocol-funded development earn its cost.

Read the thesis

The history is real. The rediscovery thesis is mine.

01 / PRIVATE MONEY02 / PROOF OF WORK03 / CREDIBLE EXIT

01 / THE STARTING POINT

First, the case
for private money.

Read Frank Braun’s original essay ↗

Frank Braun’s July 2025 thesis argues that Zcash could benefit if demand for financial privacy grows.

He connects private wealth storage and commerce to demand for privacy coins, arguing that longer-term shielded holdings and better wallet usability could reinforce adoption. His investment case also considers issuance, competition, and execution risk. [1]

Where my argument begins

Braun’s essay makes a case for ZEC. The ZCL counterweight thesis on this page is my own extension; it is not an endorsement by Braun.

02 / MY ZCL THESIS

A credible alternative
makes consent matter.

My reason for taking a ZCL position is to support an outside option. I want the Zcash Foundation and the wider ecosystem to face a real market consequence if they pursue proof of stake against the preferences of PoW supporters. Crosslink is the concrete proposal I discuss below: a hybrid that keeps PoW mining and adds stake-based finalization.

01

Keep the option alive.

Zclassic describes itself as a community-driven Zcash fork secured by proof of work. That gives this thesis a concrete starting point. [2]

02

Make exit credible.

My hypothesis: users, miners, and builders having somewhere viable to go could make a controversial consensus change less attractive.

03

Turn choice into pressure.

A ZCL position expresses my preference for PoW. For that signal to matter, it must be accompanied by useful software, security, adoption, and liquidity.

This part of my thesis concerns consensus: keeping PoW a credible choice. What PoW and PoS actually put at risk is explained next. The separate funding argument below asks how development should be paid for. Progress on one does not settle the other. The case for Crosslink’s hybrid design deserves its own hearing.

THE BASICS / PROOF OF WORK AND PROOF OF STAKE

What actually
goes at risk?

Proof of work (PoW) and proof of stake (PoS) help a network agree on its transaction history. They use different resources to make influence costly. Neither mechanism, by itself, specifies a supply cap or a development-fund reward.

On a small screen, scroll the comparison sideways.

Two security models, different economic commitments
The questionProof of work · PoW [13]Proof of stake · Ethereum example [14]
How is influence earned?Miners compete to find valid proofs using computing power. Nodes verify the work; competing valid histories are ranked by accumulated work.Validators commit coins. The protocol weights participation by stake; Ethereum uses validator proposals and attestations to select and finalize blocks.
What can be lost?Electricity is spent whether a miner wins or loses. Equipment and operations cost money; rejected or orphaned work may earn nothing.Deposited coins are collateral. Conflicting signatures can cause slashing: destruction of part or all of the stake. Missed duties can cause separate penalties. [15]
What happens to the capital?Equipment may retain resale value; electricity already consumed cannot be recovered. Ordinary PoW does not confiscate a miner’s existing coins.Honest operation can preserve the deposit while earning rewards. The capital still faces the coin’s price risk, withdrawal delays, and protocol penalties.

Agreeing on blocks does not grant a blank cheque

Miners and validators operate within rules that nodes check. More computing power or stake does not make an invalid reward valid. Changing issuance requires adoption of changed protocol rules. In Ethereum, validator votes about blocks are distinct from governance: protocol changes use an off-chain process involving multiple groups, not a simple one-coin-one-vote ballot. [16]

Why I still prefer PoW

I prefer making block producers keep paying for resources outside the coin itself. Existing coin ownership alone does not earn the right to produce PoW blocks. PoS puts real capital at risk, but compliant validators can keep that capital and receive recurring issuance. My concern is how that reward relationship shapes the people defending monetary policy.

Slashing addresses specified consensus violations, such as signing conflicting histories. Advocating a protocol change that increases issuance is not itself a slashable act. Having coins at risk therefore does not guarantee opposition to inflation. [15] Who receives the new coins matters too ↓

NATIVE LAYER 1 · PROOF OF WORK SINCE 2016

Since 2016.
That is part of the charm.

Zcash

Zclassic

Zclassic is nearly as old as Zcash. Its published launch date is just nine days later.

Zcash’s v1.0.0 release, dated October 28, 2016, included its mainnet genesis block. Zclassic dates its Equihash PoW mining history to November 6, 2016. ZCL is the native coin of its own privacy blockchain, with its own miners, consensus rules, and a public history of blocks and transactions. [12] [2]

The Lindy effect

The Lindy effect is the idea that, for some enduring technologies and ideas, surviving longer can point to a longer expected remaining life. Time gives us a history to examine. Taleb’s explanation ↗

That is part of ZCL’s appeal to me: a privacy chain with proof-of-work history stretching back to 2016. Its age is part of its charm and a reason to revisit an overlooked L1. Applying the Lindy effect here is my thesis, not a measured forecast of the chain’s remaining life. Hashpower, security, adoption and future returns still need their own evidence.

I like Zcash. I find ZCL’s reward structure fairer.

I value the privacy research and engineering behind Zcash. My fairness argument is narrower and explicit: I prefer a network where the block reward goes to the miners doing the work, without a protocol-enforced founders’ or development allocation. Zclassic’s stated model fits that principle. This is my judgment about the rules, not a claim that every ZCL holder has equal wealth or that development costs disappear. [2]

SMALL MARKET CAP · A CASE FOR REDISCOVERY

A small-cap Layer 1.
A case for rediscovery.

Loading ZCL and ZEC market capitalizations…

My thesis: the market may have overlooked a genuine privacy Layer 1 with real proof-of-work history.

Not a memecoin. A native privacy chain.

ZCL has its own blockchain, miners, and a purpose: private money secured by proof of work. What interests me is the possibility of rediscovery. I see a largely forgotten, small-cap network whose history and role as a Zcash exit option deserve a fresh look. That is the opportunity I am investigating.

A smaller market cap does not establish mispricing. Adoption, liquidity, development, and security can justify very different valuations. The live comparison makes this thesis measurable; it does not establish a price target.

03 / COMPETE THE REWARD DOWN

Funding should
earn its place.

I want competition to push protocol-funded rewards toward the minimum needed to deliver work users actually value.

Funding and consensus are separate choices

A development allocation decides who receives part of the subsidy. PoW, PoS, and hybrid finality designs decide how the chain is secured and which history becomes final. Zcash can retain PoW while reducing its development allocation; a PoS network could also have no development fund. Cutting funding neither prevents PoS nor follows automatically from keeping PoW. [5] [8]

My preference for a smaller mandatory development allocation stands independently of my preference for PoW. A ZCL position may support both preferences, but they are different claims.

A development organization should have to justify its cost, just as any other service provider does. When funding is embedded in consensus, a dissatisfied holder cannot simply cancel that allocation while continuing to use the same rules. Their alternatives are to persuade the network to change the rules, accept the arrangement, or leave.

A credible ZCL alternative could make leaving a meaningful choice. If users, capital, miners, and builders prefer a network without the same development allocation, that gives Zcash’s funding recipients a reason to ask for less, explain their budgets, and demonstrate why their work is worth supporting. The pressure would be strongest if useful work can be sustained with smaller allocations or voluntary funding.

This is what I mean by competing the reward down: make the cost of institutional funding visible and contestable. Buying ZCL does not mechanically lower a Zcash funding percentage. It supports the outside option that could make a lower percentage politically and economically attractive.

Which reward, and whose cost?

The original Founders’ Reward and later development funds are different arrangements. ZIP 214’s historical Canopy allocation included 5% of the subsidy for ZF; subsequent revisions define different recipients. I use “foundation reward” here as shorthand for protocol-directed institutional funding, not a claim that ZF currently receives the entire development allocation. [5]

With total subsidy unchanged, reducing an institutional slice reallocates coins to other recipients, such as miners. It does not by itself reduce issuance or holder dilution.

Zclassic describes its block rewards as going entirely to miners. That makes it a useful point of comparison, but it does not establish equal security, privacy features, or maintenance quality. A cheaper alternative must still work. [2]

04 / THE INCENTIVE TO DO SOMETHING

Restraint is
a deliverable.

An organization expecting recurring funding can feel pressure to produce a continuing roadmap.

My concern is an incentive mismatch. A funded organization must explain its budget, retain staff, and demonstrate progress. New protocol features produce visible milestones. Keeping a sound monetary rule unchanged produces fewer announcements, even when that restraint is more valuable to holders.

This concern applies under either PoW or PoS; it does not establish that funding causes a move to staking. Zcash’s specified development-fund periods have end dates, even if recipients may seek renewal. [5]

That can create a cycle: a budget supports a team; the team needs a roadmap; the roadmap proposes protocol changes; those changes create new implementation, audit, and maintenance work that supports the next budget. Nobody has to act dishonestly for this incentive to exist. This is my institutional critique, not evidence of any particular person’s motive.

For monetary rules, my starting point is continuity. Every change should overcome the costs of implementation risk, coordination, and weakening expectations that the rules will stay put. When the claimed improvement cannot clear that bar, leaving the protocol alone is the better outcome.

Doing nothing to issuance does not mean abandoning the software. Fix vulnerabilities, maintain nodes, improve wallets, and fund careful audits. Judge that work by user benefit and reliability, rather than the number of consensus changes shipped.

05 / CASE STUDY: ISSUANCE SMOOTHING

A smoother curve
is not enough.

Read ZIP 234 ↗

For issuance smoothing, my preference is to leave the established monetary schedule alone.

This is a third question: when coins are issued. It is distinct from who receives them and from how consensus works. Issuance smoothing does not, by itself, introduce PoS or determine a development-fund percentage.

ZIP 234 is marked Draft in the text reviewed September 12, 2026. It proposes replacing stepped halvings with a subsidy calculated from the remaining money reserve, retaining the stated 21-million cap. It also enables future reissuance of funds deliberately removed from circulation through the NSM. Its authors argue this could soften mining-revenue shocks and support long-term security. [6]

Those are the benefits the proposal needs to establish. My objection is that the cap is only one part of a monetary commitment: the timing and conditions of issuance matter too. A familiar schedule gives holders and miners a rule they can plan around. Changing it spends some of that predictability and sets another precedent for revisiting monetary policy.

A smoother revenue path may appeal to miners and, wherever funding streams receive a share of the subsidy, to those recipients as well. That creates a reason to examine incentives; it does not prove that smoothing increases an organization’s total funding or that its authors proposed it for personal benefit.

In my assessment, retaining the existing schedule is better unless proponents show that the security benefit outweighs the implementation and credibility costs. An institution needing a new project is not a reason to change the money. A credible PoW alternative can reinforce that boundary by giving people who value restraint somewhere else to go.

Deliberate removal is different from lost keys

ZIP 233 provides an explicit mechanism for removing funds from circulation. A balance whose keys are lost does not become an NSM deposit merely because it is dormant. The rich-list research described below would not justify treating inactive coins as available for reissuance. [7]

INCENTIVES / FOLLOW THE NEW COINS

Owning coins does not
erase self-interest.

Ethereum and the “ultrasound money” narrative ↓

A passive holder, a holder earning staking rewards, and a business charging staking fees do not have identical interests.

My concern is that recipients of new issuance can support more of it when they expect their rewards to outweigh dilution of their existing balance. A passive holder receives no such offset. Where coin voting exists, that difference can influence votes; where governance is informal, it can influence advocacy and which upgrades people support. Ownership creates an incentive to protect a coin’s value, but it does not eliminate the incentive to seek a larger share of its rewards.

A simple dilution example

Imagine 100 coins in total, with 50 staked. Issue 10 new coins entirely to stakers, proportionally, with no burn or costs. A person staking 1 coin receives 0.2 more: their share rises from 1/100 to 1.2/110. A person holding 1 coin without staking falls from 1/100 to 1/110. This illustrates relative ownership, not a dollar profit or Ethereum’s actual issuance rate.

That is a possible incentive, not a prediction that every holder or staker will favor inflation. Higher issuance can attract more competing stake, dilute existing coins, increase costs, or undermine the price. Miners can lobby for larger subsidies too. PoW does not remove the need for users to defend monetary rules.

Ethereum researchers Ansgar Dietrichs and Caspar Schwarz-Schilling make a related distinction in their February 2024 staking-economics analysis: holders and stakers bear dilution, while service providers earn fees from operating staked positions. They also warn that a higher nominal yield need not produce a higher dilution-adjusted return. Their proposal is analysis, not a claim about adopted policy. [17]

Ethereum and the “ultrasound money” narrative

The appeal was understandable: burn transaction fees, reduce issuance, and ETH supply could shrink. EIP-1559 introduced base-fee burning; the September 2022 Merge then removed PoW issuance and sharply reduced total new issuance. That reduction was real. It did not guarantee permanently falling supply. [18] [19]

The condition behind the narrative

Net supply change ≈ new issuance − burned ETH.

If burning exceeds issuance, supply falls. If issuance exceeds burning, supply grows. Here “inflation” means growth in the coin supply, not a consumer-price index. Small penalty-related supply changes are omitted from this simplified equation.

Dencun, activated March 13, 2024, introduced a cheaper, separate blob fee market for rollup data. Blob fees are also burned; burning was not abolished. Lower fees can nevertheless mean less ETH destroyed. In its May 29, 2025 report, Glassnode and CME documented ETH’s return to net inflation following Dencun and reduced network fees. This is a dated historical observation, not a live supply reading. [20] [21] [22]

I think it is a mistake to treat the “ultrasound money” narrative as a durable monetary promise: its deflation depends on demand. Cheaper transactions can be useful while weakening the burn that supported the scarcity story. People evaluating the asset should examine that tradeoff instead of assuming the slogan settles it.

This history does not show that ETH holders voted to raise validator issuance: Ethereum has no such simple protocol ballot, and the Merge moved gross issuance sharply downward. It shows how supply can grow again when burning falls. The separate incentive question remains: who receives issuance, who bears dilution, and who has influence when the rules are reconsidered? [16]

For ZCL, my preference is an established PoW alternative whose issuance rules can be inspected directly, with monetary changes required to earn support. ZCL still issues mining rewards; PoW is not a promise of zero inflation. My argument is for predictable rules and a credible option to leave when the beneficiaries of a proposed change cannot make their case.

OPEN SOURCE / INDEPENDENT CONSENSUS

Borrow the research.
Keep proof of work.

ZCL can evaluate compatible Zcash research and code while keeping its own consensus rules. Adopting a privacy improvement does not require adopting Crosslink’s proposed stake-based finality. The choice of development funding remains separate from both.

Zclassic already descends from Zcash’s code and privacy technology. Open-source development creates reusable work: applicable security fixes, cryptographic research, wallet improvements, and performance improvements can be evaluated for ZCL. Reusing compatible work does not require importing a founder reward or giving stake-based finalizers authority over the chain. Zclassic’s codebase ↗ · Upstream licensing ↗

In economic terms, this is a free-rider advantage: Zcash’s ecosystem can fund research whose benefits extend beyond ZEC. A smaller chain may adopt useful results while competing on a lower mandatory allocation from block rewards. I see that as another reason development funding should face competitive pressure. It does not mean the original research was free, or that the people funding and building it deserve no credit.

The savings are conditional. ZCL still needs maintainers to review licenses and dependencies, port compatible changes, audit the result, and test network upgrades. A feature tied to new transaction rules or consensus may need substantial redesign; ZCL does not automatically inherit every Zcash upgrade or its security assurances. As the projects diverge, that work can become harder.

A selective development policy

My preference is to adopt improvements that earn their place while preserving PoW. Crosslink’s stake-based finality is a separate consensus decision, not a required price of using better privacy technology. Sharing research leaves room for competing monetary and governance principles.

07 / THE GOVERNANCE DISTINCTION

Competition is
the mechanism.

Owning ZCL does not give me a veto over Zcash.

Zcash changes go through a proposal process and network adoption. The Foundation is an influential participant, not a unilateral switch for consensus rules. [3]

ECC’s published PoS research establishes that a transition has been explored. It does not establish that the Foundation can impose one, or that a particular proposal has activated. Crosslink’s proposed hybrid approach makes this design distinction concrete: miners continue producing blocks, while stake-weighted finalizers add settlement protection under the protocol’s assumptions. [4]

My concern is that tying consensus participation to stake can increase the importance of existing capital holders. That concern must be tested against the actual design. PoW has its own concentration and security tradeoffs.

08 / WHAT WOULD CHANGE MY MIND

The thesis has to earn its keep.

A good story is only the beginning. These are the conditions I would watch.

ZCL fails to become a usable alternative

If wallets, maintenance, network security, or liquidity are inadequate, the exit option is weak. A ticker alone cannot discipline another network.

Lower funding costs come at the expense of essential work

If voluntary support or a smaller allocation cannot sustain security, audits, and reliable software, the cheaper arrangement may be worse for users. The relevant comparison is the cost of delivering dependable private money.

Issuance smoothing demonstrates a compelling net benefit

Evidence that smoothing materially improves security, under realistic assumptions and after accounting for transition and credibility costs, would weaken my preference for leaving the schedule unchanged.

PoS addresses the concerns better than expected

A design with persuasive evidence for privacy, broad participation, and resistance to concentration would weaken my objection. The comparison needs a specific protocol and its assumptions.

The market does not reward private PoW money

Demand for privacy could grow without value accruing to ZCL. Even a successful Zcash investment thesis does not establish a successful Zclassic investment.

Competitive pressure never reaches governance

If the Zcash community chooses PoS regardless of activity on Zclassic, ZCL may remain an alternative without preventing the transition. This is the central causal uncertainty.

ON-CHAIN RESEARCH

Transparent balances.
A history you can inspect.

Compare ZCL and ZEC’s indexed transparent balances, then explore the full ZCL snapshot.

Our pool’s ZCL node supplies the balance export, targeting a new snapshot every two hours. The Zcash comparison fetches CipherScan’s top 100 every hour. Each source keeps its own timestamp and coverage; the bundled May 27, 2026 ZCL snapshot remains an explicitly dated fallback.

Loading the transparent balance comparison…

Zclassic: the full transparent balance index

Search all indexed ZCL addresses or filter for balances whose every contributing output is at least 100,000, 500,000, or 1,000,000 blocks old. These UTXO ages are available for ZCL only.

Loading the verified balance snapshot…

Could these dormant coins be lost?

Long-unspent outputs are candidates for research, not proof of lost keys. Savings and cold storage may stay untouched for years. These filters measure exact block age at the snapshot, without converting block counts into calendar years or assigning a probability of loss. A payment received later does not establish control of the keys; a later spend refutes loss for the outputs spent.

What does verification establish?

Current exports decode a consistent filesystem snapshot of our ZCL node and reconcile its commitment, output count, and total value with the node’s RPC. The node starts from the release’s anchored fast-sync state and validates subsequent blocks. This does not establish replay from genesis. The historical fallback instead matches the commitment pinned in Zclassic v2.1.2-beta6. That commitment covers the ordered output values, scripts, and creation-height metadata used for this ranking. This is snapshot verification, not independent replay of every historical block. The upstream commitment does not bind transaction-ID keys. The table does not identify owners, rank shielded balances, or adjust circulating supply for supposedly lost coins.

Commitment implementation ↗ · Pinned snapshot anchor ↗

09 / WHERE TO BUY

Explore ZCL
on NonKYC.io.

Ready to explore a ZCL position?

Visit NonKYC.io to check ZCL markets, current liquidity, and trading fees.

Buy ZCL on NonKYC.io

GET STARTED / COMMAND-LINE WALLET

Run your own wallet.
Keep your own keys.

Install zclassicd, the full node that holds your wallet, and zclassic-cli, the command-line tool that talks to it. These examples use the official v2.1.2-beta6 release reviewed September 12, 2026.

A downloadable wallet generator that works offline

Download the standalone ZCL wallet page ↓ · Download its SHA-256 checksum ↓. The same file includes English and Spanish. Save both files in the same folder. On a Mac, verify the download in Terminal:

MAC: VERIFY THE SAVED HTML
cd "$HOME/Downloads"
shasum -a 256 -c zcl-offline-wallet.sha256

Continue only if it reports zcl-offline-wallet.html: OK. The checksum detects a changed file relative to this download; getting both files from a compromised source would not establish authenticity. Disconnect Wi-Fi, Ethernet, and other internet connections, then open the saved HTML file in your browser. Acknowledge the preparation steps and click Generate a new ZCL address. It uses your browser’s secure random generator and works entirely inside the saved file, with no analytics or network requests.

It creates one transparent ZCL address and its compressed private key (WIF). Reveal the key only when needed, and use Save private backup to save an unencrypted text file somewhere private, outside cloud-synced folders. Keep protected backups; anyone with the WIF can spend the funds. Close the page before reconnecting. This is a key generator: balances, shielded addresses, synchronization, and spending use a separate Zclassic wallet. Verify recovery with a small test amount before relying on it. The full-node instructions below remain available.

A disconnected browser cannot protect a compromised device, untrusted extensions, or a modified download. This integration has not received an independent security audit. Review the source, pinned dependencies, and build instructions ↗.

1. Download and verify the right bundle

Use the daemon bundle for your operating system. It includes both command-line programs. Start with a fresh folder; keep an existing wallet and its data directory intact when upgrading.

macOS · Apple Silicon · Terminal

Open Terminal and paste this block. It checks for an ARM64 session (Apple Silicon, without Rosetta), downloads the official bundle into your home folder, verifies its pinned SHA-256 hash, and extracts it only if verification succeeds. A failed command stops this block. The expected hash comes from the release’s SHA256SUMS.txt.

MAC: DOWNLOAD + VERIFY
(
  set -eu
  test "$(uname -m)" = arm64
  mkdir -p "$HOME/zclassic-cli-2.1.2-beta6"
  cd "$HOME/zclassic-cli-2.1.2-beta6"
  zcl_archive='zclassicd-v2.1.2-beta6-macos-arm64.tar.gz'
  zcl_release='https://github.com/ZclassicCommunity/zclassic/releases/download/v2.1.2-beta6'
  curl -fL "$zcl_release/$zcl_archive" -o "$zcl_archive"
  zcl_sha256='4f2344da82a57b404a1eb5e5497c00ffc635ec4792f8f9e4ab9457e970d5a12a'
  printf '%s  %s\n' "$zcl_sha256" "$zcl_archive" | shasum -a 256 -c -
  tar -xzf "$zcl_archive"
)

After verification reports OK and extraction completes, run this to enter the binaries directory. Use it again when opening a new Terminal window for later commands:

MAC: BINARIES DIRECTORY
cd "$HOME/zclassic-cli-2.1.2-beta6/zclassic-2.1.2-beta6-osx-arm64"

This download is for Apple Silicon. On an Intel Mac, follow the project’s build instructions. Then continue with steps 2 and 3 below to start the wallet, synchronize, create addresses, and back up.

Linux · x86_64 · Bash

With curl, tar, and sha256sum available, this downloads the archive and extracts it only if checksum verification succeeds.

DOWNLOAD + VERIFY
(
  set -eu
  mkdir -p zclassic-cli-2.1.2-beta6
  cd zclassic-cli-2.1.2-beta6
  zcl_release='https://github.com/ZclassicCommunity/zclassic/releases/download/v2.1.2-beta6'
  zcl_archive='zclassicd-v2.1.2-beta6-linux-x86_64.tar.gz'
  curl -fL "$zcl_release/$zcl_archive" -o "$zcl_archive"
  curl -fL "$zcl_release/SHA256SUMS.txt" -o SHA256SUMS.txt
  sha256sum --check --ignore-missing SHA256SUMS.txt
  tar -xzf "$zcl_archive"
)

Then open the extracted binaries directory:

BINARIES DIRECTORY
cd zclassic-cli-2.1.2-beta6/zclassic-2.1.2-beta6-linux-x86_64
Windows · x64 · PowerShell

Download zclassicd-v2.1.2-beta6-win64.zip ↗ and SHA256SUMS.txt ↗. Calculate the archive’s hash and compare all 64 characters with its entry in the checksum file:

VERIFY SHA-256
Get-FileHash .\zclassicd-v2.1.2-beta6-win64.zip -Algorithm SHA256

After it matches, extract the ZIP with File Explorer. Open PowerShell in the extracted folder containing zclassicd.exe and zclassic-cli.exe. In the commands below, use .\zclassic-cli.exe in place of ./zclassic-cli.

2. Start the node and let it synchronize

On Linux or macOS, run these from the binaries directory. The backup directory is local to your computer; RPC access is limited to localhost.

LINUX / macOS
mkdir -p "$HOME/zclassic-backups"
chmod 700 "$HOME/zclassic-backups"
./zclassicd -daemon -server=1 -rpcbind=127.0.0.1 -rpcallowip=127.0.0.1 \
  -exportdir="$HOME/zclassic-backups"
Windows startup

Create a folder named zclassic-backups inside your Windows user folder, then start:

POWERSHELL
.\zclassicd.exe -server=1 -rpcbind=127.0.0.1 -rpcallowip=127.0.0.1 -exportdir="$env:USERPROFILE\zclassic-backups"

Keep that terminal open and run the CLI commands in a second PowerShell window in the same binaries folder.

A fresh node attempts to download the proving parameters and a fast-sync snapshot, then catches up with the network. Allow several gigabytes of downloads and additional disk space for the growing chain. Completion time depends on peers and your connection. Fast sync uses the release’s pinned snapshot commitment; it is not a replay from genesis. For full historical validation, follow the official -bootstrap=0 and parameter-download instructions.

Sync modes and parameter setup ↗

3. Check sync, create addresses, and back up

WALLET COMMANDS
./zclassic-cli getblockchaininfo
./zclassic-cli getnewaddress
./zclassic-cli z_getnewaddress sapling
./zclassic-cli z_gettotalbalance
./zclassic-cli backupwallet walletbackup01
  • getblockchaininfo: wait for the block height to catch up with the explorer and verificationprogress to approach 1. A high progress value alone does not prove that your peers are current.
  • getnewaddress: creates a public transparent address for a mining pool payout.
  • z_getnewaddress sapling: creates a separate shielded receiving address. Use the transparent address for the pool example below.
  • z_gettotalbalance: reports transparent, private, and total balances.
  • backupwallet walletbackup01: writes the backup under the -exportdir folder. Use a filename, not a full path; save later backups under new names.

Protect the wallet file and backup as keys to your funds. Keep a separate protected backup, and make a new backup after creating new addresses. This guide does not enable the release’s experimental wallet-encryption feature. Never enter private keys or a wallet backup into a pool, this site, or a support chat.

Stop the node cleanly when needed:

STOP
./zclassic-cli stop

Wallet RPC definitions ↗ · Official node guide ↗

GET STARTED / HOW TO MINE

Put work behind
the alternative.

ZCL currently uses Equihash 192,7, with ZcashPoW personalization. Choose hardware and miner software that support those exact parameters. A Zcash Equihash 200,9 configuration is not interchangeable.

Mining from a Mac

The Mac commands above install a wallet and full node. The miniZ example below uses its Linux or Windows GPU miner; its downloads do not provide a native macOS build. You can keep your payout wallet on the Mac and use a compatible GPU machine as the worker. Do not paste the Linux miner command into macOS expecting it to use an Apple GPU.

Our ZCL pool · 0.8% fee

We recommend our community ZCL pool when its live status confirms it is accepting miners. The pool fee is 0.8%, leaving 99.2% of allocated rewards for miners. That fee is 20% lower than a 1% pool fee; zpool’s published Equihash 192 settings provide a comparison. Rewards are proportional to accepted work in each pool round. Eligible balances pay out from 0.05 ZCL after coinbase maturity and shielding confirmations. The pool covers transaction fees from its operator reserve. Check the live pool status before starting; synchronization or payout readiness can close admission.

View our pool status ↗ · Open the browser GPU miner ↗

Mine in your browser

Our experimental WebGPU miner runs real ZCL Equihash 192,7 work on your device. It is designed for compatible browsers, including Chrome on supported Macs; it needs about 3.26 GiB of GPU memory. You enter your public ZCL payout address, choose a time limit, acknowledge the electricity use, and press Start. No private key or deposit is required.

Mining stays disabled until the pool confirms readiness. Once available, Stop or hiding the tab ends the session. This can heat the device and slow other apps, and earnings may not cover electricity. Shares contribute to pool rounds; they are not guaranteed blocks or payments. The native miniZ instructions below remain a separate option for compatible Linux and Windows GPU rigs.

1. Choose a pool and compatible miner

A pool combines miners’ work and pays according to its rules. Solo mining has much less frequent, more variable rewards. Running a wallet node by itself does not mean your GPU is mining.

For a concrete GPU example, use miniZ’s official downloads ↗ and check its supported GPU, driver, operating system, and published checksum. The commands below connect to our ZCL pool. Check that our live pool status ↗ says it is accepting miners before starting. Pool and miner software fees are separate.

2. Point the miner at your ZCL address

Replace YOUR_ZCL_T_ADDRESS with the transparent address from your own wallet and choose a worker name. Run this in the extracted miniZ folder on Linux:

EDIT YOUR ADDRESS BEFORE RUNNING
./miniZ --par=192,7 --pers=ZcashPoW \
  --url=YOUR_ZCL_T_ADDRESS.worker1@pool.zclthesis.com:2192 \
  -p c=ZCL --log

On Windows, use .\miniZ.exe in place of ./miniZ and put the command on one line. The endpoint is our ZCL Thesis Pool. c=ZCL selects ZCL payouts. This is shared pool mining; rewards depend on accepted work in each round. The password field contains pool settings, never your wallet password.

miniZ’s ZCL instructions ↗

3. Confirm accepted work and actual payouts

Look for accepted shares in your miner. The browser miner shows counters for the current session; our public pool page shows pool and node readiness. Investigate repeated rejected shares before leaving it running. A connected miner or a displayed hash rate alone does not establish that you are earning ZCL.

The minimum payout is 0.05 ZCL. Confirm incoming payments in your synchronized wallet or a ZCL explorer using your public address. Unpaid pool credits do not appear in your wallet balance. Compare the value of actual payouts with electricity, hardware, pool, and miner costs. Mining supports the network, but profitability is not guaranteed. Stop the foreground miner with Ctrl+C.

4. Open a web dashboard from your Mac

miniZ includes a browser dashboard for GPU statistics, charts, and console output. For a remote Linux GPU machine you already control and can access over SSH, launch the miner with telemetry bound to localhost. Replace the payout address first. If it is already running, stop it with Ctrl+C before launching this version:

ON THE LINUX GPU WORKER
./miniZ --par=192,7 --pers=ZcashPoW \
  --url=YOUR_ZCL_T_ADDRESS.worker1@pool.zclthesis.com:2192 \
  -p c=ZCL --log --telemetry=127.0.0.1:20000

On your Mac, replace YOUR_USER and YOUR_GPU_HOST with your SSH login and the GPU machine’s hostname or IP. Keep this Terminal window open while using the dashboard:

MAC TERMINAL: SSH TUNNEL
ssh -N -L 20000:127.0.0.1:20000 YOUR_USER@YOUR_GPU_HOST

In a second Mac Terminal window, open the dashboard:

MAC TERMINAL: OPEN DASHBOARD
open http://127.0.0.1:20000

The GPU worker performs the mining; the browser shows its telemetry. The built-in page is a monitoring interface, not a wallet or an authenticated start/stop service. Keep the telemetry port local and use the SSH tunnel for remote access. Closing the tunnel stops dashboard access; stop the miner on the GPU host to stop mining.

miniZ dashboard documentation ↗ · Telemetry address option ↗

Could we run our own ZCL pool?

Yes. A pool needs a synchronized ZCL node, a Stratum server that validates current Equihash 192,7 shares, reward accounting, payouts, and monitoring. Miners connect their own hardware; the pool server does not need a GPU simply to coordinate their work. Our ZCL Thesis Pool is running; its live status page reports whether it is currently accepting miners.

The legacy Miningcore ZCL configuration still specifies 200,9, and historical Z-NOMP is archived. Those are starting points for development, not verified installation recipes for current ZCL. A private integration should demonstrate valid shares, accepted block submissions, and correct payout accounting before taking public miners.

Current node mining RPCs ↗ · Legacy pool parameters ↗ · Historical Z-NOMP ↗

Can ZCL be dual-mined?

Yes: miniZ documents dual mining with two supported algorithms on NVIDIA GPUs, including Equihash 192,7. Put the ZCL connection first with --url, the second coin’s connection in --url2, and use --dualw to adjust the workload balance according to its guide. This dual mode is documented for NVIDIA; do not assume AMD or Apple GPU support.

Dual mining shares GPU capacity between separate jobs. It can reduce ZCL’s hash rate and alter power use. Compare combined accepted-share earnings and power costs with ZCL-only mining; no particular pair has been benchmarked here. This does not mean one proof of work earns rewards on both chains, which is merged mining. No ZCL merged-mining pair is established by these instructions.

Check the current supported algorithms before choosing a second coin: miniZ removed ZIL in v2.5e and removed 125,4 and 150,5 in v2.5e3, so older pairing examples may no longer work.

Current supported algorithms ↗ · Dual-mining options ↗ · v2.5e changes ↗ · v2.5e3 changes ↗

Guide reviewed September 12, 2026. Commands were checked against release source and provider documentation; mining was not run as part of publishing this page.

10 / FOLLOW THE ARGUMENT

Read the sources.
Reach your own conclusion.

01
My Zcash investment thesisFrank Braun · July 22, 2025 · Foundation for the privacy argument
02
Zclassic project overviewZclassic · Project’s description of its origins and PoW design
03
Protocol agreements and major decisionsZcash Foundation · Proposals and network adoption
04
Zcash proof-of-stake researchElectric Coin Company · May 20, 2022 · Historical research rationale
05
ZIP 214: Development fund consensus rulesHistorical and subsequent funding-stream definitions
06
ZIP 234: Issuance smoothingDraft proposal · Reserve-based subsidy, rationale, and stated supply cap
07
ZIP 233: Removing funds from circulationExplicit removal mechanism · Distinct from dormant balances
08
Crosslink FAQShielded Labs · Proposed hybrid finality design and intended benefits
09
Crosslink incentivized feature netsApril 2, 2026 · Proposed rewards and testing roadmap
10
Mechanism Design Audit of Crosslink ZebraNicolás Della Penna · January 2026 · Safety and liveness analysis
11
Crosslink: the first six weeksMay 29, 2026 · Feature-net experience and recovery questions
12
Zcash v1.0.0 Sprout releaseZcash repository · October 28, 2016 · First release containing the mainnet genesis block
13
Proof of work explainedEthereum documentation · Historical PoW mechanism and resource costs
14
Proof of stake explainedEthereum documentation · Validator deposits, proposals, and attestations
15
Staking rewards, penalties, and slashingEthereum documentation · Specific punishable behavior and reward mechanics
16
Ethereum governanceEthereum documentation · Off-chain protocol decisions and participants
17
Endgame Staking Economics: A Case for TargetingDietrichs and Schwarz-Schilling · February 22, 2024 · Dilution, real yield, and service-provider incentives
18
EIP-1559: Ethereum’s base-fee burnProtocol specification · Net inflation or deflation remains demand-dependent
19
How the Merge impacted ETH supplyEthereum documentation · Historical issuance reduction and the burn balance
20
Dencun mainnet announcementEthereum Foundation · February 27, 2024 · March 13 activation and lower rollup costs
21
EIP-4844: Shard Blob TransactionsProtocol specification · Separate blob fee market and blob-fee burning
22
Ethereum Insights and Market Trends, H1 2025Glassnode and CME · May 29, 2025 · Documented return to net inflation after Dencun

Sources reviewed September 11–12, 2026. Historical essays describe their publication context; the live strip reports source observations separately and does not track protocol activation status.