bc3.online
BC3 mining pool · BC3Hash

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 —
Pool hashrate — our share of the network
Active miners —

Over time — 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
Current effort
PPLNS —
Solo —
Work since each mode's own last block. 100 % is one block's expected work.
Luck · 7 d
PPLNS —
Solo —
Above 100 % is good fortune.
Next pool block —

View your stats

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

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 with its own proof of work

BC3 (BitcoinIII) is built on BitcoinIII Core v31.1, a fork of Bitcoin Core. It keeps Bitcoin's design — including the 21,000,000 coin maximum supply — and changes how blocks are mined. The first blocks used Bitcoin's SHA-256d; a hard fork at height 30,240 switched to SHA3-256t (little-endian) over the 80-byte block header, and a second hard fork at height 64,360 switches to BC3Hash. Each block's version bits say which one applies: bit 11 for BC3Hash, bit 12 for SHA3-256t, neither for SHA-256d.

The same fork at 64,360 replaces Bitcoin's 2,016-block retarget with ASERT: difficulty adjusts after every block, toward one block per 10 minutes on a fixed schedule, halving for every two days the chain falls behind it and doubling for every two days ahead.

What BC3Hash is

SHA3-256t kept BC3 away from Bitcoin's SHA-256d ASICs, but SHA3 itself is cheap to put in silicon. BC3Hash hashes the block header with six functions — SHA3-384, SHA3-512, SHA-512, RIPEMD-160, BLAKE2s and BLAKE2b — runs the SHA3-512 result through BC3Mix, and finishes with a domain-tagged SHA3-256 over all six. BC3Mix is the deliberately heavy part: secp256k1 scalar multiplications from tables, fixed-exponent modular exponentiations and field inversions.

One BC3Hash costs roughly 800 times as much as a SHA3-256t hash, and the work is big-integer arithmetic of the kind GPUs and CPUs already do well. SHA3 FPGA and ASIC designs do not carry over; dedicated hardware for BC3Hash would have to be built from scratch.

TickerBC3
Max supply21,000,000
Proof of workBC3Hash
Hard fork height64,360
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 run BitcoinIII Core v31.1 if you prefer a full node — older versions do not follow the chain past block 64,360.
  2. Download the miner from releases and unzip. Verify the SHA256 checksum against the release notes. You need version 2.0.0 or later: it mines SHA3-256t until block 64,360 and switches to BC3Hash by itself at the fork, without a restart. Older versions cannot mine after the fork.
  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 · rep · diff Sharesper min · stale, rej 24 h Job delaybest of 24 h Blocksfound · last Luck7 d · of expected Effortsince last block Best sharesince last block

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 — the same pool, real shares credited to your address. Like the downloadable miner it mines SHA3-256t until the hard fork at block 64,360 and switches to BC3Hash at the fork by itself. 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. :latest is version 2.0.0 or later, which mines SHA3-256t until block 64,360 and BC3Hash from the fork on, switching by itself.

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.
Upgrade before block 64,360. A container started from an older image keeps running 1.x, and 1.x cannot mine BC3Hash: after the fork it earns nothing. Restart it so the host pulls :latest again, and check that the first log lines say 2.0.0 or later. No restart is needed at the fork — 2.0.0 switches proof of work on its own.

What to expect on BC3Hash

Each BC3Hash costs about 800 times the work of a SHA3-256t hash, so hashrates drop from MH/s and GH/s to kH/s and MH/s — that is the algorithm, not a broken card. Measured with bc3-miner 2.0.0:

