myzclthesis.
EnglishEspañol
LATEST REPORTED BLOCK

Loading explorer data…

Zelcore explorer ↗
ZCL PRICE · USDT

Loading last traded price…

Where to buy ZCL ↓
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.

Checking sources…

Rich list & dormant coins ↓

ZCL vs Zcash market caps ↓

AN INDEPENDENT INVESTMENT THESIS

Privacy needs
an exit option.

I believe Zclassic gives privacy users a credible exit option. I support it for two independent reasons: preserving proof of work and making protocol-funded development earn its cost. Each argument needs its own evidence.

Read the thesis

A personal argument. Open to scrutiny.

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. 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.

SHARED ORIGINS · DIFFERENT REWARD RULES

Real proof of work.
Nearly the same age.

Zcash

Zclassic

Zclassic launched just nine days after Zcash. Both have roots in 2016.

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. By September 2026, both are approaching a decade of history. ZCL is an operating proof-of-work coin with years of mined blocks, transactions, and community effort behind it. [12] [2]

Age matters to my thesis because the outside option already exists and has a history people can inspect. Longevity alone does not establish equal hashpower, security, liquidity, or privacy capabilities. Those still need to be compared on their merits.

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]

RELATIVE MARKET VALUE

A large valuation gap.
A question worth asking.

Loading ZCL and ZEC market capitalizations…

The contrast I care about is a long-lived PoW alternative beside a much larger privacy project.

I see ZCL’s smaller valuation as a reason to investigate whether the market underestimates its value as an exit option. A market-cap gap is not proof of mispricing, and equal age does not entitle two networks to equal value. Adoption, liquidity, development, and security can justify very different valuations. The comparison makes my hypothesis 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]

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 · launch in preparation

We are building a pool for this community and intend to make it our recommended mining destination. The launch 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. It is not accepting miners yet; we will publish its connection command after share, block, and payout validation. Until then, the third-party command below is a documented example, not our pool’s endpoint.

View our pool status ↗ · Preview 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. Its ZCL guide documents a zpool configuration. Before starting, confirm the pool’s ZCL support, endpoint, fee, payout currency, and minimum payout in its current pool settings ↗. Pool and miner 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@equihash192.eu.mine.zpool.ca:2192 \
  -p c=ZCL,zap=ZCL --log

On Windows, use .\miniZ.exe in place of ./miniZ and put the command on one line. The example uses the EU endpoint from miniZ’s ZCL guide; confirm it is still listed before use. c=ZCL requests ZCL payouts and zap=ZCL selects ZCL mining at zpool. 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 the miner and the correct worker on the pool dashboard. Investigate rejected shares or a missing worker before leaving it running. A connected miner or a displayed hash rate alone does not establish that you are earning ZCL.

Check the pool’s payout threshold and transaction history, then confirm payments in your wallet after it is synchronized. 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@equihash192.eu.mine.zpool.ca:2192 \
  -p c=ZCL,zap=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. This site does not currently operate a pool.

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.

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.