# Hydra Custody Whitepaper

*Informational document. Reading this is not required to use Hydra's hosted
product, and no system checks whether you have read it, agreed to it, or
even opened it.*

## Mechanics

When you request a trading wallet, Hydra generates a new Solana keypair
entirely server-side — the secret key is never imported from you, and you
never see, enter, or transmit it. Hydra seals the secret key at rest in an
AES-256-GCM envelope (ciphertext, initialization vector, and authentication
tag) under a master secret Hydra's own operators hold on Hydra's own
servers. Decryption happens through a single narrow path in the codebase;
nothing else in the system reaches the plaintext key. Your trading key and
any LLM API key you separately provide are sealed under different master
secrets, so a leak of one does not expose the other. The only thing you ever
see is the wallet's base58 public address — the deposit address you fund.

## Authority

Hydra holds the trading wallet's private key and signs with it in both
execution modes. Approval mode and Auto mode differ in gating, not in
custody: in Approval mode you tap to approve each entry before Hydra signs
it; in Auto mode Hydra signs and executes without asking, then alerts you
afterward. Neither mode is self-custody — there is no mode in which you hold
the key.

## What That Means

Because Hydra holds the key, Hydra can move the funds in your trading
wallet. A bug, a compromised server, or anyone who obtains the key could
move them, and nothing on-chain stops that today.

**Fund your trading wallet with only what you accept being traded, and only
what you could afford to lose entirely.**

## Exits

Stop-loss, take-profit, and trailing stop fire immediately in both execution
modes and are never held for approval. Approval mode gates which entries
happen; it never gates whether your capital is protected on the way out.

## Threat Model

This section states real risks plainly rather than as a formality.

- **Server compromise.** An attacker who reaches Hydra's server reaches both
  the encrypted key material and the master secret that decrypts it — the
  two together are equivalent to holding your key outright. Nothing
  structural in Hydra's infrastructure prevents this today beyond ordinary
  server hardening.
- **Insider risk.** An operator with legitimate access to the master secret
  has the same technical capability an attacker holding that secret would
  have. Access control and process are the only mitigation in place today;
  there is no cryptographic or on-chain barrier that would stop an operator
  from moving funds.
- **Software defect.** The risk engine, the signer, and every gate that
  bounds what Hydra will trade run in the same process as everything else.
  A bug in that code is a bug in the very thing meant to bound it — there is
  no separate, independently enforced backstop today.
- **Dependency / supply-chain compromise.** The signing path depends on
  third-party libraries (Solana SDKs, cryptography libraries, the Jupiter
  integration). A compromised dependency anywhere in that chain could reach
  the signing path. Hydra pins dependency versions and reviews updates, but
  that is process, not a structural guarantee.
- **Backup and log exposure.** Database backups and application logs are
  additional places encrypted key material or the master secret could leak
  if they are mishandled, over-retained, or reach an unintended audience.
  Hydra does not log plaintext key material or the master secret by design,
  but a backup that is copied, retained past its need, or exposed by a
  separate misconfiguration is a real exposure path this document does not
  claim to have eliminated.

Across every item above, nothing on-chain constrains what a compromised key
can do. The mitigations that exist today are operational — server hardening,
access control, dependency review, log and backup hygiene — not
cryptographic or chain-enforced ones.

## What Is Not True Today

An on-chain vault program has been built but is not deployed and is not
part of this product today. Every limit described anywhere in Hydra's
documentation — position caps, loss limits, swap-only restrictions — is
software behavior enforced by code running on Hydra's own servers, not
something the Solana blockchain itself enforces or would refuse to let
Hydra violate.

## Status of This Document

This document is informational. Reading it is not required to use Hydra's
hosted product, and no system checks whether you have read it, agreed to
it, or even opened it before you fund a trading wallet or select an
execution mode.