Operations and submit()

What are vault operations

Vault operations are a series of transaction sequences used by the guardian to rebalance the vault. These transaction sequences are specified in the relevant submit call and checked and executed by the vault.

Why they matter

Operations are submitted to the vault using the submit function. The submit function gives guardians a lot of flexibility in how they want to execute operations:

• Any contract can be called and any valid calldata sequence can be an operation

• Each operation can refer to the return values of prior operations and use them to modify calldata using the built-in input/output chaining functionality

• Operations can be read-only (used to read values and use them as input for other operations) or read-write (normal transaction type actions)

• Each operation requires the guardian to submit a Merkle proof proving that the operation complies with its associated hook

But not every calldata sequence is a valid operation. Vault operations are constrained onchain for each guardian. Each vault:

• Prevents any outgoing allowances for ERC20 tokens from being created as a result of an operation

• Restricts the types of operations and contracts that are called in those operations via a Merkle tree for each guardian

How to create operations

For efficiency reasons, operations are packed in bytes.

The simplest operations will only contain:

• A target contract

• Call data to call

• Signifier of whether the call is static isStaticCall

• A Merkle proof to verify that the operation is whitelisted for the active guardian

Most operations will also contain:

• A set of configurableHookOffsets to extract variables of interest. This could, for example, be used to constrain what pools on Uniswap the guardian is allowed to swap on

In some cases, operations may contain:

• A set of clipboards if outputs from prior operations should be used as inputs for this operation and spliced into the calldata

• callbackData if a handler was used, which signifies that an operation expects a callback

• A custom hook to support more sophisticated call validation logic

• A value if the chain's native token (e.g., ether) should be passed with the submission

Caveats

The Aera team has developed SDKs in various languages to facilitate the safe creation of operations so please get in touch if you are interested in exploring becoming a guardian further.