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 own sensitive vault settings. Secondary managers can operate the vault but do not control primary-only settings such as manager assignment and some security parameters.
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 adds a delay between redemption request and fulfillment eligibility.
Use it for:
- Liquidity sourcing before fulfillment.
- Fraud and risk review windows.
- Regulatory or operational policy requirements.
Relevant APIs:
| Endpoint | Method | Description |
|---|
/api/v1/redeem-timelocks | GET | List configured timelocks |
/api/v1/redeem-timelocks/bulk | GET | Bulk timelock lookup |
/api/v1/vaults/{chain_id}/{vault_address}/redeem-timelock | GET | Read one vault’s timelock |
/api/v1/settings/redeem-timelock | POST | Prepare timelock update transaction |
Changing a redeem timelock affects future redemption requests. Existing requests are not retroactively changed.
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.
A vault below its required upkeep threshold is not considered active. Once the required balance is in place, Erebor marks it active and discoverable. Erebor returns this as upkeep_info plus activation; upkeep withdrawal lifecycle is returned separately as withdrawal_status.
Deposit Upkeep
Managers deposit upkeep through the settings flow:
POST /api/v1/settings/upkeep/deposit
Withdraw Upkeep
Withdrawals use a propose / execute pattern:
POST /api/v1/settings/upkeep/withdraw/propose
POST /api/v1/settings/upkeep/withdraw/execute
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:
| Endpoint | Method | Description |
|---|
/api/v1/session-keys | GET | List session keys visible to the manager |
/api/v1/vaults/{chain_id}/{vault_address}/session-key | GET | Read a vault session key |
/api/v1/vaults/session-key/prepare | POST | Prepare grant transaction |
/api/v1/vaults/session-key/revoke/prepare | POST | Prepare revoke transaction |
Notification Channels
Notification channels attach Slack, webhook, or websocket destinations to a vault.
| Endpoint | Method | Description |
|---|
/api/v1/notification-channels | GET/POST | List or create manager-owned channels |
/api/v1/vaults/{chain_id}/{vault_address}/notification-channels | GET | List vault channels |
/api/v1/vaults/{chain_id}/{vault_address}/notification-channels/{channel_id} | POST | Attach channel |
/api/v1/vaults/{chain_id}/{vault_address}/notification-channels/{channel_id} | DELETE | Detach channel |
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:
| Field | Description |
|---|
provider | Channel provider or transport. |
name | Operator-facing channel name. |
config | Provider-specific destination config. Sensitive values should be redacted in UI. |
created_by | Creator metadata. |
created_at / updated_at | Audit timestamps. |
- 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:
| Symptom | Check |
|---|
| Channel exists but receives nothing | Confirm it is bound to the vault. |
| Sensitive destination appears in UI | Redact config display and rotate the destination if leaked. |
| Alerts are noisy | Tune event thresholds before muting the channel. |
| Incident alert is missing | Check audit logs and notification-channel binding first. |
API Reference
| Endpoint | Method | Description |
|---|
/api/v1/vaults/{chain_id}/{vault_address} | GET | Full vault detail including fee, PPS, and upkeep data |
/api/v1/settings/fee-config | GET | Read current fee config |
/api/v1/settings/fee-config/propose | POST | Prepare fee-config proposal transaction |
/api/v1/settings/fee-config/execute | POST | Prepare fee-config execution transaction |
/api/v1/settings/deviation-threshold | GET | Read PPS deviation threshold |
/api/v1/settings/deviation-threshold/update | POST | Prepare deviation-threshold update transaction |
/api/v1/settings/pps-expiration | GET | Read PPS expiration / staleness setting |
/api/v1/settings/pps-expiration/propose | POST | Prepare PPS-expiration proposal transaction |
/api/v1/settings/pps-expiration/execute | POST | Prepare PPS-expiration execution transaction |
/api/v1/settings/pps-expiration/cancel | POST | Prepare PPS-expiration cancellation transaction |
/api/v1/settings/redeem-timelock | GET/PUT/DELETE | Read, update, or remove redeem timelock |
/api/v1/settings/banned-hook-leaves | GET | Read banned hook leaves |
/api/v1/settings/banned-hook-leaves/update | POST | Prepare banned-hook-leaf update transaction |
/api/v1/settings/min-update-interval | GET | Read minimum PPS update interval |
/api/v1/settings/min-update-interval/propose | POST | Prepare min-update-interval proposal transaction |
/api/v1/settings/min-update-interval/execute | POST | Prepare min-update-interval execution transaction |
/api/v1/settings/min-update-interval/cancel | POST | Prepare min-update-interval cancellation transaction |
/api/v1/settings/upkeep | GET/POST | Read or prepare upkeep settings update |
/api/v1/settings/upkeep/deposit | POST | Prepare upkeep deposit |
/api/v1/settings/upkeep/withdraw/propose | POST | Prepare upkeep withdrawal proposal |
/api/v1/settings/upkeep/withdraw/execute | POST | Prepare upkeep withdrawal execution |
