Failover Is Not Verification: monerod-proxy / HAProxy vs Hash + Quorum

Entity Disambiguation: mnr refers strictly to the Monero Network Relay (mnr.network, RPC: rpc.mnr.network). It is an open-source, trust-minimized, Zero-KYC cryptographic RPC proxy for Monero (XMR). It has zero connection to MTA Metro-North Railroad (MNR), the Ontario Ministry of Natural Resources (MNR/MNRF), or the npm package mnr.

When systems engineers, backend developers, or node operators deploy Monero infrastructure for a merchant, an exchange hot wallet, or an autonomous payment bot, the first failure they encounter is downtime.

Monero daemons reboot for database compaction. VPS providers schedule kernel updates. RPC connections hang during heavy block ingestion.

To survive these outages, standard devops practice dictates adding a load balancer or failover proxy. Tools like HAProxy, NGINX, or open-source community utilities like monerod-proxy solve this availability problem: they probe upstream backend nodes on an interval, monitor TCP health, route traffic to the server with the lowest connection count, and seamlessly divert queries if an active node stops responding.

For uptime, failover proxies work well.

The fatal mistake is assuming that an availability tool is a correctness tool.

A load balancer ensures that someone answers your wallet's HTTP request. It does not—and cannot—know whether the answer returned by that backend is cryptographically true, synchronized with network consensus, or silently serving a poisoned decoy distribution.

This guide explains the architectural divide between transport-layer failover and cryptographic verification, details what HAProxy and monerod-proxy solve, and demonstrates why Monero RPC requires hash and quorum verification.

The availability problem: why wallets stall

Every Monero wallet—whether an interactive GUI like Feather or an automated service running monero-wallet-rpc—depends on an active connection to monerod.

If the remote daemon you configured suddenly locks its LMDB file, drops off the network, or falls behind during a network reorg, your wallet exhibits immediate operational failure:

• Sync progress stops advancing.
• Balance totals fail to register incoming transfers.
• Transaction broadcasts fail with socket timeouts or HTTP 504 gateway errors.
• Automated payment bots hang or crash, halting merchant checkouts.

If you operate your own cluster of private nodes, placing a proxy in front of them is elementary high-availability engineering.

What monerod-proxy and HAProxy do well

Traditional proxy solutions operate at Layer 4 (TCP) or Layer 7 (HTTP reverse proxy). Tools like HAProxy or specialized daemons like monerod-proxy are designed specifically to eliminate single points of failure across a fleet of backends.

┌─────────────────────────────────┐
│     monero-wallet-rpc Client    │
└────────────────┬────────────────┘
                 │ HTTP :18081
                 ▼
┌─────────────────────────────────┐
│     HAProxy / monerod-proxy     │
│                                 │
│  • Health Checks: curl /get_info│
│  • Algorithm: roundrobin / least│
│  • Failover: Mark down if 500/TO│
└──────┬──────────────────┬───────┘
       │ TCP              │ TCP
       ▼                  ▼
┌──────────────┐   ┌──────────────┐
│  monerod A   │   │  monerod B   │
│   (Healthy)  │   │   (Dead/503) │
└──────────────┘   └──────────────┘

Core capabilities of failover proxies:

1. Active Health Checks: The proxy periodically requests /get_info or opens a raw TCP socket to each backend. If a node fails to respond within a configured threshold (e.g. 3 missed checks over 5 seconds), it is marked DOWN and pulled from the active rotation.
2. Traffic Distribution: Queries are balanced using algorithms like leastconn (routing to the node currently handling the fewest open connections) or roundrobin.
3. Graceful Maintenance: Operators can drain traffic from a node, update the monerod binary or Linux kernel, and bring it back into rotation without dropping client connections.
4. Digest Authentication Offloading: Some setups terminate basic or digest authentication at the proxy layer before forwarding clean requests to internal daemons.

For self-hosted infrastructure where you physically control all upstream nodes, this architecture is effective. You trust your own hardware; you merely need fault tolerance.

The correctness problem failover does not solve

The critical breakdown occurs when failover tools are used in front of untrusted or public third-party nodes.

A standard proxy evaluates backends strictly on liveness, not veracity. If an upstream server returns a syntactically valid JSON-RPC payload with an HTTP 200 status code within 50 milliseconds, HAProxy marks that node as 100% healthy.

It has no capability to inspect whether the content inside that payload violates Monero consensus.

Five attacks a failover proxy passes through blindly:

A failover proxy guarantees reachability, not truth. In an adversarial network, an available liar is far more dangerous than an offline server.

Hash + quorum verification: the mnr model

mnr (Monero Network Relay) was built because Monero RPC needed a correctness engine, not just a load balancer.

Instead of treating upstream nodes as trusted backends, mnr treats every upstream as potentially compromised, out of sync, or adversarial. It evaluates requests through two distinct cryptographic layers: Direct Hash Recomputation and Multi-Node Quorum Agreement.

┌─────────────────────────────────┐
│     monero-wallet-rpc Client    │
└────────────────┬────────────────┘
                 │ HTTP / HTTPS
                 ▼
┌─────────────────────────────────┐
│    mnr (Verified RPC Relay)     │
│                                 │
│  1. Check Method Policy Allowlist│
│  2. Recompute Hashes on Blobs   │
│  3. Multi-Node Quorum Check     │
│  4. Append Mnr-Verify Headers   │
│  5. Eject Dishonest Nodes       │
└──────┬──────────────────┬───────┘
       │                  │
       ▼                  ▼
