Agent-wallet security model
How the Botely agent wallet is bounded, where its private key lives, what an attacker who compromised it could and could not do, and how revocation works.
Two layers of restriction
Layer 1 โ Hyperliquid protocol: agent wallets approved via `approveAgent` are by design trading-only. They cannot sign withdrawal actions, balance transfers or any non-trading account modification. This is enforced by the Hyperliquid validators, not by Botely.
Layer 2 โ Botely server-side: the bot's execution code only ever signs `place` and `cancel` order actions, and only for the ETH-USD, SOL-USD and BNB-USD markets. The agent is technically capable of signing other trading actions (e.g. a BTC-USD entry), but Botely's code never asks it to.
Where the key lives
The agent's private key is encrypted with AES-256-GCM using a server-side master key (`MASTER_ENCRYPTION_KEY` env, never committed). The ciphertext + IV + auth tag are stored in Postgres; the master key is on the application server only.
Decryption happens in-memory during signing: each tick the bot loads + decrypts the bundle, signs the action with viem, then discards the plaintext. The plaintext never hits disk and never appears in logs.
Worst-case compromise
If both the encrypted bundle and the master key were exfiltrated, an attacker would have a working agent key. They could place / cancel orders on your account within Hyperliquid's protocol-level bounds โ they could not withdraw funds, transfer balances, expand the agent's scope or take any non-trading action.
They could place trades on markets outside the ETH/SOL/BNB whitelist (since that's a Botely-server rule, not a chain rule). For most subscribers the practical worst case is a malicious entry on a market with no live position โ closeable in minutes from your dashboard or by revoking the agent.
Revocation
Three independent kill paths: (1) per-strategy toggle in /app/settings (โค30s); (2) master switch in /app/settings (โค30s); (3) revoke the agent wallet from Hyperliquid's web UI (effective from the moment the revoke action is accepted).
After a wallet-side revoke, the encrypted Botely bundle is still in Botely's DB but useless: it no longer has signing authority on your account. Botely also flushes the bundle on next account-config refresh; backups follow the 90-day Privacy Policy retention.
Comparison with the previous dYdX-Cosmos model
Historically Botely ran on dYdX v4 with a Cosmos `MsgAddAuthenticator` authenticator whose scope (market list, message types, subaccount) was hard-limited at chain level. The new HL model has the same withdrawal protection (Hyperliquid agents cannot withdraw) but the per-market whitelist is now a server-side rule rather than a chain rule.
This is honestly disclosed in the Risk Disclosure (ยง7A.4): the residual risk is a Botely server compromise or insider action that signs outside the ETH/SOL/BNB whitelist. Mitigations: code review, change management, audit logging โ but the risk is non-zero.