Introducing Autonomous Agents

in #obyte2 years ago (edited)

Smart contracts have existed on the Obyte platform since day one.

Modeled after traditional contracts, smart contracts allow someone to have rights in the agreement based on certain conditions. An example is having the right to take all the money locked on the contract after a specific condition is met, after another payment has been made, after goods or a service has been delivered, or after a team you placed a bet on has won.

Unlike traditional contracts, smart contracts are enforced by all nodes on the network who check the conditions of the contract and add a transaction to the ledger only if all conditions are met. It is a decentralized model completely independent from any government’s legal system.

The smart contracts enabled a number of applications and use cases such as:

conditional payments;
P2P prediction markets;
P2P insurance.

All of these applications are built around P2P interactions — the voluntary relationships between two free equals.

However, there is another class of applications that are not covered by smart contracts: applications where an autonomous central counterparty interacts with multiple users and does so strictly according to the rules that are public, known in advance, and can never be changed.

That’s what Autonomous Agents are.

An Autonomous Agent (AA) acts according to a program associated with it. Its behavior is similar to that of a vending machine that receives coins and data entered on a keypad and in response, releases a cup of coffee, plays a song, or does whatever it was programmed to do.


What’s different from a vending machine, though, is that while a vending machine has an owner who can reprogram it or shut it down, an autonomous agent is truly autonomous. Its program is stored on the Obyte distributed ledger upon creation and can never be changed or removed.

To the end-user, interacting with an Autonomous Agent works just like a vending machine. The user simply sends money from their Obyte wallet to the AA’s address (which looks just like a regular Obyte address) and can optionally include any extra data related to the desired action. The AA then takes this transaction as a request and processes it according to its own program. In response the AA can perform many tasks such as sending another token back to the user, sending data to the ledger, sending coins to a different user or even sending coins and data to another AA.

From an application developer’s perspective, an Autonomous Agent is a program that is written in a simple language tailored to creation of AAs on the distributed ledger. The source code of an AA needs to be deployed on the ledger and once deployed, it is available for everybody to use. The source code becomes open once deployed and everybody is able to see what the AA will do.

Unlike smart contracts, which are best suited to pairwise P2P relationships, Autonomous Agents can interact with multiple users, are always online and on-chain, and always ready to accept requests and provide services.


This single fact vastly increases the design space available to developers. Autonomous Agents can be programmed to do almost anything a human service provider could do but:

in a fully automated way;
strictly according to a program that is known in advance and can never be changed. Unlike humans, AAs can be trusted to always do what they are supposed to do.

Some applications that can be built based on AAs:

tradable shares in prediction markets;
futures contracts;
algorithmic stable coins;
synthetic assets;
other derivatives;
collateralized lending;
margin trading;
decentralized exchange;
decentralized oracles;
payment channels;
game economies;
market makers;
automatic management of investment portfolios;

…and a lot of other applications we haven’t even thought about, and not just in the area of decentralized finance.

And Autonomous Agents can of course leverage the unique features that Obyte has, such as protocol-level tokens, easy access to data feeds posted by oracles, and attestations that enrich user identities.


Obyte smart contracts are famous for being human-readable. This allows the user to clearly see what the conditions of the agreement are without having to decipher complex terminology.

How about Autonomous Agents? They are written in a computer language. Although simple and openly published on the ledger, it is still computer code, and you can’t expect non-developers to understand it.

In line with our principles of transparency and openness to the widest possible audience, we found another solution. When a user tries to send money from the Obyte wallet, the wallet pre-calculates the expected effect of the user’s transaction, and displays this information to the user.


The user doesn’t need to read the code, doesn’t need to determine which of the many code branches will be taken, he sees what he is interested in — the result.

We are not aware of any other crypto project that takes transparency to this level. Until now, users were expected to blindly send money to a cryptic 0x…. address and trust the application developer that a “smart contract” behaves as promised.

Oscript — the language of autonomous agents

Autonomous Agents are written in Oscript — a new programming language developed specifically for this purpose. The language is very simple and any developer who has experience in curly-brace languages such as JavaScript, PHP, Java, C/C++, etc should not have any difficulty learning it.

Some of the features of the language:

convenient access to variables that describe the state of the ledger and the triggering (requesting, activating) transaction received. That’s what makes the language domain-specific. In particular, the following variables are available:

