How to track crypto whales on the blockchain: the architecture of a monitoring system

Would you like to try Octo Browser at а discount?
Use the promo code OCTOBLOG to get 30% off any subscription. This offer is valid only for new users.

How to build an initial whale database

A monitoring system runs continuously. It parses blockchain and mempool transactions, checking addresses against an internal database of tracked wallets. It also takes into account transfers from previously unknown wallets when the transfer amount exceeds a predefined threshold.

But first, you need to build the database. This happens in several stages before the parser is launched:

• Exporting the largest holders. You don't have to wait for a whale to make a transfer. You can query the blockchain for the current distribution of token balances and export the top 100 or 500 wallets, depending on your needs.

• Analyzing liquidity providers. Whales often commit capital to DEX liquidity pools to earn fees. Addresses holding the largest shares of these pools are added to the database as well.

• Analyzing Token Generation Events (TGEs). A token contract's earliest transactions reveal which wallets received tokens before they became publicly available on the market. These are usually early investors, venture capital funds, and the project team.

• Cross-referencing labeled addresses. The database is checked against publicly labeled addresses in blockchain explorers. This allows you to exclude exchange hot wallets and bridges from the dataset, preventing the system from reacting to their technical transfers.

Once the initial database is ready, the system starts monitoring transactions in real time and automatically adds newly discovered whale wallets.

How to group wallets belonging to the same owner

For security reasons, major market participants almost never keep all their funds at a single address. One whale may control dozens of wallets. Without accounting for this, the activities of a single owner can look like those of several small users—especially when individual transfers fall below the monitoring threshold. As a result, the system may miss a whale entirely.

That's why wallets are grouped into clusters—profiles representing a single owner. To build these clusters, you need to look for consistent behavioral patterns:

• Transfers to the same exchange. Several wallets regularly send funds to the same deposit address at a centralized exchange, such as Binance or Bybit. Since an exchange deposit address is unique to each customer, these wallets can potentially be linked.

• Temporal synchronization. The system compares transaction timestamps. Suppose five wallets start buying the same asset from a liquidity pool within milliseconds of one another. Most likely, a single script and owner control them.

• Post-mixer analysis. Mixers are services that obscure transaction histories to improve anonymity. New addresses that emerge after a mixer can be linked to existing clusters based on withdrawal patterns and matching transaction times and amounts. This process relies on heuristics—empirical rules used to analyze data when information is incomplete.

Wallet connections in Breadcrumbs: incoming and outgoing transfers reveal which addresses a wallet interacts with most frequently.

How to track transfers across bridges

Whales often operate across multiple networks and transfer funds through cross-chain bridges, such as Stargate, Hop, and Across. For example, a whale deposits 500 ETH into a bridge on Ethereum and receives the equivalent amount on Arbitrum or Base a minute later. A basic parser will see the funds disappear from one network and a new wallet appear on another.

To avoid losing track of the whale, the system incorporates cross-chain tracking. It monitors bridge deposit addresses and matches them with withdrawals on other networks. If the amounts and timestamps match, the whale's cluster is updated with its address on the new network.

How to filter out MEV bots

EVM-compatible networks—those based on the Ethereum Virtual Machine—host numerous MEV bots that profit from arbitrage. They use flash loans worth millions of dollars, making their trades look similar to those of whales. If these bots aren't filtered out during parsing, the system will generate false signals.

It's impossible to determine with absolute certainty that a transaction was made by an arbitrage bot. However, several indicators can help filter them out:

• Complex, cyclic smart contract calls in which a chain of calls eventually returns to the original contract.

• Zero or minimal change in the wallet's balance after a transaction. For example, a bot borrows a million dollars, executes an arbitrage trade on a DEX, and repays the loan within the same block.

Clean data is essential for maintaining a reliable whale database. Once the database is ready, reaction speed becomes the priority. That's where the mempool comes in—and it's also where MEV bots operate.

How to work with the mempool

Address clustering and bot filtering operate on confirmed blocks. But by the time a transaction has been recorded on the blockchain, the asset's price may already have changed, and the opportunity to trade may be gone. To react earlier, transactions are intercepted before execution while they're still in the mempool.

The mempool is a queue of unconfirmed transactions. When a trader submits a buy or sell order, it first enters the mempool, where it waits for validators or miners—depending on the network—to include it in a block.

There's no strict ordering in the mempool. Transactions offering higher fees (gas) tend to be processed first. Those with low fees may wait for hours or be pushed out by other transactions entirely.

A mempool bot works as follows:

1. Interception. The bot connects to a blockchain node and receives a stream of new transactions as they enter the mempool.

2. Decoding. The bot decodes the input data field to identify which smart contract function the transaction calls. For example, it detects that a particular wallet is buying a large amount of a token.

3. Front-running. The bot expects that this trade will push the price up. It submits its own transaction to buy the same asset, offering a slightly higher fee than the whale.

This is what the data in the input data field looks like.

Validators include the bot's transaction in the block first. The bot buys the asset at the old price, and the whale's transaction follows immediately afterward, pushing the price up. This strategy is called front-running.

But intercepting a transaction is only part of the challenge. Decisions must be made within milliseconds, which means the data must be stored in a format that allows for rapid analysis.

How to store data for fast analysis

Blockchains generate enormous volumes of events. Suppose you need to find correlations in the history of every swap on a major DEX over the past couple of years. A conventional relational database would be too slow for queries of this kind.

