For developers

Docs

Every address, parameter and mechanism, straight from the same configuration the app runs on. The human explanation lives in How it works.

01

The gift model

Escrowa fresh Solana keypair per gift; its token account holds the share
Custodyonly the keypair can move the share, and its secret exists only in the link
Claima transfer signed by the gift keypair, co-signed and fee-paid by the relayer
Refundthe sender's own copy of the link, claimed back the same way
Protocol fee1% at creation, a plain SOL transfer visible in the wallet preview before signing

There is no custom program and therefore no program to audit, upgrade or exploit. A gift is an ordinary account holding an ordinary token balance, moved by ordinary transfers. Everything this product promises reduces to one fact anyone can check on Solscan: the share sits at the gift address until the key in the link signs it away.

02

Network

ChainSolana mainnet
RoutingJupiter aggregator · https://lite-api.jup.ag/swap/v1/quote
IssuerBacked Finance (xStocks), a regulated Swiss issuer

Every mint was verified onchain before being written down. All listed tokens are Token-2022 mints; the issuer retains a freeze authority, which is standard for regulated tokenized equities and is listed under issuer risk in How it works.

03

Listed tokens

A ticker is listed only with real Jupiter-routable liquidity on Solana, and every send is guarded by the price impact ceiling below. All listed tokens use 8 decimals.

04

Parameters

Gift size$1 to $5,000
Slippage tolerance1.0%, enforced by the swap onchain
Max price impact3.0%, or the route is refused
Protocol fee1% at creation
Expirynone; an unclaimed gift stays claimable, and reclaimable, forever

05

Claim protocol

Creating a gift generates a fresh keypair in the sender's browser. The share is swapped and delivered to that keypair's associated token account in the same transaction the sender signs. The keypair's seed goes after the # in the link and never reaches a server.

To claim, the receiver's browser builds one transaction: create the receiver's token account if needed, transfer the full balance from the gift address, and close the emptied gift account. It signs that transaction with the key from the link and posts it to the relayer with the fee payer left open. The relayer validates every instruction against a whitelist, adds its signature, and submits. The key signs this exact transaction and nothing else, so the relayer cannot redirect the share, and the seed itself never leaves the browser.

Relayer endpoint

GET /api/claim

{ "ok": true, "relayer": "…" }  // the fee payer address to build against

POST /api/claim

{
  "tx": "…"  // base64 transaction, signed by the gift key, fee payer = relayer
}

The relayer refuses any transaction containing an instruction outside its whitelist: token account creation it funds, token transfers that do not involve its own key, and account closures whose rent returns to it. A request that would fail onchain is rejected with the reason instead of submitted.