Khalani: Reducing ZEC Cross-Chain Dependency with a Second Intent-Based Rail

Community Grants Applications
1

Khalani: Reducing ZEC Cross-Chain Dependency with a Second Intent-Based Rail

Implementation Complete, Onboarding to Production, with a Path Toward a Privacy-Native Attestation Layer

Khalani has completed implementation of a transparent-ZEC cross-chain intent provider as ecosystem-resilience infrastructure and is onboarding to production. We plan to submit this as a Zcash Community Grants proposal and post this forum thread alongside that submission. This post is intended to gather community input on the transparent-ZEC corridor and to share the longer-term architecture we’d like to bring back to the community as a separate proposal if there is interest.

TL;DR

  • What: Khalani has implemented a transparent-ZEC cross-chain intent provider, a second independent cross-chain rail for ZEC alongside NEAR Intents, to reduce the ecosystem’s single-provider dependency.

  • Status: Implementation complete and in internal testing; onboarding to mainnet now, targeted live as soon as production onboarding is complete.

  • Ask: $45,000 via a Zcash Community Grants proposal. Scope is the transparent ZEC corridor only.

  • Architecture: Intent-based settlement with an open, permissionless solver market. Not a wrapped-asset bridge, not a pool-based DEX, not custodial. Canonical ZEC in, canonical assets out.

  • Phase 2 (separate future proposal, not part of this ask): a pluggable privacy-native attestation layer so shielded-ZEC flows can be supported without every wallet, app, and solver needing to reimplement shielded custody, with a long-term path to FROST-RedPallas threshold attestation.

  • Why now: This post accompanies the formal Zcash Community Grants submission so the community can evaluate the proposal and provide input in parallel.

Note on what this is and isn’t

  • This is a community signal-gathering post that accompanies a formal Zcash Community Grants proposal.

  • The formal application will be submitted through the Zcash Community Grants process. Production onboarding is underway, but this proposal is not tied to a specific CDRGP deadline or review-period launch commitment.

  • The ask in the formal application will be $45,000

  • This is not a wrapped asset bridge, an AMM-pool-based DEX, or a custodial swap service. The architecture is intent-based with an open solver market; canonical ZEC in, canonical ZEC out.

1. Why a second provider matters today

Zcash users currently have one production-grade cross-chain intent rail: NEAR Intents, integrated by Zodl CrossPay, Brave, and others. It works well. But the ecosystem is one major outage, jurisdictional shift, or solver-network problem away from losing its primary cross-chain swap UX. A community whose entire cross-chain settlement story runs through a single external network is fragile.

A second cross-chain intent provider, independently operated with a different architectural backbone, meaningfully improves ecosystem resilience. We’ve completed the engineering work and are moving it to production now.

2. What we are not building

Three things this is not, because prior conversations on the forum have surfaced these patterns and we want to be unambiguous up front:

  • Not a wrapped asset bridge. Users deposit canonical ZEC and receive canonical assets on the destination chain (or canonical ZEC, depending on the swap direction). The terminal asset on either end is always native, not wrapped.

  • Not a liquidity-pool-based DEX. No constant-product, no stableswap, no pool curve. There is no LP token, no impermanent loss, no pool depth dependency.

  • Not a custodial swap service. Custody of published intents is on-chain at the protocol layer, not sent into a centralized exchange.

What it is: an intent-based settlement system with an open solver market. Users sign intents specifying what they want (asset, amount, destination, expiry). Permissionless solvers compete to construct match plans, and the match engine atomically settles winning solutions across multi-leg routes (e.g., ZEC → USDC-on-Base).

3. What we’ve built (implementation complete, internally testing)

The transparent ZEC corridor implementation is complete and currently in internal testing. Production onboarding is underway, targeted to be live on mainnet as soon as onboarding is complete.

Capability Status
Transparent ZEC deposit order binding with OP_RETURN intent tags Implementation complete; internal testing
ZEC spoke adapter written in Rust Implementation complete
Smart contract for treasury account accounting and payment authorization Implementation complete
Cross-chain corridors targeting Ethereum, Base, Arbitrum, Polygon, BNB, Tron EVM spokes in production; ZEC corridors pending onboarding
Integrator-facing API surface for quote / build / submit / status Implementation complete
Solver-facing API surface for websocket-based order broadcast, solution submission, and settlement confirmation Implementation complete
Multi-leg intent routing Implementation complete
Reorg detection and rollback handling Implementation complete; tested under simulated reorg
Refund flow with operator-signed refund authorization + retry budget Implementation complete

This grant application is explicitly not covering shielded ZEC capability. We do, however, want to show the community our existing research and commitment to bring shielded support online if there is community interest. We would file that work separately as a future Zcash Community Grants proposal, rather than folding it into this transparent-corridor ask.

4. What we’re asking for in the formal application

The Zcash Community Grants proposal:

  • $45,000

  • Work already substantially completed. Khalani has committed to the work and taken the engineering cost of implementation before asking the community to fund this scope

  • Verifiable against public mainnet swap activity

  • Scoped to the transparent ZEC corridor only. Shielded support is a separate future ask

5. What we are NOT asking for in this proposal

To be unambiguous:

  • We are not asking for funding to build the privacy-native attestation layer in this proposal.

  • The $45,000 figure in the formal application is for the transparent corridor only.

