zh1eLd6rSphLejbFfJEneUwzHRfMKxgzrgkfwA6qRkW
Pick your path before you copy anything
Nothing else differs. The parameters, the amounts, the helpers and the results are identical on both
paths; only the holder of the pen changes.
Request authentication
Which flows need a signed sender, the 300-second approval window, how many wallet prompts to
expect, and what to do when a request is rejected.
Shared setup
relayUrl is a value you pass on every call, and it is not read from the environment. The SDK
reads no environment variable for it, so exporting CLOAK_RELAY_URL does nothing on its own. If you
like that convention, read the variable in your own code and pass the value as relayUrl; the value
still has to be an origin on this build’s allowlist, which is exactly what the exported
CLOAK_PRODUCTION_RELAY_URL is. Omitting relayUrl, or passing "", throws
Viewing key registration is mandatory: relayUrl is required. before any network call, on every
flow including deposits. "" only means “I will submit this myself” when
enforceViewingKeyRegistration is also set to false, because the viewing-key gate runs first
and fires either way. See the warning in Cloak SDK before you reach for that
pair: it is a privacy hazard on a transfer or a withdrawal, not a configuration shortcut.Send flow (SOL->SOL, USDC->USDC, USDT->USDT)
The same send from a browser wallet adapter
Same functions, same arguments, same results. The only change is the two signing options: the deposit is signed bysignTransaction and submitted directly by the wallet, and the withdrawal is
authenticated by signMessage over the request, with walletPublicKey as the sender.
partialWithdraw and swapWithChange take the same walletOptions object; swap it in wherever the
server examples spread baseOptions. Both of them do return a change note, so the saveNotes call
above stops being a no-op the moment you substitute one, and swapWithChange needs its refund
stored under a second key as well, for the reason given in the swap section below.
walletPublicKey and depositorPublicKey are the same end user here, which is why both are set to
publicKey. Passing two different keys throws: the SDK uses one key for the request’s sender, for
screening and for viewing-key registration, so splitting it would authenticate one person and screen
another.SOL swap flow (SOL -> token)
Swaps are the one flow that can prompt more than once. A swap re-proves on every stale-root
retry, and each new proof is a new request that needs a fresh approval, so on the wallet-adapter path
add
maxWalletApprovals (default 5, floored at 1) to cap how many dialogs one swap may raise. A
depositorKeypair never prompts. Sends and withdrawals sign exactly once on either path, whatever
happens on the network.Payroll flow (multi-recipient private payouts)
History + compliance scan
Related pages
Request authentication
The signed-sender contract for every submitted flow, on both paths.
Wallet integration
Where your notes live between sessions, plus the full wallet-adapter wiring, progress callbacks
and stale-root retries.
Error handling
CloakError categories, parseError, and the stale-root retry template.API reference
The full exported surface, including every symbol on this page.