Taking Friend.Tech as an example, a brief analysis of the basic principles of on-chain robots

Author: 3PDAO

Introduction

Friend.Tech is a social platform based on smart contracts, where users need to connect their Twitter accounts to register and "issue" their own keys. Users who own keys can enter room-like chat spaces to communicate with the key's owner. It remains a centralized social platform, relying on on-chain smart contracts to implement the logic of buying and selling keys, while its main functionality is realized through a web-based IM application. Moreover, during the process of selling and buying keys, 10% of the value is divided into two parts: one part goes to the Friend.Tech developers, and the other part goes to the corresponding room's owner.

In such a scenario where keys can be bought and sold bypassing the frontend, it is natural for on-chain bots to emerge to engage in new buying, trading, and fee manipulation operations. So, how do they achieve this?

Discussing New Buying Bots

In the early stages of Friend.Tech's operation, new buying bots can yield considerable profits because, at that time, on-chain sniper bots had not evolved to a significant extent, allowing for simple information judgments to facilitate purchases with high profit expectations. Let's start with the simplest bot implementation logic and gradually build up to a more complex bot logic.

Of course, before that, we need to introduce Event, which is an abstraction of log events in the EVM under the Solidity programming language. It is usually accompanied by an emit statement to trigger events. In blockchain explorers, this corresponds to transaction logs. For example, in the following transaction of purchasing a key, it triggered a Trade event, which contains a series of information.

Event is a crucial part of DApps, as they allow for monitoring changes in contract states. For instance, Friend.Tech also listens to this contract to adjust a series of data in the database, such as the displayed price on the frontend and the holding quantity.

Simplest Idea

The simplest logic for a new buying bot is as follows: listen to the Friend.Tech contract events, and when an event triggered by a transaction meets the following conditions, call the Friend.Tech contract to buy in:

• The event is a purchase (isBuy is true)

• The trader and owner are the same address (trader == subject)

• The transaction is a room creation transaction (supply is 1)

The following diagram illustrates this process.

Contract? Atomicity!

Such bots have certain issues:

1. They cannot guarantee that new buying will definitely result in a purchase, and they cannot accurately specify the amount of ETH required to buy a key;

2. They cannot set a maximum price, for example, if the transaction reaches a certain number of keys or a certain price, it will not proceed with the purchase;

3. They are easily sniped; others can execute purchase operations through new addresses to attract such bots, aiming to deceive fees and sell for profit.

First, let's consider solving problems 1 and 2. One advantage of the EVM is that it allows for atomic calls to other contracts within a single contract, so we only need to deploy a contract for purchasing and set a series of conditions. For example, the open-source contract code on GitHub friendrekt allows for setting a maximum buying price and quantity.

For problem 3, the simplest way is to use the official API to query the corresponding user's Twitter information, then check the Twitter follower count and other information for filtering. After filtering, we can determine whether to purchase, how much to buy, and what the maximum price is. Thus, the bot's operation flow becomes as shown in the diagram below.

Technical Explosion

As we can see, this process adds information requests and smart contract calls. After the bot listens to the contract events, it determines a new account activation through simple logical judgments, then uses the API to query relevant information for filtering, and finally uses the deployed smart contract to complete the purchase. However, such bots still have flaws:

1. They cannot identify phishing Twitter accounts; some accounts may have a high follower count but consist of zombie followers, which carry significant buying risks;

2. The follower count is not convenient for judging whether a Twitter user is valuable; some KOLs may have fewer followers but are effective in operations, making it easy to filter them out;

3. The API has a certain delay; this interface can only be queried within a period (60s) after user activation, making it easy to miss many addresses and resulting in high latency.

Similarly, let's address these issues one by one. First, for problem 3, thanks to the inspiration from 0xleo in How I Lost $10,000 on friend.tech - 0xleo

We discovered another interface that allows querying address information immediately after user registration, so we can continuously monitor this interface for the latest IDs and obtain registrant information. If deemed a valuable registrant, the address can be stored in cache (to ensure persistence upon restart, a database is also needed). After listening to on-chain events and hitting the cache, we can proceed with the purchase.

Next, for problems 1 and 2, how do we determine whether a user is valuable? This requires assistance from some third-party Twitter KOL rating websites. During my exploration, I used Twiiterscan for queries. Since we can obtain registration information in advance, the time spent querying Twiiterscan before activation does not significantly impact the process. Additionally, we can manually set whitelists and buying prices to complete purchase configurations.

Finally, the basic flow of the bot we implemented is as follows. An additional "bot" pulls the latest information from the API, stores it in the database and cache after judgment, while the bot responsible for purchasing queries the cache upon receiving events and proceeds with the purchase upon hitting the cache. This cache can also store whitelist information, allowing us to select valuable KOLs and set prices and quantities for buying.

Since I implemented this bot relatively late, the profits were not very objective. I started working on it at the end of September and optimized it, reaching a peak profit of 1.2E around October 3. After failing to act promptly during those days, profits retreated, and after a series of fee expenses, it turned out to be neither profitable nor a loss. This architecture allows the bot to execute purchases in the first block after a registrant buys in. Since there is no memory pool scanning on base, most purchases following the same block are essentially a crazy play: executing purchases continuously upon detecting a buy until the purchase is complete. For example, during this process, I observed another bot:

https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c

Its strategy is simple; based on the architecture we introduced above, it does not store a database and directly starts buying until the purchase is complete. Once optimized to this extent, it becomes a game of capital volume; if you can afford the gas, you can play this way, and with the correct strategy, the profits can be particularly substantial.

Conclusion

In the introduction, we also mentioned buying, selling, and fee manipulation operations. Here, I will briefly introduce:

1. Buying and selling is a type of follow-up bot that can track profitable addresses and follow their operations. The principle is simple: filter the monitored addresses, and if it is a target address, follow the operation;

2. Fee manipulation can be divided into two types (as observed during my development process). One is done using Twitter accounts with a large follower count, directly purchasing and quickly reselling to complete the harvest. The other involves continuously creating new addresses, transferring funds, and executing purchase operations before quickly selling. The second type primarily targets the simplest logic bots and should also yield good profits in the early stages.

Thus, we have completed the introduction to the principles of on-chain bots. The specific implementation involves code that will not be elaborated on here. Friends who want to learn more can refer to the implementation of friendrekt.