> Guveno API reference v1.10.0, last updated October 17, 2026. The whole reference is at https://www.guveno.com/llms-full.txt.

## Hot wallets

A hot wallet is an automated, always-on signer: think of an exchange paying out withdrawals without a human in the loop. The SDK runs the whole prepare → sign → broadcast cycle in your process; the server never holds the key.

### When to use one

Reach for a hot wallet when funds must move programmatically: payouts, sweeps, rebalancing. For funds you don't need to move automatically, keep the key offline and sign by hand instead (cold storage): the API flow is identical, only the signing step happens on an air-gapped machine. A common split is a small hot wallet for day-to-day flow and cold storage for the bulk of reserves.

### Setup

A hot wallet needs two things: a Guveno client authenticated with an API key that holds `withdrawals:create` on the wallet, and a **key provider** that supplies the wallet's recovery phrase at signing time.

```
import { Guveno, FileKeyProvider } from "@guveno/wallet-sdk";

const guveno = new Guveno({
  apiKey: process.env.GUVENO_API_KEY, // gv_live_... (baseUrl defaults to production)
});

// Maps each wallet's key fingerprint -> recovery phrase, from a mounted secret.
// For production, prefer a KMS/HSM-backed provider (see HSM & KMS).
const keys = new FileKeyProvider("/run/secrets/guveno-keys.json");

// Load the wallet by id with the key provider, then withdraw from its addresses.
const wallet = await guveno.loadWallet(10, { keys });

const withdrawal = await wallet.withdraw({
  addressId: 50,
  assetId: 3,
  toAddress: "0xRecipient...",
  amount: "0.25",
});
```

Alternatively, source the secret straight from the server: load the wallet with your encryption password instead of a key provider: `guveno.loadWallet(10, encryptionPassword)`. Prefer the terminal? The CLI wraps the same flow:

```
guveno withdraw --wallet-id 10 --address-id 50 --asset-id 3 \
  --to 0xRecipient... --amount 0.25 \
  --keys ./keys.json   # or omit --keys to sign with the server-held secret
```

### How it signs

For each withdrawal the hot wallet asks the server to `prepare` an unsigned transaction, unwraps the recovery phrase from the key provider, signs in-process, broadcasts the signed transaction, then drops the secret from memory. Sends from the same source address are serialized so concurrent withdrawals can't collide on a nonce. Automated signing covers **Ethereum, BNB Smart Chain, Polygon, Arbitrum, XRP, Bitcoin** (native SegWit / P2WPKH), **Dogecoin** (legacy P2PKH; each input's previous transaction rides along as `prevTxHex`, and the signer reads the input value from it rather than from the payload), **Polkadot, TRON, Solana and TON** (GRAM and jettons).

### Staying safe

- The API key only authorizes `prepare`/`broadcast`; the actual spend still requires the key material your provider holds, so guard that host tightly.
- Grant the key only `withdrawals:create` on the wallets it pays from, and give it an expiry.
- Keep only what you need hot; hold the rest in cold storage.
- In production, back the key provider with a KMS or HSM rather than a plaintext file.

Source: https://www.guveno.com/docs/hot-wallets/