Today we’re excited to be sharing a powerful proof-of-concept agent service, a fully autonomous oracle built with the Autonolas stack. You can see the oracle service [running live here.](https://oracle-frontend.autonolas.tech/) The potential demonstrated here is immense, and we hope you will find it just as exciting as we do.

![oraclenewstyling.gif](/uploads/oraclenewstyling_d8ea047053.gif)

#### What is Autonolas?

Autonolas provides a novel suite of tools for creating autonomous off-chain services. This stack will allow developers to build an entirely new type of crypto app that can take action on its own, communicate with non-blockchain data services and run continuously. This is done through the use of multi-agent systems and a composable architecture that emphasizes robustness, transparency and decentralization.

#### What We’re Introducing Today

To demonstrate just one possible approach to building with the Autonolas stack, we’ve created an oracle service as a way to help developers and users understand what’s possible. In this oracle example, we demonstrate how our stack makes use of multi-agent systems to come to consensus on and return an accurate estimation of a given price pair. That price pair is the old classic: **BTC/USD**.

Oracles are a vital part of blockchain infrastructure, connecting blockchains with off-chain data sources. Today, multiple stacks for oracles exist, but like much of current web3 infrastructure, they make many compromises. Autonolas’ oracles solve many of the most common challenges through the unique properties of our multi-agent system software stack.

#### Unleashing Autonolas Oracles: What it looks like in practice

![Oracle UI one](/uploads/Screenshot_2022_08_08_at_14_23_06_beea95d219.png)

Every 300 seconds (a configurable value), the agents making up the Oracle collect price data from 4 sources (another configurable value): CoinGecko, FTX, Binance and Coinbase. Each agent retrieves price data from a single source.

![Oracle UI two](/uploads/Screenshot_2022_08_08_at_14_23_18_eac9b4dc89.png)

Once the prices have been retrieved, the agents share their observations with each other….

![Oracle UI Three](/uploads/Screenshot_2022_08_08_at_14_23_31_b74c5de601.png)

…who then each use the observed prices to compute an aggregate price according to some pre-agreed upon measure (here, the median)…

![Oracle UI Four](/uploads/Oracle_UI_Four_6c167c6449.png)

…and then finally the agents share their aggregate price and come to a consensus on it.

![Oracle UI five](/uploads/Screenshot_2022_08_08_at_14_24_19_9a061a2b52.png)

This aggregate price is then sent via a transaction by one of the agents–the keeper agent–to a smart contract deployed on-chain.

#### How Are Autonolas Oracles Different?

Autonolas oracles are able to keep blockchain’s promise of decentralization but at lower cost by replicating, off-chain, the fault-tolerance guarantees and consensus mechanisms that power on-chain activity.

Only the necessary information observed by the oracle that is required to validate its correctness is recorded on-chain. This means we can reduce spending on transactions, provide robustness, guarantee decentralization and trust-minimization.

Thanks to a composable stack, the oracle can be extended to include more than just the aggregation of the prices from various centralized exchanges. For instance, developers could extend the oracle to report more complex statistics and use machine-learning.

#### Looking Forward

This oracle is a first demonstration of an Autonolas service, and only a tiny glimpse of what’s possible–for example, a service like the one we’re demonstrating here could one day be realized as what we’re calling a “Protocol Owned Service” (PoSe), [as outlined in this Twitter thread](https://twitter.com/autonolas/status/1504120575849074699?s=20&t=kZlm8mxNLpBcrptekTOXPg). We’re building a stack that will unleash full autonomy–spanning on-chain and off-chain–for protocols and DAOs across crypto. In the coming weeks and months, we will be revealing more of our broad-ranging ecosystem and tooling.

#### Getting Involved

Oracles are a critical primitive for a range of different decentralized applications. If you’re building something which could make use of our oracles — either directly or as a part of a larger off-chain service — reach out to [our ecosystem team](mailto:oaksprout@valory.xyz). We’ll be more than happy to support you in folding this exciting new technology into your application stack.

Alternatively, if you’re an individual developer interested in multi-agent systems, working with Python and taking your web3 development skills to the next level, you should check out our new self-guided video course, the Autonolas Academy. The course 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 your own apps and services using our framework. You can [get started with those materials here](https://www.autonolas.network/academy).

We hope you’ve found this simple demonstration informative and that your understanding of what’s possible has expanded. Our goal with Autonolas is to transform the way off-chain services and apps are built, empowering developers to take their ideas to the next level. If that resonates with you, we’d love to have you along for the ride.

#### Connect With Us

For all the latest updates on Autonolas, [follow us on Twitter](https://twitter.com/autonolas) and we also invite you to [join our Discord](https://discord.gg/RHY6eJ35ar) community–it’s going to be an exciting journey, and we can’t wait to see where it takes us.


A proof-of-concept agent service, running live today

Unleashing Autonolas Oracles

On March 31st of 2022, we wrote [this blog post](https://autonolas.network/posts/9) about an exciting new development in the Autonolas story, our Autonolas Oracle Service. You can see the service [running live here](https://oracle-frontend.autonolas.tech/). What we didn’t get into in that post were the technical details–how does it actually work under the hood? Today we’re happy to be able to share some of that information with you. Let’s dive in!

![oraclenewstyling.gif](/uploads/oraclenewstyling_d8ea047053.gif)
_The Oracle Service running live._

#### What Are the Key Components of an Autonolas Agent Service?

To explain the Oracle Service, first let’s look at an Autonolas Agent Service in general terms, and the three main ingredients that make them possible. Namely:

*   a collection of [**agents**](https://open-aea.docs.autonolas.tech/) (i.e., a multi-agent system) which form the core building block that implements the service itself,
*   a **consensus gadget**, which is the mechanism that facilitates the synchronization of the shared, global state between agents, and
*   an **on-chain protocol**, which ensures the crypto-economic security of the services operated with the Autonolas tech stack.

Today we’ll discuss how agents and the consensus gadget work together in the Oracle Service, and leave the details of the on-chain protocol for another time. For now, it is sufficient to know that the on-chain protocol facilitates a mechanism where developers can publicly publish and find reusable components to build and extend new Autonolas Services.

#### Agents and their Components

Agents are the software components in charge of executing the actual actions of the service, and they can interact with agents within the same service, with external agents, or with any other external service (e.g., a web server or a blockchain node). The basic packet of information that an agent can process is called a _message_. The particularities of each message depend on what protocol the message is related to (e.g., HTTP), and the Agent has communication capabilities to process protocols that are relevant for each service.

Agent knowledge is encapsulated in what we call _skills_. Each skill implements a self-contained capability that an agent can dynamically adopt in order to expand its effectiveness in different situations. Each skill can be designed to execute both reactive actions (i.e., responding to a particular received message) and proactive actions (i.e., taking the initiative to execute some action). Skills can be programmed from scratch, or reused from the component registry.

Each agent can include as many skills as they wish, but agents belonging to an Autonolas Service need to implement a special skill that has a mechanism to replicate and synchronize their internal state. This skill is in charge of interacting with the consensus gadget, which in our case is currently based on [Tendermint](https://arxiv.org/abs/1807.04938). The interaction between the skill and the consensus gadget is achieved through an interface known as the Application Blockchain Interface, or ABCI for short. You can read more about Tendermint and the ABCI [here](https://docs.tendermint.com/). In the case of the Oracle Service, we call this special skill the Oracle ABCI App.

The Oracle ABCI App is in charge of executing a number of actions within and on behalf of the service, including contacting the appropriate data source (through its API), aggregating the observed prices, and publishing the results on the blockchain. Additionally, the Oracle ABCI App is tasked with ensuring that all the agents have the same consistent, synchronized view of the global state of the service (e.g., what stage the service is currently executing). The Autonolas Stack provides a framework to easily develop such kinds of ABCI Apps, where the developer needs to focus on the business logic, and the framework is in charge of handling the replication of the global state.

#### The Role of the Oracle ABCI App in the Service

Every Autonolas Service can be thought of as a “virtual” [finite state machine](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) shared across the agents in the service. In the case of a complex service like the Oracle Service, the Autonolas Stack allows to split functionalities in different “stages” which are meaningful by themselves, so that they can be later composed. Namely, the Oracle ABCI App for the Oracle Service can be split into the following stages:

*   **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](https://github.com/safe-global/safe-contracts), 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.
*   **Oracle Deployment:** deployments of an oracle contract, a simple implementation of an oracle contract that was forked from Chainlink.
*   **Price Aggregation:** implements off-chain aggregation of observations by the agents.
*   **Transaction Submission:** Submission of the transaction of the aggregated observations to the blockchain.
*   **Reset and Pause:** wait for a while and restart again.

Each of these stages is actually implemented internally as an FSM, and the overall FSM implemented by the Oracle ABCI app is a composition of these FSMs. The diagram below shows how these stages are composed in order to create the overall FSM:

![oracle diagram 1.png](/uploads/oracle_diagram_1_9f2b8c80b6.png)

If we zoom into the “Price Aggregation” FSM, we can see how it is internally implemented:

![oracle diagram 2.png](/uploads/oracle_diagram_2_43c7654d83.png)

This FSM represents the Price Aggregation stage of the service, where the agents:

1.  Contact and share the value observed at a given data provider (Collect Observation state).
2.  Reach a consensus on the aggregated value of their observations (Estimate Consensus state). Note that agents can use any kind of arbitrarily complex estimation strategy, e.g. from a simple median to a full machine learning model, unlike the simpler calculations that are possible when limited to on-chain only.
3.  Finally, they reach consensus on the hash of the transaction to be sent on-chain (Transaction Hash state).

A special state (Finished state) is used as the linking point to the next stage of the service: Transaction Submission. You can also see a number of events that trigger the change between these states, which are launched when certain conditions are met (e.g, when there is no majority agreement on the value to be submitted on chain).

Again, this is just one of the stages implemented as an FSM, and as you can see, it has only four states. To give you an idea of the scale, the full Oracle ABCI app, composed of all the FSMs depicted above, contains about 25 states.

By composing FSMs as above, the Autonolas Stack enables the developer to create complex services by facilitating the reusability of FSMs already developed.

#### The Architecture of the Oracle Service

Putting all together, the architecture of the Oracle Service is summarized as follows:

![oracle diagram 3.png](/uploads/oracle_diagram_3_2f795cd872.png)

Each operator is in control of an agent which, in turn, implements the Oracle ABCI App. As described above, this app is in charge of (1) observing the values of a data provider, (2) aggregating the result observed by all the agents and (3) submitting the observed value on-chain. Moreover, the Oracle ABCI App ensures that all the agents have a consistent and synchronized view of the stages that the application is executing.

It is worth noting that each agent of the service is essentially executing the same piece of code, except that each individual agent is parameterized with appropriate values, including their public and private keys, and the particular data provider (e.g., CoinGecko) that they must observe.

#### Oracle Service Owned by Protocol Governance

A separate innovation of Autonolas is an on-chain protocol that owns off-chain productive services, such as an oracle, and derives profits from them. We call this primitive “Protocol-owned Services”, or [PoSe](https://twitter.com/autonolas/status/1504120575849074699?s=20&t=HlBinwSwEzuFwLSYvK37kQ) for short. Benefits of PoSe include:

*   Ownership through on-chain governance: the protocol can decide to spin an Oracle Service via a governance vote. A percentage of the fees obtained by the oracle accrue to the protocol.
*   Operation by independent agent operators: when the protocol acts as service owner, it will open bidding slots for agent operators (think of similar to node operators but with lighter workloads) to run the oracle and receive compensation for their work.
*   Unlimited application scope: this can be applied to virtually every application, although it is especially tailored at application stacks that are highly composable, such as Autonolas.

In the face of uncertain regulation, the PoSe primitive provides the level of decentralization necessary for the ecosystem to thrive long-term. For the first time, off-chain services–which today are mostly centrally operated–can be run in a decentralized manner.

#### Get Involved

We hope that you’ve enjoyed this very brief introduction to the technical details of the Autonolas Oracle Service. More details will be available soon, and we’re looking forward to being able to share those with you. In the meantime, if you’ve found what we’ve described here interesting, we invite you to [reach out to us on Discord](https://discord.gg/RHY6eJ35ar) and [follow us on Twitter](http://twitter.com/autonolas).

You may also want to consider signing up for the 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 your own apps and services using our framework. You can [get started with those materials here](https://www.autonolas.network/academy).


A look under the hood of the Autonolas Live Price Oracle

Autonolas Oracles—Technical Details

We recently published two blog posts explaining how an Oracle Service is implemented using Autonolas. You can read those posts [here](https://autonolas.network/posts/9) and [here](https://autonolas.network/posts/11).

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](https://twitter.com/autonolas/status/1521853164638523397?s=20&t=QvdDz9BQ-R_pwe4CIOHeYA).

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.

![ATM diagram 1.png](/uploads/ATM_diagram_1_ed76210b78.png)

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.

![ATM diagram 2](/uploads/ATM_diagram_2_7a10764ef7.png)

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](https://github.com/safe-global/safe-contracts), 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.

![ATM diagram 3](/uploads/ATM_diagram_3_f87778966a.png)

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:

![ATM diagram 4](/uploads/ATM_diagram_4_aa7696a967.png)

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](https://oracle-frontend.autonolas.tech/)), 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:

![ATM diagram 5](/uploads/ATM_diagram_5_a519a9f796.png)

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:

![ATM diagram 6](/uploads/ATM_diagram_6_ec4d91f0fe.png)

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:

![ATM diagram 7](/uploads/ATM_diagram_7_06a1e22fba.png)

*   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:

![ATM diagram 8](/uploads/ATM_diagram_8_83e36fbc95.png)

#### 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](https://discord.gg/RHY6eJ35ar) and [follow us on Twitter](http://twitter.com/autonolas). 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](mailto:bd@valory.xyz).

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](https://www.autonolas.network/academy).

A Detailed Overview

Autonomous Asset Management with Autonolas

Today we’re proud to announce another step forward in our vision for Autonolas-based services that are stable, robust, reliable and deployed to whichever chain you need them on. Without further ado–our autonomous oracle is now on Polygon!

The oracle began its life on the Ethereum testnet Ropsten, and now that we’ve had a few stable months under our belt, we’re ready to take the next step and move to a mainnet deployment. Today, we’re starting with Polygon, but this is only the beginning.

Deploying the oracle on Polygon is an incremental, but meaningful step towards the chain-agnostic future we envision for autonomous services built with [Open Autonomy](https://github.com/valory-xyz/open-autonomy). You can see the oracle [running live here](https://oracle-frontend.autonolas.tech/).

We also put together a more detailed blog post that explains how the oracle actually works: you can [read that here](https://autonolas.network/blog/11).

We’re also releasing two other updates today, one to Open AEA and the other to Open Autonomy. Making changes to, and maintaining the framework is a part of our commitment to growing and expanding the Autonolas ecosystem — these updates will be coming out regularly as we move forward.

To check out the updates to Open AEA, [head here](https://github.com/valory-xyz/open-aea/releases/tag/v1.11.0), and for Open Autonomy, [here](https://github.com/valory-xyz/open-autonomy/releases/tag/v0.1.1).

If you’re interested in partnering with us to integrate the oracle into your project, please [get in touch with us directly](mailto:bd@valory.xyz). Note, whilst the oracle is running on mainnet now, it has not undergone a security audit yet, hence we do not recommend integration without our support.

Interested in building your own autonomous apps and services? Head over to the [Quick Start](https://docs.autonolas.network/quick_start/) section of the documentation to get set up.

If you’d like to have some guidance, the Autonolas Academy has a new [self-paced video course](https://www.autonolas.network/academy) that’s a perfect place to begin.

As always we’d love to hear your feedback, or just have a chat about what we’re building here, so please follow us on [Twitter](https://twitter.com/autonolas) and [join the Discord](https://discord.gg/RHY6eJ35ar). Here’s to the autonomous future of crypto–and building it together!


The first Autonolas-based service to be deployed on a mainnet

Unleashing Autonolas Oracles, Part Two: Polygon

In previous posts, we discussed how to take advantage of the unique properties of our stack to build a number of autonomous services in the Autonolas network, including oracles and asset management services. You’ll recall that a key point in the process of building an Autonolas agent service is the division of business logic into discrete "stages" that represent generic, reusable functionalities, and that other services can take these stages on board for their own purposes. 

We believe that the reusability of service components in this fashion is the key to achieving an ever-growing ecosystem of autonomous services. These services will be both robust and require only minimal effort to build. In this post, we’ll extend these ideas by exploring the reusable properties of the Autonolas stack, and provide what we hope will be valuable insight into how it can be used to enhance the infrastructure of cross-chain bridges.

**A Brief Overview of Cross-Chain Bridges**

Following the approach presented in earlier posts, the first task in the design process of an Autonolas agent service is identifying and splitting the service’s business logic into easy-to-identify, high-level functionalities. In this case, rather than building an entire cross-chain bridge, our focus will be on some of the off-chain components of the bridge infrastructure. Let us first briefly recap some core concepts of bridges.

A cross-chain bridge is a service that enables transferring assets and information from a source blockchain _x_ to a destination blockchain _y_. In the case of transferring tokens, we end up in blockchain _y_ with a representation of an asset originally minted in blockchain _x_. Chains _x_ and _y_ might operate under entirely different, incompatible consensus mechanisms. It is precisely because of this potential protocol incompatibility that there may not be a method for the native transfer of tokens between the two chains.

![bridges diagram 01.png](/uploads/bridges_diagram_01_a0a59c8aea.png)

Bridges can be classified according to a number of distinguishing features. One such classification is based on the bridge’s trust model, either _trust-minimized_ or _trusted_.

- _Trusted_ bridges typically involve external parties that need to be trusted to carry out security-sensitive operations. Users give up control of their assets and transfer the assets they would like to bridge to the trusted party. 
For example, the trusted party accepts user’s A tokens on chain _x_ and issues the corresponding token instance of A on chain _y_. This requires that the trusted party have a pool of tokens on both chains. When the corresponding transactions are considered final on chain _x_, the trusted party makes tokens available on chain _y_. 
In case of probabilistic finality, one considers a transaction (almost) final after a given number of confirmations. The trust assumptions of this kind of bridge (i.e., that the bridge operator is not going to “run away” with the user's assets) basically relies on the reputation of the operator.

- In contrast, in _trust-minimized_ bridges, users do not have to place trust in a single entity or authority; instead the security is based on cryptographic properties that ensure its correctness. This type of bridge makes extensive usage of smart contract operations on each end of the bridge (i.e., on chains _x_ and _y_). As a result, the security is equivalent to that of the underlying chain with the weaker security, and no new trust assumptions are added. 

![bridges diagram 02.png](/uploads/bridges_diagram_02_3af647c75d.png)

We can also classify bridges at the level of operation design. There are three main approaches: _lock and mint_ (lock assets on the source chain and mint assets on the destination chain); _burn and mint_ (burn assets on the source chain and mint assets on the destination chain), and _atomic swaps_ (swap assets on the source chain for assets on the destination chain with another party). 

- In the case of lock and mint, what happens is that a number of token-instance-of-_A_-on-chain-_x_ are “blocked” on chain _x_ and the same number of token-instance-of-_A_-on-chain-_y_ are “generated” on chain _y_. How this blocking and generating processes occur depends on the type of bridge. This mechanism is achieved through smart contracts on each chain: a user willing to have a representation of their A-tokens on chain _y_ will first execute a contract call locking such tokens on chain _x_, and later, an off-chain process (such as a keeper) will monitor the interactions with that smart contract and will instruct the smart contract living on chain _y_ to mint (or transfer from a pool) the corresponding tokens on chain _y_ for the user. Parties involved are incentivized to operate correctly, and slash mechanisms can be put in place to report misbehavior or illegitimate reports.

- The case of _burn and mint_ is similar, with the exception that a number of token-instance-of-A-on-chain-x are burned and no longer available.
In the case of _atomic swaps_, a number _nA_ of token-instance-of-_A_-on-chain-_x_ are exchanged by a number _nB_ of token-instance-of-_A_-on-chain-_y_ in a manner similar to a token swap in a decentralized exchange. This is the protocol used by Hop Exchange, which we will be discussing in more detail below.

**Autonolas Services Inside the Bridge Infrastructure**

A bridge infrastructure consists of a number of different entities and components that work together, both on-chain and off-chain, to implement the bridge functionality. We will now consider two types of bridge design which are particularly well-suited to improvement by an Autonolas agent service. These architectures fall into the category of trust-minimized bridges that are externally verified, and/or operated. In such a bridge, a group of external validators verify the transactions and possibly provide liquidity. Two examples that we will be examining are [Celo Optics](https://docs.celo.org/celo-codebase/protocol/optics) and [Hop Exchange](https://hop.exchange/). What follows is a brief outline of their architectures, and some insights into how they could benefit from an Autonolas agent service implementing one of their components.

![bridges diagram 03.png](/uploads/bridges_diagram_03_9c3acf4f28.png)

**Use Case 1: Decentralizing the Updater in Optics**

Celo Optics Bridge is a new bridge design without header verification which aims to provide cheap cross-chain communication. In order to bridge information from chain _x_ to chain _y_, a _Home contract_ on chain _x_ receives and aggregates such transactions. Then, an off-chain actor called _Updater_ periodically observes the chain _x_ Home contract, signs attestations to new batches of transactions, and publishes the signed attestation to the Home contract. Another external off-chain component called _Relayer_ polls chain _x_ for new signed updates, and forwards them to chain _y_. Also, a number of _Watchers_ periodically monitor both chains and report any Updater misbehavior (e.g. signing illegitimate transactions). If an Updater is found guilty of misbehavior, a slashing mechanism punishes their assets on chain _x_. We refer [here](https://docs.celo.org/celo-codebase/protocol/optics) for the complete details. 

Clearly, the untrusted Updater is a candidate to be built as an Autonolas agent service, since this will reduce the amount of trust required in that party. Here we depict the main stages of an Updater agent service built in Autonolas. We’d like to point out that several of these stages have already been discussed and reused in previous services presented in this blog (e.g., [here](https://www.autonolas.network/blog/12) and [here](https://www.autonolas.network/blog/9)), but we include them here for completeness:

- **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 for it to be valid. 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. This is a requirement to send transactions to the destination chain.
- **Monitor and Sign:** Agents periodically monitor the Home contract waiting to collect an appropriate batch of transactions. Once this happens, the agents sign the batch data structure (which is a Merkle tree) using, for example, a k-of-n threshold signature scheme with distributed key generation. The result of this stage is that the transaction is ready to be submitted on the destination chain. That is, agents agree on what is the contract call to be executed on the destination chain.
- **Transaction submission:** Actual submission of the transactions of the agreed operation to be executed on the destination blockchain.
- **Reset and Pause:** Wait for a while and restart the main cycle of the service again.

![bridges diagram 04.png](/uploads/bridges_diagram_04_6aa244fb95.png)

Following our line when discussing complex services in previous posts, let us focus on the newly introduced stage in this service, i.e., the Monitor and Sign stage. This stage can be encoded as a finite-state machine which looks as follows:

![bridges diagram 05.png](/uploads/bridges_diagram_05_0acde5118a.png)

Now, we will take a look at the conceptual execution flow of this stage through its constituent states and events:
1. The agents in the service periodically observe either blockchain looking for a batch of transactions waiting to be signed.
2. Once a suitable batch is detected, agents distributedly sign the transaction. We assume that agents are using a threshold signature scheme to sign the data structure containing the batch of transactions, therefore, no single agent is in possession of the signing key of the service.
3. Once there is consensus on the operation to be executed (i.e., the valid threshold signature), the agents agree on the transaction hash of the operation.
As occurred in the case of the Oracle Service, there is a special “dummy” state (Finished state), which is used to mark where the next stage (Transaction Submission) is going to be connected. Recall again that the output of this stage does **not** send any transaction to the blockchain: it produces the transaction hash to be sent to the Transaction Submission stage. Also, you can see a number of events in the finite-state machine indicating certain error conditions (e.g., no consensus on the agents of the service). 

**Use Case 2: Decentralizing Bonders in Hop**

The Hop exchange protocol allows bridging of tokens almost instantly between either layer-2 (Polygon, xDai, Arbitrum and Optimism) rollup sidechains, or a layer-2 and their layer-1 network, e.g. Ethereum. A rollup is an off-chain mechanism that allows for grouping of transactions taking place outside the blockchain into batches, providing a mechanism to guarantee the validity of these transactions on-chain. A smart contract is in charge of receiving a summary of these updates and the proofs of validity of what has been executed off-chain.

The Hop protocol achieves its high speed when bridging tokens through the use of a _Bonder_, which is a market maker that provides the liquidity at the destination chain in the exchange upfront, in return for a small fee. This credit is extended by the Bonder in the form of hTokens, which are then swapped for their native token through an automated market maker.

The Bonder is usually a single, external party that verifies and provides liquidity upfront. But, as identified in the [Hop whitepaper](https://hop.exchange/whitepaper.pdf), relying on a single Bonder to be available and to have enough liquidity at all times might be overly optimistic. Moreover, if the Bonder is unavailable, transfers will propagate throughout the bridge at a much lower rate, diminishing the main value-add provided by this bridge design.

One option could be to substitute the single Bonder for a network of Bonders. Substituting the Bonder with an Autonolas agent service helps to create a more reliable system, while also removing the challenges that naturally emerge when we consider a simple network of Bonders (e.g., choosing which Bonder is rewarded for a particular transfer without clogging the service). 

A simplified sketch of the stages of an FSM App implementing such a component looks like this:

![bridges diagram 06 v2.png](/uploads/bridges_diagram_06_v2_3e3ff7b596.png)

Observe that this agent service bears a lot of resemblance to the agent service used in the example service we described for Celo Optics. Concretely, the stage that differs is the “Monitor and Provide Liquidity” stage. A simplified way of defining the finite-state machine for this stage is as follows.

![bridges diagram 07.png](/uploads/bridges_diagram_07_adf94ecc53.png)


1. The agents in the service periodically observe the potential source blockchain looking for contract calls indicating that a bridge of assets is requested.
2. After finishing the previous stage, the agents reach a consensus on the concrete operation that needs to be executed (and in what destination chain). It could be the case that no operation needs to be executed (i.e., no asset bridge was requested in the previous observation interval, or the transaction was finally deemed invalid). This situation is marked through the event NO_ACTION. The service will indefinitely loop between these two states if there is no contract call to bridge assets.
3. Once there is consensus on the operation to be executed (i.e., there is valid, pending token transfer operation), the agents agree on the transaction hash of the operation. This will be submitted by the next stage, i.e., Transaction submission, and the funds will be released in the appropriate chain for the corresponding user.

Note that given the fast bridge operation requirement in this case, the observation interval must be sufficiently short to meet the system requirements. 

Also, note that in the Autonolas agent services proposed above (for the case of Celo Optics and Hop) no stage related to the deployment of smart contracts on the respective chains are required. As expected, this is the case, because unlike the [Autonolas Oracle](https://oracle.autonolas.network/), these services implement only one part of the overall service infrastructure.

**Conclusion**

If you have been following our series of technical posts ([1](https://www.autonolas.network/blog/9), [2](https://www.autonolas.network/blog/12)), you will immediately notice how the effort required to develop such complex components within a bridge service is greatly reduced thanks to the composable nature of the Autonolas Agent Services: Most of development  efforts will be focused precisely on the few specific stages that need to be adapted for the business logic needs of the particular off-chain component(s).

**Get Involved**

While there is not yet an implementation of an Autonolas Bridge in the wild, we hope that this post has given you confidence in the feasibility of building one. We have highlighted the importance of the composable nature of services in the Autonolas Stack, which allows us to build services that are fully decentralized, secure, robust, trust-minimized and crypto-economically secured on-chain. 

If you are interested in learning to build your own autonomous services, we’d like to point you to the latest version of our Academy. The refreshed Academy now includes a self-guided course you can follow at your own pace. These materials will provide you with the tools required to start building your own off-chain services. 

Additionally, for those of you who are brave enough, we will be offering a mentorship course, the Builder Track, for developers who have successfully completed the self-guided portion of the Academy.

[You can learn more about the Academy, and get started with the materials here.](https://www.autonolas.network/academy)

In any case, you are always welcome to [reach out to us on Discord ](https://discord.gg/RHY6eJ35ar) if you need community support when building your services, and we also invite you to [follow us on Twitter](http://twitter.com/autonolas) to stay up to date on all our latest developments.




A detailed look at an Autonolas-based approach

Decentralizing Cross-Chain Bridges with Autonomous Services

A Technical Overview 

Maintaining and Resetting Consensus in Autonomous Services

Today, we're excited to introduce the Autonolas Machine Learning APY Oracle, a powerful tool for predicting the future APY of Uniswap V2 Liquidity Pools.

The Autonolas Machine Learning APY Oracle pulls subgraph data from various Uniswap V2 liquidity pools and uses a sophisticated machine learning algorithm to make predictions about their future APY. These predictions are then broadcast as a feed on the blockchain, allowing anyone to consume and make use of the data.

Not only does the Autonolas Machine Learning APY Oracle demonstrate  the capabilities of autonomous services, it also illustrates the complexity that these systems can handle. An autonomous service is a type of software architecture where multiple independent agents work together to create the software's functionality. For an introduction to  autonomous services and how they work, be sure to [check out this article](https://www.autonolas.network/education-articles/2).

You can view the [repo for the Autonolas Machine Learning APY Oracle here](https://github.com/valory-xyz/apy-oracle), and see [it in action here](https://oracle.autonolas.network/). 

If you would like us to add an APY feed for a specific liquidity pool, please don't hesitate to reach out


	LEARN EDUCATION WHITEPAPER	BUILD DOCS ACADEMY COMMISSION US PROTOCOL REGISTRY	ABOUT BLOG PRESS TWITTER DISCORD GITHUB PRIVACY POLICY COOKIES POLICY
COPYRIGHT 2023VALORY AG	JOIN CAREERS DISCORD	EXPERIENCE ALTER ORBIS

Build your own decentralized off-chain infrastructure.

Keep up with Autonolas