SVM-only setup

Pick this path when your app only touches Solana — a framework-kit, gill, @solana/kit, @solana/wallet-adapter-react, or legacy @solana/web3.js app with no EVM surface. You import @usebutr/svm for discovery instead of autoDiscovery() from @usebutr/wallets, and the EVM packages never enter your bundle. The provider and hooks are identical to every other setup.

Install

@usebutr/react gives you the provider and hooks, @usebutr/svm does Wallet Standard discovery, and createWalletSource comes from @usebutr/core. No @usebutr/wallets, no @usebutr/evm.

npm install @usebutr/react @usebutr/svm @usebutr/core zustand

@usebutr/svm lazily imports @wallet-standard/app (an optional peer dependency). Install it for discovery to work; if it is absent, SVM discovery becomes a graceful no-op rather than throwing.

npm install @wallet-standard/app

Provider

Build the WalletSource with createWalletSource from @usebutr/core and discoverSvmAdapters from @usebutr/svm. Hoist it to module scope so it is created once, not on every render.

import type { ReactNode } from "react";
import { createWalletSource } from "@usebutr/core";
import { WalletManagerProvider, useDiscoveredWallets } from "@usebutr/react";
import { discoverSvmAdapters } from "@usebutr/svm";

// SVM-only: @usebutr/react + @usebutr/svm.
const svmDiscovery = createWalletSource(discoverSvmAdapters);

const WalletProvider = ({ children }: { children: ReactNode }) => (
  <WalletManagerProvider discovery={svmDiscovery} storageKeyPrefix="butr-solana-web3js-demo">
    {children}
  </WalletManagerProvider>
);

export { WalletProvider, useDiscoveredWallets };

demo-with-solana-framework-kit, demo-with-gill, demo-with-solana-kit, demo-with-solana-wallet-adapter, and demo-with-solana-web3js all use exactly this pattern (each with its own storageKeyPrefix). They re-export useDiscoveredWallets from the local wallet-provider module so consuming files import it from one place.

The bundle guarantee

The isolation is not a flag — it is your import graph. @usebutr/svm depends only on @usebutr/core; it carries no EVM or EIP-6963 code. autoDiscovery() lives in @usebutr/wallets, which depends on both @usebutr/evm and @usebutr/svm, so importing it would pull EVM in. Here you import discoverSvmAdapters from @usebutr/svm directly, so @usebutr/evm and @usebutr/wallets are never referenced and the bundler tree-shakes them out ("sideEffects": false is set on every package). See Platforms.

Chains

Pull the chain list from @usebutr/svm directly. CHAINS_BY_PLATFORM from @usebutr/wallets would re-introduce the bundle you just avoided.

import { SVM_CHAINS_LIST } from "@usebutr/svm";
const CHAINS_BY_PLATFORM = { evm: [] as const, svm: SVM_CHAINS_LIST };

SVM_CHAINS (keyed: mainnet, devnet, testnet) and SVM_CHAINS_LIST (the same as an array) are both exported from @usebutr/svm. These use Wallet Standard shortnames (solana:mainnet, not the strict CAIP-2 genesis-hash form) because that is what real wallets — Phantom, Solflare, Backpack — advertise in wallet.chains.

Capabilities and caveats

@usebutr/svm discovers wallets via the Wallet Standard. Because it lazily imports @wallet-standard/app, there is an asynchronous warmup: a restored wallet can land in pendingIds for a moment before it resolves — see Hydration.

Capabilities are resolved from the wallet's advertised Wallet Standard features: signMessage is true only if the wallet advertises solana:signMessage, sendTransaction only if it advertises solana:signAndSendTransaction, subscribe via the Standard change event. requestAccounts is generally a no-op — Standard wallets expose all accounts at once, there is no picker. Always branch on wallet.connector.capabilities.

getSigner() on an SVM adapter returns the WalletStandardWallet; you call its features directly or bridge into a Solana library. See the integration pages for the full build-and-send flow.

Next steps

• Solana Wallet Standard connector — the discovery and signer detail.
• framework-kit / gill / solana-kit / solana-wallet-adapter / solana-web3js (legacy) — build and send transactions.
• Provider setup — auto, manual, and composed variants.