Solana

The Vault supports Solana with deposits and withdrawals for native SOL and for allow-listed SPL tokens. Signing uses the same parties and the same quorum as every other network, with a different signing protocol: EdDSA rather than ECDSA.

Address Generation

A Solana address is the 32-byte Ed25519 public key, encoded in base58 — there is no prefix or wrapper around it, so addresses have no common leading character the way Bitcoin and TRON addresses do.

Solana lives in a wallet of its own. A wallet is bound to a single key, and Solana’s Ed25519 key cannot sit beside the secp256k1 key behind Ethereum, Bitcoin and TRON addresses — selecting Solana together with those networks when creating a wallet is refused.

Supported Asset Types

Fee Model

Solana fees are charged per signature and are small and predictable compared to EVM gas. The Vault quotes the fee from the network for the exact transaction it is about to send, with a floor of 0.000005 SOL, and the fee is always paid in SOL, including for SPL token transfers.

Rent and Minimum Balances

On Solana an account either keeps at least the rent-exempt minimum or is emptied completely: a balance above zero but below the minimum is not a state an account can be left in. That shapes which withdrawals are possible:

• A withdrawal may take the whole balance and leave the address empty.
• It may not leave a remainder that is above zero but below the minimum.
• The recipient’s balance after the transfer must reach the rent-exempt minimum, so a dust-sized first transfer to a brand-new address is refused.

The minimum is read from the network rather than hard-coded, so it follows the cluster. A transfer that breaks one of these rules is refused when it is created, with the bounds the amount has to fall within.

SPL Transfer Mechanics

Addresses in The Vault are always owner addresses, never token accounts. The platform derives the associated token accounts itself and sends SPL tokens with the Token Program’s checked-transfer instruction, which verifies the mint and decimals on chain.

• The custody wallet’s own token account must already exist — it is created when the wallet first receives that token.
• If the recipient has no token account for the mint, the transaction creates it as part of the same transfer, and custody pays its rent once.
• The recipient’s token account is re-checked at signing time, so an account created in the meantime does not break the transfer.

Signing and Broadcast

A Solana transaction references a recent blockhash that expires within minutes, while governance approval and a mobile signature can take longer. The Vault therefore stores only the intent of a transfer when it is created — sender, recipient, amount, and mint for tokens — and builds the actual transaction with a fresh blockhash at signing time.

Before anything is signed, the rebuilt transaction is checked back against that stored intent, and the cluster is verified by its genesis hash — a mainnet transfer cannot be signed against a devnet endpoint. After signing, the signature is recorded before the first broadcast: if a broadcast result is ambiguous, the identical signed transaction is resent and never signed a second time.

Deposit Detection

Deposits are detected through the blockchain indexer’s Solana watch API, which covers native SOL transfers and SPL token transfers for watched addresses. Balances come from two sources: the native SOL balance is read from the node at the confirmed commitment, while SPL token balances come from the indexer once the block is finalized. A balance at confirmed can still be revised, because a block at that level may yet be dropped.

Confirmation Policy

A withdrawal stays SENT until the network reports its signature as finalized, and only then becomes CONFIRMED — confirmed and processed are treated as still pending, because a transaction at those levels can still be dropped. The platform re-checks pending signatures every 15 seconds by default; the interval is a deployment setting.