Guarded launch
The limits Tuo ships with on Arbitrum One, why they exist, and what has to happen before they are lifted.
Tuo's first mainnet deployment is deliberately small. The limits below are the shape of the launch, not a temporary inconvenience, and they are set on-chain where the vault can enforce them.
The limits
| Limit | Value | Enforced by |
|---|---|---|
| Network | Arbitrum One only | Deployment |
| Products | Basis Plus Core, Delta Hedge Standalone | Product registry, seeded at deployment |
| Pools | WETH/USDC 0.05%, WBTC/USDC 0.05% | Pool allowlist, frozen at deployment |
| Minimum deposit | 2,500 USDC per deposit or top-up | MIN_DEPOSIT_USDC |
| Maximum per position | 25,000 USDC of basis | perNftCapUsdc, treasury-settable |
| Hedge exposure | At most 50% of basis (BP Core) or 90% (DH Standalone) may sit on Hyperliquid | Product policy |
| Deposits | Open to any wallet | No allowlist |
What the cap does and does not bound
The per-position cap bounds one position's basis and nothing else. There is no aggregate cap and no limit on how many positions a wallet may open, so total exposure is not bounded on-chain. Tuo accepted this deliberately: a permissionless deposit surface is the production shape, and the depositor allowlist it replaced was a treasury-held lever that did not scale.
Two consequences are worth stating plainly:
- The keeper's 150 bps per day loss budget is per position, so it aggregates to 150 bps of total value locked per day across all positions.
- The only on-chain brake on inflows is
pauseDeposits, which is reactive. Monitoring and the pauser's response time are part of the control.
The cap is a per-position ceiling during the guarded launch. It is not a statement about how much the protocol can safely hold in total.
Gates before the mainnet deployment
| Gate | Status |
|---|---|
| Internal audit-readiness review | Complete (2026-09-08) |
| Independent external review, every critical and high closed | Pending |
| Per-position cap set on-chain | Built, set at deployment |
| Paper trading with Tuo's own capital | Planned before public deposits |
| Verified source on Arbiscan for all three contracts | At deployment |
What lifts the cap
Raising the per-position cap requires two independent reviews and a live bug bounty. The
treasury Safe is the only holder that can call setPerNftCap, and the cap has no hard ceiling
above it on-chain, so the discipline is in the process, not the contract. Any change will be
announced on Changelog.
What cannot change without a redeploy
Three allowlists are fixed in the constructor and have no setter: the pools, the valuation pools, and the deposit tokens. Correcting any of them means deploying a new vault and migrating every position. This is the price of an immutable system and is described on Smart contract and oracle risk.