Skip to main content

Pause and upgradability

The Euler Vault Kit (EVK) is agnostic about whether vault creators choose to add emergency pause functionality and/or upgradability to their vaults. The option to add this functionality to vaults is provided by a factory governor smart contract. Pause functionality can be used to put vaults into a temporary read-only mode in the event of attempted malicious activity. Upgradability can be used to fix critical bugs.

Canonical vault factory​

To enhance security, vaults deployed using the canonical vault factory supported by the Euler interface currently support both pause and upgrade functions. The rules for pause and upgrade of the factory are summarised in Fig. 1.

It is important to stress that these functions are designed to be used only in the event of suspected critical security issues in the underlying code of the canonical vault factory. They are not designed to be used to add non-critical functionality or prevent a broader class of issues that might result, for example, from vaults that are configured incorrectly or challenging economic conditions.

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.