# Enabling N-party transactions with Anoma’s state machine

01 September 2021Gabriella Wong
• blockchain
• Anoma Tangram

Anoma’s state machine allows the bartering of arbitrary assets among multiple parties efficiently. With the use of a range of validity predicates, users are able to utilize Anoma to its fullest extent, expressing their desires and capabilities on intents for their transactional needs.

## Introduction

Anoma’s architecture distinguishes itself with novel technology that allows the network to facilitate the bartering of arbitrary assets among multiple parties efficiently, whereas typical step-by-step execution machines (i.e. most smart contract platforms) struggle with a higher number of participants. N-party bartering requires the use of intents and validity predicates. Users can write as many intents as they wish, expressing their desires and capabilities. Generally, intents can express arbitrary preferences over state transitions, and in special cases like on Anoma, they can be what users want to buy for what they want to sell, and the number of which they are willing to sell for what exchange rate. The intents are sent to a gossip network, then discovered by a matchmaker, who matches intents together and sends them to the state machine, calling validity predicates, which express the requirements that the offer has to fulfill in order for the transaction to go through. In other words, the state machine (i.e. the ledger) makes sure through the use of validity predicates that everyone involved is happy with the trade before accepting the transaction and changing the state.

Following Alex’s article on validity predicates, in which he explains in more detail what these are and how they are used in Anoma to determine the validity of a state transition, this article aims to illustrate more use cases of n-party bartering with Anoma’s state machine. Alongside specific examples of different transactions that Anoma’s architecture accommodates, this article will also show the validity predicates used, and the specific real-life situations that may require the use of them.

## Bartering of arbitrary valuables

The multi-party trade in its simplest form consists of three (in more complex situations, up to n on Anoma) parties trading goods. In this first example, suppose that Alice, Bob and Charlie are looking to trade different goods. Alice has obtained more concert tickets than she needs, and has 20 concert tickets. She wants to sell 17 of them so that she can still go to the concert with two friends. Bob would like to attend the concert, offering 1 ETH for two tickets. The same goes for Charlie, who instead offers 1 BTC for 5 tickets.

This transaction will be included in a block if all validity predicates are satisfied, and the validity predicate associated with each account, along with the validity predicates for the goods to be traded (the NFT, BTC and ETH validity predicates) will be called by the state machine. If the validity predicates for all accounts whose state was written or are additionally specified accept the changes, the state changes are committed. This state change does not commit if at least one account rejects this transfer, which can happen if one user (e.g. Bob) does not have (enough of) the good(s) he wants to trade, and the transaction fails. An example of a part of Alice’s validity predicate could be:

use anoma_vm_env::*; #[validity_predicate] fn validate_tx( tx_data: Vec<u8>, addr: Address, keys_changed: HashSet<storage::Key>, verifiers: HashSet<Address>, ) -> { post_state[“NFT_CONCERT/Alice/balance"] >= 3 }

In this example, Alice has written separate intents for the matchmaker, indicating that she is willing to take BTC, ETH and DOT for her concert tickets. Since Bob and Charlie are looking to buy them for BTC and ETH for an exchange rate that matches Alice’s, the ledger matches her intents with Bob and Charlie’s, as well as calls the validity predicates associated with their transactions. Figure 2 shows this part of the validity predicate that specifies that her balance of the concert ticket NFT post-transactions should always be 3 or above, otherwise the transactions will be rejected by the state machine. The user validity predicates can be customized or updated anytime, therefore if Alice decides that she does not want to attend the concert with her friends anymore and would rather sell all her tickets, she can update the last line of the validity predicate to state that the post-state balance ≥ 0. This example shows that Bob and Charlie will not make her post-transaction balance of concert ticket NFTs lower than 3 since they only want to buy 2 and 5 tickers respectively, therefore the transaction is settled and the state is changed.

This barter is generalizable to n parties and can involve assets of arbitrary nature (fungible, non-fungible etc). If each party’s offers and bids are matched, they are settled in one transaction, and the state passed to the validity predicate could be encrypted using zero-knowledge proofs if desired.

## Multi-party negotiation

Suppose that there is a villa at a holiday destination available for short-term rentals, and someone wishes to rent the whole property for a week among him and his friends, which means that they want to split the cost. In this case, the intents written on the gossip network need to specify what they are willing to pay, and when they want to rent it. The villa’s lease can be enabled for a group of people who agree upon it.

