> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration

> Upgrade your embedded wallet integration between SDK versions.

This guide covers `@rhinestone/wallet`, not the [core SDK migration](/wallets/custom-signer/integration/migration-guide). Examples use `@rhinestone/wallet@0.17.1`. Upgrade your sponsorship backend's `@rhinestone/wallet/server` before deploying the client:

```bash theme={null}
npm install @rhinestone/wallet@0.17.1
```

## 0.16 → 0.17

Nested sessions and sends stay unchanged. Check these integration points:

* **Sponsorship:** remove handling for the retired `sdk-caucasus-singular-2026-09-v1` identifier. `createSponsorshipSigner()` accepts `sdk-3.0.0-caucasus` for singular inputs and rejects the retired identifier.
* **Session-key sends:** destination-token requests work again after being refused in 0.16.0–0.16.1. Recipient delivery, Solana and module installation remain unsupported with session keys.
* **Chain handling:** `TargetChain` now includes `hypercore:perp`. If your code handles chain types exhaustively, distinguish that venue from EVM and Solana; no change is needed to an ordinary EVM or Solana send.

0.17.1 also simplifies token-send and trade review. If your UI explains what the wallet dialog shows, check [Clear signing](/wallets/embedded-wallets/clear-signing) rather than relying on older screenshots.

## 0.15 → 0.16

**Breaking, including for EVM-only apps.** Replace flat sessions and send inputs; there are no compatibility aliases.

| Before | After |
| - | - |
| `session.accountAddress` | `session.accounts.evm.address` |
| `accountAddress` or credential selectors on sends | Remove them; sends use the authenticated wallet |
| `targetChain` | `destination.chain` |
| `sourceChainId`, `sourceAssets[]` | One `source: { chain?, token, maxAmount? }` |
| `tokenRequests[]` | One `destination.token` and optional `destination.amount` |
| Top-level calls, recipient or instructions | Move them into `destination` |
| String send amounts | Positive base-unit `bigint` values |

For example, after sign-in:

```ts theme={null}
import { wallet } from "./wallet";

export async function sendUsdc(recipient: `0x${string}`) {
  const usdc = "0x036CbD53842c5426634e7929541eC2318f3dCF7e";
  return wallet.sendIntent({
    source: { chain: 84532, token: usdc, maxAmount: 1_000_000n },
    destination: { chain: 84532, token: usdc, amount: 100_000n, recipient },
    sponsorshipMode: "required",
    closeOn: "completed",
  });
}
```

`sendBatchIntent()` uses the same nested shape per item. Methods such as `signMessage()` and `getAssets()` still take the EVM `accountAddress`.

* **Funding:** omitting `source.chain` means the destination chain. Delivery and user-paid execution require a source; only fully sponsored no-delivery execution can omit it. Omit `destination.amount` for max output, not zero. See [Send a transaction](/transactions/multichain/send-a-transaction).
* **Balances and results:** narrow `AssetBalance.chainId` (`number | SolanaChainId`) before EVM-only use. Preserve native transaction identifiers and submission metadata; a timeout or `success: false` is not permission to resend. See [Holdings](/transactions/multichain/unified-balance) and [Status tracking](/transactions/multichain/end-to-end-transaction-flow#follow-the-flow).
* **Adapters:** EVM provider/viem/wagmi sends reject old funding extensions and no longer support auxiliary funding.
* **Solana is opt-in:** add `experimental_solana` only if needed, and [complete setup](/wallets/embedded-wallets/accounts#set-up-a-solana-wallet) before receiving. EVM-only apps do not need it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.