The SV2 mining gateway
for production pools

Template verification, Noise NX encryption, fail-closed prevhash switching, and a two-event share lifecycle. Every decision carries a machine-readable reason code.

Explore ReserveGrid OS Read the docs
bitcoind
:18443
template-manager
:8082
sv2-gateway
Noise NX · Channels · Shares
:3333
pool-verifier
:8081
rg-dashboard
:8084
73
GatewayReason codes
50ms
Verdict timeout
ReserveGrid OS
v1.0.2 · Stratum V2 Gateway
3
Deployment modes
2
Share lifecycle events
The problem

SV2 enables miner autonomy.
That autonomy needs guardrails.

Without ReserveGrid

Blind template acceptance Miners propose templates the pool cannot inspect. Malformed transactions, fee violations, and duplicate inputs pass through unchecked.
Stale prevhash exposure When a new block arrives, miners keep working on stale references until they notice. No fail-closed cutoff.
No audit trail Rejections happen silently. No structured reason codes, no metrics, no way to debug why shares fail.

With ReserveGrid

Policy-driven verification Every template checked against 51 configurable TOML keys. Fee thresholds, sigops limits, transaction counts, weight bounds.
Fail-closed prevhash with dual buffering Two pending templates held simultaneously during block transitions. 50ms verdict timeout, 5s stale hold. No gap in coverage, no silent fallback.
100% traceable decisions Every rejection carries a machine-readable reason_code, policy context, and share_id. Dashboards key off the same codes.
Architecture

End-to-end gateway flow

From miner handshake to upstream share submission, every hop is observable.

Noise NX TCP/NDJSON RPC Miner SV2 client sv2-gateway ReserveGrid OS pool-verifier template-manager Upstream poller bitcoind Block templates shares → pool backend (HTTP POST)
The gateway also forwards valid shares upstream via HTTP POST to the pool backend. Shares flow through a bounded queue with configurable backpressure policy.
Capabilities

What the gateway handles

Progressive deployment

Shadow evaluates policy without miners. Observe monitors real traffic without gating. Both lead to inline enforcement. One binary, one config key.

mode = "shadow" | "observe" | "inline" See modes

Two-event share lifecycle

Every share produces share_accepted at ACK and share_forward_result after upstream POST. Joined by share_id with a 1:1 invariant.

share_id: a7c3…e1 See pipeline

Fail-closed prevhash

When a new block arrives, miners hold on stale work until the verifier responds. 50ms verdict timeout, 5s stale hold, deterministic disconnect on expiry.

prevhash_timeout_ms = 50 See timing
In practice

See how these capabilities
compare to the alternatives

Scroll to continue

Comparison

What changes with ReserveGrid

Capability Traditional pool SV2 without ReserveGrid SV2 + ReserveGrid
Miner transport encryption ✗ Plaintext ✓ Noise NX ✓ Noise NX
Template verification ○ Pool-side only ✗ None ✓ Policy-driven, 73 reason codes
Prevhash safety ○ Implicit ✗ No verification gate ✓ Fail-closed, 50ms + 5s hold
Share audit trail ✗ Pool internal ✗ None at gateway ✓ Two-event lifecycle with HMAC
Reject traceability ✗ Opaque ✗ SV2 wire codes only ✓ reason_code + policy context
Operator config surface ○ Varies ✗ Minimal ✓ 51 TOML keys + env overrides
Observability ○ Custom ✗ Not built in ✓ Prometheus + event stream + Grafana
Output

What operators see

Every verdict is structured, machine-readable, and carries the policy context that caused it.

{
  "accepted": false,
  "reason_code": "avg_fee_below_minimum",
  "reason_detail": "avg_fee=141 < min_avg_fee_used=200",
  "policy_context": {
    "fee_tier": "mid",
    "min_avg_fee_used": 200
  }
}
73 reason codes 51 config keys
Get started

Ready to deploy SV2 with confidence?

Start with shadow or observe. Enforce with inline when ready.

Explore ReserveGrid OS Read the docs