Trust & governance
Contract and operational trust, immutable code, and the limits of the timelock.
Experimental mainnet deployment
Entry is invite-gated. Deposits are real ETH at risk, and unrestricted launch should not be inferred from deployed contracts. Do not deposit more than you can afford to lose entirely.
What you are trusting
You rely on contract correctness, governance decisions, accurate NAV reporting, and available strategy and queue automation. The timelock provides advance visibility, not principal protection or a guaranteed opportunity to exit before an upgrade.
Role model
Governance configures and upgrades the management layer. SECURITY has designated emergency powers, and keeper executors coordinate strategy work and queue processing. The canonical Roles and permissions page defines each role, registered-contract checks, and their limits. Current assignments live in the dated role snapshot.
The 48-hour timelock
At the snapshot, ADMIN is held by the timelock and getMinDelay() is 48 hours.
A scheduled operation must mature and then be executed. "Ready" does not mean "Done";
a merged proposal or signed Safe transaction does not prove execution.
The Security Safe can cancel timelock operations under its CANCELLER permission. Immediate SECURITY paths do not wait for the ADMIN delay.
The review window is not an exit guarantee. An exit can be paused, depend on NAV availability, or need a queue that takes longer than the timelock delay. Cancellation returns EVE and pays no ETH.
SECURITY limits and accounting effects
SECURITY can remove a supported ERC-20 from NAV accounting without recovering that asset, and revoke a Whitelist signer while the gate is enabled. These powers can change reported backing or access. See Emergency authority for authorization, pause requirements, and limits. AMM claims and eligible cancellations remain available during pauses.
Immutable versus upgradeable
| Component | Code model |
|---|---|
| Registry, EVE, AMM, Whitelist, keeper executors | Static deployed code, with configurable permissions or settings |
| Each UniCL strategy | Immutable instance; replacement uses new deployment and registration |
| Controller, StrategyManager, ExitQueue, Oracle, Converter | ADMIN-authorized UUPS upgrades |
Immutable AMM code still depends on configurable peers and upgradeable NAV/queue contracts. Immutable strategy code still depends on feeds, routes, and external pools. Fixed bytecode does not make economic behavior independent of governance.
Operational trust
Strategy and queue automation depend on keeper availability, configured permissions, gas, and reliable valuation inputs. Off-chain callers and on-chain executors have distinct permissions; see Keepers and automation.
App operators must keep network and deployment configuration aligned with the contracts. Indexing operators maintain the Goldsky deployment and its configuration. Account history is eventually consistent, while balances and action eligibility are checked through RPC. The app assumes Ethereum mainnet and handles unsupported networks explicitly. See Data access and Failure and recovery scenarios.
Strategy migration
At the October 19 snapshot, Controller 1.1.0 was active after 018 executed, and 019 and 020 had executed: the four v2 strategies were registered and the v1 strategies drained and removed. See Strategy migration for the blocks and execution transactions.
For review coverage, see Security & audits.
Last updated on