Integration Models

Every SDK open, close, and rebalance lands a Solana transaction from a Solana wallet — that never changes. What differs between partners is two things:

Who provisions and controls the Solana wallet that signs.
How the user’s funds arrive on that wallet.

This page maps the common partner setups onto the SDK flows — Managed Wallets for the recommended server-signed path, and Open a Position / Close a Position for the client-signed (BYOW) flows — so you can tell which path is yours before you write any code.

Whatever the model, the wallet needs the basket’s input token (USDC) to open. Cesto sponsors the network gas and ATA rent — the wallet needs no SOL.

The models at a glance

Managed wallets (recommended)

Cesto provisions a Solana wallet per user via Privy and signs server-side. You call open/close by user — no key handling on your side.

Your own Privy (BYOW)

You provision embedded / server wallets in your own Privy app and sign inside the one-call flow’s signTransactions callback.

Browser EOA (BYOW)

The user connects Phantom / Solflare and signs in the browser. Your backend runs the split prepare → sign → submit → poll flow.

Cross-chain (EVM → Solana)

Users hold USDC on Base. Bridge it in with the SDK’s native CCTP bridging — naturally paired with a managed wallet as the destination.

Model	Solana wallet owner	Who signs	SDK flow
Managed wallets (Cesto-managed Privy)	Cesto (Privy)	Cesto, server-side	`*.start`, no `consent`
Your own Privy	You (your Privy app)	Your backend, via Privy	One-call
Browser EOA	The end user	The user, in the browser	Split flow
Cross-chain (EVM)	Depends on the SVM wallet you map to	Owner of the mapped SVM wallet	Any of the above, after bridging

Managed wallets (Cesto-managed Privy) — recommended

Cesto provisions a Solana (Privy) wallet per user and handles signing on its side. Your integration only ever deals in user references — an external user id, the user’s EVM wallet, or the provisioned Solana address — you never touch a private key or run a signing callback. This is the lightest path to integrate, and the one to pick if your users only have EVM wallets or you don’t want to run wallet infrastructure yourself.

Provision a wallet for each user

Call cesto.users.create({ evmWalletAddress }) — idempotent, one wallet per (partner, EVM wallet). Store the returned solanaAddress against your user record.

Fund the wallet

The user bridges USDC from their EVM wallet into the provisioned address with the bridge flow (see Cross-chain). Cesto sponsors gas, so the wallet needs no SOL.

Open / close by user

Call open.start / close.start / rebalance.start with the user reference. Signing is handled on the Cesto side — no signTransactions callback, no split flow.

Full reference and an end-to-end example: Managed Wallets.

Bring your own wallet (BYOW)

You already have wallets for your users — either embedded/server wallets in your own Privy app, or self-custody browser wallets — and want them to stay self-custody. Cesto builds the unsigned transactions; your side produces the signatures.

Your own Privy

You provision and control the Solana wallets in your own Privy app (embedded or server wallets). Because your backend can sign on the user’s behalf, use the one-call flow and delegate signing to Privy inside the signTransactions callback:

const result = await cesto.open.execute({
  wallet: userSolanaAddress,
  product: 'stable-genius',
  amount: 100_000_000n, // 100 USDC @ 6 decimals
  // Receive Cesto's prepared txs, sign each with your Privy wallet, return them base64.
  signTransactions: async (transactions) =>
    Promise.all(
      transactions.map(async ({ nodeId, transaction }) => ({
        nodeId,
        signedTransaction: await signWithPrivy(userSolanaAddress, transaction),
      })),
    ),
});

signWithPrivy is your own helper over Privy’s server-side signing — the SDK never sees the key. See the one-call flow for the full callback contract.

Browser EOA (Phantom or Solflare)

The end user holds a self-custody wallet and signs in the browser. The SDK runs on your backend and hops out to the wallet for signatures — this is the split flow:

prepare (backend) ─▶ sign (browser wallet) ─▶ submit (backend) ─▶ poll (backend)

Prepared transactions expire ~60s after prepare, and the wallet must sign them byte-for-byte — any modification is rejected at submit. Walk through it in Open a Position → Split flow.

Cross-chain users (EVM to Solana)

Some partners’ users hold funds on Base, not Solana. The SDK’s bridging resource moves their USDC onto Solana natively (Circle CCTP — the user signs one burn on the EVM chain, Cesto attests and mints on Solana) — no third-party bridge, no SOL needed on the destination. Bridging pairs naturally with managed wallets: the user’s EVM wallet is the provisioning key and the funding source, so one identifier covers the whole lifecycle. The pattern:

Provision a managed wallet from the EVM address

cesto.users.create({ evmWalletAddress }) gives the user a Solana (Privy) wallet keyed to their EVM wallet — no Solana wallet infrastructure on your side. This SVM address is the bridge destination.

end user  ──▶  EVM wallet (Base)  ──▶  Cesto-managed (Privy) Solana wallet
          provisioning key              bridge destination

Bridge USDC into the managed wallet

Use bridge: quote → initiate with recipient = the provisioned solanaAddress and sourceAddress = the user’s EVM wallet → the user signs the burn on the EVM chain → submitBurn → waitForTransfer. Cesto’s relayer pays the Solana-side gas and creates the USDC token account if it’s the user’s first transfer.

Open / close on Solana

Once USDC is on the managed wallet, call open.start / close.start with the user reference, investing the arrived amount (netOut). Read holdings any time with positions.getHoldings.

With a BYOW setup the bridge works the same way — recipient is the BYOW Solana wallet and the arrived funds are invested via the client-signed open flow.

Choosing a model

Don’t want to run wallet infra, or users only have EVM wallets? → Managed wallets.
Already have Privy embedded/server wallets? → Your own Privy, one-call flow.
Users bring self-custody wallets (Phantom / Solflare)? → Browser EOA, split flow.
Users’ money is on an EVM chain? → Cross-chain: provision, bridge, then invest.

Whichever you pick, execution results and error handling are the same — see Managed Wallets, Open a Position, Rebalance a Position, and Errors & Retries.

​The models at a glance

Managed wallets (recommended)

Your own Privy (BYOW)

Browser EOA (BYOW)

Cross-chain (EVM → Solana)

​Managed wallets (Cesto-managed Privy) — recommended

​Bring your own wallet (BYOW)

​Your own Privy

​Browser EOA (Phantom or Solflare)

​Cross-chain users (EVM to Solana)

​Choosing a model

The models at a glance

Managed wallets (Cesto-managed Privy) — recommended

Bring your own wallet (BYOW)

Your own Privy

Browser EOA (Phantom or Solflare)

Cross-chain users (EVM to Solana)

Choosing a model