# Hydra Disclosure

## Custody — read this first

**Hydra holds your trading wallet's private key and signs transactions with
it — in both execution modes, Hydra is a custodial service.** Read this
section before you fund anything.

**What Hydra's code does.** Hydra's trading logic places swaps, routed
through Jupiter. Its signer also constructs and signs ordinary SOL transfers
where the mechanics require it — network tips and account-creation rent, for
example — and enforces a ceiling on the native SOL any single transaction it
signs may move. That ceiling does **not** bound SPL token movement; token
amounts are bounded by Hydra's own risk engine, which runs in the same
process as everything else. All of this is a property of software you can
read, not something the blockchain enforces. Nothing today gives the chain
itself a say in what Hydra's key can sign.

**What that does not mean.** Because Hydra holds the key, Hydra *can* move
the funds in your trading wallet. A bug, a compromised server, or anyone who
obtains that 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.**

**How the key is protected today.** Your trading wallet's private key is
stored encrypted with AES-256-GCM under a master secret Hydra's own
operators hold on Hydra's own servers. It is **not** stored in a hardware
security module, and it is **not** stored in a cloud key-management
service. If you assumed "Hydra holds your key" meant hardware-backed
custody, that assumption is wrong — stated here plainly because it is the
reader's most likely error. A compromise of Hydra's server, or of that
master secret, exposes the key it protects. Your trading key and any LLM
API key you provide are each encrypted under their own separate master
secret, so a leak of one does not expose the other.

**The two modes, both custodial.**

- **Approval mode** — Telegram asks before each trade, you tap approve,
  **Hydra signs**. You gate *which* trades happen; you do not hold the key.
- **Auto mode** — Hydra trades without asking and alerts you in Telegram
  after each trade.

The difference between the modes is gating, not custody. Neither mode is
self-custody.

**What is coming.** A future on-chain vault program would make the
swap-only limit cryptographically enforced rather than a promise: a
program-owned account that can only swap, and that you alone could withdraw
from. **It is not deployed and is not part of this product today.** It is
the next release, funded by these subscriptions. Until it ships, everything
above is Hydra's software behaving as described — not a guarantee the chain
backs.

**Two separate risks, both yours.** Trading losses and custody risk are two
different exposures. Hydra may lose money on trades — that is the risk of
autonomous trading, bounded by the risk rails below. Separately, because
Hydra holds your key, custody risk exists independent of how well the
trading strategy performs. You carry both.

**Read more.** This section states the core facts; it is not the full
picture. `docs/CUSTODY-WHITEPAPER.md` covers the same ground in more depth —
mechanics, a real multi-vector threat model, and what is and is not true
today — as optional further reading. Nothing in the product requires reading
it before you fund a wallet or select an execution mode.

## On-Chain Payment Authorisation — read this before subscribing

Subscribing to a paid Hydra tier asks you to grant Hydra's collection service
a standing, program-enforced authorisation over your USDC — a separate
wallet, a separate authorisation, and a separate risk from the trading-wallet
custody described above. Read this section before you sign.