HardwareBackendBC3Hash
NVIDIA RTX 4090CUDA~1.6 MH/s
NVIDIA RTX 4050 LaptopCUDA~180 kH/s
NVIDIA RTX 3050 Ti LaptopCUDA~150 kH/s
Intel i9-12900HK (all 20 threads)CPU~8 kH/s (~1.1 kH/s on one thread)
Browser tab, 4 threads (#/mine)WebAssembly~550 H/s

The CUDA backend needs NVIDIA driver R525 or newer. On a GPU the BC3Hash kernel uses lookup tables of 256 MiB by default; BC3_BC3HASH_WINDOW picks a smaller table for cards short on memory. To measure a machine before you rent it for long, run the image with --benchmark --algo bc3hash: it mines random jobs locally, checks every result, needs no pool and no address, and on a GPU compares the four table sizes.

docker run --rm --gpus all ghcr.io/4nderss/bc3-miner:latest --benchmark --algo bc3hash

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. Without it the CPU only steps in for BC3Hash if a GPU's kernel fails its self-test.
BC3_BC3HASH_WINDOW16BC3Hash table size on the GPU: 10 (7 MiB), 12 (22 MiB), 14 (76 MiB) or 16 (256 MiB). Bigger is usually faster; --benchmark tells.
BC3_BC3HASH_MODEautofast (~256 MiB of RAM) or compact (~7 MiB, 10–20 % slower) tables for BC3Hash on the CPU. Compact when a GPU mines, fast otherwise.

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 and reads the proof of work from each job's version bits, so it works with any BC3 pool — SHA3-256t before block 64,360, BC3Hash from it — as long as that pool has upgraded too. BC3_WALLET and BC3_WORKER become the Stratum username, joined with a dot.
For third-party miners 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.

Your miner must compute the proof of work each job asks for: SHA3-256t before block 64,360, BC3Hash from that block on. The job's block version says which — bit 11 (0x800) means BC3Hash and takes precedence over bit 12 (0x1000, SHA3-256t). A miner that only knows SHA3-256t cannot mine here after the fork.

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 on SHA3-256t, 0.000002 (2e-6) on BC3Hash. When the proof of work changes at the fork, every connection starts over at the BC3Hash value — a difficulty measured in SHA3-256t hashes says nothing about BC3Hash. 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 few seconds per connection — 3 by default; the pool operator sets it. 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. Your hashrate on the pool is averaged over 60 such intervals — the window "My stats" shows in its labels — counted from when a rig started if that was later, and drops to zero after ten intervals without a share.
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 on SHA3-256t and 0.0000001 (1e-7) on BC3Hash — about 430 hashes, a couple of seconds for one CPU thread. Difficulty 1 is 2³² hashes on average for both. 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. Both proof-of-work version bits — 0x1000 (SHA3-256t) and 0x800 (BC3Hash) — are outside the mask on purpose: they 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 — except across the fork: a share for a job of the old proof of work is stale as soon as the pool has switched.
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 per port, and 64 per IP address across both ports — room for a phone or rig fleet behind one router. 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.
BC3Hash rate
Checking a BC3Hash share costs the pool about 4 ms of CPU, so a connection may submit at most 40 of them per 10 seconds — 4 while its latest BC3Hash submit was not an accepted share. Above that the submit is answered with error 20, too many shares per second, and vardiff raises the difficulty. For a rig that has had a share accepted these refusals do not count as rejections.
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 BC3 pools, on either side of the fork. 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 (the name is kept for older clients; it is measured over hashrate_window_secs, 60 share intervals — three minutes at the default target), best_difficulty_1h, best_difficulty_24h, best_target_pct_1h and best_target_pct_24h (the closest any share came to a block, in percent of the target of the job it solved), and rigs[] — every rig seen in the last 7 days with hashrate (from accepted shares, over the same window, counted from the rig's start if it came in during it and zero once it has been silent for ten share intervals), reported_hashrate (the miner's own count, sent once a minute with mining.hashrate; null when the rig's miner does not send one, and reported_partial true when only some of the rig's connections do — display only, never used for payouts), last_share_ts, last_difficulty, accepted_24h, stale_24h, rejected_24h, mining_since_ts (the first share after the rig's last break of 15 minutes or more; null when it is not mining, and mining_since_capped true when it has mined without a break for the whole 7 days the pool looks back), blocks_found in this mode with last_block_height and last_block_ts (orphans not counted), luck_blocks and luck_expected (blocks the rig found over the last 7 days, never before the fork, from luck_since_ts, against the blocks its work should have given — each share against the difficulty of the job it solved), the rig's own round since its last block — effort_pct (each share against the difficulty of the job it solved), effort_since_ts (the block, or the rig's first share if it has none), effort_truncated (the round is older than the 30 days of shares the pool keeps, so the figure is a floor), best_since_block_difficulty and best_since_block_pct — best_difficulty and best_target_pct over 24 h, 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 and the network difficulty it was mined against, best_share_network_difficulty), windows[] (hashrate and best share for 1 min … 7 d — best_difficulty, and best_target_pct: the highest percentage of its own target any share reached, each share measured against the network difficulty of the job it solved), and effort — effort since the last block and luck over 7 d, 30 d and since start, for the pool and per mode. After the fork "since start" is since the fork: effort.lifetime_since_fork is true and effort.lifetime_since_height is the first BC3Hash block. Effort counts each share against the network difficulty of the job it solved, since ASERT changes the difficulty with every block. From the BC3Hash fork on, everything counted from shares — hashrate, effort, luck, best share — covers BC3Hash shares only, starting when the pool switched (asert.pow_since in /api/network).

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 2,016-block retarget epoch (blocks_left, retarget_change_pct, retarget_difficulty). From the BC3Hash fork at block 64,360 there are no epochs: epoch is null and asert (absent before the fork) carries the ASERT schedule instead: anchor_height, anchor_parent_time, reference_difficulty, half_life_secs, spacing_secs, min_difficulty, the tip (tip_height, tip_time, ideal_tip_time), and the exact next_difficulty of the block being mined with its schedule_delta_secs (seconds behind schedule; null for the fork block itself, which has the fixed difficulty 16). asert.pow_since is when the pool itself switched to BC3Hash (null until it has): everything counted from shares starts there. The 24-hour hashrate and its trend are also measured from the fork, not across it.

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 (best_difficulty and best_target_pct, in total and per mode), plus every block found in the range with ours and pool. Hashrate is a trailing average over avg_secs — at least 10 minutes, the same window as the live figure, and never shorter than a bucket — since the shares in a single minute are few enough to be mostly chance. Best share is the bucket's own. Only shares of the current proof of work count: after a hard fork, buckets before the pool's switch are 0.

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, with hashrate averaged over the rig list's window (avg_secs: 60 share intervals, three minutes at the default target, never shorter than a bucket). Where that spans several buckets each rig is counted from when it started and drops to zero once it has been silent for ten share intervals, so a rig that starts or stops shows within a minute. 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. Our own addition, connections: the caps (per_port, per_ip), open connections and refusals at a full port per mode (pplns, solo: open, refused_full), refusals at the per-IP cap (refused_per_ip) and how many addresses are at it right now (ips_at_cap) — counts only, never addresses. algorithm is the proof of work of the block being mined: SHA3-256t before block 64,360, BC3Hash from it. fork describes the proof-of-work hard fork — left out unless one is scheduled and announced — with height (64,360), the new algorithm (BC3Hash; null until named), difficulty_algorithm (ASERT, which replaces the 2,016-block retarget), blocks_left, active (true once the block being mined is at or past the fork) and supported (whether the pool can mine it).

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/events?mode=pplns|solo · ?wallet=address&range=24h&rig=nameserver-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, pool.status once a minute (status = pools[0] of /api/pool), and history.tick once a minute with the newest completed chart bucket for every range (ranges["1h"].point …, the same point /api/history ends with). With mode the stream also carries mode.tick every 15 s, the same as /api/mode/<mode>; with wallet it carries wallet.tick every 15 s, the same as /api/wallet/<address>, and wallet.history once a minute with the newest completed bucket of that address's chart for range and rig. A stream with either starts with a view event confirming it. Each event carries a type and the same fields as the endpoint it mirrors. This site loads each page once and then only listens.

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 is fine; polling it every second from a hundred dashboards is not. For live updates, subscribe to /api/events?wallet=<address> instead of polling — it carries the same document every 15 seconds.