Zcash Foundation ZRC-20 denial has been issued. The Foundation rejected any connection to two third-party products. These are ZRC-20 and the CASH token.
The denial followed a post published through its X account. That post described them as additions to the Zcash network.
Why the Zcash Foundation ZRC-20 denial matters
The Foundation said it had no prior knowledge of ZRC-20. It also did not know about the CASH token beforehand. According to the organization, both products come from an independent third party. They are not official parts of the Zcash protocol.
The clarification followed an X post. That post announced a token standard for Zcash. It said ZRC-20 would soon allow users to deploy, mint, and transfer tokens. CASH was presented as the first token using the system.
“Zcash now has a token standard,” the post said. It then directed users to the project’s website.
In its later response, the Foundation rejected any association. It urged users to conduct their own research before interacting. The statement identified ZRC-20 as a privately developed system. It was not created, approved, or operated by the nonprofit.
No public explanation has established how the promotional material appeared. Without confirmation, the incident cannot be described as an account compromise.
Public information about the ZRC-20 team remains limited. The project released technical documentation and promotional pages. However, the reviewed material does not identify a company or named developers.
ZRC-20 uses Zcash memos without changing its protocol
According to the project’s documentation, ZRC-20 is a draft specification. It stores JSON instructions inside encrypted memo fields. These attach to shielded Zcash outputs.
Independent indexers would read the instructions in block order. They would calculate token balances outside the Zcash consensus system. The documents describe three operations. These are deploy, mint, and transfer.
A deployment would create a ticker and set its maximum supply. Minting would issue units up to that limit. Transfers would move balances between recognized accounts.
ZRC-20 borrows its structure from Bitcoin’s BRC-20 format. However, the data carrier differs. BRC-20 uses Bitcoin inscriptions. The ZRC-20 draft would use the 512-byte memo field.
The specification states ZRC-20 is not a consensus change. It does not require smart contracts either. Zcash nodes would neither validate nor reject its instructions. The indexer would maintain the balance sheet instead.
Therefore, Zcash consensus would only confirm the underlying transactions. Recognition of CASH balances would depend on third-party software.
The project also would not provide automatic privacy. An indexer needs access to the memos before calculating balances. One proposed design sends operations to a common protocol address. It then publishes its incoming viewing key.
Ownership would rely on signatures embedded in each payload. The draft proposes separate account identifiers and Ed25519 signatures.
Several features remain unresolved. The documentation lists atomic trading and payloads exceeding 512 bytes. Structured memos and naming conflicts are also open questions.
Official Zcash changes follow a separate process
The official Zcash Improvement Proposal system provides the established route. It covers proposing features and publishing implementation details. It also covers gathering feedback and recording decisions. ZRC-20 does not appear as an adopted feature under that process.
A third-party application can use Zcash transactions without approval. It does not become part of the network’s consensus rules. The Foundation’s statement makes that distinction central. ZRC-20 may build on Zcash infrastructure. Its use of the blockchain does not make it official.
The name carries another source of possible confusion. ZetaChain already uses ZRC-20 for its omnichain format. Members of the Zcash community discussed the same label years earlier.
Recent Zcash development has centered on formal network changes. Planned NU7 proposals include reducing the block target. The change would cut it from 75 seconds to 25 seconds. Such changes require coordination among developers and node operators.