> ## 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.

# Solana support

> Choose Solana owners, transaction shapes, and fee modes in the core SDK.

The core SDK manages Solana **Swig smart accounts** with an ECDSA or passkey authority. A native Solana wallet connection is not required. Configure Solana independently or alongside an EVM account; each has its own identity and authorization.

<Note>
  These guides target SDK 3.0.0, pending publication and release verification.
  The matrices below describe SDK capabilities, not a guarantee that every
  network, token, or route is available. Check the prepared quote before
  signing.
</Note>

Start with the [Solana quickstart](/wallets/custom-signer/quickstart), then follow [account configuration](/wallets/custom-signer/account-setup/create-an-account). These pages cover `@rhinestone/sdk`; [managed embedded wallets](/wallets/embedded-wallets/overview) use a separate SDK and lifecycle.

## Owners and account readiness

| Configuration | Capability | Boundary |
| - | - | - |
| ECDSA owner | One viem secp256k1 signer authorizes spends and permitted authority changes | Not an Ed25519 keypair. Creating a Swig also requires the owner's public key. |
| Passkey owner | One viem WebAuthn account authorizes spends and permitted authority changes | Retain the credential metadata and access to its relying party. |
| Multiple authority roles | Add ECDSA keys or passkeys with explicit permissions | Roles act independently, not as an m-of-n multisig or MFA policy. |
| Receiver-only address | Receive cross-chain token delivery | Cannot deploy, sign, or fund a Solana-origin intent. |
| Composite EVM + Solana account | Use either configured VM as the source of a supported intent | No mixed-VM funding aggregation or automatic synchronization of owners. |

`getAddress('solana')` returns the asset-holding wallet, not the Swig state account. Save the generated Swig ID and state address with the owner configuration; regenerating an ID creates a different identity.

