The Curator Role
A curator manages a SuperVault’s yield strategy: which protocols receive capital, in what order, under what conditions, and with what risk parameters. The curator does not hold depositor funds — the vault contract does.
What curators control: yield source selection, oracle assignment, allocation priority, reserve ratio, strategy rules, merkle authorization, fee configuration (at creation), redeem timelock, service controls, emergency pause, and access management.
What the protocol enforces: merkle-verified execution, timelocked root updates, fee bounds (SuperGovernor), PPS staleness enforcement, $UP upkeep requirements, high-water mark fee accrual, and protocol revenue share.
Trust model: Depositors trust the curator to select sound yield sources and maintain vault health. Depositors do NOT need to trust the curator for fund custody (held by contract), honest execution (merkle-verified), accurate PPS (oracle-enforced), or fee limits (SuperGovernor-enforced).
Curator Tiers
| Role | On-chain? | Capabilities |
|---|
| Primary Manager | Yes | Full vault control. Set at creation, immutable. |
| Secondary Manager | Yes | All operations except vault settings and user management. |
| View Only | No | Read-only dashboard access. |
The primary manager key is the root of trust for the vault. If compromised, an attacker could modify yield sources, update merkle authorization, and pause operations. Use hardware wallets and consider multi-sig for production vaults.
SuperVaults combine on-chain vault contracts with off-chain automation services. Understanding how these layers interact is essential for effective curator operations.
ERC-7540 Vault Standard
SuperVault contracts are live on-chain and fully non-custodial. The curator UI at curators.superform.xyz is a management layer — it never holds keys or assets. All vault interactions are direct on-chain transactions signed by your wallet.
- Request — Depositor submits a deposit or redemption request on-chain
- Fulfillment — Keeper workers process the request when conditions are met (liquidity available, timelock expired, strategy rules satisfied)
Vault shares are ERC-20 tokens representing a depositor’s pro-rata claim on vault assets. Price-per-share (PPS) tracks the value of each share in terms of the underlying asset.
Price-Per-Share (PPS)
PPS is the core accounting primitive. It determines:
- How many shares a depositor receives for a given deposit
- How many underlying assets a depositor receives for redeeming shares
- When performance fees accrue (PPS exceeds high-water mark)
- Whether the vault is operational (PPS must be updated within the staleness window)
| PPS Metric | Description |
|---|
| Current PPS | Last on-chain recorded value |
| Calculated PPS | Off-chain computed value (may differ during update intervals) |
| HWM PPS | All-time high-water mark. Performance fees accrue only above this level. |
| Staleness countdown | Time remaining before PPS expires. If PPS goes stale, vault operations are blocked until an update is pushed. The staleness window is configurable per vault and defaults to 24 hours. |
ECDSAPPSOracle.updatePPS(). A PPS update is accepted only after at least two-thirds of weighted validator stake has signed off. Misreporting is deterred through validator slashing and an insurance fund backstop.
The Hook System
Hooks are on-chain modules that keepers invoke to interact with external protocols. Each hook type corresponds to an operation:
| Hook Type | Operation |
|---|
DEPOSIT | Deploy vault assets into a yield source |
WITHDRAWAL | Unwind a position from a yield source |
REBALANCE | Move capital between yield sources |
inspectParams) that define what arguments each invocation requires: yield source addresses, token addresses, oracle addresses, or freeform values.
A keeper can only call a hook if the exact combination of hook address + parameters matches a leaf in the vault’s on-chain merkle tree.
Merkle Authorization
Merkle authorization is the access control layer for keeper operations. The flow:
Configure
Create a hook configuration specifying which hooks are authorized with which parameters. Each (hook, params) combination becomes one leaf.
Generate
Erebor computes a merkle tree from the active configuration. The tree root is a single 32-byte hash that encodes all authorized operations.
Propose
Submit the new root to the SuperVaultStrategy contract. A timelock period begins.
Execute
After the timelock expires, execute the root update on-chain. Keepers can now use proofs from the new tree.
Yield Sources and Oracles
A yield source is an external protocol contract where the vault deploys capital to generate returns. SuperVaults support two yield source types:
| Type | Description | Example |
|---|
erc4626 | Standard ERC-4626 vault | Morpho vaults, Aave wrappers |
pendle_pt | Pendle Principal Token | Fixed-rate yield via PT purchase |
| Oracle Type | Pricing Method |
|---|
erc4626 | Share price of the underlying ERC-4626 vault |
pendle_pt | Spot market price of the PT |
pendle_pt_amortized | Linear decay to par value as PT approaches maturity |
Keeper Workers
Seven Celery-based keeper workers run continuously against each vault’s configuration:
| Worker | Responsibility |
|---|
fulfill_deposits | Allocates free vault assets to yield sources based on the configured allocation strategy |
fulfill_redeems | Processes pending ERC-7540 redemption requests |
fulfill_claims | Claims accumulated reward tokens from external protocols |
fulfill_swaps | Swaps non-underlying tokens back to the vault’s base asset |
redemption_queue_engine | Monitors the subgraph for new redemption requests |
cleanup_processed_redeems | Reconciles pending redemptions with on-chain state |
tx_manager | Broadcasts transactions, monitors confirmations, handles reorgs |
- Global enable/disable per vault (stops all workers)
- Per-service pause/resume (targeted worker control)
- Schedule adjustment (change execution frequency)
The Strategy Engine
The Strategy Engine adds rule-based automation on top of the keeper system. Curators define strategies via the Strategy Canvas with:
- Indicators — named variables evaluated each tick (e.g.,
morpho_apy, free_assets)
- Rules — boolean logic trees (
EXPR, AND, OR, NOT, VOTE) that determine when to act
- Action config — what to do when rules trigger (deposit size, target hook, slippage limits)
- Conviction config — how many consecutive ticks must pass before dispatching an intent
Strategies evaluate on configurable tick intervals and dispatch DeFiX intents to the OMS when conditions are met.
DeFiX v0.1 Intent Protocol
DeFiX is the standardized intent interface between the Strategy Engine and the OMS (Order Management System). An intent represents a desired vault operation:
Strategy triggers → Intent submitted to OMS → OMS validates merkle proof → OMS executes on-chain
| Status | Description |
|---|
Processing | Queued or being executed |
Completed | Successfully executed on-chain |
Failed | Execution failed (error details attached) |
Cancelled | Cancelled before execution |
The Prepare Pattern
All on-chain operations in SuperVaults follow a consistent two-phase flow:
- Prepare — Call a
prepare-* endpoint on Erebor. It returns raw EVM calldata ({ to, data, value }).
- Sign — Pass the calldata to your wallet for signature and broadcast.
- Confirm (where applicable) — Notify Erebor of the transaction hash for indexing.
This pattern keeps private keys off the server. Erebor constructs the correct calldata; your wallet controls signing authority.
Used for: vault creation, yield source management, user management, merkle root proposals, emergency pause/unpause.
