Skip to content

Trust boundaries

What the program guarantees

Funds sit in token accounts whose authority is the vault PDA. Only the Ohge Guard program can sign for that PDA, and it signs only inside withdraw (owner-signed, destination owned by the owner) and execute_orca_swap (one validated Whirlpool swap CPI inside the owner's policy). There is no instruction that transfers to an arbitrary account, changes the owner, extends a session, closes the vault or invokes another program.

What the session key can do

Sign execute_orca_swap transactions (and pay their fees). Every rule is re-checked by the program, so a compromised session key can at most trade within the policy until it is revoked or expires. It cannot withdraw.

What the hosted worker is trusted with

  • Session signing material. With the local-file signer, keys are generated on the worker host and stored encrypted (AES-256-GCM, key from OHGE_SIGNER_KEY). Encryption protects files at rest; whoever controls the host and the key controls the session key. This is server trust, bounded by the onchain policy, and it is stated as such in the UI.
  • With the remote-http signer, an external service holds the keys and only returns signatures. The adapter is implemented but has not been exercised against a production signing service.
  • The worker also holds the LLM API key. The model never receives signing material, handles, or anything but the verified context.

What the model is trusted with

Nothing that matters for safety. It produces an intent that is validated against a strict schema and against verified balances, the policy and the computed candidate; the program then enforces the policy again. The model cannot invent balances, assets, permissions or execution results. hold is always acceptable.

Sign-in

Wallet sign-in proves control of a key with a single-use nonce, domain and expiry. The resulting cookie identifies the wallet to the API; it grants no onchain permission.

Oracle assumptions

Reference prices come from Pyth sponsored price-update accounts owned by the pyth-solana-receiver program. The policy pins the exact account per asset, so an operator cannot substitute an older verified update within the freshness window; freshness and confidence bounds are set by the owner. If the pinned account stops updating, trading that requires references fails closed.

Venue assumptions

The Orca Whirlpool program is executed as deployed on the target cluster; the guard validates the pool against the policy and the pool's own recorded vaults and mints, forwards no extra accounts, and trusts only the vault's balance deltas as evidence of what happened.

Not covered

No audit has been performed. The remote signer, mainnet deployment and production operations have not been assessed. See Limitations and Implementation status.