The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
| Requirement ID | Title | Description |
|---|---|---|
| CER-40 | Account Status Check | |
| CER-76 | Account Status Check execution | For the Account Status Check to be performed, there MUST be only one Controller enabled for an Account at the time of the Check. The Status is determined as per data obtained from the called Controller. If the Account Status Check is successful, the EVC MUST store the timestamp of that check for the associated Account. The Controller receives the following data: * the Account address * an array of enabled controllers for the Account at the time of the check |
| CER-46 | Account Status Check forgiveness | If there's only one enabled Controller Vault for an Account, only that Controller MUST be allowed to forgive the Account Status Check if it's deferred |
| CER-41 | Account Status Check more than one controller | If there is more than one Controller enabled for an Account at the time of the Check, the Account Status MUST always be considered invalid |
| CER-42 | Account Status Check no controller | If there is no Controller enabled for an Account at the time of the Check, the Account Status MUST always be considered valid. It includes disabling the only enabled Controller before the Checks |
| CER-43 | Account Status Check number of deferred accounts | EVC MUST allow for Account Status Checks to be deferred for at most 10 Accounts at a time |
| CER-79 | Account Status Check scheduling | Anyone is allowed to require the check for any account |
| CER-34 | Account and Vault Status Checks | |
| CER-106 | Account and Vault Status Checks Deferred Liveness | Ensure any deferred checks that are enqueued are eventually executed. |
| CER-37 | Account and Vault Status Checks deferred | If the Execution Context's checksDeferred flag is set, required Account and Vault Status Checks MUST be deferred until the flag is cleared |
| CER-107 | Account and Vault Status Checks deferred scoping | Status checks may only be deferred in the context of a call, batch or controlCollateral |
| CER-75 | Account and Vault Status Checks execution | EVC MUST allow to require Account and Vault Status Checks which will be performed immediately or deferred, depending on the Execution Context |
| CER-36 | Account and Vault Status Checks immediate | If the Execution Context's checksDeferred flag is not set, required Account and Vault Status Checks MUST be performed immediately |
| CER-48 | Account and Vault Status Checks not performed | Forgiven Account and Vault Status Checks will not be performed when the Execution Context's checksDeferred flag is cleared, unless they are required again after the forgiveness |
| CER-35 | Account and Vault Status Checks storage sets restored | Both Account- and Vault-Status-Checks-related storage sets MUST return to their default state when the Execution Context's checksDeferred flag is cleared and the checks are performed |
| CER-25 | Call/Batch EVC self-call | In Call and Batch, for the sake of consistency, if the target is the EVC, the account specified MUST be address(0) and the value specified MUST be 0. In that case, the EVC MUST be delegatecalled to preserve the msg.sender and, depending on a function, a function-specific authentication is performed |
| CER-23 | Call/Batch callback | In Call and Batch, if the target is msg.sender, the caller MAY specify any Account address to be set in the Execution Context's on behalf of Account address. In that case, the authentication is not performed |
| CER-24 | Call/Batch external call | In Call and Batch, if the target is not msg.sender, only the Owner or an Operator of the specified Account MUST be allowed to perform Call and individual Batch operations on behalf of the Account |
| CER-20 | Checks-deferrable calls | |
| CER-73 | Checks-deferrable calls execution | EVC MUST support the following Checks-deferrable Call functions: call, batch and controlCollateral that are re-entrant and allow to execute calldata on an external target contract addresses or the EVC.Checks-deferrable Call functions are the only functions allowing to defer Account and Vault Status Checks. |
| CER-26 | Checks-deferrable calls msg.sender authorization | Each Checks-deferrable Call function MUST specify an Account. The functions MUST determine whether or not msg.sender is authorized to perform operations on that Account |
| CER-8 | Collaterals | |
| CER-55 | Collaterals disabling | Only an Account Owner or the Account Operator MUST be allowed to disable Collateral Vaults for the Account |
| CER-70 | Collaterals enabling | Only an Account Owner or the Account Operator MUST be allowed to enable Collateral Vaults for the Account |
| CER-9 | Collaterals number | Each Account MUST have at most 10 Collateral Vaults enabled at a time |
| CER-58 | Collaterals reordering | Only an Account Owner or the Account Operator MUST be allowed to reorder enabled Collateral Vaults for the Account |
| CER-80 | Collaterals restrictions | EVC MUST NOT be allowed to become Collateral |
| CER-22 | ControlCollateral authorization | In ControlCollateral, only the enabled Controller of the specified Account MUST be allowed to perform the operation on one of the enabled Collaterals on behalf of the Account |
| CER-21 | ControlCollateral through Permit | The Controller Vault MUST NOT be allowed to use permit in order to use controlCollateral |
| CER-11 | Controllers | |
| CER-110 | Controllers Disabling Entrypoint | Only disableController() can change isContolledEnabled. |
| CER-56 | Controllers disabling | Only an enabled Controller Vault for the Account MUST be allowed to disable itself for that Account |
| CER-57 | Controllers disabling through Permit | The Controller Vault MUST NOT be allowed to use permit in order to disable itself for an Account |
| CER-71 | Controllers enabling | Only an Account Owner or the Account Operator MUST be allowed to enable Controller Vaults for the Account |
| CER-12 | Controllers number | Each Account MUST have at most one Controller Vault enabled at a time unless it's a transient state during a Checks-deferrable Call. In a transient state, an Account can have up to 10 Controllers at once. |
| CER-81 | Controllers restrictions | EVC MUST NOT be allowed to become Controller |
| CER-27 | Execution Context | |
| CER-32 | Execution Context checksDeferred | Execution Context MUST keep track of whether the Checks are deferred with a boolean flag. The flag MUST be set when a Checks-deferrable Call starts and MUST be cleared at the end of it, but only when the flag was not set before the call |
| CER-31 | Execution Context checksInProgress | Execution Context MUST keep track of whether the Account and Vault Status Checks are in progress |
| CER-30 | Execution Context controlCollateralInProgress | Execution Context MUST keep track of whether the Control Collateral is in progress |
| CER-64 | Execution Context functions | Use of any of the ExecutionContext library functions that is meant to set (or clear) a flag or the onBehalfOfAccount address does not affect any storage region other than the one storing the flag/address |
| CER-74 | Execution Context observability | EVC MUST maintain the Execution Context and make it publicly observable |
| CER-33 | Execution Context onBehalfOfAccount | Execution Context MUST keep track of the Account on behalf of which the current low-level external call is being performed |
| CER-94 | Execution Context onBehalfOfAccount setting | Execution Context's onBehalfOfAccountaddress MUST only be set to a non-zero address if the EVC is about to execute a low-level call in callWithContextInternal.When setting onBehalfOfAccount to X address other than address(0), current msg.sender MUST be as follows:1. Any address if in permit 2. Any address if in call or batch, and msg.sender is equal to target address 3. X's Controller address if in controlCollateral 4. X's Owner or authorized Operator address in all the other cases |
| CER-39 | Execution Context onBehalfOfAccount when checksDeferred | Execution Context's onBehalfOfAccount MUST be storing address(0) when the checksInProgress flag is set |
| CER-29 | Execution Context operatorAuthenticated | Execution Context MUST keep track of whether an Account Operator was authenticated to perform the current low-level calldata call on behalf of the Account |
| CER-38 | Execution Context restored | 1. Execution Context MUST return to its default state when checksDeferred flag is cleared 2. After any function call, Execution Context MUST be restored to the value from just before the call |
| CER-28 | ExecutionContext simulationInProgress | Execution Context MUST keep track of whether the Simulation is in progress. The Account and Vault Status Checks are not considered to be a part of simulation. |
| CER-6 | Nonce | |
| CER-69 | Nonce setting | Only an Account Owner MUST be allowed to modify the Nonce for its Address Prefix and Nonce Namespace |
| CER-7 | Nonce value | New Nonce MUST NOT be lower than or equal to the currently stored |
| CER-2 | Operator | |
| CER-68 | Operator authorization | Only an Account Owner MUST be allowed to authorize an Account Operator to operate on behalf of the Account |
| CER-52 | Operator deauthorization | Account Operator that is authorized to operate on behalf the Account MUST only be allowed to be deauthorized by: * the Account Owner, or * the Account Operator itself (one Account Operator MUST NOT be able to deauthorize the other Account Operator) |
| CER-54 | Operator does not belong to the Owner | Account Operator address MUST NOT belong to the Account Owner of the Account for which the Operator being is authorized |
| CER-53 | Operator multiple allowed | Account MAY have multiple Account Operators |
| CER-62 | Operator setAccountOperator() | Calling setAccountOperator does not affect the state for any account and operator other than the target of the function call |
| CER-63 | Operator setOperator() | Calling setOperator does not affect the state for any addressPrefix and operator other than the target of the function call |
| CER-1 | Owner | |
| CER-60 | Owner common addressPrefix | Any two Accounts have a common Owner (as per haveCommonOwner) if their addressPrefix is identical |
| CER-59 | Owner override | EVC MUST NOT override the already stored Owner for a given addressPrefix |
| CER-67 | Owner storing | An Owner of the group of 256 accounts MUST be stored only once upon the first interaction of any of its Accounts with the EVC |
| CER-15 | Permit | |
| CER-16 | Permit authorization rules | The authorization rules of the Permit message calldata execution MUST be as if the calldata were executed on the EVC directly |
| CER-51 | Permit context msg.sender | msg.sender MUST be the EVC only in the Permit context. The EVC MUST NOT be msg.senderunder any other circumstances |
| CER-72 | Permit execution | EVC MUST support signed Permit messages that allow specified sender address to execute arbitrary calldata on the EVC on behalf of the Account Owner or Account Operator who signed the message (signer). If sender is not specified, anyone is allowed to execute that calldata. |
| CER-19 | Permit message EIP-712 | Signed Permit message MUST conform to the EIP-712 standard rules. The type of the EIP-712 data structure MUST be encoded as follows: Permit(address signer,address sender,uint256 nonceNamespace,uint256 nonce,uint256 deadline,uint256 value,bytes data) |
| CER-18 | Permit message validity | For the signature to be considered valid, all of the below MUST be true: * signer address corresponds to the valid signer address obtained using standard ecrecover precompile or using ERC-1271 defined rules for standard signature verification methods for contracts * unless address(0), sender address corresponds to the msg.sender calling the function * nonce is equal to the current on-chain Nonce value for signer-corresponding Address Prefix and nonceNamespace * deadline value is not greater than block.timestamp at the block of signature verification * value does not exceed the value balance of the EVC contract at the time of signature verification, or is equal to type(uint256).max * data field is not empty |
| CER-17 | Permit nonce increasing | Upon successful verification of the signature, EVC MUST increase the Nonce value corresponding to the Nonce Namespace and the Signer |
| CER-65 | Permit onBehalfOfAccount | EVC MUST only rely on the stored Execution Context's onBehalfOfAccount address when in Permit context. In other words, it MUST NOT be possible to spoof Execution Context's onBehalfOfAccount (i.e. by using call in a callback manner where authentication is not performed) and force the EVC to rely on that spoofed address |
| CER-49 | Re-entrancy | Out of the EVC functions, only the Checks-Deferrable Call functions and the Permit function MUST be allowed to re-enter the EVC. Other smart contracts, when exercised from Checks-Deferrable Call functions, MUST always be allowed to re-enter the EVC, unless Account or Vault Status Checks are in progress (Execution Context's checksInProgress flag is set) or Control Collateral is in progress (Execution Context's controlCollateralInProgress flag is set).If checksInProgress is set, it MUST NOT be possible to re-enter:* any function that modifies Account's Collaterals and Controllers * any Checks-Deferrable Call function * Permit function * any Simulation-related functions * any state-modifying Account-and-Vault-Status-Check-related function If controlCollateralInProgress is set, it MUST NOT be possible to re-enter:* any function that modifies Account's Collaterals and Controllers * any Checks-Deferrable Call function * Permit function * any Simulation-related functions |
| CER-113 | Security | To improve user security, the EVC introduces Lockdown and Permit Disabled modes. |
| CER-116 | Security Lockdown Mode Activation | Only Owner MUST be able to activate the Lockdown Mode. |
| CER-117 | Security Lockdown Mode Deactivation | Only Owner MUST be able to deactivate the Lockdown Mode. The EVC MUST NOT allow the Lockdown Mode to be disabled within the Permit context or within a Checks-deferrable Call. To disable this mode a direct call to the EVC must be made. |
| CER-115 | Security Lockdown Mode Scope | Once Lockdown Mode activated, the EVC MUST significantly reduce its functionality across the Owner's Accounts. In this mode, the Owner is restricted to managing Operators, Nonces and Security Modes, while authorized Operators are only restricted to revoking their own permissions. With Lockdown Mode active, neither the Owner nor the Operators can carry any other operations on the EVC. Notably, calling external smart contracts on behalf of the Owner or any of their Accounts is prohibited. However, enabled Controllers can still control collaterals for the Accounts (as well as perform other Controller-specific operations like forgiving Account Status Check or disabling Controller), even under lockdown. The Lockdown Mode does not protect the user in case a contract uses Batch or Call to call back itself. In such a case, the authentication on the EVC is not performed hence the Lockdown Mode is not applied, even if enabled for the contract-specified Account. Note that typically, it will only affect only Account Owner (not its virtual Accounts) as the contract is advised to pass msg.sender as onBehalfOfAccount parameter of the Call. Example: a vault using call to route the calls through the EVC, even if interacted with directly, will bypass the Lockdown Mode enabled for the vault-specified onBehalfOfAccount address (typically owner address). |
| CER-114 | Security Permit Disabled Mode Scope | Once Permit Disabled Mode activated, the EVC MUST NOT allow executing Permits that were signed by the Owner which activated this mode. The Permit Disabled Mode is a subset of the Lockdown Mode which is more restrictive. |
| CER-118 | Security Permit Only Mode Activation | Only Owner MUST be able to activate the Permit Disabled Mode. |
| CER-119 | Security Permit Only Mode Deactivation | Only Owner MUST be able to deactivate the Permit Only Mode. The EVC MUST NOT allow the Permit Only Mode to be disabled within the Permit context or within a Checks-deferrable Call. To disable this mode a direct call to the EVC must be made. |
| CER-83 | Set | |
| CER-86 | Set contains return | 1. contains MUST return true if an element is present in the set 2. contains MUST return false if an element is not present in the set |
| CER-85 | Set forEachAndClear | Set library MUST execute provided callback function on all the elements contained in the set and clear the set |
| CER-84 | Set forEachAndClearWithResult | Set library MUST execute provided callback function on all the elements contained in the set, gather callback results and clear the set. An array of bytes MUST be returned where each element of the array encodes the element on which the callback was executed, callback return status and callback result |
| CER-87 | Set get | Set library MUST return an array of all the elements contained in the set |
| CER-93 | Set insert | Set library MUST insert an element into the set unless it's a duplicate or the set is full |
| CER-92 | Set insert return | 1. insert MUST return true if an element was successfully inserted into the set 2. insert MUST return false if an element is already present in the set thus not inserted 3. insert MUST revert if an element would be inserted into the set (not a duplicate) but the set is already full |
| CER-296 | Set metadata | Set library MUST store the metadata associated with the set |
| CER-91 | Set remove | Set library MUST remove an element from the set if it's present |
| CER-90 | Set remove return | 1. remove MUST return true if an element was successfully removed from the set 2. remove MUST return false if an element was not removed from the set |
| CER-89 | Set reorder | Set library MUST swap the position of two elements so that they appear switched in the array obtained using the get function. |
| CER-88 | Set reorder input | reorder MUST revert if the second index provided is greater than or equal to the first index provided or if any of the indices provided is out of scope |
| CER-50 | Simulation | |
| CER-61 | Simulation reverts | Only batchSimulation and batchRevert functions are allowed to revert, all the other external functions have non-reverting paths |
| CER-82 | Simulation state | Simulation-related functions MUST NOT modify the state |
| CER-66 | Untrusted code execution | EVC MUST NOT execute other contracts code in its own context |
| CER-44 | Vault Status Check | |
| CER-77 | Vault Status Check execution | For the Vault Status Check to be performed, they MUST have been required by the Vault on which they will be performed. The Status is determined as per data obtained from the called Vault |
| CER-47 | Vault Status Check forgiveness | EVC MUST allow a Vault to forgive the Vault Status Check for itself if it's deferred |
| CER-45 | Vault Status Check number of deferred vaults | EVC MUST allow for Vault Status Checks to be deferred for at most 10 Vaults at a time |
| CER-78 | Vault Status Check scheduling | Only the Vault is allowed require the check for itself |