Smart contract and oracle risk

Immutable contracts

The Tuo contracts are not upgradeable. There are no proxies and no admin function that can change the fee, the pricing model or the custody rules. This removes the risk of a malicious or mistaken upgrade, and it means a bug cannot be patched in place.

Three allowlists are fixed when the vault is deployed and have no setter: the Uniswap pools, the valuation pools, and the deposit tokens. If any of them is wrong, or a pool needs to be added or removed, the whole system is redeployed and every position migrates. A bug in the contracts would be handled the same way: pause deposits, ask owners to withdraw, redeploy.

Not yet externally audited

As of publication the contracts have passed an internal audit-readiness review (no critical or high findings, static analysis clean, 311 tests including a hostile-keeper invariant suite) and are awaiting an independent external review. The external review is a launch gate: mainnet deployment is blocked until every critical and high finding is closed. Until that review is public, treat the contracts as unaudited. See Audits.

Pricing from pool TWAPs only

The vault uses no external price oracle. Its only price source is each allowlisted pool's own 30-minute time-weighted average tick, read from the Uniswap pool. Settlement NAV, the exit swap floor and the keeper's slippage floors all come from that figure.

What protects it:

• a 30-minute window, so a manipulation must be sustained rather than a single block,
• a minimum of 2,000 oracle observation slots per pool, checked at deployment,
• a 200-tick (about 2%) gate between spot and TWAP on every keeper price path, so keeper actions revert while the pool is displaced,
• deep pools: WETH/USDC and WBTC/USDC at the 0.05% tier on Arbitrum.

What does not protect it:

• Nothing on-chain bounds the depth of those pools. The cost of moving a 30-minute mean tick scales with pool liquidity, and the payoff scales with vault exposure, which has no global cap. Tuo has asked its reviewers to price this attack explicitly.
• The emergency exit is deliberately ungated. emergencyWithdraw unwinds ranges with a zero value floor and no TWAP check, so that the exit works under any market condition. Its fee is priced off the same TWAP. It is exposed to MEV and to a displaced pool by construction; the protected path is requestWithdraw then withdraw.

The keeper's attestation

The vault takes one thing from the keeper on faith: the flag that says a hedge's margin return is final. That flag can only clear the vault's record of outstanding margin to zero, only while a withdrawal request is armed, and cannot move funds. A hostile keeper could use it to write off margin the vault then stops tracking, leaving that margin at the operator address with no on-chain claim. This is a disclosed residual risk, bounded by the hedge cap and the operator binding.

Read-only and classic reentrancy

Every state-changing path is guarded, and the valuation views carry a read-only reentrancy guard so an aggregator callback cannot read a mid-swap NAV. This is standard, and it has been tested, but it is the class of bug audits most often find in vaults that hold LP positions.

Dependencies

The vault relies on Uniswap V3's position manager, OpenZeppelin 5.x, the 0x and 1inch routers, and Circle's CCTP contracts. A vulnerability in any of them is a vulnerability in Tuo. None of them can be swapped out without a redeploy.

See Architecture for the contract layout and invariants, and Roles and admin controls for what each role can do.