Access Control
Multyr contracts are deployed on Arbitrum One. The system is currently in validation phase. Deposits are not open to the public. Behavior described on this page reflects the protocol's designed behavior; some mechanisms are active in shadow testing, others become active at public launch. See the Status page for details.
Multyr implements a multi-layered access control system designed to enforce strict execution boundaries across all protocol components.
Role-Based Access Control (RBAC)
The system uses a 5-tier role model enforced at the CoreVault level:
| Role | Description |
|---|---|
| PUBLIC | Accessible by any user |
| OWNER | Full administrative control |
| GUARDIAN | Emergency controls (pause, protection) |
| OWNER_OR_GUARDIAN | Shared critical permissions |
| MODULE | Internal execution only |
All function calls routed through the CoreVault are validated against these roles before execution.
Multisig Role Assignments
| Role | Type | Threshold | Address |
|---|---|---|---|
| SAFE_GOV (OWNER) | Gnosis Safe | 3-of-5 | 0x70ef...a326 |
| SAFE_GUARDIAN | Gnosis Safe | 1-of-1 | 0x7407...d677 |
| SAFE_VETO | Gnosis Safe | 1-of-1 | 0xF0c1...f1D7 |
| ROOT_TIMELOCK | Timelock controller | 48h delay | 0x295C...2798 |
Capability matrix
SAFE_GOV (3-of-5)
- Propose parameter changes (subject to ROOT_TIMELOCK 48h)
- Add/remove Strategy Vaults (via governance)
- Modify fee parameters (via governance)
- Cannot: bypass timelock, pause without going through Guardian, move user funds
SAFE_GUARDIAN (1-of-1)
- Pause deposits and withdrawals
- Mark strategies DEGRADED or BROKEN
- Cannot: resume normal operation (requires governance), move funds, change parameters
SAFE_VETO (1-of-1)
- Cancel any pending governance transaction during timelock window
- Cannot: propose changes, execute changes, move funds
Signer identities remain undisclosed during shadow testing phase. All multisig configurations are verifiable on-chain via Safe UI or Arbiscan.
Selector-Level Enforcement
Each function selector is mapped to a required role.
This mapping is:
- defined at compile-time
- immutable after initialization
- validated during module registration
Invalid assignments revert.
Module Authorization
Only explicitly authorized modules can execute privileged logic.
Mechanism:
isAuthorizedModule[module]mapping- enforced before any sensitive operation (mint, burn, transfer)
- checked via internal guards
This prevents unauthorized contract execution.
Two-Step Ownership Transfer
Ownership changes follow a secure two-step process:
beginOwnerTransfer(newOwner)acceptOwnerTransfer()
This prevents:
- accidental ownership loss
- misconfiguration during transitions
Delegatecall Protection
Modules execute via delegatecall within CoreVault storage.
Protections include:
- role validation before dispatch
- selector registry enforcement
- restricted module access
Only approved modules can interact with core logic.
Guardian Role
The Guardian provides an independent safety layer:
- can trigger emergency pause
- cannot perform administrative changes
- operates independently from the owner
This separation reduces governance risk.
Veto & Governance Controls
Critical parameter changes may be:
- delayed (timelock)
- revoked before execution
- vetoed by designated roles
This ensures:
- no instant governance attacks
- time for review and intervention
Security Properties
The access control system guarantees:
- no unauthorized execution
- no role escalation
- deterministic permission enforcement
Summary
Multyr enforces strict access control through:
- role-based execution
- immutable selector mapping
- module authorization
- multi-layer governance protections
This ensures that all critical operations are tightly controlled and verifiable.