How can you do transactions in the future on blockchains? How can you create transactions like limit orders or stop losses for trading to manage risk and get the best prices? How can you set up a smart contract that can create its own transactions, without the need for a human to initiate them?

As I’m sure you’ve guessed, Autonomy Network is the answer 😉.

The protocol lets you stop loss out of being an LP to avoid impermanent loss, move your liquidity to a better yield farm as soon as yield rates change, all while being offline or asleep. It even enables objects like NFTs to take a life of their own and transfer themselves around Web3, send messages, and make conditional transactions.

Let’s take a look at how we’re making this possible.

Autonomy itself is essentially an on-chain registry that:

1. Allows people to register Requests for things they want to happen in the future

2. Is monitored by a decentralized network of bots waiting to execute Requests when their corresponding conditions become true

3. Organizes the network of bots with a Proof of Stake algorithm that determines which bot is able to execute Requests at a given time

That’s a little abstract, so here’s the logic flow for an example limit order on Uniswap using Autonomy. Say that you want to buy ETH with DAI at $420.69:

Logic flow for single Request

The logic is split into 1. and 2. — each number represents a separate transaction. 2a. and 2b. occur in the same transaction together

1. The user registers a Request that says “I want to swap DAI to ETH on Uniswap, if and only if, the price of ETH is less than or equal to $420.69, here are all the details someone needs to do that for me”

*The price of ETH goes below $420.69*

2a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above trade can occur. The bot executes the trade by calling Autonomy’s Registry

2b. The DAI is transferred from the user to the Uniswap contract

2c. The trade occurs and the ETH is sent to the user

2a. 2b. and 2c. all happen in the same transaction, and is made by an executing bot. 1. is the only transaction that the user makes directly. If the price of ETH had never gone below $420.69, then 2. would never have happened (even if someone had tried to execute it, it would be guaranteed to revert).

There are 2 main smart contracts that make up Autonomy — the Registry and the StakeManager.

The Registry is directly involved in the above example, because when a user makes a new Request, they register that in the Registry. When a Request is executed, the executor calls the Registry to execute it.

The StakeManager is indirectly involved in the above example because every time someone attempts to execute a Request via the Registry, the Registry checks with the StakeManager who, at that current time, is allowed to execute Requests. The StakeManager uses a lightweight Proof of Stake algorithm to determine who can execute Requests at a given time. It’s similar to other PoS systems, where a single staker is chosen from a pool proportional to the amount of AUTO they staked, except instead of being able to mine a block, they have the exclusive right to execute Requests for a 100 block period.

Autonomy is an incentivized network, from the bots to the token, AUTO.

For instance, in the example above with a simple limit order, there are 2 transactions: tx1 (registration of the Request) and tx2 (execution of the Request). The user directly sends and pays for tx1, and the executing bot directly sends and pays for tx2. Obviously, the bot doesn’t do this for free — when a Request is executed, the user has to pay for the execution of that Request plus a small fee. The total cost of tx2 is therefore the gas cost of tx2 + fee. This fee depends on whether you pay with ETH or AUTO. If paying with ETH, the fee is an extra 30% of the execution cost of tx2. If paying with AUTO, the fee is an extra 10% of the execution cost of tx2.

If paying in ETH, enough ETH to pay for the total cost of tx2 needs to get sent along with tx1 (so that the user only has to make a single transaction directly in total). The transaction cost of tx2 depends on the gas cost and the gas price. The gas cost can be estimated, but the gas price is hard to predict since it’s in the future, and gas prices on Ethereum are notorious for being volatile and unpredictable. Therefore enough ETH needs to be sent in tx1 to pay for the worst-acceptable-case for the total cost of tx2. If the actual total cost of tx2 is less than this worst-possible-case, then any excess ETH is sent back to the user. For example if the user sent 0.01 ETH in tx1 to pay for tx2, and tx2 cost the executing bot 0.002 ETH in regular Ethereum transaction fees, then 0.002 * 1.3 = 0.0026 ETH would be sent to the bot in tx2, and the remaining 0.01-0.0026 = 0.0074 ETH would be sent back to the user in tx2. In reality, the UI of the integrating dapp would abstract away all this information.

