Skip to main content

Pause and upgradability

Introduction

The option to add pause and upgrade functionality to vaults is completely optional at the protocol level, and instead provided by a vault factory governor smart contract. For factories with this feature, the "pause" function temporarily halts (read-only mode) vaults to prevent unauthorized activity in case of an emergency.

To enhance security, the default "canonical" vault factory, integrated with the Euler interface, includes both pause and upgrade capabilities. The same firms carrying out active monitoring act as "pause guardians" for this factory, with the authority to temporarily halt vaults in case of threats. An independent security council of experienced auditors oversees and approves all upgrades to the canonical factory, ensuring their safety and integrity.

Technical specification

The rules for pause and upgrade of the canonical vault factory are summarised in Figure 1.

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 rules​

Pausing can only be carried out by entities with the PAUSE_GUARDIAN_ROLE role. Once the vault factory is in read-only mode, one of two things can happen.

In the event of a pause carried out because of a false positive threat, unpausing can be carried out by entities with the UNPAUSE_ADMIN_ROLE role. Unpausing brings the vault factory to the pre-pause state and does not allow for any other changes.

In the event of a pause carried out because of a true positive threat or report of a time sensitive critical vulnerability, Euler DAO, which holds the PROPOSER_ROLE, can propose an upgrade to the vault factory code to fix a critical issue.

Upgrade rules​

An upgrade does not get automatically implemented, but instead gets implemented by the factory governor DEFAULT_ADMIN, which is configured as a standard OpenZeppelin TimelockController. The timelock adds additional security by allowing the Euler community a period of time to verify upgrade proposals, and gives entities with the CANCELLER_ROLE role the opportunity to veto improper proposals. Improper proposals are those that perform operations not intended by the DAO (because of a DAO multisig compromise, for example).

Access control roles

FactoryGovernor​

  • DEFAULT_ADMIN: Allowed to set a new implementation to execute proposals that effect code changes on the canonical vault factory. It is held by a TimelockController smart contract. It can also add or remove addresses from the two roles below.
  • PAUSE_GUARDIAN_ROLE: Allows entities to put the canonical vault factory into a read-only mode. It is held by two leading web3 security monitoring firms, as well as Euler Labs Ops multisig.
  • UNPAUSE_ADMIN_ROLE: The unpause role allows entities to configure the canonical vault factory to exit read-only mode. It is held by Euler Labs Ops multisig.

Timelock​

  • PROPOSER_ROLE: Allowed to make proposals on the timelock to effect operations (code upgrades, role changes) on the canonical vault factory. It is held by the Euler DAO multisig.
  • CANCELLER_ROLE: Allowed to veto proposals held in the timelock awaiting execution. This role is held by two parties:
    1. The Euler Security Council multisig, which is a safe-of-safe multisig comprised of the Euler Labs Ops multisigs and the multisigs of two or more leading blockchain security firms. These firms are distinct from those holding the pause role.
    2. The DAO, which holds the proposer role and acts as an additional layer of accountability.
  • EXECUTOR_ROLE: The executor role is unspecified, which means that any unprivileged address may execute a proposal after the timelock period has elapsed.