EthBackNode: why does your application need a “spacer” between it and the Ethereum node

If you have ever tried to write a crypto-wallet, a payment gateway, or simply a “backend that can send and receive ETH,” then an unpleasant thing quickly becomes clear: the Ethereum node is not your backend

This is a powerful piece of infrastructure that speaks to you in a protocol language (JSON-RPC), and does not have to be convenient for product development.

On paper, everything looks trivial: “connect to geth, request balance, send transaction, receive hash.” But in practice, you suddenly start writing what you would like not to write:

• where to store keys and how to issue them with addresses,
• how to restore a wallet using a seed phrase,
• how to track incoming/outgoing transactions across a large pool of addresses
• how to make “real-time” notifications rather than endless polling
• how all this survives a service restart and does not lose its state.

This is where EthBackNode appears - an open-source service in Go that plays the role of an “adapter” between your application and the Ethereum node, and provides pure JSON-RPC 2.0 API for standard backend tasks.

Why living directly with Ethereum JSON-RPC is difficult (and sometimes expensive)

Ethereum JSON-RPC is a good thing, but low-level. It shows the capabilities of the node, and does not answer the question “how to make a product.” When integrating, you quickly realize that the same task is divided into a dozen small tasks, and half of them are not about blockchain at all.

For example, “accept payment to the address”:

1. You need to give the client an address.
2. You need to make sure that the address is associated with a specific order/invoice.
3. You need to monitor the network and understand that the transaction has actually arrived.
4. You need to wait for confirmation (and remember that there are reorganizations).
5. You need to send an event to your backend: “payment has been received, you can ship.”
6. We need to save this entire state so that restarting the service does not pretend that “nothing happened.”

If you have one order a day, you can do it on your knees. If you have dozens/hundreds of addresses and this is at least somewhat critical for business, engineering begins.

And here it is important to note: the average backend developer usually wants exactly one thing - a predictable API, understandable events and a minimal attack surface. And not immersion in the intricacies of “how the knot works.”

What does EthBackNode do

EthBackNode is a “light” service that you install next to the node (or connect to it), and your application already communicates with it. From the outside it looks like one JSON-RPC 2..0 endpoint, inside - a set of modules (managers) responsible for addresses, subscriptions, transactions and smart contracts.

Key features it provides via the API:

1) Address generation and management

The service can create and maintain addresses on the backend side. The important thing is not that “the address can be generated” (you can do it yourself), but that there is a single place where the address lives as an entity: binding to your userId / invoiceId, storage, recovery.

2) Restoring wallets using seed phrase (BIP-39/44)

A separate pain is importing and restoring wallets. EthBackNode provides work with seed phrase (BIP-39) and derivation (BIP-44) so that you can build “normal” recovery scenarios without your own bike.

3) Monitoring of incoming/outgoing transactions

The most practical part: monitoring addresses. The service takes on the task of “monitoring these addresses and reporting when something happens.” That is, you do not turn your application into a block scanner, and do not write the subscription logic again.

4) Transfers: ETH and ERC-20

EthBackNode allows you to transfer both native ETH and ERC-20 tokens. To the backend, this looks like a single “transfer” operation, rather than a separate set of low-level calls and checks. Plus, there is a fee estimation - without it, you are either “guessing” or making additional requests yourself.

5) Callback notifications about events

Perhaps, what really saves nerves: event notifications. Instead of asking “has it arrived?” every N seconds, you can set up a callback and receive the “there was a transaction / new block / confirmation” event in your backend.

Architectural details that look boring but solve half the problems

In such services, what is usually important is not “a lot of features”, but how it will live in operation.

Go + fasthttp

Performance and ease of deployment. One binary, quick start, understandable load. In crypto backends, this is not an abstract “optimization”, but a banal necessity: many addresses, many events, many requests.

Connecting to a node: HTTP-RPC and IPC

EthBackNode supports working with the node both via HTTP-RPC and via an IPC socket. IPC is often chosen when the service and geth live on the same machine: there is less network surface, fewer problems with access configuration, and often it is simply more reliable..

BadgerDB as embedded storage

Another pragmatic choice: built-in database, without the mandatory external Postgres/Redis at the start. This greatly lowers the threshold: you can raise a service, give it a directory for data, and it will store its state itself.

Configuration in HCL

HCL is a human format from the “Hashicorp world”. It is friendly with the infrastructure approach (Git, reviews, environments), and at the same time is easier to read than 200-line JSON configs.

Modularity: managers of addresses, subscriptions, transactions, contracts

This is more important than it seems. When you have everything in one place, every change becomes risky. When there are clear boundaries, it’s easier to test, easier to expand, easier to understand.

Where is it really useful

EthBackNode is not trying to be a “universal indexer” or analytics platform. His niche is application backend for products.

• Payment processors: issuance of deposit addresses, payment monitoring, notifications, subsequent withdrawals/sweeps.
• Custodial wallets: pool of addresses, withdrawal of funds, status tracking.
• Notification services: one component monitors the network, the rest receive events.
• Backend-for-frontend: mobile/web API does not know about the blockchain - only knows about business events.
• Exchanges and services with multiple addresses: mass monitoring of deposits without a self-written “scanner of the entire blockchain.”

A small example: what it would look like in an online store

Let's say you have a small e-commerce and you want to accept payments in ETH and one popular ERC-20 stablecoin.

The scenario could be like this:

1. The user places an order → your backend creates an orderId.
2. The backend asks EthBackNode for a new address for this order.
3. The backend registers a callback URL: “if something arrived at this address, let me know.”
4. The user pays.
5. EthBackNode sees the transaction and sends an event to your callback: amount, token, hash, status.
6. You wait for the required number of confirmations and transfer the order to the “paid” state.
7. On a schedule (or immediately) you withdraw funds to the main storage address.

As a result, the “crypto part” stops spreading throughout your store’s code. It lives in one service, where it is logical to maintain and test it..

Why is this important (no slogans)

Web3 has a lot of complexities that are not “blockchain magic.” It's just engineering routine: addresses, keys, subscriptions, transaction status, confirmations, notifications, state storage.

EthBackNode lowers the entry barrier for regular backend commands: instead of talking to the node in its language, you talk to the service in the task language. And this is perhaps the most useful form of “abstraction” in applied crypto development: not to hide the blockchain, but to make its operation predictable.

If you have a product that needs to reliably receive and send ETH/ERC-20, and you don’t want to turn the main code into a set of crutches around JSON-RPC, such an adapter layer does not seem like a luxury, but common sense.

According to itprolab.dev