SuperVaults
Introduction
SuperVaults are flexible and secure vault primitives built to scale by leveraging infrastructure provided in Superform core. On top of tablestakes features for vault products, including simplified access through a singular product, non-custodial management, and the composability and transparency brought by being onchain, SuperVaults enable:
Permissionless Vault Creation: Anyone can create a new vault with Hooks, charge fees, and have validator support by paying upkeep
Infinitely Flexible Execution: Validates and executes arbitrary Hooks created in Superform Core via Merkle proofs. These can be used to deposit, stake, bridge, loop, and arbitrary set of actions that have been validated in the root
Security through Dual Merkle Validation: The system uses two Merkle trees for hook validation. A global root is managed by governance for protocol-wide hook approval and a strategy root is managed by strategists for vault-specific operations
Fee Management: Can take both management and performance fees, configurable by the strategist, with timelocked updates
Automated Emergency Controls: Provides emergency withdrawal mechanisms with built-in pause functionality on circuit breakers
These are the explainer docs for SuperVaults. We recommend users interested in building on these to simply interact with the Superform SDK, detailed further in Manage a SuperVault.
How do SuperVaults work?
SuperVault (entrypoint) — ERC-7540 vault that implements synchronous deposits and asynchronous redemptions
SuperVaultStrategy (execution) — uses Hooks execute arbitrary strategies safely
SuperVaultEscrow (holding) — custodies shares during redemption requests
SuperVaultAggregator (control) — registry, factory, and PPS oracle for all SuperVaults
Operational Flow
Deposits
User Deposit: User calls
deposit()
with assetsImmediate Minting: Shares minted synchronously at current PPS
Asset Custody: Assets transferred to strategy for allocation
Hook Execution: Strategist executes hooks to deploy capital
PPS Updates: Validators provide updated PPS reflecting new positions
Redemptions
Redeem Request: User calls
requestRedeem()
with sharesShare Escrow: Shares transferred to escrow contract
Fulfillment: Strategist executes hooks to free up assets
PPS Validation: Slippage protection against recorded request PPS
Asset Claim: User calls
withdraw()
to receive assets
Strategy Management
Hook Approval: Strategist proposes new hook root
Timelock Period: 15-minute delay configurable by governance for strategy hooks
Execution: Hook root updated and new strategies enabled
Guardian Oversight: Guardians can veto malicious updates
PPS Updates
Off-Chain Calculation: Validators calculate PPS independently
Signature Generation: Validators sign PPS with private keys
Aggregation: Signatures collected and submitted to oracle
Validation: Oracle verifies signatures and quorum
Forwarding: Validated PPS forwarded to aggregator
Strategy Checks: Aggregator runs dispersion/deviation checks
Storage: PPS stored and made available for vault operations
Creating setting up, and managing a vault
Vaults can be created in SuperVaultAggregator by calling createVault
using the following parameters. The primary strategist has full control over strategy operations and multiple secondary strategists as backup accounts can propose primary strategist changes with 7-day timelock.
function createVault(VaultCreationParams calldata params) external
returns (address superVault, address strategy, address escrow)
struct VaultCreationParams {
address asset; // Address of the underlying asset
string name; // Name of the vault token
string symbol; // Symbol of the vault token
address mainStrategist; // Address of the vault mainStrategist
uint256 minUpdateInterval; // Minimum time interval between PPS updates
uint256 maxStaleness; // Maximum time allowed between PPS updates before staleness
FeeConfig feeConfig;
}
struct FeeConfig {
uint256 managementFeeBps; // Management fee in basis points
uint256 performanceFeeBps; // Performance fee in basis points
address recipient; // Fee recipient address
}
Once vaults are created, strategists automatically benefit from the list of hooks that are in the global hooks root. However, if more functionality is to be added, primary strategists can propose a new strategy hooks root.
function proposeStrategyHooksRoot(address strategy, bytes32 newRoot) external validStrategy(strategy)
Once vaults are have funds in them, strategists must deposit UP tokens to ensure that validators are compensated for the cost of updating onchain PPS for their vaults. This is also done in SuperVaultAggregator.
function depositUpkeep(address strategist, uint256 amount)
Once funds arrive into the vault via users requestDeposit
, strategists can execute any of the hooks in the root to fulfill a deposit.
function executeHooks(ExecuteArgs calldata args) external
struct ExecuteArgs {
address[] hooks;
bytes[] hookCalldata;
uint256[] expectedAssetsOrSharesOut;
bytes32[][] globalProofs;
bytes32[][] strategyProofs;
}
A similar flow presents itself on redemptions.
Validating PPS
Flexibilty and security is economically enforced by validators submitting PPS, supported by oracle infrastructure in Superform core. If interested in becoming a SuperVault validator, we recommend reading Become a Validator.
Validators currently use a ECDSAPPSOracle which validates price updates using cryptographic signatures from the decentralized validator network.
Message Construction:
keccak256(abi.encodePacked(strategy, pps, ppsStdev, validatorSet, totalValidators, timestamp))
Signature Recovery: Uses ECDSA to recover signer addresses
Validator Verification: Checks signers against registered validator set
Quorum Enforcement: Requires minimum number of signatures
Duplicate Prevention: Prevents the same validator from signing twice
Security
SuperVaults provide superior security through a combination of hook validation, emergency circuit breakers, and comprehensive access controls with timelocks.
Hook Validation System
The dual Merkle tree system provides layered security while retaining flexibility needed for competitive returns.
Global Hooks Root:
Governance Managed: Updated by SuperGovernor with timelock
Protocol-Wide: Applies to all strategies
Guardian Veto: Can be vetoed by guardians to prevent malicious updates
Strategy Hooks Root:
Strategist Managed: Updated by primary strategist
Vault-Specific: Applies only to individual strategies
Guardian Veto: Can also be vetoed by guardians
function _validateSingleHook(
address strategy,
bytes calldata hookArgs,
bytes32[] calldata globalProof,
bytes32[] calldata strategyProof,
bool globalVetoed,
bool strategyVetoed
) internal view returns (bool) {
// If both roots are vetoed, all hooks are invalid
if (globalVetoed && strategyVetoed) return false;
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(hookArgs))));
// Try global root first
if (!globalVetoed && _globalHooksRoot != bytes32(0)) {
if (MerkleProof.verify(globalProof, _globalHooksRoot, leaf)) return true;
}
// Try strategy root
if (!strategyVetoed && strategyRoot != bytes32(0)) {
if (MerkleProof.verify(strategyProof, strategyRoot, leaf)) return true;
}
return false;
}
Emergency Mechanisms
Strategy Pausing
SuperVaultAggregator implements sophisticated checks for PPS updates. Besides checks for actives oracles, quorum requirements, and other validations, strategies can be automatically paused when:
PPS dispersion exceeds threshold
PPS deviation is too large
Validator participation is insufficient
Updates are too stale
// C2.1 Dispersion Check: stddev/mean ratio
if (dispersion > dispersionThreshold) {
checksFailed = true;
emit StrategyCheckFailed(strategy, "HIGH_PPS_DISPERSION");
}
// C2.2 Deviation Check: absolute change from current PPS
if (relativeDeviation > deviationThreshold) {
checksFailed = true;
emit StrategyCheckFailed(strategy, "HIGH_PPS_DEVIATION");
}
// C2.3 M/N Check: validator participation rate
if (participationRate < mnThreshold) {
checksFailed = true;
emit StrategyCheckFailed(strategy, "INSUFFICIENT_VALIDATOR_PARTICIPATION");
Emergency Withdrawals
Proposal Phase: Strategist proposes emergency withdrawal capability
Timelock: 7-day delay before activation
Execution: Strategist can withdraw free assets to specified recipient
Guardian Veto Powers
Can veto global hooks root updates
Can veto strategy-specific hooks root updates
Provides rapid response to malicious activity
Access Controls
Role-based permissions allow for granular control of the strategy.
Primary Strategist
Full strategy control (whitelisting strategy-level hooks, fees, processing deposits and redemptions)
Secondary Strategists
Day to day manager, everything the primary strategist can do minus whitelisting hooks and fees
SuperGovernor
Protocol governance that has strategy-level overrides (can take over strategist role), updates allowable global hook root for all strategies
Guardians
Threat monitoring network, veto powers for whitelisted hooks for security
Validators
$UP stakers that can update price-per-share with circuit breaker protections and slashing
Timelock Protections
Strategist Changes: 7-day timelock for primary strategist updates
Hook Roots: 15-minute timelock for strategy hooks, 7-day for global
Fee Updates: 7-day timelock for fee configuration changes
Emergency Features: 7-day timelock for emergency withdrawal activation
Economics
All fees taken are configurable by the strategist with a split to Superform that can be turned on by governance.
Management
Configurable by the strategist, applied to the initial deposit amount
Performance
Configurable by the strategist, applied to profits above cost basis when users redeem
Upkeep
Strategists pay UP tokens for validators to update prices
Last updated