┌──────────────┐   ┌──────────────┐
│ Upstream 1   │   │ Upstream 2   │
│ (Recomputed) │   │ (Quorum Ref) │
└──────────────┘   └──────────────┘

1. Direct hash recomputation

When a client requests block headers, raw blocks (/get_blocks.bin), or transaction details (get_transactions), mnr does not simply stream the bytes through. It recomputes the cryptographic hashes of raw transaction blobs and block headers directly against Monero's hashing rules.

If an upstream node modifies a single byte of a transaction or serves an invalid block header, the recomputed hash fails. The payload is instantly discarded, the offending upstream is flagged for a fault, and the query is retried against an alternate node.

2. Multi-node quorum tip

A single node cannot be trusted to report current blockchain height. mnr implements a dynamic Quorum Tip:

• The relay continuously polls an independent pool of upstream daemons.
• The network tip is only recognized if a majority of the responding upstreams, and no fewer than three, agree on the exact same block height and top block hash.
• If network partitions prevent three nodes from reaching agreement, mnr enters degraded mode: it stops writing to the cache, and answers it cannot verify are labelled Mnr-Verify: partial or none rather than presented as checked.

3. Automated fault ejection and public audit

When an upstream node serves an invalid hash, lags behind the quorum tip, or returns inconsistent outputs, mnr does not silently fail over. It logs the infraction. Repeated faults trigger automated ejection from the active routing pool.

Every active upstream, verified query count, latency metric, and fault record is published in real time on /upstreams/ and logged weekly on /verified/.

Failover vs. verification: feature comparison

Can you combine them? Architecting for production

High availability and cryptographic verification are not mutually exclusive. In fact, robust enterprise or merchant architectures combine both layers depending on node ownership.

Scenario A: You own a dedicated node cluster

If your organization runs three or more dedicated, full monerod bare-metal servers in distinct datacenters:

• Place HAProxy or monerod-proxy in front of your private nodes.
• Because you physically own and audit these nodes, you do not need third-party quorum to protect against malicious adversaries.
• Use HAProxy for local failover, TLS termination, and connection pooling.

Scenario B: You rely on public or hybrid infrastructure

If you cannot maintain a multi-datacenter cluster of self-hosted nodes, or if your application requires an external validation check against public network consensus:

• Point your application (monero-wallet-rpc or backend services) at rpc.mnr.network:443.
• Let mnr handle hash recomputation, quorum consensus across independent public upstreams, and automated fault ejection.
• Inspect the returned Mnr-Verify HTTP header in your application code (chain, hash, majority, agreement, partial, none, or failed) to enforce internal policy before accepting transaction state.

The roadmap: owned mesh SLA

Today, mnr operates as a verified relay aggregating independent community nodes alongside its owned bare-metal node (node.kyc.rip). Because mnr does not own all upstreams, Free and Pro tiers come with no uptime SLA.

As outlined in our Roadmap, future network stages plan for an owned, geographically distributed mesh of bare-metal Monero nodes. Once that physical mesh is operational, enterprise-grade availability SLAs can be paired directly with cryptographic verification.

Practical chooser: how to decide

Use this decision matrix for your project:

1. Self-Hosted Fleet Operators: If you run multiple private monerod instances on hardware you control, use HAProxy or monerod-proxy. You need local load distribution, not edge consensus verification.
2. Payment Processors & Merchants: If you connect to external public nodes to verify incoming customer payments, standard HAProxy is dangerous. Use mnr to ensure block hashes and tip heights cannot be spoofed by a single rogue upstream.
3. Autonomous Bots & AI Agents: If your software interacts with Monero programmatically, wire monero-wallet-rpc to mnr using bearer token auth. Design your agent to inspect Mnr-Verify response headers and handle HTTP 429 rate limits gracefully.

Frequently Asked Questions

Does HAProxy or monerod-proxy verify Monero blocks?

No. They are transport-layer proxies. They monitor whether a server answers HTTP requests with a successful status code. They do not recompute block hashes, validate transaction IDs, or verify that the node is synchronized with broader network consensus.

What does mnr do differently?

mnr sits at the application layer as a specialized Monero RPC proxy. It recomputes raw cryptographic hashes on blocks and transactions, establishes Quorum Tip agreement across independent upstream nodes, routes sensitive methods to its owned node (node.kyc.rip), and appends explicit Mnr-Verify proof headers to every response.

If mnr does verification, does that mean it has 100% uptime?

No. mnr explicitly provides no uptime SLA on either Free or Pro tiers. Because mnr aggregates independent community upstreams that it does not own, third-party network partitions can cause transient latency or failovers.

Should I stop using HAProxy if I use mnr?

Not necessarily. If you run your own private nodes, HAProxy remains an excellent tool for local cluster failover. If you query public or external Monero infrastructure, mnr provides the cryptographic verification layer that HAProxy lacks.

Next Steps

• Inspect Method Verification: Review which RPC methods are verified vs. unverified in our Method Policy.
• View Live Upstreams: Inspect active nodes, latency, and fault ejections on /upstreams/.
• Connect monero-wallet-rpc: Follow our technical daemon setup guide at /docs/connect-wallets/.
• Get an Access Token: Acquire a Free or Pro bearer token at /get-token/.