Wallet security for trading bots
The threat model for a wallet a program can sign with, the four failure paths that actually empty accounts, and a hardening sequence you can complete in one sitting.
Open the procedureKey hygiene: custody rules for wallets a program signs with
Automation needs a key that can sign without a human present. That single requirement rules out every custody model built around physical confirmation, and it is why a bot wallet is a hot wallet no matter how careful you are. The work is not eliminating that exposure. The work is deciding exactly how much each exposed key can reach, and making sure the answer is written down somewhere other than your memory.
These three pages are the custody layer of the site. They cover the threat model for a signing key, the tier structure that limits what any one compromise reaches, and the storage and rotation practices that keep keys replaceable. Nothing here asks you to enter a seed phrase anywhere.
Assumption Any key a running process can read is a key that can leak
Boundary Tiers are enforced by balance, not by intention
Non-negotiable Seed phrases never enter a config, a site or a chat
3 procedures in this section
How keys are generated, where they live, what each one is allowed to touch, and how you rotate them without losing access to the accounts they control.
Wallet segmentation strategy
Splitting one balance into tiers so a single compromised key cannot reach the rest. Roles, caps, refill rules and the account map that keeps the split honest.
Open the procedureKey storage and rotation
Where a seed phrase and a signing key can safely live, what encryption at rest actually buys you, and a rotation procedure that never leaves an account unreachable.
Open the procedureHow this section is used
Custody decisions are the ones you make once and live with for years, so they deserve the slowest reading on this site. Start with the threat model, design the tiers before you fund anything, and treat rotation as routine maintenance rather than a response to a scare. When a key does look exposed, the ordered response is in the monitoring section.
Runbooks Numbered procedures with preconditions, rollback points and stop conditions. Funding a fleet, budgeting account rent, clearing a preflight and shutting a run down without stranding value. Monitoring Signals worth alerting on, log lines worth keeping, and the ordered response for the moment a key or an endpoint is no longer trustworthy.