What we publish
Operational procedures for running trading automation on Solana: custody, funding, preflight checks, monitoring and incident response. Every page is written to be executed rather than admired, which means preconditions come before steps, steps are ordered, and the verification that tells you a step worked is stated explicitly.
Sourcing
Procedures are built from three sources, in this order of authority. First, protocol and program behaviour as documented by the projects themselves, including the Solana documentation and the SPL Token program documentation. Second, the behaviour of standard tooling such as the command line client, described by what the commands do rather than by what output we claim to have seen. Third, ordinary operational reasoning about failure, which is presented as reasoning and never dressed up as measurement.
Where a claim depends on something a reader can check for themselves, we say where to check it: an explorer, a program's documentation, or the account state itself. Where a claim cannot be checked, we prefer to describe the mechanism and leave the number out.
Numbers
Only three kinds of number appear on this site.
- Protocol constants. Values fixed by the network or a program, given with the formula that produces them wherever a formula exists. The rent-exempt minimum for an account, for example, is stated together with the byte and byte-year arithmetic behind it so you can compute it for any account size.
- Illustrative arithmetic. Worked examples that begin from inputs we state and show every step. These are labelled illustrative on the page. They are not observations, forecasts, or typical values, and substituting your own inputs is the intended use.
- Thresholds you are told to choose. Where a procedure needs a number that depends on your setup, we describe the shape of a sensible threshold and tell you to pick the value, rather than inventing one that would look authoritative and be wrong for most readers.
Banned outright
Fabricated statistics, invented survey results, incident counts, performance figures, profit or loss examples presented as real, review counts, star ratings, testimonials, named experts who do not exist, and screenshots of output we did not produce. None of these appear on this site, and if you find something that looks like one, report it as a defect.
Authorship and the byline
Pages are published as the Volume Ops Desk. That is an editorial function rather than a person, and we do not attach a fictional author, portrait or credential list to a page in order to borrow authority the writing has not earned. The desk also does not claim operational history: no page says we ran a fleet, recovered an incident, or measured a result, because none of that would be verifiable.
Commercial references
This site links to a third-party automation console operated by another company. Those links are labelled where they appear, open in a new tab, and sit next to a note that the desk earns nothing from your use of the product and does not audit it. There is no review, ranking or scoring of that product or any competitor anywhere on this site.
Two subject areas are kept commercially clean on principle: key storage and rotation, and incident response. A reader arriving at those pages is either designing custody or already in trouble, and a commercial reference in either context would be opportunistic. Those pages carry no product link in the body.
Safety rules the desk holds to
- No procedure on this site ever asks a reader to enter a seed phrase into a website, an application configuration, a chat, a screenshot or a synced note.
- Steps that cannot be undone are labelled before the step, not after it. Transfers, key rotations and account closures are treated as irreversible in every procedure.
- Where a control reduces risk without removing it, the residual risk is stated. We do not describe any setup as safe, guaranteed or fully protected.
- Nothing here is financial, legal or tax advice, and the desk has no view on whether any particular automated activity is appropriate or permitted where you live.
Corrections
Reports of errors go to the contact address. A correction that affects safety is prioritised above all other work and is applied to the page itself, because a runbook is read at the moment of use and a footnote at the bottom does not reach the person following step four. Where a correction changes the meaning of a procedure rather than fixing a typo, the page states what changed.
Updates and dates
Pages carry a last-updated date generated when the page is served, and the publication date recorded in the page metadata is the date the page was actually first built. The desk does not backdate content to look established, and does not refresh a date without changing anything on the page. If a procedure has drifted out of date because the ecosystem moved, the right fix is to update the steps, which is what the desk tries to do.