What the trading key can and cannot do

On registration the wizard broadcasts MsgAddAuthenticator with a composer tree shaped like this: AllOf [ SignatureVerification(trading-key-pubkey), AnyOf [MsgPlaceOrder, MsgCancelOrder, MsgBatchCancel], SubaccountFilter('0'), AnyOf [ClobPairIdFilter(ETH), ClobPairIdFilter(SOL), ClobPairIdFilter(BNB)] ].

Every transaction the trading key signs has to satisfy ALL four clauses. The chain rejects anything that fails even one — atomically, before any state change.

Open and close perpetual positions on ETH-USD, SOL-USD, BNB-USD only. The attacker could trade against you (open positions, close them at unfavorable prices) to drain value through bad trades — but slowly, position by position, and only on those three markets.

Cancel any pending order. Mildly annoying but reversible (you re-place the order).

Transfer funds out of your subaccount: blocked. The trading key is not on the AnyOf MessageFilter for MsgTransfer or MsgWithdrawFromSubaccount.

Trade on any market other than ETH/SOL/BNB: blocked by ClobPairIdFilter. Including BTC, LINK, AVAX, anything else.

Trade on any subaccount other than 0: blocked by SubaccountFilter. Subaccounts 1, 2, 3+ remain unreachable.

Modify the authenticator, register new ones, remove existing ones, change account settings, govern, stake: all blocked. None are in the whitelist.

If a malicious server steals the trading key, the worst-case damage is bad trades on three markets — not fund theft. You revoke the key on-chain (with a Keplr signature from your owner wallet, not from the trading key), generate a new one, and you're back in a clean state. No funds leave your subaccount during any of this.

If your owner mnemonic leaks, that's a different and worse problem — see the wallet-compromise runbook. But trading-key leaks are categorically less severe.