Zcash Community Forum forum

The Zcash Daily — Tuesday, September 22, 2026 The Q3 coinholder retroactive grants vote is now past the halfway mark with one week left — 37 proposals are live, open to shielded ZEC holders until 20:00 UTC on September 29, with a quorum threshold of ~420,000 ZEC. What’s interesting here isn’t the number of proposals — it’s that voters must upgrade to Zodl 3.14.0, the latest Vizor Wallet, or Zkool to participate, meaning every vote is a quiet privacy signal. Worth checking where quorum stands heading into the final stretch. The Colosseum Crypto World’s Fair hackathon has a Zcash track running through October 12 — teams from Solana, Ethereum, Sui, Zcash, Bitcoin, and others are competing, with Zcash among the ecosystems putting up a $100,000 dedicated prize pool. Colosseum’s stated goal is to attract 10–15 high-quality founders to integrate with Zcash. That ambition deserves scrutiny — Solana grew partly through exactly this kind of repeated builder-pipeline work, and ZCG approved the grant at a revised $150,000 . On the regulatory front, the Senate rejected CLARITY Act cloture 49–50 on September 15, leaving the bill eleven votes short of floor debate, with every Democrat voting no over unresolved ethics provisions. ZEC jumped 15% the day after — the read being that a failed surveillance-friendly framework is a tailwind for privacy coins. Unless the Senate stages a rapid re-vote before October 5, market structure legislation likely slips to 2027 — and the Zcash community’s reac

thank you for the information . I have my Zec in a trezor wallet since launch almost . I am getting mixed messages in the post . I understand that its ok no problem with them . then I also read that they might experience problem with them . does that mean I need to buy new hardware wallet ?

Bitcointalk Signature Campaign & ZEC Community Engagement — 3 Months Requested amount: $90,000 USD ($30,000 per month for three months) Duration: 3 months Category: Community & Outreach Applicant: tokensfund — project lead Murat ( Bitcointalk profile ) GitHub application: Grant Application - Bitcointalk Signature Campaign & ZEC Community Engagement — 3 Months · Issue #441 · ZcashCommunityGrants/zcashcommunitygrants · GitHub Executive Summary A three-month Bitcointalk campaign to put Zcash in front of the forum’s long-tenured, self-custody-focused audience while new attention on ZEC is arriving. Forty high-rank forum accounts — Bitcointalk staff and moderators, Legendary, Hero and Sr. Member only — will carry an official Zcash signature banner for three months, delivering roughly 14,400 banner-carrying posts. Alongside the campaign, a monthly ZEC price prediction contest gives the community a recurring reason to discuss Zcash, and every participant sets up a shielded Zcash address to enter. Progress will be reported publicly on this thread each month. Problem Bitcointalk has been running since 2009 and remains the largest general-purpose cryptocurrency forum. Its regulars are long-term holders and self-custody users — people who already understand why financial privacy matters. That is Zcash’s natural audience. Zcash currently has no signature campaign on the forum, while readers there see other projects’ banners under posts every day. At the same time, new attention is arrivi

Thanks @hhanh00 . for requesting clarity around the technical approach sections implementation details. I wanted to share that response and attached it below The exported material is an output-specific recovery key The first implementation is a sender-side selected-output disclosure, not a new zero-knowledge circuit and not a signature from my service asserting that a payment happened. For a supported Orchard output, the wallet would use the outgoing viewing key actually used for that output, locally, to derive its 32-byte outgoing cipher key (ock) from the action’s cv_net, cmx, and ephemeral public key. This uses the existing protocol derivation exposed through Domain::derive_ock; the reusable ovk is not included in the receipt. Conceptually, the artifact is: { “type”: “zcash-selected-output”, “version”: 1, “network”: “testnet”, “pool”: “orchard”, “txid”: “”, “action_index”: 0, “ock”: “ ” } This is an illustrative format, not a claim of an adopted standard. The amount, recipient, and memo are recovered from transaction ciphertext, rather than accepted as assertions in this JSON. The reference wallet would preserve the local recovery capability and the mapping to the finalized transaction/action. Before export, it would run recovery itself and show the user what will be disclosed. If the required outgoing recovery material is unavailable, export is unavailable; I am not claiming this works retroactively for every wallet or for outputs deliberately created without outgoing rec

Thanks for the pushback — you’re right on the light-client side, and I’ll correct our wording. On light wallets: agreed. Lightwalletd/Zaino deployments kept pace — the zec.rocks stack (by @emersonian ) and directories like hosh.zec.rocks list a healthy set of public endpoints, including Zaino ones. Our line “mining and light-wallet infrastructure has not followed” conflated two different things. I’ll rewrite it to say plainly that mining is the gap we’re addressing, and I’ll drop the “few operators run one” claim in the application unless we can state something narrower and true — uptime, rate limits, region, i.e. the things a wallet can actually depend on. The mining gap is narrower, but structural. Every widely used pool stack — Miningcore, NOMP/z-nomp and their forks — is written against zcashd’s mining RPC and coinbase handling. With zebrad, getblocktemplate hands back a coinbase bound to blockcommitmentshash; you cannot inject an extranonce into it without recomputing the commitment roots. That’s why those stacks can’t just switch nodes. We had to write a ZIP-244 v6 digest + coinbase builder to make a 99/1 on-chain split work at all — and it’s published under MIT (tag v0.1.0) precisely so it can be audited rather than believed. If a maintained, self-hostable, non-custodial pool engine for zebrad already exists, I’d genuinely like the pointer; I’ll link it in the proposal and reassess what’s left to fund. On “not your job” and the official stamp: agreed — and that isn’t w