In order for this to happen, all parties involved must create this transfer and submit it. During the execution phase, the validity predicates stating their intents and the recipient accounts, as well as the assets involved will be evaluated. The validity predicate will check that this transfer follows certain rules, such that all users that want to rent the property and split the cost are in possession of enough funds that the transfer does not result in a negative balance, and the sum requested by the landlord of the villa is reached.

## Collective commitments

A more complex but common scenario is that users, like many of us, want to reduce negative environmental impact in day-to-day purchases. It is difficult as an end user and consumer to stop manufacturers from externalizing the cost of carbon emissions, because the supply chain is too complex for us to determine impacts. It is also extremely difficult for a producer and manufacturer who voluntarily elects to incorporate costs into their supply chain to remain competitive. Anoma’s n-party collective commitments feature allows a manufacturer e.g. for coffee, to incorporate carbon costs in their supply chain if and only if all others do. In this situation, the Anoma state machine enforces atomic settlement, removing the middleman, and consumers have a direct say in the way they think the products they buy should be produced. At the same time, producers can stay in business even if they do not cut costs by taking options that are more harmful to the environment.

Using the concept of an oracle, additional data on the chain can be queried and stored on Anoma using validity predicates and storage. This concept allows the oracle, in this example, to obtain data about carbon outputs of coffee bean production, users can write validity predicates that state that they do not want to buy coffee if the manufacturer or producer does not compensate for X amount of carbon that is created in the process. From the perspective of the user, this can be done by writing these constraints in a piece of code inside the intent, called an intent validity predicate, and the matchmaker will then execute that code in order to see if another intent is a possible match, in case there is a producer of coffee that does incorporate a carbon cost in a way that the user prefers. Collective commitments on Anoma allow a kind of collective negotiation by consumers which wouldn’t otherwise be possible in any other situation, since intent validity predicates in collective commitments communicate the preferences of many users directly up to producers further in the supply chain. Producers can then see this and offer more options for coffee that they see fit, to be matched with consumers who are looking for more options. On the flipside, consumers can be matched with producers who sell coffee that fit their criteria, and communicate their environmental values in this fashion.

## Relational Intents

The final example of a trade involves the use of “relational intents,” a way for users to write more elaborate constraints in a validity predicate that specifies a relation between the intents. Say that Alice is looking to travel to a festival, but is looking for cheap options where her transportation, festival and accommodation options are second hand. She wants to look for a hotel and train where the check-in and travel times match, the festival ticket for the right corresponding day, and that everything does not go above a certain total cost. This would likely require her to buy from different people, and atomically purchase NFTs in which certain conditions match. Anoma’s system can satisfy this by coordinating the different NFTs, in this case a hostel booking from a hostel owner, a train ticket from a train ticket distributor, and a festival ticket from a festival ticket distributor. Alice will pay all three sellers at once, and receive all the NFTs at once if everyone’s requirements are met.

Figure 4 shows the process in which Alice writes three separate sub-intents stating her offer for the train ticket, festival ticket and hostel stay NFTs. Additionally, she writes an intent validity predicate that all three of her relational sub-intents call, specifying that she will only buy all three NFTs at the same time, which means that if one is lacking, the transaction will not process. The matchmaker looks for possible matches for the relational intents alongside the intent validity predicate, and the ledger calls the other validity predicates involved. Like the other types of bartering that Anoma’s state machine can handle, if the validity predicates for all accounts whose state was written or are additionally specified return true, the state changes are committed, and if any are rejected, no changes are committed. Note that in all the examples mentioned in this article, users can offer more than what the assets are being sold for, like Alice in this example offering 0.2 BTC for the festival ticket, while the ticket distributor is asking for a minimum buying price of 0.15 BTC. With the default Anoma matchmaker, the festival ticket distributor could receive the 0.2 BTC, more than he asked for. The logic used to match intents and create transactions are customizable by users running the matchmaking nodes on Anoma, and therefore what each Alice and the festival ticket distributor receive for the transaction can depend on this factor as well.

## Conclusion

Through the use of intents and a range of different validity predicates, users on Anoma are able to use the network to facilitate the efficient bartering of arbitrary assets in zero-knowledge if desired, and most importantly, among up to n parties. From a simple intent, users are able to codify what it is that they want to trade or barter, and with the assistance of validity predicates, they can specify if there are any conditions tied to the transactions they want to make, such as the balance they want to remain, environmental conditions of the producer they are directly buying from, or that multiple purchases have to connect in a certain way in order to transact.

The examples mentioned in this article illustrate the n-party bartering possibilities that Anoma’s state machine brings. These elaborated models of transaction execution based on Alex’s examples from validity predicates form a bigger foundation for what can be built upon in the future with Anoma.