Maya Protocol Advanced Shielded ZEC Support (Retroactive Grant)

Retroactive Grant Application - Maya Protocol Advanced Shielded ZEC Support

Full application on GitHub: Issue #19 - Retroactive Grant Application - Maya Protocol Advanced Shielded ZEC Support


Organization

Maya Protocol

Application Owner

@ahdzib-maya (Itzamna)

Requested Grant Amount

$45,000

Category

Infrastructure


Project Summary

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:

            1. Swap any supported asset (BTC, ETH, RUNE, CACAO, stablecoins, etc.) directly into a shielded ZEC address
              1. Swap from shielded ZEC into any other supported asset
                1. Do so without KYC, sign-ups, or custodial risk
              2. 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.
            2. Proof of Completion

          • All work is publicly verifiable in the MAYANode GitLab repository. Key merged merge requests include:
        • Core Shielded Support:
21 Likes

+1, this is extremely important work. I’d support doubling the reward. Thank you Maya!

7 Likes

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.

+1 for shielded support everywhere.

5 Likes

Cross-posting my question to NEAR here as it applies to Maya as well.

Maya: Can we get clarity on how you implemented shielded support, and where exactly in your stack Orchard/shielded is supported?

AFAIK full Orchard support would require that Maya validators move to FROST for liquidity storage instead of using TSS.

(cross-post context below)

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

4 Likes

You’re right, support right now is as you mention “traceable orchard”. Right now, it has to go through our transparent vault.

Just to clarify, FROST is TSS. We currently do GG20 and would have to add FROST to fully support orchard.

4 Likes

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.

8 Likes

+1. I support this work.

5 Likes

Support for decentralized swapping and liquidity is very important. Maya team has been great to ZEC. Wishing this goes through

4 Likes

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.

4 Likes

In support of this :heart_eyes:

3 Likes

+1
This work by Maya is priceless. Thank you guys :slight_smile:

4 Likes

I strongly support this grant.

6 Likes

Well-earned and well-deserved grant! Thanks for strengthening privacy-preserving money and the Zcash ecosystem.