Skip to main content

Claimable Transfers (Gifts)

Send shielded funds to an Ethereum wallet address that has not registered with Privacy Boost yet. The recipient claims by proving ownership of that address; you reclaim the funds if they never do. See Claimable Transfers for the concept and trust model.
Gift methods are called directly on the WASM PrivacyBoost instance (sdk below). They may not be present in the checked-in generated types, so the code blocks here are illustrative and not type-checked against the published build.

Sending a gift

The most common case: you know the recipient’s wallet address but they have not joined Privacy Boost. Use giftFundToWallet. Every fund/claim/refund call returns a TransferResult. The bindings read every funding field as a string and treat a JS number as missing, so pass block heights as decimal strings.
If the recipient is already a Privacy Boost user, fund with their privacy address too (giftFund) so the gift ciphertext is sealed to their viewing key for the smoothest discovery. Note the field is recipient — the 194-char privacy address:

Funding parameters

The gift binds irrevocably to recipientWallet. A wrong-but-valid address can be claimed by whoever controls it, and only an unclaimed gift is refundable. Show the exact checksummed address and require explicit confirmation before funding.

Funding result

giftFund / giftFundToWallet return a TransferResult carrying two gift fields:
result.claimLink is a pbgift:v1:... string that carries the encrypted opening the recipient needs. Share it out of band (message, QR code). Treat it like a password — it reveals the gift’s amount and recipient to anyone who reads it.

Claiming a gift

The recipient registers Privacy Boost with the same wallet address, then claims. List the pending gifts addressed to the authenticated wallet:
Claim one by its position in that list, or — more robustly — by its stable commitment cGift (the list can shift as gifts settle):
Or claim straight from a claim link, without a server lookup first:
acknowledgeUnknownSender must be true to claim. The hidden-sender model cannot reveal who funded a gift, so the recipient explicitly acknowledges accepting funds from an unknown sender. Surface this as a consent prompt.
A successful claim re-mints the gift into a normal shielded note — from then on it behaves like any other note in the recipient’s balance.

Refunding an unclaimed gift

A claim and a refund spend the same nullifier, so only one can ever settle. After the refund deadline passes, reclaim an unclaimed gift using the local record you saved at funding time.
Gift records are what make a gift refundable, and getGiftRecords() holds them in memory only: they are gone after a reload, so store each giftRecord yourself when the gift is funded. It throws once the session can no longer read the account, including after an auto-lock that ends it, rather than answering an empty list. Merge what it returns into your stored records by cGift rather than replacing them. If you ever lose the record, you can still refund by supplying every field manually via giftRefund({ recipientWallet, blind, refundAfterBlock, tokenId, amount, treeNumber, leafIndex }).
Decode a claim link into a preview with no network call — useful to show the recipient what they are about to accept. decodeGiftLink is synchronous and offline, so there is no await:

Types

A third funding mode, giftFundSecretBearer, binds a gift to a secret instead of a wallet so it can be claimed before the recipient has any wallet. It is a bearer instrument (whoever holds the link can claim), selected only by that explicit method. See the concept page before considering it.
It takes tokenAddress, amount, refundAfterBlock, and currentBlock, all strings, with currentBlock required because the refund delay is validated locally before funding. No giftRecord is returned and getGiftRecords() never lists the gift: the returned claimLink is the recipient’s claim credential and the funder’s refund credential alike.