Planning & Classification
Authored by:
Before setting up a new multisig, take time to properly assess its role and requirements. This planning phase will guide all subsequent configuration decisions and help ensure appropriate security measures.
Before You Start
Define Purpose and Scope
Document the multisig's intended use:
- Primary function - What will this multisig do?
- Asset types and amounts - What will it control?
- Operational frequency - How often will it be used?
- Decision timeline - How quickly must it respond?
- Integration points - What systems will it interact with?
Maintain an Access Control Inventory
Before classifying multisigs, protocols should first build a comprehensive inventory of all privileged roles in their system. You cannot classify risk or design multisig separation if you do not know what powers exist and where they live.
For each privileged role, document:
- Role name: The on-chain role or permission (e.g.,
UPGRADER_ROLE,owner,pauser,fee-setter) - Held by: Which address or multisig currently holds this role
- Contract: Which contract(s) this role controls
- Capabilities: What this role can do (specific functions and their effects)
- Constraints: What limits exist on this role (timelocks, parameter bounds, governance controls)
- Blast radius: The maximum potential impact if this role is compromised
This inventory is the foundation for all multisig planning — it directly informs how many multisigs you need, how to separate responsibilities, and what threshold and timelock configurations to use. Maintain it as a living document, updated whenever new contracts are deployed or roles change.
See the Registration Template for how to document this per multisig.
Assess Constraints and Recovery
Consider limiting factors that affect risk:
- Smart contract constraints - What technical limits reduce risk?
- Governance recovery - Can governance override or recover funds?
- Operational limits - Are there built-in spending or parameter limits?
- Backup mechanisms - What happens if this multisig fails?
Identify Stakeholders
Determine who should be involved:
- Required expertise - What knowledge is needed for decisions?
- Geographic distribution - Do you need global coverage?
- External signers - Should independent parties be involved?
- Backup signers - Who can step in if primary signers are unavailable?
Classification Process
Use this dual classification system to determine appropriate security measures. These classifications are guidance to help you think through risk levels - they inform threshold selection, signer requirements, and operational procedures in later sections.
Step 1: Impact Assessment
What happens if this multisig is compromised or fails?
Financial Exposure:
- Direct funds controlled by the multisig
- Indirect exposure through protocol impacts
- Maximum potential loss in worst-case scenario
Protocol Impact:
- Can the protocol function without this multisig?
- How difficult would recovery be?
- Are there alternative execution paths?
Reputational Risk:
- How visible is this multisig to the community?
- What would compromise mean for the protocol's reputation?
- Are there regulatory or compliance considerations?
Impact Classification
| Level | Financial Exposure | Protocol Impact | Reputational Risk |
|---|---|---|---|
| Low | <$100k direct exposure | Minimal disruption, alternative paths exist | Limited scope impact |
| Medium | $100k - $1M exposure | Significant operational delays, workarounds available | Moderate reputational concern |
| High | $1M - $10M exposure | Major protocol disruption, difficult recovery | Serious reputational damage |
| Critical | >$10M exposure | Protocol-wide failure, catastrophic impact | Severe reputational damage |
Step 2: Operational Assessment
How quickly and under what conditions must this multisig respond?
Response Time Requirements:
- How quickly must decisions be made?
- What are the consequences of delays?
- Are there market or competitive timing factors?
Decision Context:
- Are operations routine and predictable?
- Do market conditions affect timing?
- Is this primarily for emergency response?
Coordination Complexity:
- How many parties must coordinate?
- Are signers distributed globally?
- What communication is required?
Operational Classification
| Type | Response Time | Decision Context | Verification Level |
|---|---|---|---|
| Routine | 24-48 hours | Standard procedures, predictable operations | Full verification protocols |
| Time-Sensitive | 2-12 hours | Market conditions, protocol needs | Streamlined but thorough |
| Emergency | <2 hours | Crisis response, preventing immediate damage | Minimal delays, risk-appropriate |
Step 3: Classification Matrix
Combine your impact and operational assessments. Below are some example configurations.
| Use Case | Impact | Operational | Standard Threshold |
|---|---|---|---|
| Emergency Freeze | Critical | Emergency | 2/4 |
| Protocol Parameters | High | Routine | 4/7 (higher for upgrades, consider 7/9+) |
| Capital Allocation | High | Time-Sensitive | 3/5 |
| Treasury - Large | High | Routine | 4/7 |
| Treasury - Small | Medium | Routine | 3/5 |
| Constrained DeFi | Medium | Time-Sensitive | 2/3 |
Step 4: Document Your Decision
Record your classification decision in the Registration template.
Important Notes
⚠️ When between classifications: Always err toward higher security requirements. Classifications can be relaxed with proper justification, but security incidents cannot be undone.
This classification will guide your threshold selection (Thresholds & Configuration), signer requirements, and operational procedures throughout the rest of the documentation.
Next Steps
After completing classification, proceed to:
- Setup & Configuration - Deploy your multisig
- Registration & Documentation - Document your setup