Connected-wallet integration
Sendwithdrawal.transaction through the user’s connected wallet after showing the chain, pool, destination, gross amount, fee, net amount, and zero ETH transaction value.
to, data, value, and chain returned by the SDK. Do not decode and rebuild the call in a second transport layer.
Browser relayer boundary
A relayer is a separate system with signing, replay, deadline, rate-limit, funding, and availability requirements. Current authorization covers only the browser runtime’s exact endpoint, chain, pool, selector, and zero-value withdrawal call. Do not invent a second request protocol from withdrawal calldata. Any transport must preserve these rules:- Note secrets, recovery keys, and Merkle witnesses never leave the client.
- Target pool, selector, calldata, chain, and zero ETH value remain exact.
- A signed request binds replay protection and a short expiry.
- The client never races wallet and relayer submission.
- An unknown result is reconciled before another attempt.
Completion
Settlement requires a successful receipt at the configured pool, a spent nullifier, and the matchingWithdrawal event.
For an SDK integration, use wallet transport. Treat browser relayer submission as a separate, source-bound service rather than an SDK default.
