Skip to main content

Definitions

Ethereum Vault Connector (EVC)​

A smart contract that mediates between Vaults in order to enable their lending and borrowing functionality.

Vault​

A smart contract that accepts deposits of a single asset and issues shares in return, it may support borrowing functionality. It should implement the logic and interface necessary for interaction with other Vaults via the EVC. It may be, ERC-4626 compliant.

Account​

Every Ethereum address has 256 accounts in the EVC (one private key to rule them all). Each account has an account ID from 0-255. In order to compute the account addresses, the Account ID is treated as a uint and XORed (exclusive ORed) with the Ethereum address. Effectively, a group of 256 Accounts belonging to the same owner share the first 19 bytes of their address and differ only in the last byte.

Account Owner​

An EOA or a smart contract Ethereum address, one of the 256 Accounts with Account ID 0, that has ownership over the whole group of Accounts.

Address Prefix​

The first 19 bytes of the Ethereum address. Account Owner has a common Address Prefix with any of the Accounts that belong to them.

Account Operator​

An EOA or smart contract Ethereum address that has been granted permission to operate on behalf of the Account. The permission can only be granted by the Account Owner.

Collateral Vault​

A Vault which deposits are accepted as collateral for borrowing in other Vaults. An Account can enable multiple collaterals. Enabled collateral can be seized by the Controller Vault in case of liquidation.

Controller Vault​

A Vault that may be enabled by a user in order to be able to borrow from it. Enabling Controller submits the specified Account to the rules encoded in the Controller Vault's code. All the funds in all the enabled Collateral Vaults are indirectly under the control of the enabled Controller Vault; hence, the Accounts must only enable trusted, audited Controllers. If the Controller is malicious or incorrectly coded, it may result in the loss of the user's funds or even render the account unusable. Whenever a user wants to perform an action such as removing collateral, the Controller Vault is consulted in order to determine whether the action is allowed, or whether it should be blocked since it would make the Account insolvent. An Account can have only one Controller Vault enabled at a time unless it's a transient state during checks deferral.

Nonce Namespace​

A value used in conjunction with Nonce to prevent replaying Permit messages and for sequencing. Each Nonce Namespace provides a uint256 Nonce that has to be used sequentially. There's no requirement to use all the Nonces for a given Nonce Namespace before moving to the next one, which allows using Permit messages in a non-sequential manner.

Nonce​

A value used to prevent replaying Permit messages and for sequencing. It is associated with a specific Nonce Namespace and an Address Prefix. The Nonce must be used sequentially within its Nonce Namespace. To invalidate signed Permit messages, set the Nonce for a given Nonce Namespace accordingly. To invalidate all the Permit messages for a given Nonce Namespace, set the Nonce to type(uint).max.

Permit​

A functionality based on the EIP-712 typed data message allowing arbitrary signed calldata execution on the EVC on behalf of the signer (Account Owner or Account Operator) of the message. It is useful for implementing "gasless" transactions.

Call​

A functionality allowing to execute arbitrary calldata on an arbitrary contract with Account and Vault Status Checks deferred. In case the target contract is the EVC, delegatecall is performed to preserve the msg.sender. If the target contract is msg.sender, the caller may specify any Account address to be set in the Execution Context. In case the target contract is not msg.sender, only the Account Owner or Account Operator are allowed to execute arbitrary calldata on behalf of the specified Account.

Batch​

Like Call, but allows a list of operations that are executed atomically one by one with Account and Vault Status Checks deferred.

ControlCollateral​

A functionality allowing an enabled Controller Vault to execute an arbitrary calldata on any of the enabled Collateral Vaults on behalf of the specified Account while Account and Vault Status Checks are deferred. The Controller Vault must be the only enabled Controller Vault for the Account in order to be able to control collateral. This functionality is useful for liquidation flows.

Simulation​

An entry point into the EVC that allows for simulating the execution of a batch without modifying the state. It is useful for inspecting the outcome of a batch before executing it.

Account Status Check​

A functionality implemented by Vaults to enforce Account solvency. Vaults must expose a special function that will receive an Account address and this Account's list of enabled Collateral Vaults in order to determine the Account's liquidity status. Account status is checked immediately or is deferred until the end of the top-level Checks-deferrable Call. Account Status Check deferral allows for a transient violation of the Account solvency.

Vault Status Check​

A functionality implemented by Vaults to enforce Vault constraints (i.e. supply/borrow caps). Vaults may expose a special function that implements necessary checks in order to determine acceptable state of the Vault. Vault status is checked immediately or is deferred until the end of the outermost Checks-deferrable Call. Vault Status Check deferral allows for a transient violation of the Vault constraints.

Checks-deferrable Call​

A functionality that defers the Account and Vault Status Checks, namely: Call, Batch or ControlCollateral call. Checks-deferrable Calls can be nested.

Checks Deferral​

A functionality allowing to defer Account and Vault Status Checks until the end of the outermost Checks-deferrable Call. This allows for a transient violation of the Account solvency or Vault constraints.

Lockdown Mode​

A security feature of the EVC that can be activated by the Account Owner. Once activated, it applies to all the Accounts owned by the Account Owner simultaneously, significantly reducing the functionality of the EVC for those Accounts. This mode is particularly useful in emergency situations, such as when a malicious operator has been added or a harmful permit message has been signed, to safeguard the user's assets.

Permit Disabled Mode​

A security feature that can be activated by the Account Owner. Once activated, it applies to all the Accounts owned by the Account Owner simultaneously, preventing the execution of any Permits that were signed by the Account Owner. This mode is particularly useful in emergency situations, such as when a harmful permit message has been signed, to safeguard the user's assets.

Execution Context​

A data structure maintained by the EVC that holds information about the current execution state. It tracks the currently authenticated Account address on behalf of which the current operation is being performed, a flag indicating whether the Checks are deferred, a flag indicating whether the Account/Vault Status Checks are in progress, a flag indicating whether the ControlCollateral is in progress, a flag indicating whether an Account Operator is currently operating on behalf of the Account and a flag indicating whether the Simulation is in progress.