If paying in AUTO, nothing needs to be paid upfront. This is because AUTO tokens can be transferred from the user to the Registry during tx2 to pay for its execution. This allows users to be able to keep their funds in their account and only pay for Requests that are actually executed. It also allows for tx2 to be paid for without the user ever having to manually buy AUTO, because the trading contract that’s used can buy AUTO on behalf of the user to pay for tx2 within tx2 itself. For example if the user is doing a limit order, then the trading contract can take some of the output tokens and sell them for AUTO in order to pay for the execution of the trade.

The AUTO token isn’t a “gOveRNanCe tOKeN” that has no actual use case. AUTO is a utility token that is used to stake on the network and pay for executions of Requests. From the moment that the token is live, it’ll be able to be used for both those things. In the future, it will also be able to be used for governance. Therefore, there are 2 inherent sources of economic demand for AUTO:

• getting cheaper fees as a user

• staking and therefore the ability to collect fees by executing requests

Starting to make sense?

Awesome!

So what else can we do with this? How can we make a contract come alive?

Consider a situation where you want to automate multiple actions with different conditions, or you want to make a contract able to make transactions on its own an unlimited amount of times. For example, say you want to create a contract that mints an NFT and sends it to you on your birthday every year that contains your name, the year, and a “Happy birthday!” message. Or you want to create a contract that holds some assets and lends them out to a lending platform, and withdraws and deposits those assets on a different platform once the yield becomes better elsewhere, and to have that happen continuously. All with only a single initiating transaction from the user.

In the latter example of automatically moving funds of a treasury between lending platforms based on changing yields, let’s assume the funds are currently on Compound, and they would move to AAVE when AAVE has a better yield:

Logic flow for recursive Request

1. The user registers a Request that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

*The yield of AAVE becomes better than Compound*

2a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from Compound to AAVE

2b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

*The yield of AAVE becomes better than Compound*

3a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from AAVE to Compound

3b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

… [this keeps occurring and the funds keep moving many times]…

101a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from AAVE to Compound

101b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

I think you get the idea. There’s no limit to how many times this can happen, as long as the user sent enough ETH or AUTO (which users get a discount on fees with 😉) to fuel all the future transactions, since the executing bot needs to be repaid for the gas they spend + a small fee. The fee is an extra 30% if paying in ETH and an extra 10% if paying in AUTO. Paying in AUTO also has the added benefit of not needing to be pre-sent, because the Autonomy Registry can transfer tokens on behalf of a user, but ETH doesn’t have a transferFrom function sadly. Paying in AUTO therefore allows you to keep your AUTO in your user account and only have it spent when a Request is actually executed.

In this way, after only a single transaction to initiate things by a human, a contract can make new Requests for itself at the end of old Requests with arbitrary conditions ad infinitum.

A contract can make transactions on its own*.*

A contract can make decisions about its future*.*

A contract can become alive.

In principle, because it can act independently, there’s now nothing technical stopping a smart contract from having legal rights, legally owning property, or becoming a citizen in its own right with its own identity. In the (distant) future when AI can be run directly on a blockchain, it opens up the slightly scary/dystopian possibility for an AI to run rampant because it doesn’t need humans to power itself, it can fuel its future transactions by trading or arbitraging on-chain, and can never be turned off because it’s on a blockchain… Hopefully our future AI overlords remember who helped give them autonomy 😬

This is an incredibly powerful new piece of infrastructure for the blockchain world. Autonomy is a new money lego piece to build things with that were never possible before. It grows the pie. It enables web3 to have the same or better features that mainstream users expect and is therefore critical to bringing blockchain to the mainstream while retaining all the fundamental values of crypto like full decentralization.

Go to autonomynetwork.io to learn more. Join our community on Discord and Telegram, and follow us on Twitter to stay up to date. See you there! 😁

How can you do transactions in the future on blockchains? How can you create transactions like limit orders or stop losses for trading to manage risk and get the best prices? How can you set up a smart contract that can create its own transactions, without the need for a human to initiate them?

