1. Create or open a wallet
A newly created wallet is based on a cryptographically random Ed25519 key generated by the browser. Existing wallets can be opened with a supported Base58 private key, a recovery phrase, or a JSON secret key.
A recovery phrase is different from a single private key. A BIP39 phrase can derive multiple Solana accounts depending on the derivation path and account index. The current interface supports common hardened Solana derivation paths as well as a custom hardened path.
2. Derive the public address locally
The wallet derives the Ed25519 public key from the selected private data in the browser. That public key is encoded as the Solana address shown in the wallet interface. The network does not receive a recovery phrase or private key in order to calculate an address.
3. Read Mainnet state through RPC
Balances, token accounts, recent blockhashes, transaction signatures and transaction details are public blockchain data. The wallet requests this information through a pool of Solana Mainnet RPC endpoints. A same-origin relay is used when available, with direct browser RPC access as a fallback.
Before a direct endpoint is trusted for wallet operations, the application checks the Solana Mainnet genesis hash. An RPC failure, rate limit or access error can trigger failover to another configured endpoint.
4. SOL and token balances
Native SOL is read from the wallet account balance. Token balances are discovered from token accounts owned by the wallet under the standard SPL Token program and Token-2022 program. Only positive balances are shown in the assets list.
For a more readable asset list, the interface can supplement public on-chain balances with token names, symbols, icons and approximate USD market prices. Market display data is requested through the site's token-data relay using public mint addresses. If market metadata is unavailable, the wallet can fall back to compatible on-chain Metaplex or Token-2022 metadata for the name and symbol. A missing price does not hide the actual token balance.
Token-2022 supports optional extensions. Some assets, especially those using program-specific transfer hooks or other advanced extensions, may require accounts or instructions beyond a standard transfer. A token appearing in the balance does not guarantee that every Token-2022 extension is supported for sending.
5. Build and sign transfers in the browser
For SOL transfers, the browser builds the transfer instruction, obtains a recent blockhash, compiles the transaction message and signs it with the local Ed25519 key. For supported tokens, it builds the relevant token transfer instructions and can create an associated token account for the recipient when required.
The RPC endpoint receives the signed serialized transaction for broadcast. Changing the recipient or amount after signing would invalidate the cryptographic signature.
6. Transaction history and explorer links
The activity view first requests transaction signatures associated with the wallet address and then loads details for individual transactions as needed. Explorer links open the public Solana Explorer in a separate tab.
7. Persistent browser session
If the user chooses to remain in the wallet, an encrypted wallet seed record is stored in IndexedDB together with a non-exportable browser-generated AES-GCM key. This allows the wallet to restore the session after a refresh or browser restart on the same browser profile. Selecting Exit removes the saved wallet session.
Browser persistence is a convenience feature, not a substitute for an offline backup. Clearing site data or losing the browser profile can remove the saved session.