The privacy-native architecture, if the community wants it built, would be a separate, later proposal with its own scope and budget.

6. Phase 2: continuing toward privacy-native support

We see the transparent-ZEC implementation as phase 1: a practical, verifiable way to add a second cross-chain ZEC intent provider now. The continuation is to support privacy-native Zcash flows without forcing every wallet, app, and solver to become a Zcash privacy expert.

The hard problem is that decentralized custody normally wants assets and state to be publicly legible. Public commitments make it easier for external actors to verify balances, enforce settlement, and hold operators accountable. Privacy-native systems intentionally make assets and state publicly illegible. That is the point, but it creates a real design tension when the system still needs accountability, refunds, solver settlement, and user confidence.

Current cross-chain ZEC solutions resolve this tension by relying on commitments that are visible on a transparent ledger. That is a valid trade-off, and it works today. NEAR Intents is an example of this family: the base rail is publicly legible, and privacy can improve when wallets integrate carefully around it. But that wallet-level integration has a high bar, and metadata can still leak at the boundary between the shielded wallet, the transparent settlement rail, and the destination chain.

The architecture we’d like to build next offers the community a different trade-off choice: a pluggable privacy-native attestation layer. Apps integrate with an attestation provider that can run under different trust assumptions, rather than each app implementing shielded-ZEC custody and attestation logic from scratch. Behind the API, the provider role is pluggable:

  • Single-attestation: suitable for trusted-counterparty flows (B2B integrations, partner-agreed deployments)

  • TEE-attested: hardware- decure encrave based attestations to verify runtime execution validity

  • Distributed oracle network: economic-security-rooted attestations

  • FROST-RedPallas threshold: the long-term direction for fully decentralized custody, Orchard-native because RedPallas is a Schnorr variant; ZF maintains frost-rerandomized as the reference implementation

The provider is selected per integration. The Zcash ecosystem ends up with an open market for shielded-asset attestation providers that compete on operational model, trust assumptions, privacy properties, and decentralization. It also creates a clean path to future-proof the interface around FROST-RedPallas research as that work matures.

                 Privacy preservation
                         HIGH
                          │
   Single-operator or     │   Phase 2 Khalani direction:
   committee-controlled   │   privacy-native attestation
   attestation providers  │   provider market, future-proofed
                          │   for FROST-RedPallas variants
                          │
                          │   Wallet-integrated NEAR Intents:
                          │   stronger user privacy when
                          │   integrated carefully, but high
                          │   integration bar and boundary
                          │   metadata-leak risk
                          │
──────────────────────────┼──────────────────────────  Operator decentralization
                          │
                          │   Base NEAR Intents rail:
                          │   decentralized execution with
                          │   publicly visible commitments
                          │
   Custodial CEX          │   Khalani phase 1:
   or OTC desk            │   transparent delegator launch;
                          │   on-chain smart-contract settlement
                          │   plus OP_RETURN Zcash reconciliation
                          │
                         LOW

We’re sharing this as the continuation we would like to pursue after phase 1, not as part of this funding request. The present application remains limited to the transparent-ZEC corridor.

7. How we’ll demonstrate operational readiness

We will share evidence of implementation completion, internal testing, and production onboarding status in the Zcash Community Grants proposal and forum thread. Once mainnet operation is live, we will provide public swap activity and operational updates for community review.

8. The trade-offs we’re open about

  • The Zcash transparent delegator launch will be operated by Khalani to provide users a good initial UX. Intent settlement and refund processing are smart-contract based, with OP_RETURN-based transparent-Zcash reconciliation. This is a similar operating approach to the existing NEAR Intents architecture: start with a usable, managed integration surface while keeping settlement logic and reconciliation evidence on-chain.

  • The privacy-native vision is separate from this proposal. If the community wants it, we would propose an attestation-provider interface where different providers can run under different trust assumptions.

  • Counterparty-leg privacy is not preserved in any cross-chain swap, ours or anyone else’s. The non-ZEC leg settles transparently on the destination chain. We claim the privacy properties Zcash can realistically preserve.

9. Team / Organizational Structure

Core team on this grant:

  • Kevin Wang, CEO. Co-founded Nervos, a UTXO-based L1. Shipped protocol from zero to mainnet with millions of transactions in production. On this grant: technical oversight of the spoke adapter architecture (UTXO accounting, settlement semantics, operational design). UTXO-model L1 work is the most directly transferable possible background for a ZEC spoke adapter.

  • Tannr Allrd, CTO. Core contributor at the Maker Foundation. Maintained DAI’s financial infrastructure at peak scale ($5B+ TVL) with zero critical failures. On this grant: lead on mZEC accounting and adversarial-condition hardening; primary technical reviewer for the spoke adapter’s settlement guarantees.

  • Patrick Young, COO. Previously VP Partnerships and Marketing at Galxe. Previously Head of Web3 at Chainlink Labs, where he scaled integrations to $30B+ TVL. On this grant: ecosystem engagement & integration partnerships for the corridor.

10. Why this matters

ZEC’s value as a privacy-preserving asset depends on users being able to move it across the broader ecosystem without giving up its privacy properties. Today that path runs through one external provider. We’re proposing to be a second: modest and verifiable on the transparent side now, with a path toward a privacy-native attestation marketplace if the community wants it built.

Feedback welcome in the forum thread and throughout the Zcash Community Grants review process.