Key storage and security
Where your guard key lives, what it can and cannot do, and what a server compromise would mean.
Read this before approving a guard key
Your guard key is a non-exportable key in AWS KMS, held in hardware security modules validated to FIPS 140-3 Level 3. Its private key never leaves KMS: Bulwark never sees it, and no one can copy it. If Bulwark's signing service were compromised, an attacker could ask KMS to sign trades on your account for as long as they controlled the service. They could not copy the key, and they could not withdraw your funds.
What the guard key is
When you set up the guard, Bulwark creates a key just for you and you approve it on Hyperliquid as a named agent (bulwark-guard). Hyperliquid lets agent keys place and cancel orders and move funds between your own balances, but never withdraw (Hyperliquid: API wallets).
Reduce-only is our engine's limit, not Hyperliquid's: the key itself could place any trade. That is why the seven checks run in open code before every signature.
How it is stored
- One KMS key per user, created for you in AWS KMS (Singapore,
ap-southeast-1) as a secp256k1 signing key. AWS generates the private key inside its hardware security modules; it is never exported, not even to Bulwark (AWS KMS: features). - Two separate roles. The service that creates keys can only create, describe, disable and schedule deletion of keys tagged for Bulwark. The signing service can only ask KMS to sign and read public keys. Neither can export a key.
- Signing. The signing service sends KMS only the hash of an action that has already passed the seven checks, and checks that every signature recovers to your key's address.
- Never returned. No part of Bulwark can read key material, because none leaves KMS. The web app and the API only ever see your key's address.
The fallback: an encrypted key on Bulwark's server
If KMS is unavailable, Bulwark can instead create your key on its signing service and store it encrypted (AES-256-GCM) under a master key that exists only as a secret on that service. Each encrypted key is bound to your account and network, decrypted only for a single signature, and cleared from memory right after. Unlike a KMS key, an encrypted key is not hardware-backed: if that server and its master key were compromised, the key itself could be copied and used to place trades. It still could not withdraw.
Keys created during the testnet preview before KMS was switched on are encrypted keys. Settings › Account shows which kind your key is. To move to a KMS key, replace your key.
Rotation and removal
- Replace your key: a new key is created; it takes over only once you approve it on Hyperliquid. The old one then stops signing at once: a KMS key is disabled and scheduled for deletion, an encrypted key is destroyed.
- Wipe your key: a signed command stops the guard, cancels the orders it placed while the key can still sign, then retires the key the same way. A disabled KMS key cannot sign; AWS deletes it after a 7-day waiting period. Every step is in your audit log.
- On Hyperliquid: wiping does not remove the approval there. Approve a different key under the same name, or let the approval expire.
- Expiry: when you approve the key on Hyperliquid you can set how long the approval lasts.
Your trading key
The optional trading key for your own orders is created in your browser and stays there (it is not sent to Bulwark). Like every Hyperliquid agent, it cannot withdraw. Anyone with access to your browser profile could trade with it; you can forget it in Settings.