Search
Search for projects by name or address
Zcash via NEAR Intents
This route has no Ethereum contracts. Real-time monitoring is not supported.
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.
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.
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 (formerly Zashi), the Electric Coin Company’s self-custodial wallet, which embeds the NEAR Intents swap directly and pays out into shielded addresses.
Flow
- 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, also an EOA, and mints a wrapped token (eth.omft.nearoreth-0x…omft.near) on NEAR. There is no multisig or onchain verification on either side. The mint memo names the Ethereum transaction hash. - 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. Every balance and swap is public state on the NEAR blockchain. - Withdraw into Zcash. The wrapped ZEC (
zec.omft.near) is burned through the Zcash connectorzcash-connector.bridge.near, which builds a transaction from bridge UTXOs and has it signed by NEAR’s MPC network (v1.signer, 9/15 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. - Inside Zcash. The ZEC now sits in the shielded pool. Transfers inside the pool hide sender, recipient and amount.
- 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.nearon 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.
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, every address registers its past and future actions publicly. 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.
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.
How to keep it private: 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.
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.
How to keep it private: Hold the ZEC in the pool for days, split or merge it with other shielded funds, and swap back amounts that match no payout.
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 but is off by default and does not cover block sync. Ethereum RPCs and NEAR relayers see only what is public anyway.
How to keep it private: Turn on Tor in Zodl before the first swap, pin one server or your own lightwalletd in manual mode, and use a separate wallet account per round trip.
The Operator runs the 1Click 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, session or timing. It screens every address with KYT vendors, can lock any account and can hold bridged funds.
How to keep it private: Use Tor for both legs, and do them from different sessions days apart with amounts that do not match.
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.
How to keep it private: Use a separate Zodl account per round trip, so one recovered key exposes only that trip.
Funds can be stolen if
- the custodial bridge operator’s single mint key or its Ethereum treasury key is compromised.
- 4/5 NEAR Intents DAO council members upgrade the Verifier maliciously.
- 2/5 Rainbow Bridge DAO council members upgrade the Zcash connector, its token or the light client maliciously.
- 9/15 NEAR MPC nodes collude to sign Zcash transactions from bridge addresses.
Funds can be frozen if
- the DAO or one of the two single-key account lockers freezes the user’s account in the Verifier.
- the custodial bridge operator freezes a deposit or withdrawal for a compliance review.
- the whitelisted relayers stop proving Zcash deposits or triggering Zcash withdrawals.
Privacy can be lost if
- 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.
- the same Zcash address receives more than one payout, since every payout note is decryptable by anyone.
- the operator or its screening vendors join the two legs through IP address, session or partner key. Tor is off by default in Zodl.
- the lightwalletd server links the wallet’s fetch of the payout transaction with its later broadcast of the exit.
- elliptic-curve cryptography is broken: all of an account’s addresses share one incoming viewing key, and the addresses are public.
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 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 a 2/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 (9/15) 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.
Transparent setup
Detailed description
Transparent proving systems require no trusted setups and have no additional setup-related trust assumptions.