Running automation without losing the keys

Volume Ops Runbook is the operations half of running trading software on Solana. Not which bot to buy: how the wallets are split, how the fleet is funded, what is checked before a live run, what wakes you up, and what you do in the first hour when a key looks compromised.

Open the automation console Read the preflight checklist

Procedures, preconditions and rollback steps. Every irreversible step is labelled as one.

operating loop

segment   tiers defined, caps written, account map current
fund      reserve -> treasury -> dispatcher -> execution
preflight dry run, simulate, one-wallet canary, abort tested
observe   balance floor, failure rate, liveness, outbound
stand down drain, close, sweep, reconcile, archive

The operating loop

Five stages, in this order, every run. Skipping one does not remove it from the loop; it moves it to the point where it costs more.

Segment

Decide what each key is allowed to reach before a single lamport moves.

Fund

Fan out from a reserve to working wallets against per-wallet floors you wrote down first.

Preflight

Dry run, simulate, then send one real transaction from one wallet.

Observe

Watch balances, failures and liveness from outside the process doing the work.

Stand down

Drain, close accounts, reconcile the ledger and archive the run.

Featured runbooks

The four procedures operators reach for most often, in the order the consequences arrive.

Key hygiene

Wallet security for trading bots

A bot wallet is a hot wallet by definition. The threat model, the four paths that actually empty accounts, and a hardening sequence you can finish today.

Open the procedure Key hygiene

Key storage and rotation

Where a seed phrase and a signing key can safely live, what encryption at rest really protects, and a rotation order that never strands an account.

Open the procedure Runbooks

Rent and account costs

Rent exemption is locked capital, not a fee. What each account type reserves, and which lamports come back when you close it.

Open the procedure Monitoring

Incident response playbook

The ordered first hour after a key looks compromised: contain, move, revoke, rotate, reconstruct. Written for the worst moment to be reading it.

Open the procedure

Three sections, three kinds of consequence

Custody decisions are made once and live for years. Procedures are followed under time pressure. Monitoring decides how long a problem runs before anyone notices.

Runbooks

Numbered procedures with preconditions, verification steps and a stated stop condition.

Funding a wallet fleet
Rent and account costs
Preflight before a live run
Shutting a run down cleanly

Open the section

Key hygiene

Custody: what generates a key, where it lives, what it may sign for, and how it is replaced.

Wallet security for trading bots
Wallet segmentation strategy
Key storage and rotation

Open the section

Monitoring

Seeing a run go wrong early, keeping logs that answer questions, and responding in order.

Monitoring and alerting
Reading bot logs
Incident response playbook

Open the section

The short preflight

The full gate list lives in the preflight runbook. This is the compressed version an operator can read from a phone before authorising anything, and it is deliberately short enough to actually be used.

If any line here is unclear, the run is not ready. An unclear precondition is a precondition that has not been met.

Open the full preflight gate list

The account map matches the keys the software will actually load.
No key in the run has ever been typed into a browser, a chat or a synced note.
Every execution wallet is above its floor: rent reserve, fee buffer, working amount.
The endpoint and its credential are the ones you intended, and the credential is not in a log.
A single transaction has been simulated and read, not just submitted.
One wallet has completed a canary at the smallest usable size.
The stop path has been exercised at least once, by the person who will use it.
Someone specific has agreed to answer the alerts for the duration of the run.

What a managed console removes from the runbook

Most of this site exists because operators run automation on their own machines, with their own keys and their own scripts. A hosted console changes which parts of the loop you build yourself; it does not change who carries the consequences of a key.

Scheduling, retries and the fan-out arithmetic are already implemented and versioned.
Run state, failures and history sit in one view instead of a log file you have to grep.
Endpoint credentials live in one place rather than in every script you wrote at midnight.
What it does not remove: custody. Anything that trades for you holds a key that can sign.

Read the operator-side questions to ask about any hosted tool in the key hygiene section before you fund anything.

Look at a managed setup

The console referenced across this site is a third-party product that runs multi-wallet activity on Solana venues. Open it if you want to see what the hosted version of this loop looks like before deciding to build your own.

See a managed setup

Third-party site, opens in a new tab. The desk earns nothing from your use of it and does not audit its results.

How this desk writes procedures

A runbook is only useful if it is correct at three in the morning. That constraint decides what goes on the page and what stays off it.

Mechanism before opinion

Every step explains what the network or the program actually does, so you can adapt the procedure when your setup differs. Protocol constants are stated with their formula, not copied from memory.

Numbers are protocol facts or labelled arithmetic

Rent minimums, fees and limits come from the protocol. Everything else is illustrative arithmetic shown in full so you can substitute your own inputs. The desk publishes no measured results and no case studies.

Irreversible steps are named

Transfers, key rotations and account closures cannot be undone. Where a procedure passes a point of no return, the page says so before the step rather than after it. Read the editorial policy for sourcing and corrections.