bc3.online
BC3 mining pool · SHA3-256t

Mine BC3 on your own hardware.
Keep the entire block reward.

bc3.online pays out inside the block you find — the subsidy goes to your address in the coinbase transaction itself and never passes through the pool's wallet. Our only revenue is the block's transaction fees.

Download the miner Try it in your browser first How to get started What is BC3?

Live blocks

Live from node
Mining block—
Network hashrate—
Difficulty—
Avg block time—
Retarget est.—
Network epoch —

View your stats

Hashrate, rigs, found blocks and payouts for your wallet — solo and PPLNS.

Pool hashrate—our share of the network
Active miners—
Current effort — work since our last block, as a share of one block's expected work
Luck · 7 d · 30 d · since start — above 100 % is good fortune
Next pool block —

Pool hashrate — PPLNS and solo separately; bars show best share, marks show found blocks

Loading chart data…
PPLNS hashrate Solo hashrate Best share (right axis) Block-winning share Our block Other pool's block drag to zoom · double-click to reset

Best share

The closest we have come to a block — 100% of target wins it.

Last hour — —
Last 24 h — —

If we win this block

Block reward
—
To miners
—
To pool (tx fees)
—

Pool lifetime

Blocks found
—
Best share ever
—
Fees earned by the pool
—
our entire revenue — 0 % of the subsidy

No blocks found yet — every block the pool finds will be listed here.

Choose your mode

Connectstratum+tcp://bc3.online:3111
PPLNS hashrate—
Active PPLNS miners—

Steady payouts for steady work

PPLNS (Pay Per Last N Shares) splits each found block's subsidy between everyone who contributed shares in the recent window, proportional to work. The right choice when your hashrate is small relative to the network.

Paid inside the coinbase

When a block is found, the distribution is written directly into the coinbase transaction — one output per participant. No balances held by us, nothing to withdraw. Spendable after 100 blocks maturity.

The window

Your shares are difficulty-weighted over a rolling window of 2× the network difficulty. Payouts below 0.0001 BC3 are folded into the window's largest participant instead of creating dust.

Full PPLNS statistics →

Username is your BC3 address, optionally with a rig name: yourBC3address.rigname — password is ignored. Already running your own miner? Point it at the endpoints above, and see the stratum details for ports, vardiff and how to set your own difficulty.

The fee model: 0% of your reward

You get the subsidy

The full block subsidy is paid to your address (or the PPLNS window) as the first outputs of the coinbase transaction. Trustless — we cannot withhold it even if we wanted to.

We get the transaction fees

The pool's revenue is the fees from the block's transactions — close to zero on the young BC3 network today. We are betting on the network growing.

100 blocks maturity

As in Bitcoin, coinbase rewards become spendable after 100 blocks (~17 hours). That is a consensus rule that applies to every pool — nobody can pay out faster.

What is BC3?

A Bitcoin relaunch in its own hardware class

BC3 (BitcoinIII) is built on BitcoinIII Core v29.1, a fork of Bitcoin Core. It keeps Bitcoin's design — including the 21,000,000 coin maximum supply — with a single consensus change: proof of work is SHA3-256t (little-endian) over the 80-byte block header, activated by hard fork at height 30,240.

Why change the algorithm?

No other coin used SHA3-256t when BC3 launched, so the network does not compete with Bitcoin for existing SHA-256d ASICs. The project's thesis: a coin with its own proof-of-work algorithm can develop its own hardware class, so its security has no inherited ceiling.

TickerBC3
Max supply21,000,000
Proof of workSHA3-256t
Hard fork height30,240
Next halvingblock 210,000

The whitepaper, source code and community links live on the official site: bc3.network.

Get started in five minutes

  1. Get a BC3 address. Create a wallet right here in your browser — your keys are generated in the tab and never sent anywhere. Or use BitcoinIII Core if you prefer a full node.
  2. Download the miner from releases and unzip. Verify the SHA256 checksum against the release notes.
  3. Start it and pick a mode. Paste your address, name your rig, choose PPLNS (steady payouts) or solo (the whole block or nothing).
  4. Mine. The client shows your hashrate, shares, and — in solo mode — estimated time to block.

No GPU of your own? The same miner runs as a Docker image on rented hardware — mining on rented GPUs covers clore.ai, Vast.ai and RunPod.

