The relayer

Without a relayer, a user who unshields signs and pays for their own withdrawal transaction — which links that withdrawal to a wallet they control, partially defeating the point. The relayer closes that gap: it submits the withdrawal and pays the gas, so the transaction is signed and paid by the relayer, not the user.

How it works

1. The user builds an unshield bound to a chosen relayer address and fee, both public signals in the proof. publicAmountOut = amount − fee.
2. Instead of sending the transaction themselves, the user POSTs the proven op to the relayer's HTTP endpoint. No wallet signature from the user is needed for the chain transaction — the proof authorizes the withdrawal.
3. The relayer validates and, if everything passes, signs and submits the transaction, paying gas.
4. The recipient receives amount − fee at a fresh public address unlinkable to any wallet the user controls; the relayer receives fee from the pool.

What the relayer checks (before submitting)

• The op is an unshield, and the bound relayer address is its own (otherwise it would pay gas for someone else's fee).
• The fee clears its configured minimum.
• The proof verifies against the pool's reconstruction of the public signals.
• The root is in the recent-roots window and the nullifiers are unspent.

If any check fails it rejects with a reason and submits nothing.

Trust: liveness, not safety

Single-relayer MVP

Today there is one relayer — a censorship / centralization point, in the same spirit as the single sequencer. A production system wants many relayers (a relayer market) so no single party can censor. That decentralization is future work; the safety guarantees above hold regardless of how many relayers exist.

The self-pay path remains available as a clearly-labeled fallback (linkable to the user's wallet). See Using the app.