[Deploy the account](/transactions/relaying/account-deployment#create-a-solana-swig-before-spending) before funding it. Deployment is a separate sponsored operation, not part of the first spend. A successful `deploy` result can mean the Swig already existed **without checking its authority**. Verify the on-chain root key and permissions before depositing; an address alone is not proof of ownership. The SDK has no Solana `isDeployed` method.

<Warning>
  Creation installs a permanent root authority. It cannot be removed or repaired
  by rotating another role. Never prefund an undeployed, predictable wallet. If
  the root is compromised, move assets to a new wallet.
</Warning>

## Transactions and tokens

Solana examples import `solanaDevnet`, `solanaMainnet`, and `solanaAddress` from `@rhinestone/sdk/solana`. Use base58 addresses exactly as given; they are case-sensitive. Amounts are integer base units, not decimal token quantities. The native SOL sentinel is `11111111111111111111111111111111`, not wrapped SOL's mint or EVM's zero address.

| Flow | SDK input | Token and execution boundary |
| - | - | - |
| [Same-cluster SPL transfer](/transactions/relaying/relay-a-transaction) | `source.token`, `destination.token`, and an explicit recipient | Both tokens must be the same SPL mint. Native SOL and different-mint swaps are not supported by this transfer shape. |
| [Same-cluster instructions](/transactions/relaying/relay-a-transaction#run-a-solana-instruction-batch) | `destination.instructions`, optional lookup tables | Encode recipients and token movement in the instructions. No delivery token, amount, or recipient fields. |
| [EVM → Solana delivery](/transactions/multichain/send-a-transaction) | EVM source token and Solana destination mint/address | Token delivery only; no destination Solana instructions. Actual token pairs depend on the route. |
| [Solana → EVM delivery](/transactions/multichain/send-a-transaction#deliver-from-solana-to-evm) | One Solana source mint or native SOL; EVM destination token | Name an EVM recipient unless an EVM entry supplies the default. Actual token pairs depend on the route. |
| [Cross-VM swap](/transactions/trading/make-a-swap) | Different source and destination tokens on the supported corridors above | Same-chain Solana swaps require caller-built instructions, not the SPL transfer shape. |
| [Authority management](/wallets/custom-signer/account-setup/native-signers/passkeys#manage-solana-passkeys) | `destination.authority` | One add/remove operation, authorized by a role with management permission. |

Instructions accept Jupiter-style JSON or structural `@solana/web3.js` instruction objects, not `@solana/kit` objects directly. The SDK accepts at most 32 instructions, 8 lookup tables, and 1,232 bytes of instruction data. These limits do not guarantee that a transaction fits Solana's full transaction-size or compute limits, or that a route will execute every program.

Solana-origin requests do not support source calls, auxiliary funds, custom deadlines, settlement-layer filters, or quoter filters. They do not deliver directly to HyperCore, Tron, or Stellar. Cross-cluster Solana transfers are not a supported same-chain transaction.

The SDK also models Solana-funded EVM execution for composite accounts. These guides cover delivery only until that execution path has release verification; token arrival must not be reported as successful destination execution.

## Fees, sponsorship, and rent

Both ECDSA and passkey owners use the same fee controls. Actual costs and accepted sponsorship categories come from the selected route, not the owner type.

| Operation | User-paid | Sponsored | Rent and limits |
| - | - | - | - |
| Swig deployment | No | Required, automatic gas sponsorship | Integrator pays creation rent and fees; no user signature. |
| Add/remove authority | No | Required, automatic gas sponsorship | Sponsor funds new role rent; removal returns rent to the wallet. No caller-supplied `source` or `sponsored`. |
| SPL transfer / cross-chain delivery | Yes | Requested with the shared `sponsored` option | Quote includes applicable fees. `source.maxAmount` caps the selected source debit; it is not an exact-spend guarantee. |
| Instruction execution | Select an SPL mint or native SOL as fee token | May omit `source` when gas-sponsored | No `source.maxAmount`, app fees, or protocol fees. Sponsorship does not fund the assets moved by the instructions. |

The relayer fronts Solana network costs; user-paid flows reimburse applicable quoted costs. Account creation, token-account rent, role rent, and network fees are distinct costs. Do not hardcode a fee or assume gas sponsorship covers every rent or bridge charge. Inspect the selected quote and any caller-authored instructions. For native SOL sources, the wallet's rent-exempt reserve is not spendable.

Full sponsorship can narrow the available cross-chain routes. A refused sponsored quote does not silently become user-paid. See [Sponsor fees](/transactions/sponsorship/sponsor-fees) for the shared flags and [security policies](/wallets/custom-signer/integration/security#apply-a-bounded-solana-delivery-policy) for server authorization.

## Authority management and recovery

Use `addEcdsaKey`, `removeEcdsaKey`, `addPasskey`, and `removePasskey` from `@rhinestone/sdk/solana`:

* `allButManageAuthority` can spend and execute instructions, but cannot change authorities.
* `manageAuthority` can add/remove non-root authorities, but cannot spend directly.
* `all` has both capabilities.

Both management permissions can grant `all` to another key and take over the wallet. They are not limited recovery rights. The orchestrator refuses removal of the root or last management authority. Follow [recovery setup](/wallets/custom-signer/recovery/set-up#solana-enroll-a-recovery-key) to enroll a recovery key, then [recover access](/wallets/custom-signer/recovery/recover-an-account).

`getAuthorityStatus` checks one requested authority change. Only `applied` confirms that change; `conflict` is not success. It does not establish global readiness or settle an in-flight intent. Reconcile the original intent before retrying.

## What stays EVM-only

Do not translate these examples into Solana counterparts:

* ERC-4337 UserOperations, bundlers/paymasters, EIP-7702, EVM factories and modules, and native Safe relaying.
* Smart Sessions and their policies, guardian-threshold recovery, multisig, and MFA validators.
* Generic account message/typed-data signing and independent-owner signature assembly.
* `getPortfolio` and EVM JSON-RPC provider configuration.

The [prepare, sign, submit, and status lifecycle](/transactions/multichain/end-to-end-transaction-flow) stays shared. Status items use `transaction.vm === 'svm'` and `transaction.signature` for Solana; a transaction reference alone is not proof of completion.


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