Skip to main content

Pause and Upgradability

Introduction

At the protocol level, the ability to pause and upgrade vaults is entirely optional. This functionality is provided through a vault factory governor smart contract, allowing for flexibility in implementation. For factories that choose to implement these features, the pause function serves as a critical safety mechanism, temporarily halting vaults to read-only mode in emergency situations.

The default "canonical" vault factory, which is integrated with the Euler interface, includes both pause and upgrade capabilities as part of its security architecture. This factory is protected by a team of pause guardians, consisting of leading web3 security monitoring firms and the Euler Labs Ops multisig. Additionally, an independent security council of experienced auditors oversees and approves all upgrades to the canonical factory, ensuring the safety and integrity of any changes.

Technical Architecture

The pause and upgrade system is built on a sophisticated access control framework, as illustrated in Figure 1. This framework ensures that only authorized entities can perform critical operations while maintaining transparency and security.

Figure 1: Summary of canonical vault factory pause and upgradability rules and access controls

Figure 1. Summary of canonical vault factory pause and upgradability rules and access controls.

Pause Mechanism

The pause functionality is controlled by entities holding the PAUSE_GUARDIAN_ROLE. When activated, this function places the vault factory in read-only mode, effectively preventing any unauthorized activity. The system then follows one of two paths depending on the nature of the threat.

If the pause was triggered by a false positive threat, the system can be unpaused by entities with the UNPAUSE_ADMIN_ROLE. This process restores the vault factory to its pre-pause state without implementing any additional changes.

In cases where a genuine threat or time-sensitive critical vulnerability is identified, the Euler DAO, which holds the PROPOSER_ROLE, can initiate an upgrade process to address the issue. This upgrade process is carefully controlled to ensure security and transparency.

Upgrade Process

The upgrade process is designed with multiple layers of security. Rather than implementing upgrades automatically, they must go through the factory governor DEFAULT_ADMIN, which is implemented as an OpenZeppelin TimelockController. This timelock mechanism serves several important purposes:

  1. It provides the Euler community with a window to review and verify upgrade proposals
  2. It allows entities with the CANCELLER_ROLE to veto any improper proposals
  3. It protects against potential DAO multisig compromises by requiring multiple layers of approval

Access Control Framework

Factory Governor Roles​

The Factory Governor implements three key roles:

The DEFAULT_ADMIN_ROLE role is held by a TimelockController smart contract. This role has the authority to set new implementations and execute proposals that modify the canonical vault factory code. It also manages the assignment of the other roles.

The PAUSE_GUARDIAN_ROLE is distributed among two leading web3 security monitoring firms and the Euler Labs Ops multisig. These entities have the authority to activate the pause function when necessary.

The UNPAUSE_ADMIN_ROLE is held by the Euler Labs Ops multisig, which has the authority to restore normal operations after a pause.

Timelock Roles​

The Timelock system implements three distinct roles:

The PROPOSER_ROLE is held by the Euler DAO multisig, which can submit proposals for code upgrades and role changes to the canonical vault factory.

The CANCELLER_ROLE is held by two distinct entities:

  1. The Euler Security Council multisig, which is a safe-of-safe multisig comprising the Euler Labs Ops multisigs and the multisigs of two or more leading blockchain security firms. These firms are separate from those holding the pause role.
  2. The DAO itself, which holds the proposer role as an additional layer of accountability.

The EXECUTOR_ROLE is intentionally unspecified, allowing any unprivileged address to execute a proposal after the timelock period has elapsed. This design choice ensures transparency and community participation in the upgrade process.