We recently published two blog posts explaining how an Oracle Service is implemented using Autonolas. You can read those posts here and here.

In that example, we showed how Autonolas can be leveraged to make a decentralized, autonomous Oracle Service, but the potential of Autonolas Services doesn’t end there — far from it!

Today, we would like to discuss our current work towards building an Autonolas Asset Management Service. Such a service will allow users to delegate control of their funds and autonomously execute the most optimal investment strategy(ies) with them, according to the users’ preferences.

Our research into DAO treasury management in particular has shown that autonomous management could be of great help in putting a DAO’s assets to productive use. You can see the results of that research in this Twitter thread.

In this post we’ll also take a closer look at the technical details, particularly how the composable nature of the stack allows developers to build complex apps and services. Let’s dive in!

Autonolas Asset Manager Services: A Primer

As we’ve outlined in earlier posts, an Autonolas Agent Service is composed of a collection of agents, each managed by a different operator. The agents jointly implement the business logic of the service in such a way that they must reach consensus on the operations to be executed. The consensus mechanism ensures the agents agree on the state of the service at every point in time. Hence, as long as a certain threshold of legitimate agents is met inside the service, no collusion of malicious agents can provoke service failures or execute unwanted operations (e.g., rogue investment operations).

To understand the service, let us first consider what a regular user might do when they wish to invest funds into some liquidity pools. At a high-level, this operation can be divided into two tasks: firstly, deciding on an investment strategy (e.g., when to switch from one liquidity pool to another), and secondly, once a decision has been made, executing the actual operation. Similarly, the functionality of an Asset Manager Service can be split into these two domains of responsibility, as detailed next.

The first is a functionality that is in charge of identifying the investment strategy. This functionality can be as simple or as complex as we want. For example, it could consist of a full machine learning model which includes stages such as scraping the appropriate data sources, training and cross-validating the model, which outputs the optimal predictions (according to that model). Note that we are not expecting this part of the service to execute any actual operations on any user’s wallet. It simply states what the optimal strategy is at any given time.

The second is a functionality that is in charge of executing the fund transfer operations, in order to implement the actual investment operations. This functionality is fed from the output produced by the previous component (i.e., the optimal investment strategy at the current time), and is in charge of building and submitting the appropriate transactions to execute the orders. At every decision step, a number of things could occur. The functionality might:

A. Do nothing, because the funds are currently distributed according to the optimal investment strategy received.

B. Do nothing, because the fees of executing the operations would exceed the benefits.

C. Execute a capital swap between liquidity pools to benefit from a more advantageous position (e.g., withdrawing from one liquidity pool and depositing into another that is more profitable, or swapping between assets).

Implementation Strategy 1: Two Services

Each of the two responsibilities discussed above have value on their own. A service, which we call APY Estimation Service, could be in charge of making investment strategies publicly available so that other users or services can make use of. They can also select from a number of different investment strategies and make decisions about which one(s) to follow at every moment.

Additionally, a Liquidity Rebalancing Service could feed from a pre-configured investment strategy, that might or might not be the one coming from the APY Estimation Service, and execute the operations on behalf of the users.

Recall from earlier posts that every Autonolas Service is composed of a number of agents that replicate an application that implements the business logic of the service. Semantically, this application can be broken down into independent stages, each of which achieves a particular task towards completing the objectives of the service. Then, each stage is implemented as a finite state machine (FSM), and, when composed appropriately, they give shape to the global FSM of the service — which is named FSM App.

Below we can see how the different stages (that is, FSMs) are connected in each of these two services.

Many of these stages have already been presented in our [post about the Oracle Service](TK Link), in this diagram only the highlighted ones are new, namely, the Build APY Model, the APY Estimation and the Liquidity Rebalancing stages. For the Liquidity Provision Service, we require:

• Agent Registration: implements the registration of agents, i.e., the commitment of the agents to participate in the service.
• Safe Deployment: deploys a Gnosis safe contract, which is a multisig smart contract wallet that requires a minimum number of signers from a signers group to approve a transaction before it can occur. Obviously, in this case, the group of signers are the agents that are part of the service. This assures that no single agent from the group can compromise the funds contained in it and means agents do not hold any meaningful funds themselves.
• Liquidity Rebalancing: Generates the transactions that will implement the prescribed investment strategy. All of the transactions can be bundled together using the Gnosis multisend contract.
• Transaction Submission: Submission and settlement of the transaction on the blockchain.
• Reset and Pause: Wait for a while and restart the “main loop” again.

Observe that the “main loop” of the service cycles through the stages:

Liquidity Rebalancing — Transaction Submission — Reset and Pause.

Indeed, this should be the usual life cycle of the service if no unexpected conditions occur.

For the APY Estimation Service, on the other hand, there are a couple of stages that are specific to the service:

