Skip to main content
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.
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.
Start with the Solana quickstart, then follow account configuration. These pages cover @rhinestone/sdk; managed embedded wallets use a separate SDK and lifecycle.

​
Owners and account readiness

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

​
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. 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. 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 for the shared flags and security policies 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 to enroll a recovery key, then recover access. 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 stays shared. Status items use transaction.vm === 'svm' and transaction.signature for Solana; a transaction reference alone is not proof of completion.