Skip to main content

Portal Deposit Addresses

Give a user a reusable, public, exchange-style deposit address. Anyone can fund it with standard ERC-20 transfers, and the funds are credited into the owner’s shielded balance without revealing which account was credited. See Portal Deposit Addresses for the concept and trust model. The TypeScript SDK exposes the full portal lifecycle through the sdk.portal resource.

Checking support

delegateAddress() returns the portal delegate address advertised by the server’s /info, or undefined when the server does not support portals:

Creating a portal

create does everything in one call: it derives a fresh portal address E from your seed, delegates it to the portal implementation, registers the on-chain owner binding, and publishes the discovery registry entry.
Pin a derivation index to re-derive a specific portal deterministically:

Listing your portals

Checking a portal’s status

Receiving deposits

A sender funds a portal with an ordinary ERC-20 transfer to E — they need nothing from Privacy Boost. List the deposits observed at a portal:
A deposit moves through these states:
Each deposit reports the sweepFeeBps snapshotted at sweep time; feeAmount is grossAmount - netAmount.

Sweeping

Sweeping moves a portal’s balance into the pool. It is permissionless and deployments normally run a keeper, so you rarely call it, but sweep is available as a self-service backstop. It returns the sweep transaction hash:

Reclaiming an un-credited deposit

If a swept deposit is never credited, reclaim it after the cancel delay. The funds return to the portal address E, never to the caller:

Withdrawing raw funds from E (escape hatch)

For funds resting at E that can never be swept (for example a token that is not registered with the protocol), withdraw builds a signed raw EIP-1559 transaction you broadcast yourself. Read the nonce and gas/fee values from your own RPC:

Types