Permissions Model

The SuperVaults system separates protocol governance, vault accounting, and day-to-day operations. The safest mental model is:

Primary manager is the highest-authority vault operator within protocol, timelock, Merkle, fee, PPS, and accounting constraints.
Secondary managers execute delegated operational actions within the same onchain constraints.
View-only users observe the vault.
Registry maintainers maintain global metadata.
Session keys / keepers execute narrowly-authorized automation.

Role Tiers

Role	Onchain?	Scope	Typical Use
Primary Manager	Yes	Highest-authority vault operations	Multisig / hardware-backed operator
Secondary Manager	Yes	Delegated operational execution	PM, operations, risk
View Only	No	Read access	Analysts, auditors, monitors
Registry Maintainer	No	Global registry CRUD	Internal registry operations
Session Key / Keeper	Yes, delegated	Specific executable actions	Strategy and OMS automation

Primary Manager

The primary manager is set at vault creation and is the highest-authority vault operator. This role does not take custody of depositor assets: assets can be idle in the vault or deployed into external positions, and manager actions are constrained by protocol logic, active Merkle roots, PPS/accounting checks, fee limits, and timelocks for sensitive changes. Primary Manager replacement uses SUPER_GOVERNOR or a Secondary-initiated timelocked recovery proposal, not an ordinary user-management edit. Primary manager responsibilities:

Vault settings and sensitive configuration.
Secondary-manager assignment.
Session-key grant and revoke flows.
Upkeep funding and withdrawal control.
Pause, unpause, and emergency operations.
Merkle root proposals, onchain synchronization, and separate proof-artifact publication.

Treat the primary manager as production infrastructure. Use a multisig or hardware-backed wallet. If the primary manager key is compromised, the attacker may be able to exercise the role’s authorized operating powers, subject to protocol checks, timelocks, Merkle allowlists, and accounting constraints.

Secondary Managers

Secondary managers are onchain delegates for operational work. They can execute only the actions authorized for their role and, for hook execution, only pre-authorized hook/parameter combinations proven against the active Merkle roots. They can typically:

Manage strategies.
Configure yield sources.
Work with merkle tree configuration.
Pause/unpause operational services.
Add/remove view-only collaborators and update display names.

They cannot unilaterally bypass primary-only settings, timelocks, Merkle validation, PPS checks, fee limits, or vault accounting.

What Managers Cannot Do

Manager roles are operational roles, not custody of depositor wallets or unrestricted control over vault assets. Managers cannot:

Withdraw depositor assets to arbitrary wallets outside vault redemption, strategy, or emergency flows enforced by the contracts.
Execute arbitrary calldata against yield sources; hook execution must match pre-authorized Merkle leaves and protocol validation.
Bypass ERC-7540 redemption accounting, PPS-based calculations, slippage expectations, or share/accounting updates when fulfilling redemptions.
Instantly apply sensitive changes that are timelocked and visible onchain, such as fee updates, certain PPS parameter changes, upkeep withdrawals, Secondary-initiated Primary Manager recovery, and hook-root updates.
Override global protocol constraints such as banned leaves, pause state, validator-secured PPS requirements, or governance-maintained limits.

View-Only Users

View-only access is offchain. It grants dashboard visibility without transaction authority. Use it for:

Risk monitors.
Analysts.
Auditors.
Partners who need vault state without write access.

Registry Maintainers

Registry maintainers manage global metadata shared across vaults, including:

Yield source registry entries.
Oracle registry entries.
Hook registry entries.
Token asset metadata.

This role is not vault-scoped and should be tightly controlled.

Session Keys and Keepers

Session keys are delegated execution keys used by automation. A session key does not imply broad manager authority; it authorizes a specific automation path. Keepers and OMS execution still depend on:

Effective activation through upkeep funding or an applicable exemption.
Valid session key readiness.
Active merkle root and proofs.
Non-paused vault / services.
Strategy state and emergency locks.

If any of those gates fail, automation should stop even when a session key exists.

Permission Matrix

Action	Primary	Secondary	View Only	Registry Maintainer	Session Key / Keeper
View dashboard	✅	✅	✅	—	—
Create vault	✅	—	—	✅	—
Fund upkeep	✅	✅	❌	—	—
Withdraw upkeep	✅	Usually ❌	❌	—	—
Configure strategies	✅	✅	❌	—	—
Reorder strategies	✅	✅	❌	—	—
Manage yield sources	✅	✅	❌	—	—
Configure hooks / merkle roots	✅	✅	❌	—	—
Propose strategy hook root	✅	❌	❌	—	—
Grant / revoke session key	✅	Usually ❌	❌	—	—
Pause vault	✅	✅	❌	—	—
Arm emergency exit	✅	✅	❌	—	—
Add/remove secondary managers	✅	❌	❌	—	—
Add/remove view-only users or update display names	✅	✅	❌	—	—
Registry CRUD	—	—	—	✅	—
Execute authorized hooks	—	—	—	—	✅

Matured hook-root proposals can be executed onchain by anyone after the configured timelock; publishing the downloadable proof artifact is a separate operation. Erebor permits either manager to update display names; the UI restricts Primary and Secondary Manager name edits to the Primary Manager.

API Patterns

# List vault users
GET /api/v1/users?vault_address={address}&chain_id={chainId}

# Prepare add secondary manager transaction
POST /api/v1/users/secondary-manager/prepare

# Prepare remove secondary manager transaction
POST /api/v1/users/secondary-manager/remove/prepare

# Add view-only user offchain
POST /api/v1/users/view-only

# Remove view-only user offchain
DELETE /api/v1/users/view-only/{wallet}

A 403 Forbidden means the connected wallet lacks the required role for that operation.

Getting Started

Vault Setup

Vault Operations

Access & Settings

Distribution

Safety & Incident Response

Automation

API Reference

Role Tiers

Primary Manager

Secondary Managers

What Managers Cannot Do

View-Only Users

Registry Maintainers

Session Keys and Keepers

Permission Matrix

API Patterns

​Role Tiers

​Primary Manager

​Secondary Managers

​What Managers Cannot Do

​View-Only Users

​Registry Maintainers

​Session Keys and Keepers

​Permission Matrix

​API Patterns

Role Tiers

Primary Manager

Secondary Managers

What Managers Cannot Do

View-Only Users

Registry Maintainers

Session Keys and Keepers

Permission Matrix

API Patterns