Checks-deferrable Call

The EVC exposes multiple functions, each with its own characteristics, that allow for the Account Status Checks and Vault Status Checks to be deferred. call, batch and controlCollateral so called checks-deferrable call functions, can be nested and allow for the checks to be deferred until the end of the execution of the outermost function call.

As mentioned above, when interacting with the EVC, it is often useful to defer certain checks until the end of the transaction. This allows a user to temporarily violate some of the constraints imposed by the vaults, so long as the constraints are satisfied at the end of the transaction.

In order to implement this, the EVC maintains two sets of addresses in regular or transient storage (if supported): accountStatusChecks and vaultStatusChecks. Those sets will exist for the duration of the checks-deferrable call, and are then discarded. Only one set per account/vault addresses can exist at a time. However, nesting calls is allowed.

When the outermost call ends, the address sets are iterated over:

• For each address in accountStatusChecks, confirm that at most one controller is installed. If a controller is installed, invoke checkAccountStatus on the controller for this account and ensure that the controller is satisfied. If no controller is installed, checkAccountStatus is not invoked and the account status is considered valid by default. Hence, disableController must be used with care.
• For each address in vaultStatusChecks, call checkVaultStatus on the vault address stored in the set and ensure that the vault is satisfied.