That's why Web3 systems use column-oriented database management systems, such as ClickHouse. During analytical queries, they read only the columns needed for the calculation—such as wallet_address and amount—without processing the other transaction fields. This makes it possible to aggregate billions of rows in milliseconds.

Speed is critical here. Imagine a bot detects a $5 million token purchase in the mempool. Before deciding what to do next, it needs to determine whether the transaction is a routine portfolio rebalance by a fund or unusual activity from a wallet that has been dormant for a long time. To do this, the bot compares the transaction with the wallet's activity over the past three years. Without column-oriented storage, this check could take minutes, allowing the whale's transaction to go through first. ClickHouse can return the result in milliseconds.

How to load blockchain data into a database

Blockchain data isn't stored in tables. Instead, it's represented as a sequence of events (logs) encoded in hexadecimal. To work with these logs, you need to decode them using an ABI—the contract interface specification that describes how to interpret the data.

You could write your own parser. However, it would then need to query every block, decode the logs, and handle chain reorganizations separately for each smart contract. This is time-consuming and difficult to maintain.

Using an indexer, such as The Graph, is easier. You define which smart contract events you need in a subgraph. The indexer scans the blockchain from the first block, decodes the logs, and makes the data available through a GraphQL API.

All the system needs to do is query The Graph, retrieve structured data about whale trades, and load it into ClickHouse. The bot can then analyze the data and make a decision.

How to incorporate social media signals

The blockchain shows only the transfer itself—for example, "Whale A transferred $1 million to an exchange." It doesn't tell you why.

A large transfer might indicate that the owner is preparing to sell. In that case, you may want to open a short position or exit an existing one. But it could also be a scheduled token unlock for the project team, announced in advance on X (Twitter) or Discord. Without this context, the bot may send false alerts or execute trades that lead to losses.

That's why the system includes a social media analysis module covering X (Twitter), project Telegram channels, and Discord. It's a separate background worker that continuously collects posts through WebSocket feeds, processes them using local neural networks, and updates a metric called "social sentiment" in the in-memory Redis database. Social sentiment represents the overall attitude of social media users toward each token.

The mempool scanner doesn't waste time making external requests. When it detects a large transfer from a whale to a centralized exchange, it checks the sentiment value in Redis.

For example, the scanner detects a $10 million transfer in the mempool. Sentiment for that token has dropped sharply over the past three minutes because the social media worker found news of a protocol hack. This suggests that the whale isn't rebalancing a portfolio but exiting the asset. The bot submits a short transaction before the whale's trade goes through. Scenarios like these must be carefully planned and tested in advance; otherwise, a bot's mistake can lead to real financial losses.

How to collect social media data without getting blocked

X (Twitter), Discord, analytics platforms, and news aggregators restrict automated data collection. They use anti-fraud systems such as Cloudflare and Akamai, which can detect a standard headless Chrome browser.

For more reliable data collection, the architecture includes an anti-detect browser. Profiles are managed programmatically through Puppeteer or Playwright rather than manually. Octo Browser supports this integration through its API.

Octo Browser provides detailed documentation on working with its API.

To pass the checks, the browser needs to appear to be a real device operated by a real person. Octo Browser lets you create dozens or hundreds of such profiles, each with isolated data. Octo spoofs digital fingerprints of each profile at the browser kernel level, including the User-Agent, fonts, WebGL/WebGPU parameters, screen resolution, and more.

The data collection process works as follows:

1. The bot uses the API to launch an Octo Browser profile with a dedicated proxy.

2. The profile opens the target platform with its unique fingerprint, making it appear to anti-fraud systems as an ordinary visitor.

3. The bot retrieves session tokens and cookies and passes them to lightweight workers.

4. The workers request data directly through the platforms' APIs and pass it to an NLP model.

5. If a session expires or the platform requests verification, the bot launches the profile again to obtain a new session.

The anti-detect browser isn't used here to imitate user actions, but to pass various checks. Isolated profiles with separate fingerprints help ensure more reliable access to fresh posts at the time of a transaction.

How to choose which whales to track

The system's final output is either a notification to the user or a command sent to a trading engine. But following every whale doesn't make sense.

Some large wallets don't provide useful trading signals. These include early Bitcoin miners and investors who simply move old holdings between cold wallets. More interesting are addresses that consistently buy near local lows and sell near local highs. These are known as smart money.

To distinguish between the two groups, the system adds a scoring module. The bot evaluates the historical performance of each tracked wallet using several metrics:

1. Win Rate: The proportion of the wallet's trades that closed in profit.

2. PnL (profit and loss): How much the address has earned in dollars over the past six months.

3. Entry timing: How much earlier the wallet buys assets compared with the rest of the market.

Based on these results, the system assigns weights to wallets. You can configure the bot to send alerts only when activity comes from a smart money wallet with a Win Rate above 70%.

Conclusion

A whale-tracking system consists of several modules. First, a wallet database is built and clustered, with cross-chain bridges taken into account, and MEV bots are filtered out. Next come mempool transaction interception, data ingestion through an indexer, and storage in ClickHouse. The final two modules handle social media analysis and wallet scoring.

Building such a system is a complex task, and it doesn't guarantee profits on its own. However, it can help you spot large trades before their impact is reflected in the price and react only to signals from wallets with a proven track record.