CoreVault Lifecycle
A CoreVault instance progresses through a series of well-defined states, from initial deployment through production operation and eventual immutability. Each transition is governed by on-chain controls and cannot be bypassed.
Deployment
The CoreVault is deployed via the VaultFactory, which produces a fully initialized vault instance with its module wiring and initial configuration in a single atomic transaction. This eliminates the risk of partially configured vaults reaching a user-facing state.
Configuration
After deployment, the vault is configured with:
- Strategies: which lending adapters are registered and their initial allocation targets
- Parameters: buffer targets, fee rates, batch limits, and other operational settings
- Roles: assignment of governance, guardian, keeper, and operator roles with their associated timelock and multisig requirements
All configuration changes during this phase are subject to the same access control and timelock rules that apply in production.
Shadow Testing
Before accepting real deposits, the CoreVault enters a shadow testing phase. During shadow testing:
- The full protocol stack runs on-chain (CoreVault, all modules, all strategies)
- Operations execute against live DeFi protocols with test or limited capital
- Strategy behavior, fee calculations, rebalancing logic, and emergency procedures are validated in real conditions
- No external depositor funds are at risk
Shadow testing provides the confidence that the system behaves correctly under real market conditions before production launch. Current deployments begin in this phase before transitioning to production.
Production
Once shadow testing is complete, the vault transitions to production:
- Deposits are open to users
- Strategies actively deploy capital and generate yield
- All governance, monitoring, and operational procedures are live
- The StrategyHealthRegistry and BatchGuardrails enforce safety constraints continuously
Sealed State
After the protocol has stabilized in production, the core contracts can be sealed via the SystemSealer module. Sealing is a one-way operation that makes the CoreVault's critical logic immutable:
- No further upgrades to the core vault logic
- No changes to fundamental accounting rules
- Remaining privileged functions (emergency pause, strategy management) continue to operate under their existing timelock and guardian controls
Sealing is irreversible. Once sealed, the core cannot be modified. Only explicitly documented emergency controls remain active, each protected by timelock and guardian rules.
Sealing is a security milestone. It signals to depositors and integrators that the foundational protocol behavior is fixed and will not change.
Emergency States
At any point during production (whether sealed or not), the protocol supports three emergency responses:
| Action | Effect | Scope |
|---|---|---|
| Pause | Halts deposits and/or withdrawals on the vault | CoreVault-wide |
| Degrade | Stops new capital from flowing to a specific strategy | Per-strategy |
| Recall | Withdraws all capital from a specific strategy back to the vault | Per-strategy |
Emergency actions are governed by the guardian role and can be executed without timelock delay when immediate response is required. All emergency actions are logged on-chain and visible to depositors in real time.
Document version: 1.1 Last updated: 2026-03-29