Preface
Friend.Tech is a social platform based on smart contracts. Users need to connect to their Twitter to register and "issue" their own keys. Users with keys can enter a room similar to a group chat to communicate with the owner of the key. It is still a centralized social platform, but relies on smart contracts on the chain to implement key purchase and sale logic, and its main function is an IM application based on web pages. Moreover, during the process of selling and purchasing keys, 10% of the value will be divided into two parts, one part is given to the Friend.Tech developer, and the other part is given to the owner of the corresponding room. Then, when such a key can bypass the front-end to complete the purchase and sale, robots on the chain will naturally be generated to carry out new operations, buying and selling, and fee fraud. So, how are they achieved?
A brief discussion on creating new robots
Creating new robots can bring considerable profits in the early stages of Friend.Tech's operation, because at this time the sniper robots on the chain have not yet evolved to a certain level. They can be purchased after making simple information judgments and can have a high profit. Profit expectations. Now, let's start with the simplest robot implementation logic and complete a complex bot logic step by step.
Of course, **Event** needs to be introduced before this. Events are an abstraction of log events in the EVM under the Solidity programming language. It is usually paired with an emit statement to **trigger the event**. Corresponding to the transaction logs in the blockchain browser, for example, the following transaction to purchase a key triggers a Trade event, which contains a series of information.
合约时间
Events are an important part of DApp, through which they can monitor the status changes of the contract. For example, Friend.Tech will also monitor the contract to adjust a series of data in the database, such as the displayed price on the front end, the holding quantity, etc.
The simplest idea
Then, the simplest logic for creating a new robot is as follows: monitor the contract events of Friend.Tech, and when it is found that an event triggered by a transaction meets the following conditions, call the contract of Friend.Tech and follow the purchase
* The event is a purchase (`isBuy` value is true) * The trader and owner are the same address (`trader` == `subject`) * The transaction is a transaction that creates a room (`supply` is 1)
The figure below is a flow chart of the process.
最简Bot
contract? Atomic!
There are certain problems with such robots:
1. There is no guarantee that the new key will be purchased, and secondly, the amount of eth required to purchase the key cannot be accurately given; 2. It is also impossible to set an upper limit price, such as how many keys or prices are reached when the transaction is executed. Make a purchase; 3. It is easy to be sniped. Others can perform purchase operations through the new address to attract such robots, in order to achieve the purpose of defrauding handling fees and selling for profit;
First consider solving problems 1 and 2. One of the benefits of EVM is that it can atomically call other contracts in one contract, so you only need to deploy a contract to make a purchase and set a series of conditions, such as the open source contract on Github Code [ friendrekt ], you can set the maximum buying price, and quantity.
For question 3, the simplest way is to use the official interface https://prod-api.kosetto.com/users/{address} to query, get the user Twitter information of the corresponding address, and then query the number of Twitter fans and other information. Filter and then decide whether to buy, how much to buy and what the highest price is. At this point, the robot's operation process becomes as shown in the figure below.
引入代购合约
technological explosion
It can be seen that this process adds information requests and smart contract calls. After the robot monitors the contract events, it determines that the new account is activated after simple logical judgment, then uses the API to query the relevant information for filtering, and finally uses deployment smart contract to complete the purchase. But such robots still have flaws:
1. It is impossible to judge phishing Twitter accounts. Some accounts have a high number of followers, but they are all zombie followers and have no value. There is a great risk in buying them; 2. The number of followers is not easy to judge a Twitter user. Is it valuable? Some KOLs have a small number of fans, but they can operate, so it is easy to filter out these people; 3. There is a certain delay in the API. This interface can only be queried within a period of time (60s) after the user activates it, so it is easy to miss Many addresses and high latency;
Again, address these issues one by one. Let’s look at question 3 first. Thanks to 0xleo ’s reminder [ How I lost $10,000 on friend.tech - 0xleo ], I found another interface that can query address information after user registration `https://prod- api.kosetto.com/users/by-id/{id}`, then you can continuously and incrementally monitor this interface to find the latest id and get the registrant's information. If it is judged to be a valuable registrant, the address will be stored in the cache (in order to ensure restart persistence, a database is also needed), and the purchase will be made after the on-chain event is monitored and the cache is hit.
Followed by questions 1 and 2, how to judge whether a user is valuable? Then you need the assistance of some third-party Twitter KOL rating websites. During the exploration process, the author used Twiiterscan to query. Since the registration information can be obtained in advance, it does not take much time to query Twiiterscan before activation. of influence. In addition, you can also manually set the whitelist and purchase price to complete the purchase configuration.
Finally, the basic process of the bot we implemented is as follows. An additional "robot" pulls the latest information of the API and stores it in the database and cache after judgment. The robot specifically responsible for purchasing queries the cache information after receiving the event and makes a purchase after hitting the cache. This cache can also store whitelist information. Select some valuable KOLs and then set the price and quantity to buy them.
提前监听与影响力分析
Since the author implemented this bot relatively late, the profit is not very objective. We started to realize and optimize it at the end of September, and reached the highest profit of 1.2E around October 3. After a few days of failure to make a move in time, the profit retreated. After adding a series of handling fees, there was no profit or loss. A robot with this structure can buy in the first block after the registrant buys. Since there is no such cool operation as memory pool scanning on the base, most people who follow the same block to buy are basically crazy. How to play: After monitoring the purchase, continue to execute the purchase until the purchase is completed. For example, another robot seen in this process: https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c.
Its strategy is very simple. Based on the architecture we introduced above, it does not store the database and starts buying directly until the buying is completed. After optimization to this level, it becomes a game of fighting for funds. You can play this way if you can afford to burn gas, and if the strategy is correct, the profit will be very considerable.
Conclusion
In the preface, we also mentioned the operations of buying and selling and fee fraud. Let’s briefly introduce them here:
1. What you are buying and selling is a copying robot. After tracking a more profitable address, you can follow its operation. The principle is also very simple. Filter the monitored address and follow the operation if it is the target address; 2. Fee deception There are two types (observed by the author during the development process). One is to use a Twitter account with a large number of fans to complete the purchase directly and sell it quickly to complete the harvest. The other is to constantly create new addresses, transfer money and then perform purchase operations and sell them quickly. The second type is mainly aimed at bots with the simplest logic, which should also be very profitable in the early stages.
At this point, we have completed the introduction to the principles of on-chain robots. The specific implementation involves code and will not be explained. Friends who want to know more can also refer to the implementation of [ friendrekt ].
Twitter: https://twitter.com/3PDAO
Telegram: https://t.me/Labs_3P
Mirror: https://mirror.xyz/3p-labs.eth
Medium: https://medium.com/@3p-labs
Followin: https:// Followin.io/zh-Hans/kol/4075816318
Foresight News: https://foresightnews.pro/column/detail/873
