eCash (XEC) Mining Pool Setup — Address‑Safe Pool Operations
eCash uses SHA256 proof‑of‑work, which means ASIC miners can contribute hashpower to XEC pools. Reliable XEC pools require the same fundamentals as BTC: stable full nodes, a resilient Stratum layer, safe accounting, and clear miner onboarding. This guide covers the practical design and launch checks for production XEC pools. For XEC pools, we focus on correct installation and configuration of the pool stack (Stratum + node + UI) and the operational maintenance that keeps shares, payouts, and uptime healthy.
XEC pool overview: avoid address mistakes and payout disputes
For eCash, a pool operator’s biggest avoidable risk is sending payouts to the wrong kind of address. Miners may paste different formats, and your pool should validate what the wallet will actually pay to—before balances build up.
- Address validation: enforce the exact address format(s) your XEC wallet accepts and document that format in the miner UI.
- Unit clarity: make sure miner-facing balances and payout history are consistent in the units you display, so users don’t misread amounts.
- Stratum stability: VarDiff (variable difficulty) and ban rules should prevent noisy clients from distorting hashrate charts and share volume.
- Payout verification: test the full credit → payout → confirmation loop privately before you allow open registrations.
XEC pool engine selection: Yiimp, Miningcore, and operational fit
XEC pools can run on the same proven SHA256 pool engines. The important part is integrating wallet rules and miner documentation so deposits and payouts are unambiguous.
- Yiimp-based: If you want a classic pool UI, the Yiimp setup guide route is a quick way to deliver accounts, workers, and earnings pages.
- Miningcore: If you prefer service separation and an API-driven architecture, start with the Miningcore setup guide approach and harden from there.
- Custom stack: Use custom when you need specialized accounting, strict allowlists, or custom address-validation behavior.
Don’t assume miners all use the same address format. Validate at entry, display the expected format clearly, and reject ambiguous inputs early.
XEC pool build: nodes, Stratum gateways, and payout plumbing
- XEC full node(s): deploy nodes, supervise services, and restrict RPC to pool components only.
- Pool core + database: share tracking, maturity logic, and retention sized to your expected traffic.
- Stratum endpoints: port plan, VarDiff (variable difficulty) tuning, bans/limits, and miner docs that minimize bad submissions.
- Payout pipeline: wallet signing, batching policy, and payout model selection; use payout schemes and how to choose SOLO vs PPLNS vs PROP as references.
- Website UI: dashboard pages that show balances and payouts clearly, plus a status page reflecting actual health.
- Security hardening: firewalling, backups, secret storage, and monitoring guidance (see {{A0}}).
We align the address validator with the wallet and daemon behavior. If the wallet won’t accept an address, the pool shouldn’t accept it either.
XEC miner connection examples (what to publish publicly)
Keep public documentation simple: one domain, a small set of ports, and examples that you have tested with real miners.
stratum+tcp://POOL-DOMAIN:3333
stratum+ssl://POOL-DOMAIN:3443When you publish your help page, include a short section on address format expectations and how to verify an address in the wallet before mining starts.
XEC-specific pitfalls: address formats, units, and confirmations
- CashAddr-style inputs: if you accept a prefixed format, document the exact prefix you expect and validate it server-side.
- Format normalization: if multiple formats are accepted, normalize display so miners don’t see “different” addresses for the same destination.
- Unit display: define rounding and units so payment history reconciles cleanly to wallet transactions.
- Confirmation policy: credit blocks and mark payouts final using a consistent, documented rule.
XEC launch checklist (make payouts boring)
- XEC node synced and monitored; alerts cover stalled tip and abnormal peer behavior.
- RPC restricted and authenticated; only pool services can reach wallet methods.
- Stratum ports tested with common ASIC firmware; VarDiff and bans stable under reconnect tests.
- Accounting verified; database backup and restore drill completed.
- Address validation tested with multiple formats; the pool rejects anything the wallet won’t pay to.
- Payout test completed end-to-end, including confirmation tracking and UI reconciliation.
- Public docs published with clear address guidance and a short troubleshooting section for miners.
XEC pool FAQ: operator questions we see often
Which address format should miners use for XEC payouts?
Use the format your wallet supports and that your pool validates. We configure the pool to reject unsupported formats at signup so payouts cannot be misrouted.
Can you run an XEC pool as invite‑only at first?
Yes. We often start with private access so you can validate address handling, payouts, and monitoring before opening registrations to the public.
How do you handle XEC unit display on the dashboard?
We choose a consistent display unit, apply deterministic rounding, and make sure the payment history matches wallet transactions so miners can verify earnings.
Will XEC work with rented hashpower or marketplaces?
Often yes, but we treat marketplace traffic as a separate class. We use dedicated ports and stricter limits to avoid reconnect storms and misleading hashrate charts.
What do you need from me to begin an XEC pool setup?
Send your target pool type, expected hashrate, hosting plan, engine preference, and whether you need help operating the pool after launch.
Deploying XEC publicly? Contact us and mention which address formats you want to accept and display.