Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Governor contracts

Governor contracts can hold the governorAdmin authority of Euler Vault Kit (EVK) vaults and compatible oracle routers. They authenticate and forward administrative calls according to their role configuration. A curator, DAO, multisig, or risk steward can hold one or more roles in a governor, depending on the deployment.

The result is a flexible way to separate routine parameter changes, timelocked governance, and emergency actions.

The role of governor contracts

An EVK vault exposes a governorAdmin address with broad vault-configuration authority. The exact callable functions depend on the target contract and governor. This vault-level authority is distinct from the EVault factory's upgradeAdmin, which can affect factory-linked upgradeable vault implementations; see Factory Governor.

Roles and configuration

Governor contracts use role-based access control, often selector-based, to manage permissions:

  • DEFAULT_ADMIN_ROLE: The most powerful role, able to grant/revoke other roles and perform admin actions. It should generally be held by a reviewed multisig or DAO-controlled address.
  • WILD_CARD: Grants access to all function selectors, typically held by a timelock for day-to-day governance.
  • Function Selector Roles: Grant access to specific functions, allowing granular permissioning.
  • Guardian and emergency roles: Their names and powers vary by implementation and can include LTV_EMERGENCY_ROLE, HOOK_EMERGENCY_ROLE, and CAPS_EMERGENCY_ROLE. Inspect role membership and callable selectors rather than inferring authority from a label.

Careful assignment and monitoring of these roles is critical. A misconfigured role can affect vault behavior, oracle routing, caps, LTVs, or emergency response.

Types of governor contracts

Euler provides several specialized governor contracts, each with different operational tradeoffs:

GovernorGuardian

GovernorGuardian is a simple, proxy-like governor for vaults. Default admins can call any function, while guardians can pause or unpause the vault. It includes a cooldown to prevent repeated pausing and allows selective re-enabling of methods (e.g., only allow withdrawals/repays). Its authority and recovery behavior depend on deployed roles and configuration; review those values rather than treating the contract type as a safety designation.

GovernorAccessControl

GovernorAccessControl provides selector-based access control: permissions are granted per function selector, or globally via the WILD_CARD role. Whitelisted callers can invoke specific functions on target contracts, with authentication and forwarding handled by the governor. It can be used standalone or as part of a timelock-enabled governance suite. This is the most flexible and granular governor type.

GovernorAccessControlEmergency

This contract inherits from GovernorAccessControl and adds emergency roles for rapid response. Emergency guardians can instantly lower borrow LTV, pause vault operations, or lower supply/borrow caps. These actions can provide a circuit breaker during risk events. Recovery from emergency states, such as unpausing, goes through the timelock process when a timelock is installed.

CapRiskSteward

CapRiskSteward is a specialized risk management contract that works alongside selector-based governors. It allows authorized users to adjust supply and borrow caps within predefined bounds and cooldowns, and to update interest rate models (IRM) only to those deployed by a recognized factory. This can delegate limited parameter management to reviewed stewards while keeping broader control with the governor and timelock.

Timelock integration: dual timelock model

The recommended deployment uses the GovernorAccessControlEmergencyFactory, which sets up:

  • Admin Timelock: Holds the DEFAULT_ADMIN_ROLE, controls governance of the governor contract itself (break-glass, rarely used).
  • Wildcard Timelock: Holds the WILD_CARD role, used for day-to-day governance (parameter changes, etc.).

The dual timelock model makes queued changes visible before execution, gives users time to respond to pending changes, and separates emergency actions from routine parameter changes.

How to call the GovernorAccessControl contract

To call a function on a vault via GovernorAccessControl, you must append the target vault address to the calldata. This allows the governor to authenticate the call and forward it to the correct vault. Here's a simple example in Solidity:

// Assume you want to call setCaps(uint16,uint16) on a vault via the governor
address vault = VAULT_ADDRESS;
uint16 supplyCap = 1000;
uint16 borrowCap = 500;
 
// Fetch the governor address from the vault contract
address governor = IVault(vault).governorAdmin();
 
// Encode the function selector and arguments
bytes memory encodedCall = abi.encodeWithSelector(
    IEVault.setCaps.selector,
    supplyCap,
    borrowCap
);
 
// Append the vault address (20 bytes) to the calldata using abi.encodePacked
bytes memory encodedCallWithTarget = abi.encodePacked(encodedCall, vault);
 
// Call the governor contract
(bool success, bytes memory result) = governor.call(encodedCallWithTarget);
require(success, "Governor call failed");

This pattern is also used for GovernorAccessControlEmergency and CapRiskSteward contracts. The governor contract extracts the trailing address and forwards the call to the vault, authenticating the caller's permissions for the function selector.

Read next