amounts received in the triggering transaction;
data received in the triggering transaction;
who sent the triggering transaction;
state variables of the current and other AAs;
data feeds;
balances of this and other AAs;
information about assets;
arithmetic operations;
logical operations (AND, OR, etc);
string concatenations;
some math functions;
some crypto functions for calculating hashes and validating signatures created off-chain;
branching with if/else;
no loops;
no functions (to prevent infinite recursion);
scalar and object data types;
generation of deterministic pseudo-random number from seed.

To control the resource usage, the number of expensive operations (e.g. crypto functions and database accesses) is capped at 100 per Autonomous Agent. This limit is checked at deployment time and any AA that tries to exceed this limit simply will not be deployed. This makes sure there is no chance for a deployed AA to fail at run time due to resource constraints such as “out of gas”.

There is no complex pricing of operations and run time resource calculation, we kept things simple and included the cap on the number of expensive operations alone.

The fees paid by users and AAs are still 1 Byte of currency per 1 byte of data added to the DAG.

Oscript is used to specify what the response transaction is going to be depending on the triggering transaction and the overall state of the ledger. The response transaction, in turn, can send money to other AAs and trigger their execution. However, the response transaction is first written to the ledger and the initial AA finishes before passing control on to the next AA. This way of handling requests ensures that it is easy to argue about the state of the program at any point as there is no way that another AA can influence it in the middle of the initial AA’s execution. There is no reentrancy issue.

No miners — no front-running, no miner manipulation

In blockchains, it is a common concern that miners can manipulate the order of transactions in a block, refuse to include transactions in a block, or insert their own transactions ahead of others in order to get an unfair advantage in some smart contracts. Non-miner users can also try to get a better position in a block by paying a higher fee after they see other (victim) transactions. Every smart contract design has to be carefully analyzed for such threats and mitigations developed. This makes smart contract design challenging and error-prone on blockchains.

Obyte doesn’t have blocks or miners, and such issues simply don’t exist. Transactions are ordered as they are ordered on the DAG, no fee can change the order. Users just add their transactions to the DAG themselves, there is no authority who decides about the order or about inclusion or non-inclusion of transactions.

Triggering transactions that send money to AAs cause the execution of the AA code after the trigger transaction becomes stable (i.e. it is certain that it is not a double-spend). Every full node executes the AA code on its own and adds the resulting response transaction to its version of the ledger. It doesn’t need to broadcast the response transaction to peers because all peers follow exactly the same rules and must arrive at exactly the same resulting response transaction. The result is determined solely by the rules, there is no need for voting rounds or proof-of competitions.

Autonomous Agents vs smart contracts

Autonomous Agents are not the same as smart contracts but there is still a lot in common between them.

While a (smart) contract exists between (or among) two or more parties, an (autonomous) agent is a party of an interaction.

While the parties of a (smart) contract are equal free men (or software agents acting on behalf and under full control of equal free men) who get rights from the contract, Autonomous Agents are dumb service providers with no free will. The relations between users and AAs are unequal by design — all the rights belong to users, AAs just follow their orders.

What’s common between smart contracts and Autonomous Agents? Both have rules associated with them, the rules are written in a machine-readable form and open for everybody to see, the rules can never be changed, and the rules are applied by all full nodes on the network where nobody has a privilege.


This is going to be the first major upgrade to the Obyte protocol, and it took us around 9 months to develop. We are normally conservative about protocol upgrades as they potentially disrupt the existing applications and we believe that the lower you go in the technical stack, the more stable these layers of the stack should be. The protocol is the base layer and should be the most stable.

Although the current update is not supposed to affect the existing applications, bugs are still possible and we want the new version to undergo extensive testing before we release it on livenet.

Today we are releasing the upgrade on testnet only

We are also launching a developer contest to invite developers to create many different AAs, run them on testnet, explore various edge cases where bugs could be lurking, and have a sizeable number of working and tested AAs by the time we launch the upgrade on livenet.

We expect that this testing and development will take 2–4 months.

Now, if you are a developer and feel like trying out Autonomous Agents, head to write your first AA in the easy-to-use browser editor, and deploy it to testnet! There are many samples available to learn from and to start from and a Getting started guide on our developer site.