Operational risk

Tuo's contracts are strategy-agnostic. Every decision about your position is taken off-chain by the Tuo engine and executed by a Tuo-run keeper. That makes Tuo's operations part of the risk.

A compromised or faulty keeper

The keeper is an address with a signing key in a cloud HSM, driven by Tuo's backend. If that key, that backend, or the engine feeding it were compromised or simply wrong, the vault bounds the damage inside the vault:

Be precise about what that buys. The loss budget is a rate limiter, not a solvency guarantee. It is per position, so it aggregates to 1.5% of total deposits per day. Compounded, 1.5% a day is roughly 36% of a position in a month. It does not meter losses on Hyperliquid at all: a hostile keeper can bridge margin to the position's operator and lose it on the venue without touching the budget, up to the product's hedge cap. The real bound is detection followed by the treasury Safe revoking the keeper role. There is no break-glass unwind and no role that can reach a deployed range. Detection latency is the binding constraint on loss.

Tuo monitors the on-chain loss counter, changes to the operator allowlist and bridge discrepancies as mandatory alerts, and the keeper role is rotatable by the 2-of-3 Safe in one transaction.

The operator keys are part of the custody perimeter

Each position's hedge margin is at an address whose key is in Tuo's HSM. Losing that key strands whatever margin is on Hyperliquid at that moment. An operator key that has held margin is never deleted, and a position's binding to its operator is permanent, so operator keys cannot be rotated under a live position. The cloud account holding those keys is therefore part of what a customer trusts. See Counterparty and venue risk.

One backend, one engine

Tuo runs one backend service and one engine service. If either is down:

• no new keeper actions are taken and positions hold their current shape, hedged or not,
• the dashboard NAV stops updating (it is computed every five minutes by the backend),
• withdrawals that need the hedge closed wait until the keeper is back,
• your emergency exit does not depend on either. It is an on-chain call from your wallet, 24 hours after a withdrawal request, recovering everything on-chain in kind.

The engine going down is designed to mean "hold", not "act on stale data". A signal the engine could not fully determine is quarantined and never executed automatically.

The engine is frozen and proprietary

The strategy is a fixed, versioned engine that Tuo does not modify. Its behaviour is pinned by checksums and regression tests. That protects against silent strategy drift, and it means the strategy cannot adapt to a market regime it was not backtested on without a deliberate new version.

Data lag and withheld figures

The backend reads the chain at finality, which on Arbitrum trails the head by ten to twenty minutes, so recent events show up with that delay. The dashboard valuation deliberately publishes nothing rather than a partial figure when a leg cannot be priced, so you may see a gap in the chart rather than a wrong number.

Key-person and team risk

Tuo is a small team. Treasury actions need two of three hardware-wallet signers. Loss of the team, or of two signers, would leave the vault running with no one to rotate the keeper or sweep fees, but would not lock your funds: withdrawals and emergency exits need no Tuo signature.

See Roles and admin controls and Security overview.