A technical clarification inside a Zcash Community Forum retroactive-grants discussion is forcing a more precise definition of what “shielded swaps” can and cannot mean on cross-chain DEX infrastructure.
In a Feb 8 comment on the Maya Protocol Advanced Shielded ZEC Support retroactive grant thread, a Maya contributor argued that even if the stack later supports full custody for Orchard funds, cross-chain swaps still cannot be fully private end-to-end under the current design. The reason is structural: the non-ZEC side of the trade settles on transparent chains, and the swap path still leaves metadata visible on MAYAChain.
That is a subtle but important distinction. It separates “shielded ZEC support” from “fully private swapping,” and it gives reviewers a concrete framework for evaluating privacy claims tied to cross-chain liquidity.
Zcash can hide sender, receiver, and amount when transactions remain fully shielded in its privacy pools. The Orchard pool is specified in ZIP 224 as a shielded protocol designed for strong privacy properties. That strength, however, does not automatically carry across chains.
A cross-chain swap is not one transaction. It is a sequence of transactions and state transitions across multiple systems.
When only one leg is shielded, privacy becomes asymmetric. The ZEC leg can be protected while it is inside Zcash’s shielded pool, but the other asset leg still settles on a transparent chain like Bitcoin or Ethereum. That settlement is visible by design, including the amounts moved, the timing, and the destination addresses involved on the transparent chain.
On top of that, the cross-chain DEX must interpret user intent and coordinate routing. In MAYAChain-style architectures, that intent commonly travels through transaction metadata such as memos. MAYAChain documentation explains that inbound transactions include a memo field that communicates user intent and is inspected to process swaps, and that this transaction event data is indexed for public queries through its APIs, including the transaction memo concept docs and the Midgard public API.
The result is a practical ceiling. A user can gain privacy for the ZEC portion of a swap, but not for the entire cross-chain action.
The same forum thread discusses implementation tradeoffs and the reality that current flows can still be traceable at the boundary.
One Maya team member describes today’s Orchard support as “traceable orchard,” noting that the flow still has to pass through a transparent vault boundary before the swap machinery completes. In other words, the system can accept shielded deposits and deliver shielded outputs, but the operational middle layer still includes transparent handling that can create correlation risks when amounts and timing line up.
This is not a trivial nuance. Many users interpret “shielded” as a guarantee of end-to-end unlinkability. Cross-chain swaps are more like a privacy sandwich: shielded at the edges, transparent in the middle.
That can still be useful. It can reduce the exposure of ZEC addresses and protect the ZEC leg from direct graph analysis. Yet it should not be marketed as a complete privacy cloak for the entire swap.
The forum clarification points to two places where observers can still learn about a “shielded swap.”
First, the non-ZEC chain. If a swap touches a transparent asset, that asset’s chain will expose transaction details such as value, address endpoints, and timing.
Second, the cross-chain DEX coordination layer. MAYAChain processes swaps by observing inbound transfers and reading intent fields, and its documentation describes how memos encode swap directives and routing choices. Those memos exist specifically so the network can act on them. They are therefore not inherently private.
The exact fields that are visible can vary by route and chain type, but the general category of exposed information tends to include swap intent, inbound and outbound asset identifiers, transaction timing, and routing steps. This is consistent with why MAYAChain publishes a memo specification and a public indexing API that parses transaction events for queries.
The discussion also ties privacy constraints to custody architecture.
For full Orchard custody in a multi-validator setting, a threshold signing scheme must be compatible with Zcash’s shielded spend authorization. That is why the thread references FROST and other threshold cryptography approaches.
Zcash documents FROST-based multisignatures for spend authorization in ZIP 312, describing how a threshold Schnorr construction can fit Zcash spend authorization requirements. The point is not that FROST alone creates end-to-end cross-chain privacy. It does not. The point is that it could change the custody boundary by making it more feasible to hold and spend shielded funds in a distributed signing environment.
Even if that custody boundary improves, the privacy ceiling described by the Maya contributor remains. Transparent settlement on the non-ZEC leg and observable coordination metadata outside Zcash still exist.
The practical takeaway is that “shielded swap” language should be evaluated by the full path, not the entry point.
A high-confidence review typically checks three things.
That makes this forum clarification newsable despite being niche. It is a rare case where a builder publicly draws a bright line around privacy claims, which helps the ecosystem avoid overpromising and helps users understand what they are really getting when they choose a cross-chain shielded route.
The post Maya Contributor: Cross-Chain Shielded ZEC Swaps Still Leak Metadata Outside Zcash appeared first on Crypto Adventure.
