Friend.Tech is a social platform built on smart contracts, requiring users to connect their Twitter accounts for registration and issue a "key" to gain access. Users with a "key" can enter "rooms," similar to group chats, and engage in conversations with the "key" owners. While it remains a centralized social platform, it employs smart contracts to facilitate the purchase and sale of "keys." The primary functionality is delivered through a web-based instant messaging (IM) application. During the process of buying and selling "keys," 10% of the transaction value is split into two parts, with a portion going to the developers at Friend.Tech and the other part directed to the owner of the corresponding "room."
With the ability for these "keys" to be used independently for purchases and sales, it naturally leads to the emergence of on-chain bots for activities such as new token acquisition, trading, and fee manipulation. So, how are these operations implemented?
New Token Acquisition Bots
During the early days of Friend.Tech's operation, new token acquisition bots had the potential for substantial profits. This was because, during this period, on-chain sniper bots hadn't yet reached a significant level of development. As a result, with basic information assessment, these bots could engage in token purchases with a high profit expectation. Now, let's delve into the fundamental logic of bot implementation, beginning with a basic strategy.
Before we proceed, it's essential to understand "Events." In the Solidity programming language, events are abstractions of log events within the Ethereum Virtual Machine (EVM). Typically, we use the "emit" statement to trigger events. These events manifest as transaction logs in blockchain explorers. For example, consider the following transaction for purchasing a "key." It triggers an event named "Trade," which encompasses a series of relevant pieces of information.
Events play a pivotal role in decentralized applications (DApps) because they allow us to monitor state changes within smart contracts. In applications like Friend.Tech, events serve as channels for tracking contract activities, facilitating timely adjustments of various data stored in databases. These adjustments include updating frontend displays of price and holdings, ensuring the real-time accuracy and consistency of the application.
The Simplest Approach
So, the most straightforward logic for a "front-running" robot is as follows: it listens to the events of the Friend.Tech contract and initiates a purchase within the Friend.Tech contract when the event triggered by a transaction satisfies the following conditions:
- The event represents a purchase (isBuy is true).
- The trader and the owner have the same address (trader == subject).
- The transaction is for creating a "room" (supply is 1).
The diagram below illustrates this process:
Issues with the Robot
However, such robots come with certain issues:
- There is no guarantee of successfully purchasing new tokens.
- The exact amount of Ether required to purchase tokens cannot be accurately determined. Additionally, the robot cannot set an upper limit on the token quantity or price during execution.
- Robots are susceptible to front-running, where other individuals can create new addresses to initiate purchases, luring the robot to buy and, in turn, perpetrate fee fraud or profit from the situation.
To address the first and second issues, the advantage of the Ethereum Virtual Machine (EVM) is its ability to facilitate atomic contract calls. This means that we can invoke other contracts within a single contract. Therefore, deploying a dedicated contract for purchasing and configuring it with various conditions, such as maximum purchase price and quantity, can fulfill the required functionality. For instance, the open-source "friendrekt" contract code available on GitHub allows setting conditions for maximum purchase price and quantity. This approach helps mitigate problems 1 and 2.
Regarding issue 3, a straightforward method involves utilizing an official interface to query a user's Twitter information, including the number of followers. Subsequently, the robot can filter based on this information. After filtering, the robot can make decisions on whether to purchase, how much to purchase, and what the maximum price should be. This clarifies the robot's operational flow, as illustrated in the diagram below.
Technology
This process involves an increase in information requests and smart contract calls. After the robot detects a contract event and confirms it as a new account through simple logic checks, it proceeds to filter relevant information using an API. Finally, the robot utilizes a deployed smart contract to complete the purchase. However, robots of this kind still exhibit certain limitations:
- Inability to identify phishing Twitter accounts. Some accounts may have a high number of followers, but they are essentially zombie accounts with no actual value. Purchasing from such accounts carries significant risks.
- Follower count is not a reliable indicator of a Twitter user's value. Some Key Opinion Leaders (KOLs) may have a relatively small number of followers, but they actively engage with their audience. This makes them difficult to identify and can lead to their unintentional exclusion.
- APIs are subject to certain delays. This particular interface can only be queried within a specific time frame (60 seconds) after user activation. This constraint can lead to missing out on many addresses and introduces high latency.
For problem 3, an alternative approach has been found. Another available interface allows querying address information after user registration. This means that we can continually monitor this interface to obtain the latest IDs and registrant details. If it is determined that the registrant holds value, their address can be stored in a cache. To ensure persistence, a database is also required to retain this information. Subsequently, through blockchain event monitoring and cache hits, decisions can be made on whether to execute a purchase. This method streamlines the entire process.
To address problems 1 and 2, it is crucial to determine the value of users. In this regard, third-party Twitter Key Opinion Leader (KOL) rating websites can be leveraged. During the exploration process, the author used Twiiterscan for these inquiries. Since it is possible to obtain registration information before activation, the time spent querying Twiiterscan has minimal impact on the overall process. Additionally, manual configurations, such as setting up whitelists and purchase prices, can be employed. This method enhances the precision of selecting users with potential.
Ultimately, the basic workflow of the robot we have implemented can be summarized as follows: an additional robot is responsible for obtaining the latest information through the API, which is then stored in a database and cache after assessment. The robot primarily dedicated to purchasing, upon receiving an event, queries the information stored in the cache. If a successful match is found, it proceeds with the purchase. This cache can also store whitelist information, allowing for the selection of valuable Key Opinion Leaders (KOLs), and the configuration of purchase prices and quantities. This streamlined process simplifies robot operations and management.
Buying and Selling, Fee Deception Operations
The principle behind the buying and selling tracking robot is quite straightforward. It tracks addresses that are performing well in terms of profit and mimics their operations. The implementation of this approach is relatively direct; it involves filtering the monitored addresses, and if a target address is identified, the robot follows its actions.
Regarding fee deception, the author observed two primary scenarios during the development process. In one situation, Twitter accounts with a substantial number of followers are utilized to directly purchase tokens and promptly sell them for profit. In the other situation, a continuous creation of new addresses is employed. Transactions are made, followed by a rapid execution of purchase operations, succeeded by quick resale. The second scenario mainly targets the most straightforward logic in robots but also offers substantial profit potential in the initial stages. These are strategies that need to be considered.
