Merkle Trees

What is the Merkle Tree?

Some guardian actions could be harmful and could lead to lost or frozen funds:

• Withdrawing a position to an address controlled by the guardian

• Swapping tokens without a slippage limit

• Taking too much risk (e.g., through a highly leveraged borrowing position)

• Sending assets to a protocol where they can't be retrieved

Each Aera vault maintains a whitelist of allowed operations which lets vaults reject operations that are not in this list.

Each entry in the Merkle tree supports a single operation type which includes:

• The contract that can be called

• The specific function called of the contract (specified via the sighash)

• The configurable or custom operation hook to use (if applicable), explained below

• Expected arguments returned by the pre-hook

During a submission, each operation is checked using the following steps:

• The guardian provides all the arguments needed to reconstruct the Merkle leaf when calling submit

• The pre-hook (provided by the guardian) is called with the calldata of the operation and returns a series of arguments selected for checking

• Since the contract, sighash and hooks are provided by the guardian and the selected arguments have been extracted by the pre-hook, we have everything we need to recreate the Merkle tree leaf. The Merkle tree leaf is then checked for inclusion using the provided Merkle proof

• Next, the operation is executed

• Any post-operation hook is executed (if it exists)

• If neither the pre-hook or post-hook reverts and the operation is in the Merkle tree, the operation is successful

If any operation fails during a submit, then the whole submit fails.

Why It Matters

Previous versions of Aera constrained operations merely by capturing the value of each position onchain. This was simple to reason about and worked well to prevent loss of value. However, the costs of invoking onchain oracles rise with each integration. Moreover, an oracle based approach doesn't support more fine-grained constraints.

A comprehensive whitelist would not only support specific contracts and functions that can be called but also restrictions on specific arguments. To store it onchain in each vault and refer to during each submission would be too prohibitive from a gas perspective.

Merkle trees provide an alternative, very storage-light way to maintain a large whitelist. Only a single Merkle root needs to be maintained in the vault but guardians now have to submit Merkle proofs alongside their operations. The proving process is straightforward to automate but it's important that the vault owner and the guardian both have access to the Merkle tree off chain.

How to use the Merkle Tree

The Aera team has built various tools to help with the construction of Merkle trees. Please reach out if you would like help.

Caveats

Note that the Merkle tree that is approved for a guardian can radically impact the trust model of the vault. Aera protects assets against guardians only to the extent that guardians are correctly constrained via Merkle trees. Not doing so can be catastrophic in the event that a guardian is compromised.