Skip to main content
SuperformOS Vault Settings — upkeep activation and notification-channel controls Vault Settings is the configuration hub for vault-level controls. Most settings use the same pattern: Erebor prepares calldata, the manager wallet signs, and the protocol contract applies the change onchain. Public SuperVault detail pages expose Vault Settings as read-only context. Manager-only controls, including upkeep deposit/withdrawal and settings transactions, remain in the authenticated Operate flow.
Prepare endpoints return transaction data. They do not mutate protocol state by themselves. The connected wallet must sign and submit the transaction.

​
Access Model

Primary Managers control sensitive vault settings and Secondary Manager assignment. Minimum PPS update interval proposals and cancellations are Primary-only; either manager can prepare execution through Erebor, and anyone can execute the matured proposal onchain. See Permissions Model for the full matrix.

​
Fees

Configure the vault’s performance fee, management fee, and fee recipient. Fee changes protect depositors through the protocol’s proposal/timelock rules. The dashboard displays current values and prepares the required transaction when a primary manager proposes a change.

​
PPS Parameters

Price-per-share controls define how often PPS can update and when stale data blocks operations. Common fields:
  • Deviation threshold — maximum allowed difference between calculated and current PPS.
  • PPS expiration / staleness — when vault operations should stop waiting for a fresh PPS update.
  • Minimum update interval — minimum time between PPS updates.
These settings are read from vault detail data and changed through signed transactions.

​
Redeem Timelock

Redeem timelock is an offchain keeper timing setting, not an onchain transaction. The keeper applies the current vault delay to pending requests when checking fulfillment eligibility. Use it for:
  • Liquidity sourcing before fulfillment.
  • Fraud and risk review windows.
  • Regulatory or operational policy requirements.
Relevant APIs:
Changing the delay also changes eligibility for already-pending requests. Review pending requests before updating it, then read back the saved setting.

​
Banned Hook Leaves

A banned hook leaf is blocked even if it appears in an authorized merkle tree. Use this to quickly stop a specific hook + parameter combination while you prepare a cleaner merkle config update. Banning a leaf is narrow: it blocks the exact leaf, not the entire hook category.

​
Upkeep and Activation

Upkeep funds vault automation. It is also the practical activation gate for a new vault. The Upkeep panel shows:
  • Current upkeep balance.
  • Upkeep token.
  • Required balance and shortfall.
  • Activation status: active or insufficient_upkeep.
  • Whether the vault is active for keeper operations and discoverable in public listing surfaces.
  • Pending upkeep withdrawal proposal, if any.
Erebor marks a vault active and discoverable when its upkeep threshold is satisfied or an exemption applies. Read the returned threshold, shortfall, and activation rather than inferring activation from balance alone. Upkeep data is returned as upkeep_info; upkeep withdrawal lifecycle is returned separately as withdrawal_status.

​
Deposit Upkeep

Managers deposit upkeep through the settings flow:
The dashboard handles token allowance checks first, then prepares the deposit transaction for wallet signature.

​
Withdraw Upkeep

Withdrawals use a propose / execute pattern:
Use withdrawals carefully on live vaults. Pulling the balance below threshold can make the vault inactive or undiscoverable.

​
Session Keys

Session keys delegate limited execution authority for automation. They are used by the OMS / Strategy Engine path so strategies can publish and execute intents without asking the manager wallet for every tick. Erebor exposes vault-scoped session-key inventory and prepare endpoints: OMS also exposes strategy-automation session-key readiness and rotation endpoints. See OMS API.

​
Notification Channels

Notification channels attach Slack, webhook, or websocket destinations to a vault. Use notification channels for operational alerts, monitoring, and downstream automation.

​
Alert Delivery

Alerts connect vault events to notification destinations. Treat alert delivery as operational plumbing: create the channel first, bind it to the vault, then verify delivery with a low-risk event before relying on it for incidents. Notification channel records include: Recommended alert categories:
  • Upkeep shortfall or activation loss.
  • PPS staleness.
  • Failed keeper runs.
  • Session-key readiness changes.
  • Emergency pause / unpause.
  • Emergency liquidity exit arm / stop.
  • Merkle generation or publish failure.
  • Repeated OMS execution failure.
Troubleshooting:

​
API Reference