What would you earn?

Try:
Per day—
Per week—
Per month—
Expected time to a block—

Solo and PPLNS earn the same amount on average — the pool takes 0% of the subsidy either way. What differs is the shape: solo pays the whole block at once and nothing in between, PPLNS pays a steady share of every block the pool finds. The figures above are the long-run average; over any short period you may get much more or much less.

Important about addresses: BC3 uses exactly the same address formats as Bitcoin. Native segwit (bc1q…), taproot (bc1p…) and the legacy formats (1… and 3…) all work — for mining payouts as well as for the wallet. Never send BTC to a BC3 address or vice versa — the transactions live on different chains and cannot be moved between them.
Full overview

Statistics

Hashrate (15 min)—
Active miners—
Active rigs—
Last block—
In payout window—
Effort since last block —
Luck · 7 d · 30 d · since start — above 100 % is good fortune
Chance of a block — within 24 h · within a week · within 30 days, at this mode's current hashrate

PPLNS hashrate — bars show best share in this mode, marks show blocks found in it

Loading chart data…
PPLNS hashrate Best share (right axis) Block-winning share Our block Other pool's block drag to zoom · double-click to reset

Hashrate & best share per window

WindowHashrateBest share

How close is a block?

A share becomes a block when its difficulty reaches 100% of the network target.

Best share, last hour —
Best share, last 24 h —
Network target —

—

Active miners (last 15 minutes)

AddressRigsHashrate (15 min)Best share (15 min)Last share
Your statistics

Wallet

Your hashrate — bars show your best share, marks show your blocks

Loading chart data…
PPLNS hashrate Solo hashrate Best share (right axis) Block-winning share Your block drag to zoom · double-click to reset
Hashrate (15 min)—
Best share (24 h)—
Active rigs—
Window share——

Your rigs — PPLNS — every rig seen in the last 7 days

Rig Status Hashrate15 min Diff Shares 24 hacc · stale · rej Uptime24 h · 7 d Job delaybest of 24 h Best share24 h

Hashrate & best share per window — PPLNS

WindowHashrateBest share

On-chain balance - read live from our node

Confirmed coins this address holds on the BC3 chain, including any that never came from this pool. The Total earned / Paid / Maturing figures below are this pool's own payout bookkeeping. Immature above counts every coinbase output this address holds, whoever mined it; Maturing below counts only the ones this pool paid you. If you mine only here the two will usually match — a gap means coinbase from somewhere else.

Total balance
—
Spendable now
—
Total earned—paid + maturing
Paid—mature after 100 blocks
Maturing—this pool's payouts, awaiting confirmations

Earnings over time — payouts per day, last 30 days

Last 7 days
—
Last 30 days
—
Per day, 30-day average
—
today

Blocks found — by one of your rigs

BlockRewardWhenModeRigStatus

Payouts

BlockAmountWhenModeStatusProof

Each payout is an output in the block's own coinbase transaction. "Verify" opens it in the explorer — the payment never passed through the pool.

Wallet · runs entirely in your browser

Your BC3 wallet

Keys are generated and used here, in this tab. They are never sent to us, never stored on this device, and disappear the moment you lock or leave.

For serious amounts, use BitcoinIII Core instead. A browser wallet is convenient for mining payouts and small balances, but any browser is a bigger attack surface than a desktop wallet — extensions can read the page, and a lost tab means a lost session. Write your recovery phrase down on paper; it is the only way back in.

Create a new wallet

Generates a 12-word recovery phrase in your browser. Write it down before you continue — it cannot be recovered later.

Open an existing wallet

Enter a 12 or 24-word recovery phrase to see your balance and send coins.

Try it in your browser

Mine BC3 right now.
Then get the fast one.

This tab really mines — same algorithm, same pool, real shares credited to your address. It is also roughly a hundred times slower than the miner you can download, and that is the point of letting you try it.

Download the real miner Setup guide

Start mining

Idle
Hashrate—
Shares (accepted / found)0 / 00 rejected
Best share—
Pool difficulty—

How this compares

This tab
—
GPU miner
—

Start mining to see how this tab stacks up against a GPU.

The browser runs one hash at a time per thread inside a sandbox. The downloadable miner runs thousands in parallel on your graphics card, with the same payout model — the block reward goes straight to your address in the coinbase.

