> For the complete documentation index, see [llms.txt](https://docs.aera.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aera.finance/operations-and-submit.md).

# 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.