Migrating from Privy
How Privy concepts map to Swivy, and how a migration runs without touching existing wallets.
Preview: Swivy is not generally available
Swivy runs in staging only. Swop itself has not migrated yet and still runs on Privy. Request early access.
In plain words: Swivy was built to do the job Privy does, with a similar SDK shape, so moving is mostly a matter of swapping the provider and the hooks. Existing users keep their old wallets until they choose to move.
Concept map
| Privy | Swivy |
|---|---|
| App | Environment (appId + publishableKey for clients, secretKey for servers) |
PrivyProvider | SwivyProvider from @swivy/react |
| Login with email / SMS / passkey | Email code login today, with passkey, TOTP or SMS as a second factor. Passkey and SMS as the main login (loginWithPasskey, signupWithPasskey, requestSmsCode) are in review |
| Login with an external wallet | requestWalletLogin + signInWithWallet (EVM wallets and Phantom) |
| Embedded wallets (EVM, Solana) | Managed accounts, auto-created at login per policy |
useWallets / create wallet | useEmbeddedWallets() / ensureEmbeddedWallet(chain) |
| Sign / send transaction | Signing and transaction intents (signMessageAndWait, createTransactionIntentAndWait) |
| Gas sponsorship | executionPolicy.sponsorship, per network with caps |
| Delegated signers for agents | Agent session grants (scoped, expiring, user-approved) |
| App-owned server wallets (treasury, fee payer) | /v1/server/wallets, secret key plus a required authorization key. In review, not on staging yet |
users().get / get user by email / delete | GET /v1/server/users/{id}, GET /v1/server/users?email=, DELETE /v1/server/users/{id} (wallets are kept). In review |
verifyAccessToken | POST /v1/server/sessions/verify (Swivy sessions are opaque, so a backend checks them with Swivy). In review |
| Key export | exportManagedAccount, off unless policy allows, step-up required |
| Webhooks | swivy.intent.completed today. Retries on Privy's schedule plus identity, wallet and failed-intent events are in review |
| Bitcoin wallets | Segwit wallets with raw-hash signing (the useSignRawHash pattern) are in review. Your app builds and broadcasts the transaction |
How a migration runs
- Stage on testnets (
base-sepolia,solana-devnet) with your own environment. - Dual stack: new users get Swivy wallets; existing users stay on their current wallets.
- Move existing users when you're ready, by key export or by re-keying to a new Swivy wallet, with a reason to do it.
- Switch off the old provider once nobody depends on it.
Swop will follow the same steps: new users on Swivy first, existing users later, nobody's existing wallet touched without their action. See Status & roadmap.
Why teams move
- Costs follow signing, not head count. Per-user pricing grows with every user; Swivy's cost grows with signing work and storage.
- One login across your apps. Environments in the same project share users and wallets, and Sign in with Swop extends that to other apps.
- Your graph stays yours. Users, wallets and audit logs live in your environments.