SuperVaults separates protocol ownership from day-to-day operations. The safest mental model is:
- Primary manager owns the vault.
- Secondary managers operate the vault.
- 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 | Full vault control | Multisig / hardware-backed owner |
| Secondary Manager | Yes | Operational controls | 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.
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 proposal / publish workflows.
Treat the primary manager as production infrastructure. Use a multisig or hardware-backed wallet. If the primary manager key is compromised, the attacker can control the vault.
Secondary Managers
Secondary managers are onchain delegates for operational work.
They can typically:
- Manage strategies.
- Configure yield sources.
- Work with merkle tree configuration.
- Pause/unpause operational services.
- Add view-only collaborators.
They cannot replace the primary manager or take over primary-only settings.
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:
- Active upkeep funding.
- 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 or publish merkle root | ✅ | Permissioned | ❌ | — | — |
| Grant / revoke session key | ✅ | Usually ❌ | ❌ | — | — |
| Pause vault | ✅ | ✅ | ❌ | — | — |
| Arm emergency exit | ✅ | ✅ | ❌ | — | — |
| Add/remove secondary managers | ✅ | ❌ | ❌ | — | — |
| Add/remove view-only users | ✅ | ✅ | ❌ | — | — |
| Registry CRUD | — | — | — | ✅ | — |
| Execute authorized hooks | — | — | — | — | ✅ |
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}
403 Forbidden means the connected wallet lacks the required role for that operation. 
