Skip to main content
An embedded wallet gives your user one sign-in experience with separate onchain accounts. EVM is enabled by default; experimental_solana adds a managed Solana account without replacing the EVM account. This page covers @rhinestone/wallet. The core SDK lets you manage your own signers and has a different capability set.

​
Shared behavior

  • One application wallet. Passkeys belong to your application’s domain. Sessions expose chain accounts under accounts, and sends use the authenticated wallet—not an account or credential selector supplied with each request.
  • One funding source per intent. Select a chain and token explicitly. Combined holdings are a display total, not pooled spending power or automatic cross-VM routing.
  • The same send lifecycle. Use nested source and destination, review, authorize, then track by intent ID. Submission is not finality; a timeout is not permission to resend.
  • Sponsorship does not supply assets. Fully sponsored execution without delivery can omit source; assets consumed by calls or instructions must already be available. User-paid execution and token delivery require a source.
See Accounts for client setup and Send a transaction for examples.

​
Account architecture

Authentication provisions identities, not onchain deployment. Solana setup confirms the original passkey, service recovery and the other active passkeys before receiving readiness. It can require several approvals and resume incomplete steps without changing the wallet. See Deploy accounts.

​
Capabilities

Available features depend on the network and route. See Supported chains for EVM coverage and Availability for Solana development guidance. Solana delivery does not support native SOL or cross-cluster transfers. Instruction sends accept a same-cluster fee-token source or fully sponsored source-free execution, but no source cap or positive app fee. See Relay a transaction. EVM-funded delivery to Solana does not require the opt-in; managed Solana setup and spending do. To use funds in a Solana application, receive externally or deliver from EVM, then execute. Those are separate operations: failed execution does not undo successful funding.

​
Recovery and authority

Both accounts support additive hosted recovery: the configured email or OAuth identity authorizes adding a replacement passkey, not revoking the lost one. EVM recovery runs first; Solana results are tracked per cluster, and incomplete recovery can resume on the next sign-in. The recovery paths differ:
  • EVM: configured user-held recovery keys and the standalone emergency recovery app can provide a separate recovery path.
  • Solana: setup requires an enrolled service recovery key. PRF/file recovery and the emergency recovery app do not recover this wallet. The original root cannot be removed through the managed API.
The Solana service key is fixed, with no automatic rotation or propagation of EVM registry revocations. There is no normal signed-in add-passkey API. See Recover an account and the authority trust boundary.

​
Availability

Managed Solana is experimental and off by default. Not meant for production use.
Use Solana Devnet for development. Start with USDC transfers within Devnet, USDC delivery from Base Sepolia, and same-network instructions. Use email-based recovery; do not rely on Solana → EVM delivery or Google/Apple recovery yet. Token support varies by network and route. A token appearing in the wallet balance does not mean it can fund every transaction. Instruction review shows the programs and accounts involved, but does not simulate balance changes. See Clear signing.