What it is

- A backend-facing JSON-RPC 2.0 service that sits between application code and Ethereum nodes

- Handles common infra concerns: address generation, transaction submission, confirmation tracking, basic monitoring

- Intended to be run as a standalone service alongside a local or remote Ethereum node

Why we built it

- Direct JSON-RPC usage from backend services repeatedly led to duplicated logic: retries, nonce handling, tx lifecycle tracking, error normalization

- We wanted a thin, explicit layer that centralizes this logic instead of spreading it across multiple services

Design choices

- Written in Go as a long-running service

- JSON-RPC 2.0 API to stay compatible with existing backend patterns

- Supports IPC for local nodes (preferred for latency and security)

- Event delivery is at-least-once (clients must deduplicate)

- No Docker-first setup (IPC + containers adds operational complexity)

Conscious limitations

- Not a node replacement

- Not an indexer

- Not intended for public or untrusted exposure

- Does not try to abstract all Ethereum complexity away

- Requires backend teams to handle idempotency and state consistency

Where it likely does NOT fit

- Frontend or client-side usage

- High-level dApp frameworks

- Teams looking for fully managed RPC or hosted infrastructure

- Systems that require exactly-once guarantees without client logic

We’re sharing this mainly to get architectural and operational feedback:

- Are the trade-offs reasonable?

- Where would this approach break at scale?

- What obvious edge cases or failure modes are missing?

Repo: https://github.com/ITProLabDev/ethbacknode

Open to critique — especially from people who’ve operated Ethereum infra in production.