Recover an existing Turnkey wallet

Before you start

• An existing Turnkey wallet associated with your account.
• Original browser/device owner access where required; app login alone is insufficient.

Preserve the original owner access

Select Turnkey — recovery only in Wallet to inspect the original wallet. Reconnecting the browser’s saved owner key is different from signing in to COMPUTER.EXE. The wallet is not replaced when owner connection fails.

Use the owner connection control and read its error if automatic connection fails. Missing owner authority or provider readiness can disable signing while status reads remain possible. A native wallet cannot recover the old wallet’s keys.

Optionally transfer supported assets

Keeping both wallets is allowed; migration is not automatic or required. The supported withdrawal flow moves assets individually, not NFTs, other tokens or open positions. Existing launches and strategies remain bound to their original wallets.

COMPUTER transfers can initialize a receiving token account and show a token transfer fee. USDC requires an initialized receiving token account in this legacy flow. Leave enough SOL for fees and any rent before moving remaining SOL.

1. Select Native, open Deposit, and copy its exact Solana address only when deposits are enabled.
2. Return to Turnkey and authorize that exact native address as the withdrawal destination using the original owner access.
3. Review and send a small supported test transfer. Wait for confirmed receipt in Native before proceeding.
4. Move COMPUTER and USDC before remaining SOL, subject to the displayed account and fee requirements. Keep Turnkey access for assets or obligations not covered by the flow.

Review the legacy withdrawal record

Legacy withdrawal uses destination authorization, an asset/amount review, explicit consent and genuine owner approval. Check whether the destination is active or pending; retry activation only when that action is offered.

Use the persisted latest request and reconciliation/status controls after an uncertain submission. A reconciliation error does not automatically resend the transaction. A capability-unavailable banner means signing and sending are not available; it is not permission to bypass the gate.

1. Check the active destination and asset, then review the amount, recipient and fees.
2. Approve only the reviewed request through the original owner flow when enabled.
3. Retain the request reference and signature. If pending or unknown, check that same request before considering another transfer.

Export requires the actual owner

Legacy export requires provider capability and a matching genuine owner signer. Read the exposure warning, connect owner access if needed, acknowledge and use Export generated wallet. Key material is displayed in the provider’s secure export surface; do not share it.

The saved-backup acknowledgment is offered after the completed export sequence. A checked box or successful app login is not cryptographic proof that a recoverable backup exists. Store the actual exported recovery material privately and follow the compatible wallet’s documented import format.

Explicitly cancel a pending address change

Opening a withdrawal-address cancellation link does not cancel anything. The public cancellation page requires the full valid link and an explicit confirmation; it removes the sensitive fragment from the address bar after reading it.

A successful result says the pending change was cancelled. An invalid, expired or no-longer-pending result does not prove a current destination was changed back. Return to Wallet and inspect its current destination. A request error can be retried without treating cancellation as completed.

1. Open the original complete cancellation link privately; do not forward or screenshot its credentials.
2. Read the pending-change action and press its explicit cancellation button.
3. Read the result and return to Wallet to verify the destination state. If you did not request the change, also review account sessions.

Related guides