mnr — Stage 0 MVP Plan

a verified proxy over public Monero nodes, plus one of our own

1. What Stage 0 is, in one paragraph

A single Rust binary, mnr-relay, on one VPS. It accepts Monero daemon RPC at rpc.mnr.network (and a .onion), authenticates a path token, applies the method policy from the gateway plan, caches what is safe to cache, fans out writes, and forwards everything else to a pool of upstreams. The pool is public nodes that already serve the community, plus one node we run and list publicly ourselves. Every answer that can be checked is checked — block and tx hashes, header linkage, height agreement across upstreams — so the proxy is more trustworthy than any single public node a wallet would otherwise pick blindly. It says exactly this on its front page. It is free, with a cheap Pro tier for people who want higher limits, and it makes no availability promise, because we do not run most of the nodes.

What it is not: not a gateway (no SLA, no owned mesh), not a network (no operator agent, no settlement), not a way to resell other people's nodes at Business prices. Those are Stages 1 and 2, and the gate to each is in §9.

2. Rules toward public nodes (non-negotiable; they are the ethics of Stage 0)

1. Disclose. The front page, the docs and the User-Agent say what this is. Upstream list is public at mnr.network/upstreams with each node's current status and our request rate to it.
2. Contribute. Our own node is a full node, listed on the public node lists, open to the public with the same restricted RPC everyone else offers, and it carries the heaviest traffic class (wallet-sync streams) by preference so public nodes see light calls from us, not floods.
3. Cap ourselves. Per-upstream ceilings: 5 rps light calls, 2 concurrent get_blocks.bin streams, 10 MB/s. Above that, requests queue or go to our own node. These caps are config, published, and stricter than what most public nodes would tolerate.
4. Identify. User-Agent: mnr-relay/0.x (+https://mnr.network/upstreams) on every upstream request so an operator can see who we are and how to reach us.
5. Honour opt-out. Any node operator who asks is removed within 24 hours; the opt-out list is public. We also check a /.well-known/mnr-optout on each upstream host daily so operators can remove themselves without contacting us.
6. Never pass client identity. No client IP, no X-Forwarded-For, no token, nothing but the RPC body reaches an upstream.
7. Use restricted RPC only. The policy table's allow-list is enforced before dispatch; we never call admin methods on anyone's node.

The disclosure paragraph for the front page, verbatim:

mnr is a verified proxy. Your wallet's requests are forwarded to public Monero nodes run by community members, and to our own public node. We check every block, transaction and header we return against its hash and against several nodes, so you get a better answer than any single node gives — but the nodes are not ours, and we make no uptime promise. We cap our traffic to each public node, identify ourselves to operators, honour opt-outs, and publish the full upstream list. If you need nodes we run ourselves, with an SLA, that is a separate paid service coming later.

3. Upstream pool

4. Verification at Stage 0

Reused from the network doc §3.4, trimmed to what one box can do:

Verified request counts and fault counts per upstream are the numbers on the public upstreams page. This is the feature: "we caught node X serving a wrong header on Tuesday, here's the proof" is what makes people trust the proxy over a raw public node.

5. Method policy, caching, auth, limits

• Method policy: the gateway plan §3.3 table as-is, compiled into mnr-core::policy.
• Cache: in-memory (moka, 1 GB cap) for SWR and immutable-below-tip−10; on-disk store deferred to Stage 1.
• Auth: path token /v1/<token>/… and Basic auth alternative, 256-bit, hashed at rest in SQLite; rotation endpoint with 24 h grace. Free tokens are issued instantly from the site; no email.
• Limits: in-process token bucket per token; daily WU quota in SQLite.

$9 is deliberately a supporter price. It pays the two boxes at ~15 subscribers, and it tests the only question Stage 0 needs to answer: will anyone pay for verification and convenience over nodes they could use for free?

• Payments: view-only monero-wallet-rpc on the relayer box, subaddress per invoice, activation at 10 confirmations, renewals extend valid_until. XMR402 flow deferred to Stage 1 unless Ripley wants it in week 4.
• Logging: no request logs; aggregate metrics only; token hash prefix in error samples. The gateway plan §3.6 policy applies.

6. Architecture (one binary, one box)

clients ──▶ rpc.mnr.network (TLS, axum) ──┐
clients ──▶ <onion>.onion (local tor)  ───┤
                                          ▼
                     mnr-relay ──── auth (SQLite) ── limits ── policy ── cache ── verify
                                          │
                       ┌──────────────────┼───────────────────────┐
                       ▼                  ▼                       ▼
              owned node (WireGuard)   public clearnet nodes   public .onion nodes (via tor SOCKS)
              full, --public-node      HTTPS/HTTP, capped      light calls only, 8 s timeout

background: prober (15 s) · header-chain sync · cache epoch on reorg · invoice watcher (wallet-rpc) · metrics (/metrics, Prometheus)

Crates: mnr-core (policy, hash, verify, header chain — the same crate the network doc specifies) and mnr-relay (everything else). No agent, no directory, no settlement. Config is one TOML file; upstreams are a list with kind: owned | public, transport: https | http | onion, and per-node caps.

Relayer box: 4 vCPU / 8 GB / 80 GB NVMe (header chain + SQLite + cache). Owned node: 8 vCPU / 32 GB / 1 TB NVMe on a different provider, in the sizing of the gateway plan §4.

7. Four-week build

Exit criteria for "MVP shipped": a stock CLI wallet and Feather sync from scratch through rpc.mnr.network; injected wrong-header test from a fake upstream produces an ejection and a public log entry; owned node listed on public node lists and serving outsiders; no request logs anywhere; upstream caps demonstrably enforced under load; at least 10 identified upstream operators informed, zero unresolved opt-outs.

8. Risks specific to Stage 0

9. Gates to the next stages

Collect three numbers weekly from week 6: paying Pro tokens, WU served per day (split owned/public), and backends asking for an SLA (any client who asks "what uptime do you guarantee?" is a tally mark).

• Go to Stage 1 (gateway: two more owned nodes, Business tier, SLA credits) when either five backends have asked for an SLA, or the owned node serves > 60% of WU for four consecutive weeks, or Pro revenue covers two more boxes. The gateway plan is the spec; its M1 starts the day the boxes are ordered.
• Go to Stage 2 (mnr network: operator agent, settlement, directory) when either three public-node operators ask to be paid or to plug in formally, or a partner (wallet, hosting business) wants to run their own relayer on our binary. The network architecture doc is the spec; P1 starts from a working relayer rather than from zero, which removes roughly a quarter of its schedule.
• Stay at Stage 0 if none of the above within 12 weeks of public beta — in which case the proxy remains a maintained public good at $90/month, and the business question is answered honestly.

10. Decisions for the two of you this week

1. Confirm the $9 Pro price and Free allowance (500k WU/month).
2. Provider for the owned node (different from the relayer VPS's provider).
3. Whether to require two-upstream get_outs agreement for Free as well (safer, roughly halves Free capacity).
4. Who signs the upstream-operator notices (B, in their own name or the project's).
5. Whether to include .onion upstreams at launch or in week 5 (they add Tor plumbing to week 4).