As I’m sure you’ve guessed, Autonomy Network is the answer 😉.

The protocol lets you stop loss out of being an LP to avoid impermanent loss, move your liquidity to a better yield farm as soon as yield rates change, all while being offline or asleep. It even enables objects like NFTs to take a life of their own and transfer themselves around Web3, send messages, and make conditional transactions.

Let’s take a look at how we’re making this possible.

Autonomy itself is essentially an on-chain registry that:

1. Allows people to register Requests for things they want to happen in the future

2. Is monitored by a decentralized network of bots waiting to execute Requests when their corresponding conditions become true

3. Organizes the network of bots with a Proof of Stake algorithm that determines which bot is able to execute Requests at a given time

That’s a little abstract, so here’s the logic flow for an example limit order on Uniswap using Autonomy. Say that you want to buy ETH with DAI at $420.69:

Logic flow for single Request

The logic is split into 1. and 2. — each number represents a separate transaction. 2a. and 2b. occur in the same transaction together

1. The user registers a Request that says “I want to swap DAI to ETH on Uniswap, if and only if, the price of ETH is less than or equal to $420.69, here are all the details someone needs to do that for me”

*The price of ETH goes below $420.69*

2a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above trade can occur. The bot executes the trade by calling Autonomy’s Registry

2b. The DAI is transferred from the user to the Uniswap contract

2c. The trade occurs and the ETH is sent to the user

2a. 2b. and 2c. all happen in the same transaction, and is made by an executing bot. 1. is the only transaction that the user makes directly. If the price of ETH had never gone below $420.69, then 2. would never have happened (even if someone had tried to execute it, it would be guaranteed to revert).

There are 2 main smart contracts that make up Autonomy — the Registry and the StakeManager.

The Registry is directly involved in the above example, because when a user makes a new Request, they register that in the Registry. When a Request is executed, the executor calls the Registry to execute it.

The StakeManager is indirectly involved in the above example because every time someone attempts to execute a Request via the Registry, the Registry checks with the StakeManager who, at that current time, is allowed to execute Requests. The StakeManager uses a lightweight Proof of Stake algorithm to determine who can execute Requests at a given time. It’s similar to other PoS systems, where a single staker is chosen from a pool proportional to the amount of AUTO they staked, except instead of being able to mine a block, they have the exclusive right to execute Requests for a 100 block period.

Autonomy is an incentivized network, from the bots to the token, AUTO.

For instance, in the example above with a simple limit order, there are 2 transactions: tx1 (registration of the Request) and tx2 (execution of the Request). The user directly sends and pays for tx1, and the executing bot directly sends and pays for tx2. Obviously, the bot doesn’t do this for free — when a Request is executed, the user has to pay for the execution of that Request plus a small fee. The total cost of tx2 is therefore the gas cost of tx2 + fee. This fee depends on whether you pay with ETH or AUTO. If paying with ETH, the fee is an extra 30% of the execution cost of tx2. If paying with AUTO, the fee is an extra 10% of the execution cost of tx2.

If paying in ETH, enough ETH to pay for the total cost of tx2 needs to get sent along with tx1 (so that the user only has to make a single transaction directly in total). The transaction cost of tx2 depends on the gas cost and the gas price. The gas cost can be estimated, but the gas price is hard to predict since it’s in the future, and gas prices on Ethereum are notorious for being volatile and unpredictable. Therefore enough ETH needs to be sent in tx1 to pay for the worst-acceptable-case for the total cost of tx2. If the actual total cost of tx2 is less than this worst-possible-case, then any excess ETH is sent back to the user. For example if the user sent 0.01 ETH in tx1 to pay for tx2, and tx2 cost the executing bot 0.002 ETH in regular Ethereum transaction fees, then 0.002 * 1.3 = 0.0026 ETH would be sent to the bot in tx2, and the remaining 0.01-0.0026 = 0.0074 ETH would be sent back to the user in tx2. In reality, the UI of the integrating dapp would abstract away all this information.

