You may check the application on our GitHub page. There is a readme file that contains information about installation and how to use it.
https://github.com/algorder/algorthic
We will disclose some future ideas about Algorthics in this article.
In the current version of Algorder, there isn’t any system that distributes orders to Algorthics. Algorthics are checking all accounts and if they find an order that its condition is met, they send it. There are some potential problems with this architecture:
Between two Algorthics that run the node.js application, one of them could end up sending more orders according to the other one and earn more tips. Because there isn’t a particular system that distributes the orders among them equally.
There were several approaches we discussed as a team.
Current approach:
Any Algorthic could run this application separately. It’s a trustless system. But it could end up distributing tips unequally.
Approach 2:
We discussed setting a limit for Algorthics. It could depend on the amount of Algor token they hold.
For example :
If an Algorthic A holds 20.000 ALGOR tokens, and Algorthic B holds 10.000 ALGOR tokens. Once Algorthic-A sends 2 orders, he won’t be able to send another order until Algorthic-B sends 1 order. So that we could ensure that the tips will be distributed among them in a fair them.
But the problem with this approach is, we could not detect whether those Algorthics are running an application at a specific time or not from on-chain implementation. So if Algorthic-A sends 2 orders, but when it’s algorthic-B ‘s turn, maybe he is not checking the orders at the point, so the system will delay because of it.
Approach 3:
In addition to approach 2, we could develop a server that is in touch with all Algorthic applications. We will know which Algorthics are running an application at a specific time, so our main application could distribute the orders among them equally. We will also need to develop a solution on-chain to make ensure that Algorthics will only be able to send orders unless they are using our node.js application, and in touch with our main server application. This approach fixes the distribution of tips problem, but it is not a trusted system, it will be the centralized solution.
Approach 4:
We could introduce ALGOR staking. In this approach, none of the Algorthics will need to run an application. Only we are going to run an application that checks and sends the orders. We will be distributing the tips among ALGOR stakers. This will also be a centralized solution.
Conclusion & Future:
We didn’t want to introduce a centralized or non-trustless approach in our project. So we started with the current approach. We get some great ideas for our system from our community about using a subnet. Thanks again for those great feedbacks. With a subnet we could develop a system that Algorthics will be validators (running servers) to send orders. There are other possible approaches we could go with when subnets arrive at Avalanche Network. We will disclose much more details about it in the following months.
About the future of this node.js application. Currently, our node.js application simply checks all Algorder accounts and orders in a loop. If you wish you may run several instances of this application for checking accounts in parallel. Currently, as the Algorder team, we are running 5 instances of this exact node.js application. We may reduce it to 1 when the community starts to run many applications.
We may also introduce a more involved version of this node.js application, where it indexes all the orders, tracks the price itself, when the price changes of a token, it retrieves the related orders from the index and checks them. But since there is a very limited number of orders being sent on Algorder, this version is simply good enough for now. We are focusing on increasing the number of orders sent on Algorder. First, we should increase the usage of Algorder, then it’s easy to develop more involved Algorthics applications. We will be disclosing more details in our next article about our plans(roadmap).
