Maya Protocol has built and deployed full end-to-end shielded Zcash (ZEC) support on its cross-chain decentralized exchange, enabling users to perform native cross-chain swaps directly to and from shielded (Sapling/Orchard) addresses without intermediaries, KYC, or custodians. This represents the first and only decentralized, permissionless cross-chain DEX with native shielded ZEC support, giving Zcash users unprecedented access to cross-chain liquidity while preserving their financial privacy.
Background
A Zcash Community Grants (ZCG) grant titled “Transparent & Shielded DEX with Maya Protocol” was awarded to Hanh Huynh Huu (Ywallet Creator) to support the initial Zcash integration concept. Maya Protocol did not receive any portion of those funds. Nevertheless, the Maya Protocol team independently carried out the full engineering effort to bring Zcash to production on the Maya DEX.
This retroactive grant application covers the entirety of Maya Protocol’s uncompensated engineering work to deliver production-grade transparent and shielded ZEC support, including:
Shielded inbound transaction support — Users can send ZEC from shielded addresses to Maya Protocol’s vault, with the system correctly processing the swap using OP_RETURN memos.
Shielded outbound swap destinations — Full end-to-end shielded support where swap outputs are sent directly to Unified Addresses (UA), Sapling, and Orchard receivers.
Shielded memo parsing — Bifrost can derive inbound viewing keys (IVK) and trial-decrypt Sapling/Orchard notes to read shielded memos, enabling shielded-to-shielded swap flows.
TEX/UA address normalization — All ZEC addresses (TEX, Unified) are normalized to their default receiver before matching outbound transactions.
NU6/NU6.1 network upgrade support — Full support for the Zcash NU6 and NU6.1 consensus upgrades
UTXO management hardening — Extensive work on ZEC UTXO reservation, signing, checkpoint flows, solvency checks, and double-spend prevention.
Rust-to-Go FFI layer — Built and maintained Rust bindings (via librustzcash and UniFI) exposing shielded cryptographic operations to Maya’s Go-based Bifrost client.
Impact on the Zcash Ecosystem
This work makes Maya Protocol the first decentralized cross-chain exchange where users can:
Swap any supported asset (BTC, ETH, RUNE, CACAO, stablecoins, etc.) directly into a shielded ZEC address
Swap from shielded ZEC into any other supported asset
Do so without KYC, sign-ups, or custodial risk
This directly advances Zcash’s mission of financial privacy by giving shielded ZEC real cross-chain utility and liquidity access. Services like BitcoinVN (which received a Coinholder grant for their shielded ZEC instant swap service) already leverage Maya Protocol’s infrastructure for their cross-chain swap functionality.
28+ merged merge requests across the MAYANode codebase, with 9+ months of active development (June 2025 - February 2026). Maya Protocol mainnet is live with full shielded ZEC support.
Budget Breakdown
The total budget reflects engineering compensation for the core development team over 9 months (June 2025 - February 2026), with approximately 30% of the team’s capacity allocated to Zcash work:
ZolyDevMaya — Lead ZEC Developer: $18,900
Itzamna — Core Developer: $18,900
Bitol Maya — Core Developer: $6,750
**Total: $44,550
**
Please see the full grant application on GitHub for complete technical details, the full list of merged merge requests, and the budget breakdown.
We welcome feedback and questions from the community!
Shielded ZEC on DEXs is a massive win for privacy. Users shouldn’t have to sacrifice privacy to trade.
This infrastructure enables apps like ZChat to exist in a more complete ecosystem - users can acquire ZEC privately, then use it for private messaging.
I want to caution everyone to what we should flag as “traceable orchard” support across our community. When is an orchard transaction traceable? When someone deposits into Orchard with an exact amount, then withdraws from Orchard that same nearly-exact amount. Especially if the withdraw happens soon after the deposit.
To a new dev in our ecosystem, the easiest way to support orchard is to allow users to deposit into an orchard address, then immediately transfer those funds out into a transparent address. That’s almost as good as not using orchard as all, it’s very very traceable.
When a project claims shielded support, let’s be vigilant about verifying what exactly they mean by that. The “traceable orchard” approach I define above is not entirely bad - it is a baby step towards full orchard support - and is perhaps better than nothing. But what I really don’t like about it is that users get a huge false sense of security.
(Context: Immense tooling and understanding exists for Bitcoin addresses, which is why I strongly support Zcash transparent addresses (which are essentially BTC addresses) for developer evangelism. T-addresses got us NEAR and Maya years sooner, if ever. TSS is the technology that allows Maya and NEAR to safely store massive amounts of Zcash across multiple validators in a mostly-trustless, decentralized way. But it does not support Orchard addresses. For that you need FROST. So, transparent addresses are essential right now, and are absolutely both a feature and a bug.)
Worth adding a structural point that may help frame this discussion:
Maya is a cross-chain DEX. So even in a future where FROST replaces the transparent vault and full Orchard custody is possible, swaps still cannot be end-to-end private under the current architecture. The non-ZEC leg (BTC, ETH, CACAO, RUNE, etc.) settles on transparent chains, and swap metadata remains visible on Mayachain.
So the practical privacy ceiling is: shielded on the ZEC side, transparent at the Maya/counterparty boundary. That’s an inherent property of cross-chain swaps when only one side is shielded.
Feels like useful context for evaluating both the current implementation and future improvements.
I definitely support this. DEX support has been an incredible unlock for Zcash, and I appreciate the Maya team’s commitment to privacy and shielded TXs.
Hey @thowar2 thanks for the comment! Indeed, we only support transparent inbound address for swaps, even if it’s from shielded to shielded. We’ll probably start working on it this year. We’ll also look into adding fully shielded into Asgardex; that would help close down the development we already did to support from/to shielded swaps, but we expect Zodl to be faster on that.
I have a stuck ZEC deposit against Maya’s shielded memo path and no way to reach anyone at Maya, so I’m posting here since this thread covers that work.
On 2026-08-08 at 14:57 UTC I sent 0.03364154 ZEC from Edge wallet to Maya’s active asgard vault t1RBkNhHAwZcrhN3YmJ9wS8eCcAVWFQg7oh, swapping to USDT on Arbitrum. Txid: 1c50121b5d842c97f70096b6056c23428c814b7013e1460cd78511263aedd384, block 3440800.
Maya has never observed it. /mayachain/tx/status returns inbound_observed: started=false, and Midgard has no action for the txid.
/mayachain/lastblock has ZEC last_observed_in pinned at 3440653, mined 2026-08-08 11:53:44 UTC — no movement in over 28 hours — while all 38 active nodes report their own ZEC scanner height at 3441854. So the scanners advance but observations never register. HALTZECCHAIN, HALTZECTRADING, SOLVENCYHALTZECCHAIN and HALTSIGNINGZEC are all 0, and Zcash itself is producing blocks normally at ~75s. The last ZEC deposit of any kind in Midgard is 2026-08-06 03:54 UTC.
Meanwhile the vault already spent my UTXO in tx db2810547f773452cf961e394cdefb405d72779d0c80c5f81e68e9591d6b12d8, block 3441017 — so the funds are in protocol custody and in use, with no swap credited.
I sent from shielded funds, so the transaction has no OP_RETURN — one transparent output, no nulldata. The memo shown by my wallet is =:ARB.USDT:0x9fEbA620E7cd7008aEdfB20297974fA8402dEe9b:0/1/1:ej:75, so the destination is unambiguous. A shielded sender means there is no refund path.
Is anyone able to pass this to the Maya operators, or say whether stalled blocks get replayed once observation recovers?
Thank you, that’s the first clear answer I’ve had — much appreciated If there’s any consideration for the affected users when it’s settled, that would be very welcome — but mainly I’m just glad it’s being handled.
If there’s any consideration for the affected users when it’s settled, that would be very welcome — but mainly I’m just glad it’s being handled.