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.