Components & Logic

This section provides a simplified overview of the components, their functions within the Autopilot system, and a summary of the rebalance logic to help users achieve a basic understanding of the Autopilot system.

For a comprehensive breakdown of the system, its components, and functionality, please refer to the Developer docs.

System Components

Autopilot, when viewed as a system and not as a product or concept, is comprised of multiple components that as a whole fulfill the purpose of continuously rebalancing assets from an Autopool into the destinations with the best risk/return profile.

Schematic overview with highlighted asset flow

Autopool

Modular Option Set

Autopools are the system component which the user interacts with directly by depositing and withdrawing the base asset, the Autopool returning the depositor a receipt token. Autopools use the ERC-4626 standard and represents a fixed set of destinations (pools and DEXs) to which assets may be deployed to.

Stats System

Providing Data

The Stats System is responsible for making various signals available on-chain and keeping the destination data up-to-date. These signals are then stored and processed by “calculators” that are kept up to date through a keeper network. Other system components rely on the data to get an accurate picture of the destination (e.g. trading fees).

Solver

Finding the Solution

Simply put, the Solver is an off-chain component that listens to opportunities to rebalance into higher yielding destinations and finds the path and timing for rebalances, which it proposes to the Strategy for validation. Inversely, it will also solve for and propose solutions to rebalance out of destinations that violate safety constraints. This is similar to how off-chain swap routing software (DEX aggregators) will find and split up trades between many pools to get the best price.

Strategy Contract

The Gatekeeper

The Strategy is a set of gatekeeping contracts responsible for determining if a given rebalance proposal meets its requirements and is in the best interest of an Autopool. Additionally, the Strategy will ensure that the immutable constraints are not violated.

---

Rebalance Logic

This explanation will highlight a few of the components and steps necessary to arrive at a valid rebalance solution.

The Data

Autopilot does not simply chase the highest yield, but processes a comprehensive set of data in order to attain long-term rather than short-term outperformance. The Stats System is collecting, storing and processing this data, for example:

• APR and it's different components:

  • ETH Staking Yield: ETH yield generated by Consensus and Execution Layer rewards

  • Fee APR: Yield generated from swap fees

  • Incentive APR: Additional rewards paid to liquidity providers

• Price return:

  • Exchange rate vs underlying ETH backing

• Rebalancing costs:

  • Gas fees

  • Slippage

  • Trading fees

The above factors are weighted in order to account for e.g. likelihood of APR stability. More detail on the different yield types and APR weights can be found here.

Solution and Constraints

Based on the data made available by the Stats System, the Solver proposes rebalance solutions to interchangeably convert assets and LP tokens, as well as LP token into other LP tokens. The rebalance solutions are proposed to the Strategy backing the Autopool. The Strategy verifies on-chain the validity of the proposal and adherence to immutable constraints, also by use of the Stats System's data. Among the strategy’s key features we have the following:

• Composite Return Metric - The Composite Return Metric is a score associated with destinations for liquidity within Autopools. This metric breaks down APRs into separate parts. As such, Autopilot has the flexibility of overweighting/underweighting different components for further optimization. A valid rebalance needs to observe an increase of this metric.

• Adaptive Rebalance Offset Period - The adaptive rebalance constraint is a gatekeeping condition for rebalances, which states that the expected return associated with a rebalance needs to be recouped over a given period. It is worth noting that this is a self-learning mechanism with a variable cost offset period that adapts to different market environments based on the observed yield volatility.

Lastly, the Strategy has a multitude of additional immutable constraints, such as the total slippage (i.e. total difference in the value of the in and out LP tokens), as well as lookback tests that validate an increase in net asset value (NAV) over time. Once fully validated by the Strategy, the rebalance proposal is executed.