• Build APY Model: Fetches the data from a number of data sources, builds and cross-validates the ML model.
• APY Estimation: Executes the estimation at the current time based on the trained model. Alternatively, it could include a stage where the model parameters are updated.

In this case, the main loop of the service will consist of looping through the two stages:

APY Estimation — Reset and Pause.

It is worth noting that the proposed architecture can, of course, be refined according to the service needs and the envisioning of reusability for some of the stages. For example, it would be perfectly legitimate to split the Build APY Model stage into two stages: one in charge of scraping and collecting the data, and the other one in charge of building the model itself.

Implementation Strategy 2: Single Service

As described above, these two functionalities can be regarded as independent Autonolas Services which bring value on their own. But they can also be merged into a single Service thanks to the composable nature of the service architecture.

This is a birds’ eye view of what the internals of an Autonolas Asset Management Service would look like when composed using the stages from the two services above:

Observe that now the main loop of the service cycles through four stages:

APY Estimation — Liquidity Rebalancing — Transaction Submission — Reset and Pause.

Indeed, this service looks pretty much the same as the Liquidity Provision Service–except that now, the investment strategies are decided internally by the service itself, rather than being provided externally.

Details on a Stage of the Asset Management Service

As can be seen, whether one wishes to implement these functionalities as a two-tiered service, or as a single service, there are three stages that are new (compared to the Autonolas Oracle Service), and therefore they will need to be implemented by the developer. Let’s take a look at what’s going on for one of them–the Liquidity Rebalancing stage.

Recall that each such stage implements an FSM which is replicated across all the agents of the service. In the case of this particular stage, the FSM looks something like the diagram below, which we have simplified slightly for illustration purposes:

The service executes a number of operations at each state, focused on the execution of the investment strategy. More in detail:

• The Strategy Evaluation state is the “controller state” within the Liquidity Rebalancing internal FSM: whenever the execution path reaches the Liquidity Rebalancing stage, it is the component that decides what to do next. In this state, the service determines whether the funds are invested in the current liquidity pool as prescribed by the investment strategy, or if they must be swapped. In the latter case, it is in charge of orchestrating the set of operations to execute the swap between liquidity pools. Typically, this is not a simple operation, and a number of multisend transactions are required (e.g., one multisend transaction to exit one pool and another multisend transaction to enter another pool). Therefore, this state first directs what the “next step” will be in this collection of transactions, and stores the necessary information to direct the FSM to the following appropriate state when it is revisited. The starting point of each of these operations is one of the states depicted below.
• The Enter Pool Transaction state is executed when the Strategy Evaluation state determines that it is advantageous to enter a certain pool. This state is in charge of generating the transactions required to achieve this operation. The Asset Management service works by having a “base” token (typically a stable coin like USDc or WETH) as a reference for any of the tokens that the service will be managing. That is, a user willing to use the service will need to provide “base” tokens, and the service output will also be in the form of “base” tokens. For this reason, whenever the service determines that some funds (in “base” tokens) need to be deposited into an (A,B)-liquidity pool, a total of 6 transactions need to be executed as follows:

As shown above, this collection of transactions are encoded as a multisend Gnosis contract. The result is that a number of AB-LP tokens are sent back to the user. Note that this state is only in charge of generating the transaction and the transaction hash–it is not responsible for submitting the transaction on-chain. The next stage (Transaction Submission) will take charge of that. The state Finish Enter Pool is simply a placeholder state, to mark the link between the Liquidity Rebalancing stage and the Transaction Submission stage.

• Similarly to the above, the Exit Pool Transaction state is in charge of creating the collection of transactions required to exit a pool of tokens A and B, upon providing the corresponding AB-LP tokens. The collection of transactions encoded in this stage can be seen in the diagram below:

• The Swap Back Transaction state is in charge of swapping back tokens A and B to the “base” tokens. The Strategy Evaluation state will orchestrate the sequence of operations towards this state whenever there is the need to exchange tokens to a more profitable pool that uses tokens different from A and B. The collections of transactions is summarized below:

Conclusion

As you can see, composability is at the heart of Autonolas apps and services. By allowing developers to make use of, reuse and recombine these various components in flexible structures, we can minimize duplication of effort. Common components can be reused where appropriate and additionally, their composable nature means that they can be nested inside of each other. This will allow for the creation of complex applications that we expect to unlock exponential growth in the wider ecosystem of decentralized services.

If you’ve found what we’re describing here exciting and want to incorporate this technology in your projects, we invite you to reach out to us on Discord and follow us on Twitter. There’s a wide range of potential use cases extending far beyond what we’ve been able to cover here, and we’d love to help you discover and build them, so please get in touch.

Additionally, if you’re a developer interested in building your own apps and services, you may be interest in our Autonolas Academy. The Academy is a self-paced learning experience, with the option, on completion, to apply for a more intensive, cohort-based Builder Track. The program is designed to teach you everything you need to know to develop using our framework. You can get started with those materials here.