Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to 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.
  • Exception: a contract answering an ERC-1271 isValidSignature call from the EVC must not authenticate through the execution context. See ERC-1271 signature validation.

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.
  • 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, except in code answering an ERC-1271 isValidSignature call (see ERC-1271 signature validation).
  • 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.

ERC-1271 signature validation

permit verifies a smart-contract signature by staticcalling isValidSignature on the signer, before it sets the permit's own execution context. While isValidSignature runs, msg.sender is the EVC, but the execution context still holds the onBehalfOfAccount of any enclosing call or batch. That account need not belong to the signer: when a call or batch item targets its own caller, the caller sets the account without authentication.

A contract that answers isValidSignature, and any code it reaches, must therefore not authenticate through the EVC. That rules out treating msg.sender == evc together with getCurrentOnBehalfOfAccount or getRawExecutionContext as an authenticated caller, and the EVCUtil helpers built on that pattern (_msgSender(), _msgSenderForBorrow(), onlyEVCAccount, onlyEVCAccountOwner). Validate the signature against state the signer controls, such as an owner's ECDSA key or signatures it has approved onchain.

The deployed EVC is immutable, so this applies to every existing deployment. See the EVC security notes.

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.