Skip to main content

Security Considerations

The Euler Vault Kit (EVK) is designed with security as a priority, but there are inherent limitations and risks that developers and users should be aware of. This document outlines key security considerations when working with EVK vaults.

Known Limitations

Governance Risk​

Vaults can be configured in different combinations of upgradeable/immutable and governed/finalised. Each combination presents different risk profiles:

  • Upgradeable + Governed: Subject to both factory admin and governor risks
  • Immutable + Governed: Subject only to governor risks
  • Upgradeable + Finalised: Subject only to factory admin risks
  • Immutable + Finalised: No governance risks

There are also risks to creating immutable/finalised vaults:

  • If market conditions change, making a formerly safe collateral asset or price oracle unsafe, only governed vaults can be reconfigured
  • If critical bugs are found in the Vault Kit code, the factory admin will only be able to fix upgradeable vaults

Collateral Validation​

Using vaults with illiquid or manipulable underlying assets could threaten the safety of depositors. It's critical to evaluate the smart contract code that implements each collateral vault. A badly coded or malicious vault could:

  • Refuse to release funds in a liquidation event
  • Lie about the value of its holdings
  • Have dangerous configurations that might encounter bad debt situations

Hooks Security Concerns​

Hooks can implement condition checks that (maliciously or not) could prevent liquidations from succeeding. Vaults with hooks installed should be carefully audited to ensure they don't interfere with critical functions like liquidations.

Exchange Rate Manipulation​

While EVK implements several protections against exchange rate manipulation (virtual deposits, internal balance tracking), these protections are not perfect for external vaults and assets accepted as collateral. In particular, empty or near-empty external collateral vaults may still be susceptible to manipulation attacks, which could affect the security of any vault accepting them as collateral. Vault governors should carefully evaluate the risk profile of each external vault before accepting it as collateral. Refer to Donation Attacks section for more information.

Overflows​

There are several potential overflow conditions that could affect vault operations:

  • If values such as total supply, borrows, and cash approach their upper limits, the accounting logic of the vault becomes undefined
  • The interest accumulator could eventually overflow if interest rates remain extremely high for extended periods

Price Oracle Risks​

While the oracle adapters themselves (at least those developed by Euler) are immutable, vaults that use a governed oracle router can update their pricing source as long as governance over the router is retained. If the router is finalized or governance is revoked, the oracle configuration becomes immutable. If a price oracle becomes unreliable or compromised and the router is still governed, it can be updated to point to a new, secure adapter. Vaults rely on their configured oracle (or router) for pricing collateral and liabilities, so robust governance and timely updates are critical for security.

Nested Vault Limitations​

Using a nested vault (i.e., a vault as collateral for its own liability vault) can cause liquidation to fail due to re-entrancy issues when pricing the nested collateral. While some EVK deployments attempted to prevent this at the code level, this approach introduced operational challenges and is being reconsidered. The risk remains low-severity and is best addressed through careful governance.Vault governors should be aware that using nested vaults as collateral may result in failed liquidations and should evaluate this risk when configuring vaults.

Security Best Practices

Vault Configuration​

When configuring vaults:

  1. Carefully select appropriate LTVs based on both the underlying asset's risk and the vault containing it
  2. Consider using both borrowing and liquidation LTVs to protect against oracle price delays and manipulation
  3. Configure a non-zero liquidation cool-off period to prevent certain types of price oracle attacks
  4. Use LTV ramping when reducing the liquidation LTV to avoid unfair liquidations

Collateral Validation​

Before accepting a vault as collateral:

  1. Verify it was created by a trusted factory by calling the factory's isProxy() function
  2. Evaluate the security of its underlying asset, price oracle, and configuration
  3. Verify that its transfer method doesn't invoke any external contracts that could run attacker code
  4. Be cautious with vaults that have hooks installed, as they may interfere with liquidations

Oracle Security​

When selecting price oracles:

  1. Use reliable and decentralized oracle solutions when possible
  2. Consider using oracles with a non-zero bid-ask spread to communicate real-time pricing risks
  3. For cross pricing, ensure that all price sources in the chain are reliable

Risk Management​

For ongoing risk management:

  1. Monitor positions for unhealthy debt-to-collateral ratios
  2. Implement robust liquidation systems to ensure unhealthy positions are liquidated efficiently
  3. Consider the implications of using a vault as collateral that itself accepts risky collateral

Governance Practices​

If governing a vault:

  1. Make governance actions transparent and predictable to users
  2. Use timelocks for sensitive operations like changing LTVs or price oracles
  3. Consider using limited governor contracts that can only perform specific actions
  4. Have clear procedures for emergency responses to market events or discovered vulnerabilities

Vault Security Features

Liquidation Cool-Off Period​

The cool-off period prevents an account from being liquidated inside a block where it was previously healthy. This protection helps prevent certain types of price oracle attacks by forcing attackers to keep positions open between blocks, exposing them to potential risk.

LTV Ramping​

When reducing liquidation LTVs, a ramp duration can be specified to linearly decrease the LTV over time. This protects borrowers from sudden LTV changes that could cause unfair liquidations.

Bad Debt Socialisation​

Vaults have bad debt socialisation enabled by default to handle cases where a liquidation still leaves an account with outstanding debt. This prevents bank-run scenarios as it socializes losses to all depositors.

Internal Balance Tracking​

Vaults track balances internally rather than depending on direct token balance checks. This prevents certain types of donation-based exchange rate manipulations.