Skip to main content

Security Considerations

The Ethereum Vault Connector (EVC) is designed as a foundational layer for secure, modular lending and collateral management. While it provides robust security features, both protocol users and integrators must understand its security model, limitations, and best practices to ensure safe operation.

Core Security Features

Lockdown Mode​

EVC introduces a LOCKDOWN MODE for emergency response. When activated by the owner, it restricts all accounts under that owner to only managing operators and nonces. All other operations, including calling external contracts, are blocked. This is especially useful if a malicious operator is added or a harmful permit is signed. Controllers can still control collaterals for the accounts under lockdown, allowing for safe unwinding of positions if needed.

Permit Disabled Mode​

Owners can activate PERMIT DISABLED MODE to immediately block execution of any permits signed by them. This is a rapid response to accidental signing of a harmful permit.

Authentication and Authorization​

  • Authentication is handled by the EVC, which verifies the true sender and context for every operation (including sub-accounts and operators).
  • Authorization is the responsibility of the vault. When called via EVC, vaults must use getCurrentOnBehalfOfAccount to determine the authenticated account and controller status.

Account and Vault Status Checks​

  • EVC enforces rigorous account and vault status checks, ensuring that accounts remain solvent and vault-level invariants are maintained.
  • Vaults must require and implement these checks after any operation that could affect solvency or global constraints.

Execution Context and Re-entrancy Protection​

  • EVC maintains an execution context for each batch or call, deferring checks until the end of the context for atomicity and gas efficiency.
  • The checksInProgress and controlCollateralInProgress mutexes prevent re-entrancy and ensure that status checks and collateral control are performed safely.

Vault Implementation Security Considerations

Vaults integrating with EVC must:

  • Implement the IVault interface and follow the EVC vault specification (vault implementation considerations).
  • Use the callThroughEVC modifier (or equivalent pattern) to ensure status checks are always deferred and performed in the correct context.
  • Always use getCurrentOnBehalfOfAccount for authorization when called via EVC.
  • Require account and vault status checks at the end of any operation that could affect solvency or vault invariants.
  • Implement checkAccountStatus and, if needed, checkVaultStatus with the recommended access control and context checks.
  • Be careful with re-entrancy guards: when called directly (not via EVC), requiring a status check will immediately call back into the vault, which can trigger a re-entrancy guard. Use the callback pattern or relax the guard for status check calls as needed.
  • Only allow calls to trusted contracts; never allow arbitrary contract calls from the vault.
  • Restrict allowed collateral vaults to a known-good set of audited addresses or use a registry/factory for validation.

Known Limitations and Attack Vectors

EVC Contract Privileges​

EVC can call any contract with arbitrary calldata. It should never be given special privileges or hold tokens/ETH except temporarily mid-batch.

Read-only Re-entrancy​

EVC's non-transient storage can be read while checks are deferred, but each operation leaves these lists in a consistent state. Vaults should not rely on the controller/collateral sets if checks are deferred.

Simulation Limitations​

The simulation feature sets a flag that can be observed by external contracts. Malicious contracts could behave differently during simulation, so simulations should not be relied on for security with untrusted contracts.

Controller Risk​

When a user enables a controller, all their collateral is subject to the controller's rules. Only the controller can disable itself, typically after all debt is repaid. Vaults must implement a standard disableController function.

Operator Risks​

Operators have broad permissions; only trusted, audited contracts should be authorized as operators. Owners should be prepared to revoke operator permissions quickly if needed.

Best Practices for Developers and Users

For Vault Developers​

  • Always use the EVC utility contracts and recommended modifiers for authentication, authorization, and status checks.
  • Restrict collateral vaults to known-good, audited contracts.
  • Require account and vault status checks after every operation that could affect solvency or vault invariants.
  • Use the callback pattern or relax re-entrancy guards for status check calls as needed.
  • Implement and test disableController logic carefully.
  • Never allow uncontrolled calls to arbitrary contracts.

For Protocol Integrators and Users​

  • Use LOCKDOWN MODE and PERMIT DISABLED MODE immediately if suspicious activity is detected.
  • Only enable trusted, audited controllers and operators.
  • Use sub-accounts to isolate risk between positions.
  • Be aware of the risks of using vaults as collateral, especially if they themselves accept risky collateral.