There is a moment in almost every Ethereum developer’s journey when they realize that subscribing to eth_subscribe(“newPendingTransactions”) over WebSocket is not actually giving them real-time access to the mempool. What it provides instead is a delayed view—transactions that have already passed basic validation, been accepted into the node’s transaction pool, and exposed through RPC interfaces. By the time your subscriber receives the event, the transaction is no longer “new” in any meaningful sense from the node’s perspective.
This distinction becomes critically important when you are working on systems where timing, ordering, or early access to transaction data matters. By the time a transaction is visible through standard APIs, it has already entered the competitive environment of the mempool, where ordering, propagation, and inclusion dynamics are already in motion.
This tutorial explains how to hook directly into the transaction pipeline of go-ethereum at the moment a transaction enters your node. More specifically, you will intercept transactions before they are accepted into your node’s local transaction pool, before they are exposed through RPC or WebSocket interfaces, and before your node has propagated them further across the peer-to-peer network.
It is important to be precise about what this means. This approach does not give you global first access to transactions across the Ethereum network. Transactions may already exist in other nodes’ mempools or have propagated through parts of the network before reaching your node. What this technique gives you is the earliest possible access within the execution pipeline of your own node.
Working at this layer requires going beyond standard library usage. There is no plugin system or middleware hook in go-ethereum that allows this kind of interception. Instead, you must fork the client, extend its transaction pool architecture, and run your own modified binary. While this introduces operational overhead, it also unlocks a level of control that is otherwise inaccessible.
By the end of this tutorial, you will understand how the transaction pool in go-ethereum is structured, how to extend it safely, and how to implement a reusable interception layer that can power real-world systems such as compliance filters, protocol-specific detectors, and low-latency analytics pipelines.
Why Node-Level Interception Matters
Most developers who want to observe Ethereum transactions rely on well-established tools such as eth_subscribe, eth_newPendingTransactions, or third-party infrastructure providers. These tools are reliable, easy to use, and sufficient for a wide range of applications, including dashboards, alerts, and general analytics.
However, there exists a category of problems where observing transactions after they enter the mempool is fundamentally too late. These problems tend to arise in systems where control, latency, or determinism are critical.
For example, if you are operating a compliance layer for an institutional node, you may need to evaluate every incoming transaction against a sanctions list or internal policy before it is even admitted into your node’s pool. Rejecting or flagging transactions after they have already been queued may not meet regulatory or operational requirements.
In another scenario, if you are building MEV infrastructure, even small amounts of latency introduced by WebSocket subscriptions or external APIs can materially impact performance. In such systems, being able to observe and process transactions at the earliest possible point inside the node can provide a meaningful advantage.
Similarly, if your goal is to build a high-throughput analytics pipeline, you may want to extract structured transaction data such as calldata, fee parameters, and sender information in a single pass, without the overhead of external subscriptions or redundant decoding layers. Doing this inside the node allows you to minimize copying, reduce latency, and maintain tighter control over data flow.
There are also more advanced use cases, such as building private transaction pools or implementing custom validation logic for specialized transaction types. These require direct interaction with the node’s internal transaction handling mechanisms, which cannot be achieved through external APIs.
Flashbots’ research found that MEV extraction grew over 300x in absolute dollar terms between January 2020 and January 2021. The infrastructure enabling that extraction, private transaction pools, bundle simulation, node-level ordering hooks, all lives at exactly this layer of the stack.
Understanding the Scope and Limitations
Before diving into implementation details, it is essential to clearly define what this approach does and does not provide.
Intercepting transactions at the node level allows you to observe them before they are accepted into your node’s local transaction pool. This means you can act on them before they are queued, indexed, or exposed through standard RPC interfaces. It also allows you to run custom logic in the same execution context as the transaction pool itself.
However, this does not imply that the transaction is globally unseen or private. Ethereum operates as a distributed peer-to-peer network, and transactions propagate across nodes independently. By the time a transaction reaches your node, it may already have been seen, validated, or even propagated by others.
What you gain is not global exclusivity, but local priority within your own infrastructure. For many systems, that distinction is exactly what matters.
How the go-ethereum Transaction Pool Works
To effectively extend the transaction pipeline, you need to understand how it is structured internally.
In go-ethereum, the transaction pool is not a single monolithic structure. Instead, it is implemented as an aggregator called TxPool, which coordinates multiple subpools. Each subpool is responsible for handling a specific category of transactions and implements a shared interface that defines how transactions are filtered, validated, and stored.
Out of the box, go-ethereum includes two primary subpools. The first is the legacy pool, which handles standard transactions including both pre-EIP-1559 and EIP-1559 formats. This is where the vast majority of transactions are processed. The second is the blob pool, introduced with EIP-4844, which handles blob-carrying transactions used for data availability in Layer 2 systems.
When a transaction arrives at the node either from the peer-to-peer network or via a local RPC call, it is passed into the TxPool. The pool then iterates through its list of subpools and calls the Filter() method on each one. The first subpool that returns true claims the transaction and becomes responsible for processing it.
This modular architecture is what makes interception possible. By introducing a custom subpool into this pipeline, you can observe transactions as they flow through the system.
Extending the Pipeline with an Interceptor
The key idea behind this approach is to implement a custom subpool that acts as an observer rather than a claimant. Instead of taking ownership of transactions, this subpool simply inspects them and passes them along to the appropriate default pool.
This is achieved by implementing the SubPool interface and ensuring that the Filter() method always returns false. By doing so, your interceptor does not claim any transactions, allowing the standard pools to continue functioning normally.
At the same time, because your subpool is registered within the transaction pool, it participates in the transaction processing flow. In current versions of go-ethereum, this allows the interceptor’s Add() method to be invoked for incoming transactions, enabling you to run custom logic at a very early stage.
It is important to note that this behavior is not part of a formally stable extension API. The exact invocation order and mechanics may change between versions of go-ethereum, so it is essential to validate your implementation against the specific version you are using.
Forking and Maintaining go-ethereum
Implementing this approach requires modifying the source code of go-ethereum. There is no supported plugin system that allows external code to hook into the transaction pipeline at this level.
This means you must fork the repository, apply your changes, and build your own version of the client. While this is straightforward from a technical perspective, it introduces ongoing maintenance responsibilities.
The go-ethereum codebase evolves frequently, and changes to the transaction pool are not uncommon. Keeping your fork up to date requires regularly merging upstream changes, resolving conflicts, and ensuring that your modifications remain compatible. Additionally, you must stay current with security updates, as running an outdated client can expose your node to risks.
For production systems, this maintenance overhead should be treated as a first-class concern rather than an afterthought.
Designing the Interceptor Pool
At the core of the implementation is a struct that satisfies the SubPool interface and delegates transaction processing to a user-defined handler function.
The handler is defined as a function that receives a transaction and its sender address. This design keeps the interception logic modular and testable, allowing you to swap implementations without modifying the underlying plumbing.
The interceptor maintains minimal internal state, including the current chain head and a signer used to recover sender addresses from transactions. Synchronization primitives such as mutexes are used to ensure safe access to shared state across goroutines.
The most important method in this implementation is Add(), which serves as the interception point. For each incoming transaction, the interceptor recovers the sender address and invokes the handler. The handler can then perform any desired logic, such as logging, filtering, or forwarding data to external systems.
Crucially, the interceptor does not block or reject transactions by default. It returns nil errors, allowing the normal transaction processing pipeline to continue uninterrupted. If you want to implement hard rejection, additional modifications to the transaction routing logic would be required.
Wiring the Interceptor into the Node
To activate the interceptor, it must be registered as a subpool within the TxPool. This is done by modifying the part of the codebase where the transaction pool is instantiated and inserting your interceptor at the beginning of the subpool list.
The order is important. By placing the interceptor first, you ensure that it observes transactions before they are processed by the default pools. At the same time, because it does not claim transactions, it does not interfere with normal routing.
Once integrated, you can build the modified client and run it on a local development network. From there, sending transactions to the node will trigger your interceptor logic, allowing you to verify that it behaves as expected.
Practical Patterns for Real-World Use
With the interception mechanism in place, you can implement a variety of practical patterns.
A compliance blocklist is one of the simplest use cases. By maintaining a set of blocked addresses, you can flag or log transactions originating from those addresses before they enter your node’s pool. This can be extended to integrate with external data sources or regulatory APIs.
Another common pattern is protocol-specific detection. For example, by inspecting the first four bytes of transaction calldata, you can identify function selectors associated with protocols like Uniswap and detect swap operations in real time. This forms the basis of many on-chain analytics systems.
For high-throughput analytics, an asynchronous processing model is essential. Instead of performing heavy computation or I/O directly in the interceptor, you can enqueue lightweight events into a buffered channel and process them in a separate goroutine. This ensures that the transaction pipeline remains fast and responsive, even under high load.
Concurrency, Performance, and Safety
The transaction pool operates in a performance-critical part of the node. Any logic you introduce here must be carefully designed to avoid degrading throughput or stability.
Handlers are executed synchronously as part of transaction processing, so they must be extremely fast. As a general rule, synchronous execution should be limited to simple in-memory operations such as map lookups or channel sends. Any expensive work should be offloaded to background workers.
Concurrency is another important consideration. Your handler may be invoked from multiple goroutines, so any shared state must be properly synchronized using mutexes or other concurrency primitives.
Memory management also plays a role. Retaining references to full transaction objects can prevent them from being garbage collected, leading to increased memory usage over time. To avoid this, you should copy only the fields you actually need and discard the rest.
Finally, it is important to consider security implications. Poorly implemented handlers can introduce denial-of-service risks by blocking the transaction pipeline or consuming excessive resources. Treat this layer as production-critical infrastructure and design accordingly.
When Not to Use This Approach
Despite its power, this approach is not appropriate for every use case.
If your goal is simply to monitor transactions for analytics or user-facing applications, standard APIs and third-party services are usually sufficient and significantly easier to maintain. Similarly, if you do not control the node infrastructure or cannot commit to maintaining a fork of go-ethereum, this approach may introduce more complexity than it is worth.
In general, node-level interception should be reserved for systems where early access, low latency, or deep integration with the transaction pipeline is a strict requirement.
What This Unlocks
By extending the transaction pool in this way, you gain access to a powerful architectural layer that underpins many advanced Ethereum systems.
This includes MEV infrastructure, private transaction pools, compliance enforcement systems, and real-time analytics pipelines. These systems all rely on the ability to observe and act on transactions at the earliest possible point within the node.
Other Ethereum clients, such as Reth, explore similar ideas with different design philosophies and extensibility models. Understanding how these patterns translate across clients can provide additional insight into the evolving architecture of Ethereum nodes.
Conclusion
Hooking into the transaction pipeline of go-ethereum allows you to intercept transactions at the moment they enter your node, before they are accepted into the local transaction pool and exposed through standard interfaces. While this does not provide global first access, it offers the earliest possible visibility within your own infrastructure.
Implementing this capability requires forking and maintaining go-ethereum, as well as carefully designing your interception logic to meet strict performance and safety requirements. However, for systems that depend on low latency, fine-grained control, or deep integration with the node, the benefits can be substantial.
The approach outlined in this tutorial provides a foundation that you can build upon. Whether you are developing compliance tools, analytics pipelines, or advanced transaction handling systems, understanding this layer of the Ethereum stack opens the door to a new class of possibilities.
How to Hook Into go-ethereum Before a Transaction Reaches Your Node’s TxPool was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.