> ## 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. # Networks > Compare the account model, capabilities and limitations of embedded wallets on EVM and Solana. 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](/wallets/custom-signer/solana-support) 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](/wallets/embedded-wallets/accounts) for client setup and [Send a transaction](/transactions/multichain/send-a-transaction) for examples. ## Account architecture | Aspect | EVM | Solana | | - | - | - | | Onchain account | A smart-account contract, deployed separately on each chain | A Swig-controlled wallet with authority roles maintained per cluster | | Address | The same smart-account address across supported EVM chains | A separate base58 wallet address, shared across clusters | | Session | `accounts.evm.address` | Optional `accounts.solana`, with provisioning status and per-cluster readiness | | Network identifier | Numeric chain ID | Exported `solanaDevnet` or `solanaMainnet` CAIP-2 cluster ID | | Transaction authorization | User passkey approval plus a request-scoped service co-signature | Native Swig authorization using the passkey retained from sign-in | | Deployment | Included in the first real execution on a chain when needed | Explicit app-sponsored `deploy({ chain })`, including required authority enrollment | | Safe receiving | A counterfactual address can receive before deployment when its exact account configuration is preserved | Wait for the selected cluster to report `ready: true`; an address or balance alone is insufficient | 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](/wallets/embedded-wallets/accounts#deploy-accounts). ## Capabilities Available features depend on the network and route. See [Supported chains](/home/resources/supported-chains) for EVM coverage and [Availability](#availability) for Solana development guidance. | Capability | EVM | Solana | | - | - | - | | Same-network execution | Contract calls; multiple calls in one intent can execute atomically | App-supplied instructions on one cluster; no decoding or simulation guarantee | | Token delivery | Same-chain and supported cross-chain delivery | Same-cluster SPL delivery with matching mints and EVM → Solana delivery; see [current limitations](#availability) | | Funding and destination execution | An EVM source can fund calls on another supported EVM chain in one intent | Cross-VM delivery cannot include destination calls or instructions; fund first, then execute separately | | Swaps | Supported token swaps on EVM routes | Same-cluster delivery is not a different-mint swap | | Batches | Several independent intents, or atomic calls within one intent | Solana-signed intents must be sent alone | | Session keys | EVM SmartSessions | Not supported | | Integrations | EIP-1193, viem, wagmi and external-wallet connections | Use `WalletClient` directly; those adapters do not expose Solana | | Detached signing | Message and typed-data signing | No public message or raw-transaction signing API | 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](/transactions/relaying/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](/transactions/multichain/send-a-transaction#fund-a-managed-solana-wallet). 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](/wallets/recovery/recover-an-account) and the [authority trust boundary](/wallets/recovery/trustless-recovery#managed-solana-authority). ## 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](/wallets/embedded-wallets/clear-signing#solana-instruction-review). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.