**What the authorisation permits.** A pull of exactly the subscribed plan's
USDC amount, at most once per billing period, and only to the single
destination wallet published in that plan's own on-chain terms — the same
terms shown to you on the Billing card before you connect a wallet, and
independently checkable against the Plan account on-chain (`hydra billing
show-plans` is the exact check Hydra's own operator runs before trusting a
deployment's configuration).

**What it does not permit.** No other token. No other amount. No other
destination. No SOL. And no relationship whatsoever to your trading wallet —
the wallet you connect to subscribe is a different wallet from the one Hydra
custodies and signs with under the Custody section above. Granting this
authorisation gives Hydra's collection key no reach into that other wallet at
all.

**The program is upgradeable — these are program-enforced limits, not
immutable ones.** The Solana Subscriptions program these guarantees rely on
is deployed under an upgrade authority held by a Squads multisig that Hydra
does not control. Its published audit reviewed the program at commit
`d6b3a5d`, with fixes verified through `debb4f75`; the release actually
deployed on mainnet postdates that audited baseline, at commit `7d0cdd7`.
Hydra makes no trustlessness claim about the limits above: they are enforced
by this program's code today, not by anything the chain would refuse to let
a future upgrade change.

**How to revoke, without asking Hydra.** Two ways, from your own wallet, at
any time. Cancel the subscription on-chain — this stops future collection
and preserves your access through the period you already paid for; it is
never a partial refund. Or revoke the SPL token delegate directly on your
USDC account, from any wallet you control — this removes the authorisation
immediately, at the cost of the next collection failing (Hydra detects this
as a delegate eviction and tells you, in Telegram and on the Billing card,
rather than silently marking you past due).

**Another application can evict this authorisation too.** Your USDC account
has a single delegate slot. If another application later takes it — by
signing its own token approval on that same account — Hydra's authorisation
is displaced exactly the way a self-revoke displaces it, and the next
collection attempt fails. Hydra detects this before attempting a transfer,
never mistakes it for an empty wallet, and prompts you to re-authorise
rather than leaving you silently past due.

## Algorithm Disclosure

**How Hydra decides:**

1. **Scouts scan the chain.** Five lightweight scanner subagents (new-pool,
   momentum, whale, social, tokenized stocks) continuously monitor Solana
   for trading signals. Four of the five are LLM scanner subagents; the
   tokenized-stocks scout makes **no model call at all** — it is a
   deterministic price comparison between a tokenized stock's on-chain price
   and the issuer's own published quote, publishing only on a discount. Each
   scout produces ranked candidates independently.

2. **Fusion filters candidates.** A deterministic pre-filter combines scout
   signals using configurable weights. Only candidates with multi-signal
   corroboration reach the trader. The fusion weights, corroboration bonus,
   and threshold are configurable per subscriber.

3. **The trader decides.** A Claude LLM call evaluates each surviving
   candidate group. The trader outputs a conviction fraction (0-1) and
   rationale. It never sees bankroll, prices, or liquidity — a downstream
   system converts conviction to position size.

4. **Safety gates screen.** Before any trade, deterministic safety checks
   run: honeypot/rug detection, liquidity floors, holder concentration,
   sell-simulation. Unsafe tokens are rejected before any funds move.

5. **Risk rails enforce limits.** Position caps (per-trade, per-token,
   portfolio-wide), daily loss kill switch, and stop-loss/take-profit/
   trailing exits are enforced in code — not by prompt instruction.

6. **The trade executes.** Trades execute from your trading wallet, signed
   by Hydra's key, routed through Jupiter. Slippage bounds and daily-loss
   limits are enforced by Hydra's code *before signing* — not on-chain.

**What the LLM cannot see:**
- Current bankroll or wallet balance
- Live token prices or liquidity
- Other subscribers' decisions
- Historical P&L

**What runs outside the LLM:**
- All risk rail enforcement (code, not prompt)
- All safety screening (deterministic pipeline)
- All exit management (watcher process)

None of the above is enforced on-chain today — every item in this list is
Hydra's own code, running with the operational and custody risk described
above.

**No human reviews individual trades, mode-dependent.** In **auto mode**, no
human reviews individual trades — the system executes within its configured
risk rails and the operator monitors aggregate health only. In **approval
mode**, you approve each trade Hydra proposes over Telegram before it is
signed. **Exits — stop-loss, take-profit, and trailing stop — and the kill
switch are never held for your approval, in either mode; they fire
immediately.** Approval mode gates which entries happen. It does not gate
whether Hydra protects the position you are already in, because a
stop-loss that waits for a tap is a stop-loss that does not fire while you
are asleep.

## Known Limitations

- P&L figures exclude priority fees, Jito tips, and account rent
- Fill amounts for hosted trades are based on Jupiter quotes, not confirmed
  on-chain deltas (slippage can cause 0.1-1% variance)
- The dashboard serves plaintext HTTP by design (loopback-only, SSH tunnel
  for remote access)
- Approval mode's gate applies to entries only. An entry you do not approve
  does not happen — so an opportunity can pass while you are asleep or
  away — and a proposal you do not answer within its approval window
  expires and is not executed. Exits are never affected: a stop-loss,
  take-profit, or trailing exit fires whether or not you are watching
  Telegram.
- The approval window is short by default (three minutes, operator
  configurable). An expired proposal always produces an explicit Telegram
  message telling you it expired — never silence.
- **As of 2026-08-21, Hydra has not executed a trade for any subscriber.**
  Any performance figures shown come from the operator's own trading or
  paper-trading sessions and are not subscriber results.

## Tokenized Securities — read this before trading one

Hydra can classify certain Solana tokens as tokenized equities (for example,
tokens issued by Backed Finance's xStocks or Ondo Global Markets) and route
them through screening built specifically for that asset class. This section
discloses the risks that are unique to that asset class, on top of
everything above. If you never hold a tokenized-equity position, none of
this applies to your trades. As of this writing, this capability is
enabled by default in the code. No account trades a tokenized-equity token
until that account has recorded an explicit agreement to this section,
presented as an accept/decline choice in the Telegram bot. **The operator is
not exempt** — the operator's own account passes the same gate a subscriber
does, an explicit decision recorded alongside this change. Declining, or
simply not answering, leaves an account gated: no tokenized-equity entries
for that account. If this disclosure's text is materially revised, every
prior agreement stops applying and each account is asked again before its
next tokenized-equity entry.

**A token is a claim, not the share.** A tokenized equity is not the
underlying stock. It is a claim on a share that a third-party custodian
holds on your behalf. Holding it exposes you to that custodian's solvency,
honesty, and continued willingness to honor redemption — a counterparty
exposure the memecoin risk description above does not describe. A custodian
that becomes insolvent, acts in bad faith, or simply stops honoring
redemption requests can leave the token worth less than what it claims to
represent, independent of anything Hydra's code does correctly.

**The token trades when the underlying market is closed.** A tokenized
equity can be bought and sold on-chain around the clock. The stock it
represents only trades during the underlying exchange's regular session. A
price printed while that market is closed — nights, weekends, holidays — is
not anchored to a live, tradeable reference price on the underlying side.
That price is unanchored, not necessarily wrong. Hydra knows the
underlying's regular-session calendar, including holidays and scheduled
early closes. By default, Hydra now enters at a reduced size — a quarter of
the size it would otherwise take — rather than refusing, while the
underlying session is closed; an operator can still configure Hydra to
refuse new entries outright during that time instead.

**The reference price is a delayed quote, not a net asset value.** Hydra
measures how far a tokenized equity's on-chain price has drifted from a
reference price and surfaces that drift as a premium or discount. As
currently built, that reference price is the issuer's published market
quote for the underlying share (Backed Finance's public xStocks API, since
2026-09-05), not an issuer-published net asset value — Hydra has
not obtained NAV data from any issuer. Tokens from an issuer that publishes
no such quote (Ondo, today) have no reference price and are never entered.
Every premium/discount figure Hydra
surfaces states the quality of the reference price behind it. A reading is
refused — surfaced as unavailable, never estimated — only when no quote can
be obtained at all. While the underlying market is closed, Hydra instead
measures the gap against the issuer's last trade and labels that reading as
unanchored, rather than refusing it. A stated premium or
discount is a measurement against a delayed market quote for the
underlying, not against the token's net asset value. Since 2026-09-14, the
reference price may instead come from an independent market-data feed
(Alpaca's IEX tier) carrying the feed's own quote timestamp when the
underlying's regular session is open; absent that feed, or when it cannot
be reached, the reference remains the issuer's own published quote, or the
last eligible print while the session is closed — always labelled with
which of these it is. For a token whose own underlying has no direct
feed coverage, Hydra may instead use a documented proxy instrument's price
(for example, an index-tracking token priced off a closely related fund)
— stated here plainly because a proxy reading describes a different, related
instrument, not the token's own underlying. What Hydra compares the
on-chain price against is that reference price scaled by the issuer's
current multiplier — its own published redenomination factor — not the
raw reference alone; when that multiplier cannot be read, the premium or
discount is reported as unmeasured rather than computed against a guessed
multiplier.

**You cannot redeem these tokens with the issuer — the only exit is selling
them.** Every tokenized-equity issuer Hydra currently recognizes restricts
redemption of the token for the underlying claim to participants it has
onboarded directly: institutional counterparties, or clients who have
completed the issuer's own KYC and wallet-whitelisting process. An ordinary
holder is not one of those participants and cannot redeem the token with the
issuer at all. Your only exit is selling the token to someone else on the
secondary market, at whatever price that market offers at the moment you
sell. Hydra's own exits work the same way — every position Hydra opens, it
closes by selling on-chain, never by redeeming with an issuer. What you
carry, as long as you hold, is the risk that the token's on-chain price
drifts away from the underlying's price and that nobody is obliged to close
that gap for you. Hydra measures that gap whenever a reference price can be
obtained — against the delayed vendor quote described above while the
underlying's regular session is open, and against the issuer's last trade
while it is closed. Refusal is reserved for when no reference can be
obtained at all — a stale quote, or no market-data key configured. When it
can measure the gap and the gap is inside the
operator's configured band, Hydra enters at a reduced size. A reduced size
limits how much of this risk one position carries; it does not remove the
risk, and it is not a remedy for it. Whether Hydra will enter one of these
positions at all is an operator policy setting: the shipped default refuses
every entry on a token with no holder redemption, and an operator must
deliberately turn the reduced-size policy on.

**A pool priced in a tokenized stock is not a tokenized stock.** Since September
2026, Solana launchpads (Pump.fun's Custom Pairs, StonkFun) let anyone
launch an ordinary token whose pool is quoted in a tokenized equity instead
of SOL or a stablecoin. Trading volume in such a pool looks like demand for
the equity and is not — it is speculation in the ordinary token, and holding
that token gives you no claim on the share at all. Hydra labels the two
cases apart on the evidence its scouts publish: a token that is itself a
reviewed tokenized equity, versus an ordinary token that is merely priced in
one. The second kind is screened as an ordinary token, through the memecoin
safety gates, not through the tokenized-equity path described in this
section — and none of the protections above (the session check, the
premium/discount measurement, the issuer review) apply to it, because there
is no underlying share behind it to check against. This is a label the
trader weighs, not a refusal: Hydra does not decline such a token for being
priced in a tokenized stock, it declines to mistake it for one.

**A stock split changes the token's price, not its value.** Corporate
actions on the underlying — a stock split most notably — change the
reference price without changing what the token actually represents. Hydra
reads a recorded corporate action on the underlying as a redenomination of
the claim, not as a loss, and states the split ratio when it can compute
one from the vendor's data.

**Hydra cannot see an intraday trading halt on the underlying.** If the
underlying exchange halts trading in a stock intraday — a circuit breaker,
a news-pending halt, a regulatory halt — Hydra has no visibility into that
halt today. Hydra knows the underlying's regular-session calendar (open,
closed, holiday, scheduled early close), but not a real-time trading-halt
feed. If the underlying halts while the token keeps printing on-chain,
Hydra will not know the underlying stopped trading. This is a present
limitation of the system, stated plainly rather than softened: an
undisclosed blind spot in a system that moves money is exactly the failure
mode this document exists to prevent.

**Hydra makes no determination about a tokenized security's legal status.**
Whether a given tokenized-equity token, its issuer, or the act of trading
it is subject to securities law, and whether you are eligible to hold one,
are questions Hydra's code and this document do not attempt to answer.
Hydra makes no representation about the securities-law status of any
tokenized-equity token, or about your eligibility to hold one. Gating
subscriber eligibility for this asset class by geography or other criteria
is not yet built and remains an open item, separate from everything
described above. Nothing in this document, or anywhere else in Hydra's code
or documentation, characterizes any tokenized-equity token, its issuer, or
the activity of trading it under any securities law — that determination
belongs to counsel, not to this document.