Skip to main content

Execution Context

Execution Context is a data structure maintained by the EVC which holds information about current execution state. It tracks the currently authenticated account address on behalf of which 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.

Nested Execution Contexts​

If a vault or other contract is invoked via the EVC, and that contract in turn re-invokes the EVC to call another vault/contract, then the execution context is considered nested. The execution context is however not treated as a stack. The sets of deferred account and vault status checks are added to, and only after unwinding the final execution context will they be validated.

Internally, the execution context stores a checksDeferred flag that is set each time a checks-deferrable call is started and cleared only when its value before the call was false. Once the flag is cleared, the deferred checks get performed. Nesting calls is useful because otherwise calling contracts via the EVC that themselves want to call other contracts through the EVC would be more complicated.

The previous value of onBehalfOfAccount is stored in a local "cache" variable and is subsequently restored after invoking the target contract. This ensures that contracts can rely on the onBehalfOfAccount at all times when msg.sender is the EVC. However, when msg.sender is not the EVC, vaults cannot rely on onBehalfOfAccount because it could have been changed by a nested context.

checksInProgress​

The EVC invokes the checkAccountStatus and checkVaultStatus callbacks using low-level call instead of staticcall so that controllers can checkpoint state during these operations. However, because of this there is a danger that the EVC could be re-entered during these operations, either directly by a controller, or indirectly by a contract it invokes.

Because of this, the EVC's execution context maintains a checksInProgress mutex that is acquired before unwinding the sets of accounts and vaults that need checking. This mutex is also checked during operations that alter these sets. If it did not do this, then information cached by the higher-level unwinding function (such as the sizes of the sets) could become inconsistent with the underlying storage, which could be used to bypass these critical checks.

controlCollateralInProgress​

The typical use-case for collateral control is for a liability vault to seize collateral assets during a liquidation flow.

However, when interacting with complicated vaults that may invoke external contracts during a withdraw/transfer, a liability vault may want to ensure that no other collaterals are removed during the seizure.

In order to simplify the implementation of this check, the controlCollateralInProgress mutex is locked while invoking a collateral vault during the controlCollateral flow. While locked, no accounts' collateral or controller sets can be modified.

Additionally, during collateral control, the EVC cannot be re-entered via call, batch, controlCollateral or permit.

Extra Information​

The execution context also indicates some extra information, which could be useful if a contract wants to know extra information about the EVC's authentication. This includes information about simulation and operator authentication status.