Skip to content
The Sniper Bot Index

Risk desk

Three pages that are worth more than any strategy on this site, because they are about not handing away control. Token screening, key custody and the failure patterns that repeat, with the honest limits of each stated alongside the method.

Section 03 / Risk desk 3 reference pages

Risk in automated trading has two distinct halves that are usually discussed as one. The first is whether the thing you are buying can be sold: a question about program state, authorities and liquidity. The second is how much any single mistake can cost you: a question about custody, permissions and segmentation. They need different tools and different habits.

Between them sits a third topic, operational failure, which is neither a scam nor a market loss but a system behaving in a way its operator did not anticipate. That is where most money is actually lost, and it is the least discussed of the three, because it is nobody's fault in a satisfying way.

The recurring position of this desk is that risk control is not a feeling of safety, it is a number chosen in advance. What is the maximum this credential can lose. What is the price impact if I exit this position at current depth. Which failure mode is producing this loss. Once those questions have written answers, the remaining uncertainty is market uncertainty, which is the only kind worth carrying.

Pages in this section

01

Why sniper bots fail: eight failure modes

Late detection, failed landing, slippage blowout, weak filtering, rent shortfalls, key exposure, throttling and unhandled migration, each with the observation that distinguishes it, plus a post-mortem template.

02

Pre-entry safety checks

Mint and freeze authority, Token-2022 extensions, pool ownership, depth against your size, holder concentration and a simulated exit. Twelve checks with what each one still misses.

03

Keys, wallets and bot permissions

Three custody models compared, what a wallet connection actually grants, delegates and account authority, a wallet tier architecture, blast radius and a revocation runbook.

What screening can and cannot prove

Every on-chain check reads program state, which describes what is currently possible rather than what anyone intends to do. A clean authority configuration excludes a family of mechanical traps and says nothing about whether the people holding the supply will sell into you tomorrow. Reading a passing checklist as a safety rating is the single most common misuse of these tools, and it is encouraged by products that present the result as a score.

The same applies to custody. No configuration makes a private key safe; segmentation only bounds what a disclosure costs. A tiered wallet structure does not prevent compromise, it decides in advance how large the loss will be, which is a different and more achievable goal.

Order of reading

Start with the failure modes if something has already gone wrong, because that page is organised as a diagnostic rather than as an explanation. Start with the checks if you are configuring a filter. Start with custody if you are about to paste a key anywhere, which is the moment when the decision is cheapest to reverse and the one most people move through without pausing.

The one-line version

Never give automation a seed phrase, only a single derived key, and never fund an operating wallet with more than one session needs.

Other sections