Demo build. This is a software product for sale — not an investment, token sale, or financial service. Coins shown run on testnet and have no monetary value. Buyers are responsible for their own licensing, compliance and any mainnet launch.

Demo pool testnet only no real mining revenue
BTC testnet XMR testnet ETC testnet RVN testnet KAS testnet GCC testnet

Connecting to your own node.

The fastest path from "I have a GPU or ASIC" to "shares are landing" on the testnet demo. Five steps.

01 Why point the wallet at your own backend

By default the wallet talks to an Electrum/Electrs (Esplora) backend that I run, so you can try the stack without standing anything up yourself. But the wallet is built for operators, and the whole point of the white-label stack is that you run your own chain under your own brand. When you do, you point the wallet at your backend instead of mine.

There are three reasons to do this:

  • Privacy. Whichever Electrum server you connect to sees the addresses you query. Running your own keeps that on infrastructure you control rather than asking a third party.
  • Trust. Your wallet’s balances and broadcasts are only as honest as the backend serving them. Your own indexer, talking to your own full node, removes the question of trusting someone else’s.
  • Your own chain. If you have re-branded the stack and launched a chain with its own ticker and address prefix, the public backends do not index it at all. The wallet has to talk to the Electrs instance sitting in front of your node, because nothing else knows your chain exists.

02 What your backend needs

The wallet speaks the Electrum protocol to an Electrs server that indexes your node (the same Esplora-style indexer the bundled networks use). So the backend side is two pieces:

  1. A full node for your chain — for the GCC family that is the Litecoin/Scrypt-derived daemon running and fully synced.
  2. An Electrs index pointed at that node, which builds the address index the wallet queries and exposes the Electrum RPC port.

For anything beyond a machine on your own LAN you also want TLS in front of Electrs, with a certificate that actually validates — the wallet connects over ssl:// and checks the certificate, so a self-signed cert that the device does not trust will be refused. A certificate from a normal CA (for example via a reverse proxy terminating TLS) is the simplest path.

03 Run an Electrs index

If your node is already up and synced, bringing up Electrs in front of it is a matter of telling it where the node is, where to write its index, and which address to serve the Electrum RPC on. A minimal invocation looks like this:

bash
point electrs at your synced node
electrs \
--network mychain \
--daemon-rpc-addr 127.0.0.1:9332 \
--db-dir /var/lib/electrs/db \
--electrum-rpc-addr 0.0.0.0:50001

That exposes the plaintext Electrum port on 50001. Do not point the wallet straight at that across the internet — put a TLS terminator (a reverse proxy, or a stream proxy doing TLS) in front of it and publish the ssl:// port instead. A common convention is to serve plaintext on 50001 internally and TLS on 50002 to the outside world.

04 Set the Electrum URL in the wallet

On the device, open Settings → Network and choose the custom Electrum URL option. Enter your endpoint in the form:

text
format: scheme://host:port
ssl://electrum.yourdomain.example:50002

Use the ssl:// scheme for a TLS endpoint — which is what you want for anything off your own LAN. The host must match the name on the certificate, and the port is whichever one your TLS terminator listens on. Save, and the wallet reconnects to your backend; from then on its balances, history and broadcasts all flow through your node.

If you are only testing on a trusted local network you can use a plaintext tcp://host:50001 endpoint, but treat that as a lab convenience, not something to expose publicly.

05 Troubleshooting

Most failures connecting to a self-hosted backend fall into a few buckets:

  • TLS / certificate errors. The certificate is self-signed, expired, or its hostname does not match the URL you typed. Use a CA-issued certificate and make sure the hostname in the URL is exactly the one on the cert.
  • Clock skew breaks TLS. If the device’s clock is wrong by more than a few minutes, TLS certificate validation fails even with a perfectly good certificate, because the validity window check is time-based. Set the phone to automatic network time. This one is easy to miss because the error looks like a certificate problem, not a clock problem.
  • Wrong network selected. Pointing the wallet at an Electrs that indexes a different chain than the network you have selected gives you an empty or nonsensical balance. The address prefix is the tell: a gcc1… wallet needs an Electrs indexing GCC, not TC2.
  • Connection refused or timing out. The Electrum port is not reachable from the phone — a firewall is blocking it, the TLS terminator is not running, or you published the wrong port. Confirm the port is open and that Electrs has finished building its index (a fresh index is not ready to serve until it catches up to the node’s tip).

06 A note for re-branders

If you have taken the stack, changed the coin name, ticker and address prefix, and launched your own chain, this is the screen that joins your wallet build to your chain. The bundled networks in the public wallet are there for demonstration; your launched product points at your own Electrs over ssl://, and your users never see my backend at all.