If paying in AUTO, nothing needs to be paid upfront. This is because AUTO tokens can be transferred from the user to the Registry during tx2 to pay for its execution. This allows users to be able to keep their funds in their account and only pay for Requests that are actually executed. It also allows for tx2 to be paid for without the user ever having to manually buy AUTO, because the trading contract that’s used can buy AUTO on behalf of the user to pay for tx2 within tx2 itself. For example if the user is doing a limit order, then the trading contract can take some of the output tokens and sell them for AUTO in order to pay for the execution of the trade.

The AUTO token isn’t a “gOveRNanCe tOKeN” that has no actual use case. AUTO is a utility token that is used to stake on the network and pay for executions of Requests. From the moment that the token is live, it’ll be able to be used for both those things. In the future, it will also be able to be used for governance. Therefore, there are 2 inherent sources of economic demand for AUTO:

• getting cheaper fees as a user

• staking and therefore the ability to collect fees by executing requests

Starting to make sense?

Awesome!

So what else can we do with this? How can we make a contract come alive?

Consider a situation where you want to automate multiple actions with different conditions, or you want to make a contract able to make transactions on its own an unlimited amount of times. For example, say you want to create a contract that mints an NFT and sends it to you on your birthday every year that contains your name, the year, and a “Happy birthday!” message. Or you want to create a contract that holds some assets and lends them out to a lending platform, and withdraws and deposits those assets on a different platform once the yield becomes better elsewhere, and to have that happen continuously. All with only a single initiating transaction from the user.

In the latter example of automatically moving funds of a treasury between lending platforms based on changing yields, let’s assume the funds are currently on Compound, and they would move to AAVE when AAVE has a better yield:

Logic flow for recursive Request

1. The user registers a Request that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

*The yield of AAVE becomes better than Compound*

2a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from Compound to AAVE

2b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

*The yield of AAVE becomes better than Compound*

3a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from AAVE to Compound

3b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

… [this keeps occurring and the funds keep moving many times]…

101a. The bot who is authorized to execute Requests at that time is monitoring all pending Requests and sees that the above Request can be executed. The bot executes the trade by calling Autonomy’s Registry, moving the funds from AAVE to Compound

101b. A new Request is registered in Autonomy’s Registry that says “IF the best platform to lend at changes, move my assets from where they are to the new best platform, AND THEN create a new Request that does the same thing”

I think you get the idea. There’s no limit to how many times this can happen, as long as the user sent enough ETH or AUTO (which users get a discount on fees with 😉) to fuel all the future transactions, since the executing bot needs to be repaid for the gas they spend + a small fee. The fee is an extra 30% if paying in ETH and an extra 10% if paying in AUTO. Paying in AUTO also has the added benefit of not needing to be pre-sent, because the Autonomy Registry can transfer tokens on behalf of a user, but ETH doesn’t have a transferFrom function sadly. Paying in AUTO therefore allows you to keep your AUTO in your user account and only have it spent when a Request is actually executed.

In this way, after only a single transaction to initiate things by a human, a contract can make new Requests for itself at the end of old Requests with arbitrary conditions ad infinitum.

A contract can make transactions on its own*.*

A contract can make decisions about its future*.*

A contract can become alive.

In principle, because it can act independently, there’s now nothing technical stopping a smart contract from having legal rights, legally owning property, or becoming a citizen in its own right with its own identity. In the (distant) future when AI can be run directly on a blockchain, it opens up the slightly scary/dystopian possibility for an AI to run rampant because it doesn’t need humans to power itself, it can fuel its future transactions by trading or arbitraging on-chain, and can never be turned off because it’s on a blockchain… Hopefully our future AI overlords remember who helped give them autonomy 😬

This is an incredibly powerful new piece of infrastructure for the blockchain world. Autonomy is a new money lego piece to build things with that were never possible before. It grows the pie. It enables web3 to have the same or better features that mainstream users expect and is therefore critical to bringing blockchain to the mainstream while retaining all the fundamental values of crypto like full decentralization.

Go to autonomynetwork.io to learn more. Join our community on Discord and Telegram, and follow us on Twitter to stay up to date. See you there! 😁