wygogogo19: Zcash is retiring zcashd in favour of zebrad , but mining and light-wallet infrastructure has not followed. AFAIK Light wallets have already updated to use zebrad, such as GitHub - zecrocks/zcash-stack · GitHub ( @emersonian ’s stack), which is hosted at zec.rocks and has a pretty long directory ( https://hosh.zec.rocks ) Where are you getting the impression that light wallets haven’t migrated? And migrating miners is, bluntly put, not your job. Legitimate institutional miners will never use software which doesn’t have the official stamp from ZODL.

A fire hose of information I know. But my aim is to have a much detail as possible here so folk can find it in one place, and migrate their ZEC before the Sprout pool is frozen in ice. TL;DR: The transparent pool is NOT being put on ice. Only Sprout, as of Nov 2026. An old wallet.dat or wallet export from 2016-2018 may contain transparent ZEC, Sprout ZEC, or both. Sprout addresses start with zc... and Sprout spending keys with SK... . Check what it actually controls before Sprout is put on ice.

Applicant: @wygogogo19 (Yang Wang) — RobotBase, independent infrastructure operator Category: Infrastructure · Requested: $19,500 over 6 months (milestone-based) GitHub application: Grant Application - Zebra-Native Non-Custodial Mining Stack (RobotBase) · Issue #439 · ZcashCommunityGrants/zcashcommunitygrants · GitHub What this is Zcash is retiring zcashd in favour of zebrad , but mining infrastructure has not followed. We have built — and now operate in production — a Zebra-native, non-custodial Stratum V1 pool : block templates come from our own zebrad v6.3.0 node, and the coinbase transaction itself pays 99% to the miner’s t -address and 1% to the pool’s infrastructure address (ZIP-244 mode 2). There is no pool balance, no withdrawal step and no registration — the username is the payout address. This grant turns that working system into a reusable public good: an integration test harness and CI, an operator runbook validated by an independent operator, a miner-firmware compatibility matrix, and a stable specification for our six-value-pool telemetry API (transparent / sprout / sapling / orchard / ironwood / lockbox). Already live today Source code (MIT, tag v0.1.0 ): GitHub - wygogogo19/zebra-stratum-pool: Non-custodial Equihash 200,9 Stratum v1 mining pool engine built natively for Zebra (zebrad v6+). Features ZIP-244 on-chain coinbase splitting (Mode 2, 99/1) with zero custody. MIT licensed. · GitHub Reference deployment: https://zec.robotbase.cc/ — mining parameters, li

I’m sorry, NEAR escrow contracts? As in the same NEAR contracts as in My experience exiting shielded ZEC from Zodl to NEAR Intents: $589k USDT still held 50 days despite a written compliance clearance , which is clearly not trustless and the validators can just unilaterally REFUSE to sign transactions? Personally, this proposal is too unreliable, for multiple purposes: (a) contrary to what this post claims, it uses transparent addresses (which it hopes the wallet will CONVERT to shielded), which leak metadata on the chain, and more importantly, it links it to you REAL WORLD IDENTITY. It is trivial for the bank to link the CDM transaction amounts and time to the transparent deposit time. Discounting that, (b) “The funds can only be released with cryptographic confirmation of fiat settlement (seller confirmation).” WHAT? Then it’s not cryptographic, it’s just when seller wishes! What if the seller never wishes to release funds? Do the funds just return? If so, what prevents the seller from just taking the funds regardless of whether the buyer has gotten funds or not? How does the contract verify the bank transaction happened anonymously? It’s like Swiss cheese but full of regulatory hurdles, each of which can land you several years in prison. God I would love to see this done in the US. They’d classify it as an unlicensed money transmitter so fast it’d create a sonic boom, and then you get to see Roman Semenov 2.0

The Heavy - Short Change Hero

No, I’ve never sideloaded. I’m on macOS with a nano OS. Can you point me to instructions on how to do that?

github.com/ZcashCommunityGrants/zcashcommunitygrants Grant Application - P2P Cash-to-ZEC Onboarding via Bank CDMs opened 09:48AM - 20 Sep 26 UTC imerkle ### Terms and Conditions - [x] I agree to the [Grant Agreement](https://9ba4718 … c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded - [x] I agree to [Provide KYC information](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD - [x] I agree to disclose conflicts of interest - [x] I agree to adhere to the [Code of Conduct](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and [Communication Guidelines](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284) - [x] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story. - [x] I agree that for any new open-source software, I will create a `CONTRIBUTING.md` file that reflects the high standards of Zcash development, using the [`librustzcash` style guides](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference. - [x] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any [merge](https://github.