Meter Stable (MTR) SHA256/SHA256d Pool Setup — Practical Operator Guide

This page covers the pieces that make a Meter Stable (MTR) SHA256/SHA256d pool dependable: validating the daemon you’re running, locking down RPC, tuning Stratum sessions, and proving payouts end-to-end.

On this page

Pre-flight checks
Software stack
Deployment scope
Miner onboarding
MTR-specific quirks
Go-live checklist
FAQ

Meter Stable pool blueprint: verify the chain before you scale

A SHA256 pool is only as good as its node layer. With less common forks, the first risk is running the wrong binary or the wrong network. Before you open Stratum publicly, confirm the daemon’s chain identity, RPC surface, and wallet behavior under load.

Chain identity: Confirm network magic/chain params match the MTR chain you intend to mine; mismatches look like “stuck sync” and phantom blocks.
Accounting model: Pick SOLO/PPLNS/PROP based on who bears variance; document it in plain terms so miners can predict payouts.
Wallet strategy: Decide whether payouts use an online hot wallet or a split hot/cold process; test address validation and fee handling.
Session controls: Set connection caps, bans, and VarDiff (variable share difficulty) so one miner can’t destabilize the Stratum front end.

Stack selection for MTR: fast launch vs long-term maintainability

For MTR you can run the same core engines used for BTC-like SHA256 coins. The right choice depends on whether you prioritize a classic website-first pool or an API-first service you integrate into your own UI.

Yiimp-based: Best when you want a familiar pool website quickly and you’re comfortable with PHP/MySQL ops. See Yiimp setup guide.
Miningcore: .NET engine with clean config and strong throughput; useful when you want predictable deployment and API-driven stats. See the Miningcore guide. See Miningcore setup guide.
Custom build: Recommended if the MTR daemon requires coin-specific template logic, nonstandard RPC fields, or bespoke payout/reporting.

MTR pitfall to plan for

If the MTR network is thin, reorg risk rises. Treat “maturity” (the confirmations required before coinbase can be spent) as an operational control: delay payouts until your node shows coins as spendable, and alert on deep reorgs.

Implementation scope for a production MTR pool

MTR node layer: Build/install, initial sync, RPC allowlisting, secrets handling, and restart-safe service units.
Pool core + database: Share persistence, round accounting, block tracking, and retention policies sized for your expected share rate.
Stratum gateways: Port layout, TLS/SSL option, VarDiff curves, and banning rules tuned for your miner mix.
Payout pipeline: Batching, thresholds, fee accounting, and idempotent payout runs. See payout schemes and SOLO vs PPLNS vs PROP.
Operator UI: A minimal dashboard for hashrate, rejects, blocks, and payment history; optional public pages for trust.
Security baseline: Firewalling, least-privilege DB users, log integrity, and backup/restore drills. See security hardening.

If you operate multiple SHA256 coins, keep each coin’s node RPC credentials, wallet keys, and payout tables isolated. Cross-contamination is how small incidents become accounting failures.

Miner-facing endpoints for MTR (plus a worker format note)

Publish only what miners need: a primary endpoint, a backup endpoint, and a worker naming convention. For ASIC farms, the worker suffix is typically used for identifying rigs; keep the separator consistent across your docs.

stratum+tcp://POOL-DOMAIN:3333
stratum+ssl://POOL-DOMAIN:3443

We also provide a short “copy/paste” section for common ASIC firmware UIs, plus a longer troubleshooting page for reject codes.

Meter Stable operational notes that change day‑2 behavior

Daemon/RPC compatibility checks: On first run, validate getblocktemplate, submitblock, and longpoll behavior with real miners; forks sometimes diverge in subtle fields.
Address validation and payout hygiene: Confirm whether addresses are legacy/segwit-style and whether the wallet rejects unknown prefixes. Add server-side checks so a bad address cannot enter the payout queue.
Explorer/indexing expectations: If you need public block links, plan an explorer or indexer early; without txindex or equivalent indexing, payment verification becomes painful.

MTR launch readiness list

Daemon is fully synced on the correct chain and reports stable peers over time.
RPC is bound and authenticated safely (no public RPC), with monitoring on sync height and IBD state.
Stratum endpoints tested with at least two miner families (ASIC firmware + a proxy/marketplace client).
VarDiff and ban thresholds tuned so bursts don’t overload the share processor.
Payout run tested end-to-end using small-value transactions and a rollback plan.
Backups verified by restore tests (DB + configs + wallet procedure), not just by “files exist.”
Public docs published: endpoints, worker format, payout schedule, and support contacts.

Meter Stable pool Q&A

What do you need to confirm before launching an MTR pool?

We start by identifying the exact daemon/repo you’re running, then verify chain params, RPC calls used by the pool (template + submit), and wallet send behavior. That validation prevents days of debugging a “working” setup that is on the wrong network.

Can you harden RPC for an MTR node without breaking pool functions?

Yes. We keep RPC on private interfaces, use strong auth (cookie or rpcauth where supported), and restrict firewall rules to the pool hosts. The pool only needs a small RPC surface; everything else stays blocked.

How do you handle payout safety when maturity or reorg depth is uncertain?

We wire payouts to spend only confirmed, mature coinbase. If the daemon reports coins as immature, they are excluded. We also alert on reorg events so you can pause payouts during instability.

Can I run MTR alongside other SHA256 coins on one platform?

Often yes, but we isolate wallets and accounting per coin, and we keep coin-specific node quirks in separate configs. That avoids a single daemon issue cascading into other payout tables.

What information should I send for an MTR setup quote?

Share your expected hashrate, pool type (solo/private/public), target hosting, and whether you want a full public website UI or an operator-only deployment. If you already have an MTR daemon build, include the repo/source so we can validate RPC behavior.

If you want a Meter Stable pool that survives real miner traffic, contact us with your target hashrate and deployment style. Contact us.