# Zcash via NEAR Intents Markdown version of https://l2beat.com/privacy/projects/zcash-near-intents ## Summary **Warning:** This route has no Ethereum contracts. Real-time monitoring is not supported. - Metrics: Not tracked. Data tracking is not available for this project. - Tracked on: Ethereum - Attributes: Bridged, ZK, Transfers, Any amount ### Risks - Trusted setup: Transparent setup (sentiment: neutral). Transparent setup: No trusted setup and no additional setup-related trust assumptions. - Exit window: None (sentiment: bad). The Verifier can be upgraded at once by 4/5 NEAR Intents DAO members, the Zcash bridge by 3/5 Rainbow Bridge DAO members with no verified delay, and the Ethereum-side funds sit in an operator-controlled EOA, so there is no window to leave before a change takes effect. This protocol does not pass the walkaway test: users cannot fully use it if all centralized protocol participants disappear. Ethereum deposits and withdrawals are executed off-chain by the custodial bridge operator, and Zcash withdrawals need a whitelisted relayer to trigger the MPC signature. Without the operators, only Zcash deposits that were never credited can be refunded, after a two-day timelock. - Privacy: Link privacy. Public observer: Link private (sentiment: good); Chain analyst: Link private (sentiment: good); Network observer: Link at risk (sentiment: warning); Privileged insider: Link exposed (sentiment: bad); Future adversary: Link exposed (sentiment: bad). - Reproducibility: Partially reproducible (sentiment: warning). The Verifier, the custodial bridge token, the Zcash bridge and the Zodl wallet are open source, but the bridge back end, the 1Click API and the solver relay are closed services that every Ethereum leg depends on. ### About A round trip from Ethereum into shielded ZEC and back through NEAR Intents, so that Zcash's shielded pool serves as the privacy pool. ### Links - Website: https://near-intents.org, https://z.cash, https://zodl.com - Docs: https://docs.near-intents.org, https://zips.z.cash/protocol/protocol.pdf - Explorer: https://nearblocks.io/address/intents.near, https://nearblocks.io/address/zcash-connector.bridge.near, https://etherscan.io/address/0x2CfF890f0378a11913B6129B2E97417a2c302680 - Repository: https://github.com/near/intents, https://github.com/Near-One/btc-bridge, https://github.com/Near-One/btc-light-client-contract, https://github.com/defuse-protocol/defuse-frontend, https://github.com/zodl-inc/zodl-ios - Social: https://x.com/near_intents, https://x.com/zodl_app - Other: https://docs.near-intents.org/security-compliance/terms-of-service, https://docs.near-intents.org/security-compliance/risk-and-compliance, https://mpc-operators.nearone.org/ ## Protocol description Zcash via NEAR Intents touches three blockchains, but can be abstracted as a privacy pool with Ethereum as its base: Ethereum assets are bridged to the NEAR Intents ledger, swapped into ZEC and paid out into Zcash's shielded pool, where the actual privacy lives. To come back, the ZEC is sent to a fresh NEAR Intents deposit address, swapped and withdrawn to any Ethereum address. The reference client is [Zodl](https://zodl.com) (formerly Zashi), the Electric Coin Company's self-custodial wallet, which embeds the NEAR Intents swap directly and pays out into shielded addresses. ### Flow 1. **Ethereum to NEAR Intents.** Each swap quote from the 1Click API comes with a fresh Ethereum deposit EOA. The user sends ETH or an ERC-20 there. The operator's so-called Proof-of-Authority (PoA) bridge, in practice a custodial bridge with a single admin key, sweeps the funds into its treasury account [`0x2CfF…2680`](https://etherscan.io/address/0x2CfF890f0378a11913B6129B2E97417a2c302680), also an EOA, and mints a wrapped token (`eth.omft.near` or `eth-0x…omft.near`) on NEAR. There is no multisig or onchain verification on either side. The mint memo names the Ethereum transaction hash. 2. **Swap to ZEC.** Market makers quote off-chain through a relay run by the operator. The winning quote settles atomically in the Verifier contract [`intents.near`](https://nearblocks.io/address/intents.near). Every balance and swap is public state on the NEAR blockchain. 3. **Withdraw into Zcash.** The wrapped ZEC (`zec.omft.near`) is burned through the Zcash connector `zcash-connector.bridge.near`, which builds a transaction from bridge UTXOs and has it signed by NEAR's MPC network (`v1.signer`, 11/17 signers). The payout can be a shielded Orchard output into the Ironwood pool. Zodl requests a fresh shielded address for every swap. The recipient address is published in the burn message on NEAR. 4. **Inside Zcash.** The ZEC now sits in the shielded pool. Transfers inside the pool hide sender, recipient and amount. 5. **Back to Ethereum.** The user sends ZEC from the pool to a fresh bridge deposit address, a transparent address derived by the connector from the quote. A whitelisted relayer proves the deposit against the Zcash light client `zcash-client.bridge.near` on NEAR, wrapped ZEC is minted and swapped, and the custodial bridge operator pays the Ethereum recipient from its treasury. ### Privacy considerations Nothing on Ethereum or NEAR is hidden: the Ethereum sender, asset and amount, the swap, the Zcash payout address and the Zcash amount are all public, and the same holds for the return leg. The only privacy the route offers is that the shielded pool breaks the link between the ZEC paid out in step 3 and the ZEC deposited in step 5. The connector requires every shielded payout to be encrypted with an all-zero outgoing viewing key so that the contract can check it, which means anyone can decrypt the paid address and amount of every NEAR Intents payout. And the amounts that enter and leave the pool are public, so a round trip of similar size within a short time is linkable by the well-known Zcash round-trip heuristic. The Zcash side of the flow is only as private as the wallet. Zodl syncs through public lightwalletd servers and offers Tor as an opt-in setting. The 1Click API sees the IP address and both addresses of every leg. ### Custody and control The Ethereum leg is fully custodial: the treasury and deposit addresses are EOAs controlled by the operator, and a single key (`bridge-mng.near`) mints the wrapped tokens. Deposits and withdrawals on the Ethereum side are executed by off-chain services. The Verifier lets two single-key accounts and the DAO freeze any account's balance, which the operator uses for compliance holds. On Zcash, funds are held by MPC-derived addresses, deposits are verified against an on-chain light client, and an unverified deposit can be refunded permissionlessly after a two-day timelock. Normal withdrawals still need a whitelisted relayer to trigger the MPC signature. ### Fees The Verifier charges 1 pip (0.0001%) per swap. The 1Click API adds 0.25% (25 bps) for unauthenticated integrators and 0.20% (20 bps) for authenticated ones such as wallets, which may add their own fee on top. Each leg also carries a bridge withdrawal fee, currently 0.000035 ETH on Ethereum and 0.00032 ZEC on Zcash. ### Compliance Intents Technology Ltd. (British Virgin Islands) screens every quote against the NEAR Intents AML portal, Binance AML, AMLBot, PureFi and TRM Labs. Its terms allow it to delay, block or freeze bridged funds, collect IP and wallet addresses, and geoblock a list of jurisdictions. Market makers must pass KYB. No KYC is asked of end users, but funds have been held for weeks during compliance reviews, and swaps were paused network-wide after the Rhea Finance exploit in April 2026. ### Anonymity set The anonymity set is the Zcash Ironwood shielded pool. Because payout and deposit amounts are public at the pool edge, the effective set behind a user's exit is the set of pool entries (public on NEAR) that could match it in amount and time, not the whole pool. ## Privacy **What the protocol promises:** Hides which funds leaving Ethereum come back as which, by passing through Zcash's shielded pool. Everything on Ethereum and NEAR is public. On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note. ### Public observer Link private (sentiment: good) **Who:** Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links. Examples: A curious counterparty, an employer, a journalist. Nothing ties the ZEC that enters the shielded pool to the ZEC that leaves it. Everything up to the pool edge is public: the Ethereum deposit, the NEAR ledger entries that credit, swap and withdraw it, and the Zcash address and amount of every payout, which the bridge encrypts so that anyone can decrypt them. **Advice:** Receive the ZEC straight into a fresh shielded address, as Zodl does per swap, and pay the return leg from the pool. The web app pays transparent addresses only, which adds a public shielding step. **Inside** - Sender: private - Recipient: at risk. Payout notes are decryptable by anyone, so a reused address ties payouts together. - Amount: private - Asset: exposed. Only ZEC exists inside the pool; the assets swapped from and to are public on NEAR. - Link: private **Sources** - [Custodial bridge mint carries the Ethereum transaction hash in its memo](https://nearblocks.io/address/eth.omft.near) - [Withdrawal message names the target Zcash address](https://github.com/Near-One/btc-bridge/blob/4711c2f1d035a208464b9729bb24e45ed9ab7831/contracts/satoshi-bridge/src/api/token_receiver.rs#L8-L16) - [Payouts are encrypted to an all-zero outgoing viewing key](https://github.com/Near-One/btc-bridge/blob/4711c2f1d035a208464b9729bb24e45ed9ab7831/contracts/satoshi-bridge/src/zcash_utils/orchard_policy.rs#L13-L63) - [Zodl requests a fresh shielded address per swap](https://github.com/zodl-inc/zodl-ios/blob/15f1eed4024d2c996b0d38c746d5aed235704a01/secant/Sources/Features/SwapAndPayForm/SwapAndPayStore.swift#L943) - [Web app accepts transparent and TEX addresses only](https://github.com/defuse-protocol/defuse-frontend/blob/752a7838d1e73b00e6965a9cb6a08af68b447e41/src/components/DefuseSDK/utils/validateAddress.ts#L131-L145) ### Chain analyst Link private (sentiment: good) **Who:** Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters. Examples: Chain analytics firms, ZachXBT, data brokers. The amount paid into the pool and the amount later sent to a bridge deposit address are both public with their timing, so a round trip of similar size within hours pairs them. Deposit addresses are fresh per quote but spent together with the bridge change address, so every exit is attributable to NEAR Intents. **Advice:** Hold the ZEC in the pool for days, split or merge it with other shielded funds, and swap back amounts that match no payout. **Inside, compared with a public observer** - Recipient: at risk - Asset: exposed - Link: at risk. Round-trip amount and timing across the pool edge pair a payout with a later deposit. **Sources** - [Kappos et al., An Empirical Analysis of Anonymity in Zcash (USENIX 2018)](https://arxiv.org/abs/1805.03180) - [Deposit address derived per quote from the deposit message](https://github.com/Near-One/btc-bridge/blob/4711c2f1d035a208464b9729bb24e45ed9ab7831/contracts/satoshi-bridge/src/deposit_msg.rs#L49-L52) - [Bridge change address and UTXO set](https://nearblocks.io/address/zcash-connector.bridge.near) ### Network observer Link at risk (sentiment: warning) **Who:** Sits between the user and the chain and sees web2 traffic only: RPC providers, relayers and broadcasters, indexers, ISPs. Learns IP addresses, timing, browser fingerprints, ciphertext and what becomes public. Assumes Tor to send transactions and, where the client has an RPC setting, an own node to read the blockchain. Examples: Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend. Zodl syncs through public lightwalletd servers, which see which transactions the wallet fetches and broadcasts, and so the payout and the later exit of the same wallet. Tor covers these calls and the swap requests including session isolation but is opt-in and does not cover block sync. **Advice:** Turn on Tor in Zodl before the first swap. **Inside, compared with a public observer** - Recipient: at risk - Asset: exposed - Link: at risk. The lightwalletd server sees the wallet fetch the payout and later broadcast the exit. **Sources** - [Tor is off unless the user enables it](https://github.com/zodl-inc/zodl-ios/blob/15f1eed4024d2c996b0d38c746d5aed235704a01/secant/Sources/Dependencies/SDKSynchronizer/SDKSynchronizerLive.swift#L28) - [Default lightwalletd endpoint](https://github.com/zodl-inc/zodl-ios/blob/15f1eed4024d2c996b0d38c746d5aed235704a01/secant/Sources/Dependencies/ZcashSDKEnvironment/ZcashSDKEnvironmentInterface.swift#L21) - [Zashi 2.1: which calls Tor covers](https://electriccoin.co/blog/zashi-2-1-enhanced-privacy-with-tor-beta/) - [Hornby, Fixing Privacy Problems in the Zcash Light Wallet Protocol](https://defuse.ca/downloads/Fixing%20Privacy%20Problems%20in%20the%20Zcash%20Light%20Wallet%20Protocol.pdf) ### Privileged insider Link exposed (sentiment: bad) **Who:** Holds a protocol operator role or receives keys or plaintext by design: upgrade admin, sequencer, decryption or view key holder, TEE vendor, association set provider, hosted prover, note registry. Examples: A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator. The Operator runs the 1Click bridge API, the Ethereum custody and the screening, so both legs sit in its logs with the IP address and wallet identifiers of each request, plus the fresh Zcash refund address Zodl attaches to every swap out of ZEC. It has no key into the shielded pool, so joining the legs still needs IP or timing. It screens every address with KYT vendors, can lock any account and can hold bridged funds. **Advice:** Always use the Zodl Tor feature, wait some time in the shielded pool and use amounts that do not match. **Inside, compared with a public observer** - Recipient: private - Asset: exposed - Link: at risk. IP address, partner key and timing of both legs sit in one operator's logs. **Sources** - [1Click terms: IP and wallet data, screening, freezes](https://docs.near-intents.org/security-compliance/terms-of-service) - [Screening providers](https://docs.near-intents.org/security-compliance/risk-and-compliance) - [Any account can be locked by DAO or locker role](https://github.com/near/intents/blob/fa44ede9e874931c39a6c4246de82bc40f4f8d99/defuse/src/contract/accounts/force.rs#L21-L33) - [Owner-only mint of the wrapped Ethereum assets](https://github.com/near/intents/blob/fa44ede9e874931c39a6c4246de82bc40f4f8d99/poa-token/src/contract.rs#L79-L81) - [Zodl sends its partner key and refund address with each quote](https://github.com/zodl-inc/zodl-ios/blob/15f1eed4024d2c996b0d38c746d5aed235704a01/secant/Sources/Dependencies/SwapAndPay/sources/Near1Click.swift#L313-L344) - [Upgrades & Governance](https://l2beat.com/privacy/projects/zcash-near-intents#upgrades-and-governance) ### Future adversary Link exposed (sentiment: bad) **Who:** Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and future cryptanalysis such as a large quantum computer that breaks elliptic-curve key exchange and pairings, but not hashes, symmetric ciphers or lattices. Examples: First well-funded insiders, then everyone in a potential post-quantum future. All of an account's rotated addresses share one incoming viewing key on the Pallas curve, and every payout address is public on NEAR. A quantum computer recovers that key from any one address and decrypts every note the account ever received, including the change notes of its exits, which joins both legs of every round trip. Ironwood's quantum-recoverable notes protect funds, not privacy. **Advice:** Use a separate Zodl account per round trip, so one recovered key exposes only that trip. **Inside, compared with a public observer** - Sender: at risk. Spends are found through the change notes they pay back to the same account. - Recipient: exposed - Amount: exposed - Asset: exposed - Link: exposed **Sources** - [Orchard key agreement on the Pallas curve](https://zips.z.cash/protocol/protocol.pdf#concreteorchardkeyagreement) - [ZIP 2005: quantum recoverability, not quantum privacy](https://zips.z.cash/zip-2005) - [Payouts are encrypted to an all-zero outgoing viewing key](https://github.com/Near-One/btc-bridge/blob/4711c2f1d035a208464b9729bb24e45ed9ab7831/contracts/satoshi-bridge/src/zcash_utils/orchard_policy.rs#L13-L63) ## Risk summary ### Funds can be stolen if 1. the custodial bridge operator's single mint key or its Ethereum treasury key is compromised. 2. 4/5 NEAR Intents DAO council members upgrade the Verifier maliciously. 3. 3/5 Rainbow Bridge DAO council members upgrade the Zcash connector, its token or the light client maliciously. 4. 11/17 NEAR MPC nodes collude to sign Zcash transactions from bridge addresses. ### Funds can be frozen if 1. the DAO or one of the two single-key account lockers freezes the user's account in the Verifier. 2. the custodial bridge operator freezes a deposit or withdrawal for a compliance review. 3. the whitelisted relayers stop proving Zcash deposits or triggering Zcash withdrawals. ### Privacy can be lost if 1. the ZEC is swapped back in an amount and at a time that matches the payout; both are public at the edge of the shielded pool. 2. the same Zcash address receives more than one payout, since every payout note is decryptable by anyone. 3. the operator or its screening vendors join the two legs through IP address, session or partner key. Tor is off by default in Zodl. 4. the lightwalletd server links the wallet's fetch of the payout transaction with its later broadcast of the exit. 5. elliptic-curve cryptography is broken: all of an account's addresses share one incoming viewing key, and the addresses are public. ## Upgrades & Governance The route touches three governed systems. None of them has an onchain delay that a user could rely on, and the Ethereum side has no contracts at all. ### NEAR Intents Verifier (`intents.near`) The Verifier is a NEAR contract with `near-plugins` roles. `intents.sputnik-dao.near`, a Sputnik DAO with five council members and a 4/5 threshold, holds the `DAO` role and is super admin, so it can grant every other role. Upgrades go through `ctl-intents.near`, a controller contract whose only admin is the same DAO. A passed proposal deploys the new code at once. Six accounts hold `PauseManager` and can halt all swaps and withdrawals. Nobody holds `UnpauseManager`, so only the DAO can resume. Two EOAs each hold `UnrestrictedAccountLocker` and can lock any user account, which stops its intents and withdrawals while deposits keep arriving, only the DAO can unlock. ### Custodial "PoA" bridge (`omft.near`, `eth.omft.near`) Despite the name, nothing here is a proof-of-authority consensus or a multisig. The `poa-factory` contract `omft.near` deploys one token per bridged asset and mints on the permission of `TokenDepositer`: `bridge-mng.near`, an EOA, and `int-mnt-dao.sputnik-dao.near`, a three-member DAO whose members can each execute a call alone. The same DAO as above is super admin. Nothing on NEAR verifies that a mint is backed. On Ethereum the funds sit in the escrow [`0x2CfF…2680`](https://etherscan.io/address/0x2CfF890f0378a11913B6129B2E97417a2c302680) and in per-quote deposit accounts, all plain EOAs. ### Zcash connector (`zcash-connector.bridge.near`, `zec.omft.near`, `zcash-client.bridge.near`) The connector, the token's controller and the light client are all governed by `rainbowbridge.sputnik-dao.near`, a Sputnik DAO with five council members and a 3/5 threshold. `bridge-ops.near` (five EOAs) can stage code, pause the connector and run migrations; `pm.bridge.near` can pause. Deposits are credited only after `omni-relayer.bridge.near` or `intents-relayer.near` submit an inclusion proof against the light client, whose headers are relayed by `zcash-relayer.near`. Withdrawals are signed by the NEAR MPC network `v1.signer` (11/17, see the [MPC operators page](https://mpc-operators.nearone.org/)) on request of a whitelisted relayer. A user cannot trigger the signature alone. The one permissionless path is a refund of a deposit that was never credited, executable by anyone after a two-day timelock (fourteen days when the relayer has flagged the request). Bridge fees are 0.0001 ZEC minimum per deposit and withdrawal, adjustable by the DAO. ## Trusted setup Risk levels follow the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381). Yellow (medium risk): all contributions are published and the final output can be verified, the ceremony client is open source, there were at least 30 contributions, participation was open to the public and announced, and participants are publicly identified. Green (lowest risk): everything required for yellow, with at least 150 contributions. Red (highest risk): at least one requirement for yellow is not met. N/A: the proof system needs no trusted setup. ### Transparent setup - Risk: N/A (no trusted setup) - Proof systems: Halo2 (Plonk) Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.