Get the GPU miner What would that earn?

Activity

Rig name webtest — that is how this browser shows up in the pool statistics. Rejected shares are normal right after a new block: the job you were working on became stale.

Docker · one image, every backend

Mine on rented GPUs.

One Docker image covers NVIDIA, AMD, Intel and CPU, and it is configured entirely by environment variables — which is all a rental platform like clore.ai, Vast.ai or RunPod lets you set. No command line, no config file, no build step.

The image

ghcr.io/4nderss/bc3-miner:latest

Public, no login needed. Built and published by the same workflow that cuts each release, from the tagged source.

The minimum

Two variables. Everything else has a working default.

BC3_WALLET=bc1qyouraddresshere
BC3_WORKER=rig1

That mines PPLNS on every GPU the host exposes.

On a rental platform

  1. Pick a machine and choose a custom image. Paste ghcr.io/4nderss/bc3-miner:latest where the platform asks for the Docker image. Field names differ between providers, but every one of them has this box.
  2. Set the environment variables. BC3_WALLET, BC3_WORKER, and BC3_REQUIRE_GPU=1. See the note below on why the third one matters when you are paying by the hour.
  3. Leave the command empty. The image starts the miner itself. Anything you type there replaces it.
  4. Start it, then read the first ten log lines. They name every GPU that was found. If the count is wrong you know before the first hour is billed.
  5. Check the pool. Your rig shows up under your address within a minute or two of the first share.
There is nowhere to put --gpus all, and you do not need it. That flag is only a wrapper that sets NVIDIA_VISIBLE_DEVICES; this image already declares it, and rental hosts run the NVIDIA container runtime as Docker's default. The GPUs are exposed without any flag. Set NVIDIA_VISIBLE_DEVICES=0,1 yourself if you want only some of them.
Always set BC3_REQUIRE_GPU=1 on a rented machine. Without it the miner falls back to CPU when no device reaches the container — and you go on paying GPU prices for CPU hashrate, with nothing in the logs but a low number. With it the container exits, so the host's restart policy or your alerting has something to notice.

One container, or one per card?

One container, all GPUs

The default, and correct: every card gets its own worker with its own slice of the nonce space. The pool sees one rig with the combined hashrate. Nothing extra to configure.

One container per card

Add BC3_GPU_ID=0, =1 and so on, with a distinct BC3_WORKER each. The pool then reports hashrate, last share and found blocks per card — so a dead card looks like a dead card instead of an unexplained dip. Worth the extra typing on a machine you rent by the hour.

Every variable

VariableDefaultMeaning
BC3_WALLET—Your BC3 address. Required.
BC3_WORKER—Rig name, appended to the address.
BC3_MODEpplnspplns or solo. Picks the pool port.
BC3_POOLfrom modehost:port. Overrides BC3_MODE — point the image at any Stratum pool.
BC3_BACKENDautoauto, cuda, opencl or cpu.
BC3_GPU_IDallUse only this one GPU, counting from 0.
BC3_REQUIRE_GPUunsetExit rather than fall back to CPU.
BC3_INTENSITY1001–100. Below 100 the machine stays usable.
BC3_THREADSnone in GPU modeCPU threads to add alongside the GPUs.

Casing does not matter — BC3_WALLET and bc3_wallet both work.

On your own machine

NVIDIA 
docker run -d --name bc3-miner \
  --restart unless-stopped \
  --gpus all \
  -e BC3_WALLET=bc1qyouraddresshere \
  -e BC3_WORKER=rig1 \
  ghcr.io/4nderss/bc3-miner:latest

Unlike on a rented host, here you have to grant the GPU yourself. One line changes between the three cases:

Your hardwareWhat to pass
NVIDIA --gpus all Needs the NVIDIA Container Toolkit installed on the host.
AMD or Intel --device /dev/kfd --device /dev/dri The image ships the OpenCL loader; the driver comes from your host.
CPU only nothing With no device passed it falls back to CPU on its own.

docker logs -f bc3-miner shows which backend it picked and how many devices it found. A docker-compose.yml with both patterns is in the repository.

Mining to another pool. Set BC3_POOL=host:port and the image connects there instead. It speaks plain Stratum v1, so it works with any SHA3-256t pool — BC3_WALLET and BC3_WORKER become the Stratum username, joined with a dot.
For SRBMiner, cpuminer and your own builds

