A Brief Analysis of On-Chain Bot Fundamentals: The Case of FriendTech
TechFlow Selected TechFlow Selected
A Brief Analysis of On-Chain Bot Fundamentals: The Case of FriendTech
How do on-chain bots perform functions such as participating in new token offerings, trading, and fee fraud by bypassing the front-end to complete purchases and sales?
Navigating Web3 tides with focused insightsPreface
Friend.Tech is a smart contract-based social platform where users must connect their Twitter accounts to register and "issue" their own keys. Users who own a key can enter a room—similar to a group chat—to communicate with the key's owner. It remains a centralized social platform, relying solely on on-chain smart contracts to manage the logic of buying and selling keys, while core functionalities are implemented via a web-based IM application. During each key purchase or sale, 10% of the transaction value is split between two parties: a portion goes to the Friend.Tech developers, and the remainder goes to the room's owner.
Given that these keys can be bought and sold without going through the front end, it’s natural for on-chain bots to emerge, conducting activities such as new-user sniping, trading, and fee fraud. But how exactly do they work?
On Sniping Bots
In the early days of Friend.Tech, sniping bots could generate substantial profits because on-chain sniper bots had not yet evolved to their current sophistication. Early bots could make purchases based on simple information checks and still expect high returns. Now, let’s start from the most basic bot implementation logic and gradually build toward a more complex bot architecture.
Before that, we need to introduce Event. In Solidity, an event is an abstraction of log entries within the EVM. Events are typically triggered using an emit statement. On blockchain explorers, these appear as transaction logs. For example, in the following key purchase transaction, a Trade event was emitted, containing a series of data points:
Events are a crucial component of DApps, enabling monitoring of contract state changes. Friend.Tech itself listens to these events to update its database—for instance, adjusting displayed prices and holding counts shown on the frontend.
The Simplest Approach
The most basic sniping bot operates as follows: listen to Friend.Tech contract events, and when a transaction-triggered event meets all the following conditions, call the Friend.Tech contract to buy immediately:
-
The event is a buy action (
isBuyis true) -
The trader and the owner are the same address (
trader==subject) -
The transaction creates a new room (
supplyequals 1)
The diagram below illustrates this process:
Contract? Atomicity!
However, this simple bot has several issues:
-
It cannot guarantee successful purchases, nor precisely calculate the ETH amount required to buy a key;
-
It lacks a price cap mechanism—for example, stopping purchases once the number of keys or the price exceeds a certain threshold;
-
It is vulnerable to front-running attacks, where others may use new addresses to place initial buys and lure these bots into executing transactions, thereby profiting from fees or dumping afterward.
To solve problems 1 and 2, we leverage one of EVM’s strengths: atomic execution across multiple contract calls within a single transaction. By deploying a dedicated contract to handle purchases and enforce conditions (e.g., maximum price and quantity), we can overcome these limitations. For example, open-source code like friendrekt on GitHub allows setting upper limits on purchase price and volume.
For problem 3, the simplest solution is to query the official API to retrieve the corresponding address’s Twitter profile, then filter based on follower count and other metrics before deciding whether and how much to buy, and at what maximum price. The bot workflow now evolves into the following:
Technological Evolution
As shown, this updated process adds external information fetching and smart contract invocation. After detecting a contract event and confirming it's a new account activation, the bot queries additional data via API, filters accordingly, and finally uses a deployed contract to execute the purchase. However, even this improved bot has flaws:
-
It cannot detect phishing Twitter accounts—some have high follower counts but consist mostly of fake or zombie followers, posing significant investment risk;
-
Follower count alone is insufficient to judge a user’s value; some influential KOLs may have fewer followers but strong engagement, potentially getting filtered out incorrectly;
-
API latency is an issue—the official endpoint only becomes available about 60 seconds after user activation, leading to missed opportunities and high delays.
Each of these issues can be addressed individually. Starting with issue 3, inspired by 0xleo's post How I Lost $10K on friend.tech:
We discover another API endpoint that allows querying user data immediately upon registration: query. By continuously incrementing and monitoring this endpoint, we can track the latest user IDs and obtain registrant information in real time. If a registrant appears valuable, we store their address in cache (and ideally in a persistent database for reliability). When the chain event listener detects a relevant event and finds a matching entry in the cache, it triggers a purchase.
Next, addressing issues 1 and 2: How do we determine a user’s actual value? This requires third-party Twitter KOL scoring tools. During my exploration, I used Twiiterscan for evaluation. Since registration data can be obtained in advance, querying Twiiterscan before activation incurs negligible delay. Additionally, manual whitelisting and predefined buy prices further refine purchase decisions.
Finally, our fully realized bot follows this general flow: a separate “monitoring bot” continuously polls the API for the latest registrations, evaluates them, and stores promising addresses in a database or cache. The purchasing bot listens for on-chain events and, upon a cache hit, executes a buy order. This cache can also store whitelist entries—valuable KOLs pre-selected with configured buy prices and quantities.
Since I started building this bot relatively late, profits were not substantial. Development and optimization began in late September, peaking around October 3rd with a return of up to 1.2 ETH. However, failing to exit positions promptly led to profit erosion, and after accounting for gas and other fees, the net result was roughly break-even. Bots with this architecture can execute purchases in the very first block after a user’s activation. Since Base does not support mempool scanning techniques, most bots operating within the same block adopt an aggressive strategy: repeatedly attempting purchases until successful. An example is this observed bot:
https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c
Its strategy is straightforward: bypassing database storage entirely, it starts buying immediately upon detection and keeps retrying until success. At this level of optimization, it becomes a capital-intensive game—those who can afford higher gas costs dominate, and when executed correctly, profits can be highly rewarding.
Conclusion
Earlier, we mentioned trading bots and fee fraud strategies. Here’s a brief overview:
-
Trading bots are copy-trading bots that follow profitable addresses. The principle is simple: filter monitored addresses, and mirror transactions from selected targets;
-
Fee fraud comes in two forms (observed during development): One uses Twitter accounts with many followers to buy and quickly sell, harvesting profits. The other involves constantly creating new addresses, transferring funds, making quick purchases, and rapidly selling. The second type primarily targets basic-logic bots and likely yielded good returns in the early stages.
With this, we conclude our exploration of on-chain bot mechanics. Specific implementations involving code are beyond the scope of this article, but interested readers may refer to the friendrekt project for details.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@3PDAO
