Privacy
Zecpass makes one claim: nothing on Robinhood Chain links the address that receives $ZECPASS to the ZEC that paid for it. This page states what that claim rests on, what it does not cover, and how it can be broken by the user.
The observers
Walk the road and ask, at each step, what is public.
On Zcash
The user sends from a shielded balance to a transparent deposit address. Zcash calls this a deshielding transaction. On the chain it shows:
- the amount received by the transparent address,
- the transparent address itself,
- the block time.
It does not show the sending address, the sender's balance, or any earlier transaction. The shielded pool's zero-knowledge proofs are what hide them; Zecpass adds nothing to that and takes nothing from it.
What an observer of Zcash learns: somebody deshielded X ZEC to a NEAR Intents address at time T. NEAR Intents deposit addresses are recognisable as such. So the observer learns that a NEAR Intents swap of X ZEC started at T, and nothing about who.
At NEAR Intents
1Click sees the deposit, the quote it issued, the destination (the relayer's address on Arbitrum One) and the refund address (the user's transparent address). It does not see the shielded sender. It knows the refund address belongs to the same user, which is why the refund address should be a fresh transparent address, not one you use to receive from exchanges.
NEAR Intents publishes swap history through its explorer API. A swap of X ZEC to the Zecpass relayer at time T is discoverable there. That is public information about Zecpass volume, not about any user.
On Arbitrum One
The solver pays ETH to the relayer address. The relayer sends ETH to Relay's deposit contract with the user's pass encoded as the recipient. Both are public. An observer of Arbitrum One learns: the Zecpass relayer received Y ETH at T+7min and forwarded Y ETH to Relay toward pass P at T+7min. This is the link the relayer creates and the reason the relayer is the weak point, discussed below.
At Relay
Relay sees the relayer's deposit and the pass address. It learns the same thing as the Arbitrum observer.
On Robinhood Chain
Everything is public: ETH arriving at pass P, the sweep, the buy on the Pons curve, the transfer of $ZECPASS to the beneficiary B. Pass P is derived from B, so P and B are the same identity. An observer of Robinhood Chain learns: B received tokens bought with Y ETH that came through Relay from the Zecpass relayer. They can walk back to Arbitrum One and see the relayer received Y ETH from a NEAR Intents solver. They can then look at NEAR Intents and see that a swap of X ZEC produced that Y ETH. They can then see, on Zcash, that X ZEC was deshielded at time T.
And there the walk ends. The Zcash side is a wall. Every step back from B stops at some shielded balance sent X ZEC.
So what is the claim, exactly
The road is fully traceable from the beneficiary back to the deshielding transaction, and untraceable from the deshielding transaction back to a person. This is a precise statement, and it is enough for what Zecpass promises: the Robinhood Chain address has no owner that the chain can name.
It is not anonymity of the Robinhood Chain address going forward. Whatever B does next is public, as on any EVM chain.
The relayer, honestly
In bridge mode the relayer holds the user's ETH on Arbitrum One for seconds, and it is the party whose transactions link a NEAR Intents settlement to a pass. Two things follow.
It could steal. One order's worth of ETH, once, and then the site, the stats page and the NEAR Intents explorer would all show it. The hub vault and the treasury are worth more than one order. Instant mode is capped per order and per day for the same reason in the other direction: the relayer key cannot drain the vault faster than the caps allow. See Security.
It could log. The relayer necessarily knows, at the moment of settlement, which deposit address paid which pass. But it never knows the Zcash sender, so what it could leak is the same link an observer of Arbitrum One already has. The relayer stores orders in a JSON file; the file holds the deposit address, the refund address, the beneficiary, the pass, the amounts and the transaction hashes, for the life of the order, and is trimmed of terminal orders older than thirty days. The refund address is the only field that an Arbitrum observer does not already see, and it is only sensitive if you reuse it.
The direct rail
When NEAR Intents solvers start quoting ETH on Robinhood Chain, the relayer stops receiving anything: the intent pays the pass directly. The relayer then only creates quotes and triggers sweeps, and holds nothing, ever. The trace on Robinhood Chain becomes B received tokens bought with ETH that came from a NEAR Intents solver, which is the same wall one step closer.
How users break it
Zecpass cannot protect a user from these; it can only say them plainly.
- Reusing the beneficiary address. If B has ever interacted with an address that is known to be yours, B is yours. Make a fresh wallet. The pass page does it in the browser.
- Reusing the refund address. A transparent Zcash address that has received from an exchange with your name is your name. Make a fresh one in Zodl for each pass.
- Round amounts at regular times. An observer who sees you deshield 1.0000 ZEC every Monday at 09:00 and sees pass P receive the matching ETH every Monday at 09:08 does not need the relayer's logs. Vary the amount, vary the time.
- Talking. Posting "just got my $ZECPASS" from an account with your name, next to a wallet screenshot, undoes everything above.
- Sending from a transparent balance. If the ZEC never entered the shielded pool, the deshield step does not exist and the Zcash side is as public as Bitcoin. Shield first, wait, then send.
What Zecpass will never add
No accounts, no email, no analytics that identify a visitor, no wallet connection required to ask for a pass. The site sets no cookies. Orders are stored in the browser's local storage under zecpass.orders so that a closed tab is not a lost order; clear it whenever you like.