Stratum details.

Everything a third-party miner needs to point at bc3.online: ports, the username format, how the difficulty is set, and what gets a share rejected. Plain Stratum v1 — no extensions required.

Endpoints

PPLNSstratum+tcp://bc3.online:3111
Solostratum+tcp://bc3.online:3112

No TLS and no backup port: one server, plain TCP. Both ports serve the same chain tip; only the payout model differs. Measure your latency with ping bc3.online.

Login

Username
yourBC3address.rigname — the rig name is optional and becomes default when left out. Anything after the first dot is the rig name, spaces and all; keep it short and ASCII so it reads well in the tables.
Password
Ignored. x is fine. A d=… difficulty hint in the password is not parsed — use mining.suggest_difficulty instead (below).
Addresses
bc1q…, bc1p…, 1… and 3… all work. Bech32 is case-insensitive; the pool stores it in lower case.

Difficulty and vardiff

Starting difficulty
0.1 for an unknown rig. A rig the pool has seen in the last 15 minutes starts at the level its own recent shares suggest, so a fast card does not flood the pool with tiny shares while vardiff catches up.
Target
One share every 15 seconds per connection. The pool re-evaluates after 12 shares, or after 90 seconds with at least two, and at most every 10 seconds on a clock when shares stop coming.
Step
At most ×4 or ÷4 per retarget, and only when the change is at least 20 %. A new difficulty takes effect with the next job (mining.set_difficulty followed by mining.notify).
Range
Floor 0.001. The ceiling is relative to the PPLNS window: one share may never be more than 1/100 of the window (2× the network difficulty), so at today's difficulty the cap is around 2 % of the network target. That keeps a single share from dominating anyone's payout.
Your own level
mining.suggest_difficulty is honoured, clamped between the pool's starting difficulty and the ceiling above. Vardiff keeps adjusting from there — the suggestion sets where you start, not a fixed value.
Version rolling
BIP310 mining.configure is supported with mask 1fffe000. The SHA3 version bit is outside the mask on purpose: it can never be rolled away.
Extranonce
extranonce1 is 4 bytes, extranonce2 is 4 bytes. mining.extranonce.subscribe is acknowledged.

Shares

What gets rejected

21 stale
The job is no longer known (a connection keeps its last 8 jobs), or it was built on a chain tip that has since changed. Shares that were already in flight when the tip changed get a 5-second grace period.
22 duplicate
The same hash submitted twice on one connection.
23 low difficulty
The hash does not meet the share target the connection was given.
20 / 24
Malformed submit, or a submit before mining.authorize.

Every rejection is counted per rig and reason, and shown as accepted · stale · rejected on your stats page. Stale above about 2 % usually means latency or a slow job switch on your side.

Job delay on the same page is the pool's measurement of that: on every new block it notes how long it takes until your rig's first share on the new job, and shows the best case over 24 h — your network latency plus the miner's job switch, without the luck of when the next share happens to come. A couple of seconds or more, and stale shares follow — but the red mark waits for about 20 new blocks after the rig connected: the best of a handful is mostly luck, so the count is shown under the number.

Limits and retention

Connections
512 in total, 16 per IP address. The handshake must complete within 30 seconds, and a connection that is silent for 30 minutes is closed.
Abuse
100 rejected shares in a row, or 200 within 10 seconds, closes the connection. Accepted shares never count against you.
Retention
Accepted shares are kept for 30 days, rejected ones for 7. Rigs stay on your stats page for 7 days after their last share, marked offline.
Jobs
A new job on every network block and at least every 20 seconds. clean_jobs is true only when the tip actually changed.
Rented GPUs and Docker: the same details apply to the bc3-miner image, which speaks plain Stratum v1 and also works against other SHA3-256t pools. Your address and rig name become the username, joined with a dot.
JSON over HTTPS · no key needed

The pool API.

Everything on this site is read from these endpoints, and you can read them too — for Grafana, Home Assistant, a Telegram bot or your own dashboard. Public, read-only, and served with Access-Control-Allow-Origin: * so a page on another site can fetch them directly.

Your address

GEThttps://bc3.online/api/wallet/<address>

