JAAA, Joint Account Autonomous Agent

Hey_Monkey
Autonomous Agents powered by Obyte
6 min readSep 26, 2019

Powered by Obyte

edit: new JAAA address is BNYR4KQWO75M5FP2VSRF6VKPCUHPNHOI

Principle

This AA deals with joint accounts. A joint account is an account that has several ‘owners’. When a payment is initiated by one of the owners, the others receive messages asking to validate the payment or to refuse it. When the payment is validated by every user, it is processed.

‘hierarchical’ or ‘flat’

The account can be set to ‘flat’, then every user is equal and messages are sent to all the users at the same time when a payment is initiated. If the account is set to ‘hierarchical’, the first registered user has more responsibilities than the second one which has more responsibilities than the third one and so on… When a payment is initiated, the last user of the hierarchy is asked for validation, only if he does, the next level user is asked for validation etc, until the top user is reached.

Use cases

The flat account can be used for common account of couples, the hierarchical one can be use in businesses to process orders that need supervisors validation, or in a families, when children need approbation of parents to do big purchases, etc…

Technical info

JAAA is using a secondary AA called HOLLAA (holder of linked list AA) that helped to maintain and iterate lists. In this case, lists of users.

In the hierarchical mode, we never iterate the full list, we just ask for the next validator of the list. Therefore, there is no limitation in the number of user per account.

In the flat mode at the creation of a payment, all the users must be informed so the full list of user is iterated. This is done by a lot of back and forth transactions between JAAA and HOLLAA. As there is in AA rules a limitation of 2000 operations and maximum complexity of 100 per trigger, an important number of users can become problematic.

To reduce the number of operations per user, JAAA is actually user LHOLLAA a Light version of HOLLAA where only the needed functionalities for this use case have been kept. Finally I have realized that the limitation is not the number of operations or the complexity but the limit of 10 AA interactions per trigger. The max number of user for the flat mode is then 4 :(

HOW TO

Create an account

Open your Obyte wallet and prepare a payment to JAAA address:

PKDTQ6GRJPJ6WXA35WKGUW3QJBHOLHK6

The AA will bounce you the instructions:

The message says that for every interactions you will have to set the ‘account_name=<account name>’. This will be true when the account will be activated but during the initialization of the account, your address is recognized and you can add the users, set the mode (hierarchy, flat) and activate the account without setting the account name every time. If you don’t wait for transaction confirmation between each initialization steps, you will have to ignore this bouncing message.

Only the address that add the first user will be able to setup the account so be sure to use a single address wallet to create the account.

Initialize the account

Start the account creation by setting its name and adding a first user (if you plan to create a hierarchical account, this user will be the ‘big boss’):

Be sure to use addresses of single addresses wallet for the users.

You have to sent transaction for every users, but now you don’t need to specify the account name anymore:

Let’s add a third and last user, the nickname is always optional, it will be used to create nicer messages when it will be payment validations time:

We have added 3 users we should now activate the account by setting at the same time if it is a’flat’ one or ‘hierarchical’ one. This one will be a hierarchical:

You account is now activated and those transactions created as small balance already available to make our first payment.

You can notice that the list of user is not visible in the primary AA (JAAA) state. They are store in the secondary AA called LHOLLAA (light version of HOLLAA) that is used to create linked list that can be iterated. You can find its address in the definition of the primary AA:

Our users are visible in the state of LHOLLAA:

Initiate a payment

Starting from now any of the registered users can initiate a payment with funds from the account. Let’s say that the bottom user want to pay 30.000 bytes, for a purchase, to the address: AGFB2ZNL4GEO2GEY4YSKNZX6U7XUGGPG:

Payment validations

A lot of state variables are set and a lot of data are exchanged between AAs but the response messages are following:

payment description available in the JAAA state variables.

Our structure being the following:

MYESSCFGDERS3YIEGNZDOG2BI5HKQHLU // big boss 35IT3ZYKEPQSCXG2F7A7KWNRAD3SZXN4 // petit chef MPG4MHVYUAP3B5IQX44LTINTSUKYB6JA // unknown employee

And the payment being initiated by the bottom user, the next validation requested is from the next level user: ‘petit_chef’. He receives the following message:

(remark: the (1) is due to the fact that this user doesn't have a nickname, if the petit_chef would have initiated the payment we would have seen ‘35IT3ZYKEPQSCXG2F7A7KWNRAD3SZXN4(petit chef)’)

The user that received the approval request will have to send the received pay_id to JAAA to continue the process of validation. If he decide not to validate the payment he must return ‘cancel =true’ in addition of the pay_id.

This time, he is choosing to validate the payment^^:

Finally, the highest level user validation is reached and after its validation (providing at its turn the pay_id to JAAA), the payment is executed:

All payment related variables are removed from the AA:

And the recipient receives its money:

Refill the account

The account balance is now quite low, so it is time to fill it back. Anybody can do it:

Enjoy joint payments and as usual enjoy AA coding^^.

--

--