Overview

Background

System Components (e.g., smartcontracts) are designed with Functions that can be called by permissioned Roles. Roles are mapped to Signers within the smartcontract code or via permissioning systems such as OZ AccessControl or Solmates.

Process

1. Assess each function's criticality

2. Assess performance requirements e.g. how often each function will be called, and required reaction time for signers.

3. Map function to roles; and map roles to signer addresses.

Note: For mETH Protocol, all Critical functions are only mapped to Security Multisigs.

Function Criticality

Rating	Definition
Critical	Can modify other critical role permissions (super admin). Can move principal assets to custom destination addresses either directly via function call, or indirectly via first modifying routes. Can cause the protocol to be drained via setting of risk parameters (e.g. exchange rates, fees, sanity bounds). Can modify the core protocol logic (i.e. via upgrades)
High	Can move protocol fees or reward assets (but not principal assets). Can collude with multiple other permissioned roles to indirectly drain assets via adjustment of risk parameters or other economic exploits. Note that this will likely require the collusion of all Pausers.
Medium	Cannot directly or indirectly access a material amount of assets. Can cause service disruptions via malicious actions - e.g. pausing components of the protocol.
Low	Can cause service disruptions only via non-activity.

Signer Types

Type	Comments
Security Multisig	Reaction Time: 2 days+ Policy: typically requires at least 6 signers across multiple organizations (e.g. core team, and tech partners) and functions (e.g. engineering, business, finance) Key Management: SAFE Multisig
Engineering Multisig	Reaction Time: within 6 hours Policy: typically requires at least 3 signers within the same engineering team.
EOA	Reaction Time: within 6 hours Key Management: hardware wallet
Service (Node)	Reaction Time: real time Policy: can be flexibly setup as a single signer, with quorum or threshold rules, 1-of-M, or proposer-approver. Key Management: typically real time nodes which need to have their private key online for the required system performance (i.e. hot wallet). The private key is protected by industry standard setups such as cloudHSM and secure enclaves.