The page behind "My stats", as one document. Per mode (pplns, solo): hashrate_15m, best_difficulty_1h, best_difficulty_24h, and rigs[] — every rig seen in the last 7 days with hashrate, last_share_ts, last_difficulty, accepted_24h, stale_24h, rejected_24h, uptime_24h_pct, uptime_7d_pct, job_delay_ms (best time from a new block's job to the rig's first share on it, over 24 h) with job_delay_samples, and first_seen_ts — the rig's oldest share the pool still keeps, up to 30 days back — with first_seen_truncated true when that oldest share sits at the retention limit, so the rig may have started earlier. PPLNS adds est_window_share_pct, est_next_block_sats, window_rank and window_ahead. Then blocks_found[], payouts[] (latest 100, each with status, coinbase_txid and vout), totals, and windows_pplns[] / windows_solo[] for 1 min to 7 d. Amounts are in satoshi, times are unix seconds.

curl -s https://bc3.online/api/wallet/bc1qyouraddresshere | jq '.pplns.hashrate_15m, .totals'

Every endpoint

GET/api/statsrecomputed per request; effort and luck once a minute

Pool hashrate (10-minute window) in total and per mode, active miners and rigs, the current block template (template), lifetime (blocks per mode, orphaned blocks, fees earned, best share ever), windows[] (hashrate and best share for 1 min … 7 d), and effort — effort since the last block and luck over 7 d, 30 d and since start, for the pool and per mode.

GET/api/networkcached 15 s

Tip height, difficulty, difficulty-implied hashrate, the block-derived hashrate for the last 24 h with its trend against the six days before, average block time, and the retarget epoch (blocks_left, retarget_change_pct, retarget_difficulty).

GET/api/history?range=1h|6h|24h|7dbuckets of 60 / 300 / 900 / 3600 s

Time series for the charts: hashrate per mode and best share per bucket, plus every block found in the range with ours and pool.

GET/api/blocks?limit=25&offset=0&ours=true

Blocks newest first, paginated, with total. orphaned=true narrows it to our orphaned blocks. Our own blocks carry finder, finder_rig, reward_sats, fees_sats, difficulty, coinbase_txid, confirmations and status (pending, confirmed, orphaned).

GET/api/mode/pplns · /api/mode/solo

One mode in full: windows, active miners, last block, effort and luck for that mode. PPLNS adds the payout window — contributions[] with each address's share, shares in the window, and window_ahead (how much newer work sits in front of its latest share), plus pplns_window_diff and pplns_window_filled.

GET/api/wallet/<address>/history?range=24h&rig=name

Same buckets as /api/history, for one address, split per mode. rig narrows it to one of the address's rigs.

GET/api/wallet/<address>/blocks?limit=25&offset=0

Blocks the address found or was paid from, paginated.

GET/api/wallet/<address>/payouts?limit=1000&offset=0

Every payout, paginated up to 1000 at a time — the export behind the CSV button. Orphaned payouts are included with status: "orphaned".

GET/api/rejects?range=1h

Rejected shares in the window (1h, 6h, 24h, 7d): totals per reason (stale, duplicate, lowdiff, invalid), accepted shares in the same window, and the 25 rigs with the most rejects, each with its own accepted count.

GET/api/poolcached 15 s

Pool status in the ckpool-style format aggregator sites read: uptime, users, workers, hashrate per window, accepted and rejected shares since restart, shares per second, node peers and uptime.

GET/api/price

BC3 in USD from the exchange, with 24 h change, high, low and volume. available: false before the first successful fetch, stale: true when the exchange has been unreachable.

GET/api/eventsserver-sent events

A live stream: stats.tick every 10 s, network.tick every 15 s and on every block, block.network, block.ours, price.tick. Each event carries a type and the same fields as the endpoint it mirrors.

GET/api/chain/utxos?address=…cached 30 s per address

Unspent outputs and balance for an address, straight from the node — what the browser wallet builds transactions from. Answers 503 while another scan is running; try again in a few seconds.

POST/api/chain/broadcast

Body {"raw_tx": "<hex>"}. Relays a signed transaction through our node and returns {"txid": …}, or the node's rejection reason as a 400.

Be gentle. The endpoints are cached where it matters, but /api/wallet/<address> runs a dozen database queries. Polling it every 15 seconds — as this site does — is fine; polling it every second from a hundred dashboards is not. For live updates, subscribe to /api/events instead of polling.