📈 Permission Hierarchies: Viewer to Admin

Understand how role levels grant increasing capabilities

Design access control for DAO operations

Your Progress

0 / 5 completed

Introduction

Permission Hierarchies

Role Assignment

Security Models

Key Takeaways

📊 Permission Hierarchy Design

Not all permissions are equal. DAOs must stratify access by risk level: Critical (treasury, upgrades), High (role changes, emergency controls), Medium (parameters, moderation), and Low (voting, viewing). Each tier requires different safeguards—multi-sig for critical, time-locks for high-risk, single admin for medium, and open access for low. Hierarchy isn't just about roles; it's about matching controls to consequences.

🎮 Interactive: Permission Risk Explorer

Select a permission to understand its risk level, required safeguards, and real-world attack scenarios. See how DAOs layer security controls.

Treasury Transfer

critical Risk Level

Execute token transfers from DAO treasury to external addresses. Highest risk permission.

🛡️ Required Safeguards

Admin + 3/5 Multi-sig

Multiple signers + time delay required. Cannot be executed by single address.

⚠️ Attack Scenario

Attacker with admin key drains $10M treasury to external wallet. Multi-sig prevents this—needs 3/5 approvals.

🏛️ Real Example

MakerDAO uses multi-sig (6/10) for treasury transfers. Even with admin compromise, attacker needs 5 more signers.

🔐 Security Layers by Risk Tier

Critical (Treasury, Upgrades)

1.Multi-sig: Require M-of-N signatures (e.g., 3/5). Single key compromise cannot execute.

2.Time-lock: 24-48h delay between approval and execution. Community can detect and cancel.

3.Governance vote: Large proposals require community approval (e.g., >50% quorum).

4.Audit requirement: Smart contract changes must pass security review before deployment.

High (Role Changes, Emergency)

1.Admin-only: Restrict to admin role (fewer addresses than members).

2.Event logging: Emit on-chain events for all role changes (transparent audit trail).

3.Rate limiting: Maximum 1 emergency pause per week (prevents abuse).

Medium (Parameters, Moderation)

1.Moderator role: Separate from admin, limited to non-financial actions.

2.Community oversight: Moderators elected by governance, removable by vote.

Low (Voting, Viewing)

1.Open access: Anyone with tokens can participate (permissionless).

2.Spam protection: Token threshold (e.g., 0.1% supply) or identity verification.

💡 Key Insight

Permission hierarchies are about defense in depth. A single safeguard (e.g., admin-only) isn't enough for critical operations. You need layered security: multi-sig (multiple people), time-lock (temporal buffer), governance vote (community oversight), and audit (expert review). Think of it like a bank vault—multiple locks, cameras, guards, and time delays. Each layer makes attacks exponentially harder. The higher the risk, the more layers you add. Low-risk permissions (voting) can be permissionless; high-risk (treasury) must be fortress-level secure.

← Introduction