Seconds to answer.
A digital twin of a BTX mining operation.
Digital twins came out of heavy industry — a live software replica of a jet engine, fed by telemetry, used to test changes without touching the real thing. A field report from the BTX mining operation: a ~500-line, zero-dependency Python digital twin of a live mining stack — node, fleet, and forward economics — built and validated in a single session, with the node down the entire time.
The first question we asked it — should we rent four A6000s? — came back in seconds with a breakeven number a gut feel could never produce. The twin paid for its own construction before it was an hour old.
Whyte Consolidated Research · 2026-07-02· 10 min read · State mirrored at tip 148,149
The sensors already exist. The physics is known exactly.
A mining operation is a surprisingly good fit for the digital-twin pattern that heavy industry pioneered — and for three specific reasons. BTX is an unusually clean specimen: it re-runs Bitcoin's early monetization sequence on GPU compute — the BTC flip, as the circle of holders calls it — so both the physics and the economics arrive pre-modeled.
The “sensors” already exist. A Bitcoin-lineage node exposes everything over RPC — getblockchaininfo, getmininginfo, getnetworkinfo. The miners log their throughput. There is nothing to instrument.
The physics is known exactly. Block discovery is a Poisson process. Expected block rate is your_hashrate / network_hashrate × blocks_per_day. Difficulty retargeting and subsidy halvings are deterministic consensus code you can mirror line for line.
Real experiments are expensive. “Let's rent GPUs for a month and see” costs four figures. “Let's simulate it 8,000 times” costs milliseconds. That asymmetry is the entire business case.
- ✓A live mirror of chain state — tip, difficulty, network hashrate, fleet share.
- ✓Seedable from debug.log chainwork deltas when the node is down.
- ✓A fleet model you can edit — measured dig/s, cost per hour, what-if overlays.
- ✓A forward simulator that mirrors chainparams.cpp consensus constants.
- ✓Free time-series telemetry — every sync appends a JSONL snapshot.
- ✓A single session of stdlib Python that paid for itself before it was an hour old.
- ✕Not a miner — the twin never mined a block and never will.
- ✕Not a price oracle — the $399.25/BTX input is the btxprice.com model price at writing: a dated input, not a constant.
- ✕Not a spreadsheet average — it reports distributions, including the 13% zero-block tail.
- ✕Not mining-specific — the pattern generalizes to any system with RPC and logs.
Three data sources, one model, no dependencies.
The twin — contrib/twin/btx-twin — is deliberately boring: python3 stdlib only, one file, three layers.
State mirroring, with graceful degradation
The collector tries sources in order: live RPC via btx-cli (height, difficulty, networkhashps, peers); then the node's own debug.log — every UpdateTip line still carries height, log2_work, and the block-header timestamp, and chainwork delta over wall time is network hashrate, in the same digest-equivalent units the live RPC reports; then the last stored snapshot. Our 500-block seed window gave 171.9 Mdig/s and 90.4 s observed spacing against a 90 s target — self-consistent to within half a percent. The node happened to be cleanly shut down during the entire build. It didn't matter. That's the point: the twin gives you observability of a system that isn't currently running.
A fleet model you can edit
A JSON file of devices — name, measured digests/sec, cost per hour, enabled flag. Ours holds the two profiles we've actually benchmarked: an Apple M5 on the Metal backend (4,574 dig/s) and a rented RTX A6000 (2,548 dig/s — CPU-feed-bound at 4 vCPUs, a story of its own). What-if flags (--add name:rate:cost, --disable name) overlay scenarios without touching the saved config.
A forward simulator that respects consensus
Constants mirror chainparams.cpp: 90-second spacing, 20 BTX subsidy, 525,000-block halvings. Block finds are Poisson draws; a --growth parameter compounds network hashrate daily — and because retargeting holds spacing roughly constant, growth shows up the way it does in real life: as erosion of your share, not slower blocks.
Mirrored state, then the question that motivated the build.
| Metric | Value | Note |
|---|---|---|
| Chain tip | 148,149 | mirrored with the node cleanly shut down |
| Network rate | 171.9 Mdig/s | recovered from debug.log chainwork deltas |
| Observed spacing | 90.4 s | against a 90 s target — self-consistent to ~0.5% |
| Our fleet (M5 Metal) | 4,574 dig/s | a 0.0027% network share |
| Expected revenue | 0.51 BTX/day | baseline, electricity rounds to zero |
| Median wait to next block | ~27 days | the number that makes solo variance concrete |
| Metric | Value | Note |
|---|---|---|
| Scenario | 4× RTX A6000 | $0.49/hr each, 30 days, network +1%/day |
| Expected blocks | 2.1 (~43 BTX) | fat distribution — P10 is zero blocks |
| Rental cost | $1,411 | the full downside in a zero-block month |
| Expected revenue | ~$17,100 | at $399.25/BTX, the btxprice.com model price at writing |
| Expected net | +$15,700 | strongly EV-positive under that price |
| Breakeven price | $32.96/BTX | the trade survives a 12× price collapse |
Price input: $399.25/BTX — the btxprice.com model price at time of writing (2 July 2026). Within the circle of BTX holders, pricing expectations anchor to that model, which makes it the right input for a twin whose job is to mirror reality. The baseline M5, whose electricity rounds to zero, is already earning ~$200/day of expected value at that price.
So renting is strongly EV-positive under that price assumption. But the twin surfaces something a spreadsheet average hides: a solo miner eats a 13% chance of a month with zero revenue — losing the full $1,411 rental. The distribution, not the mean, is what tells you whether you can stomach the variance or should be pooling.
There's a supply-side reading of that variance, too. Terms like these select for patient, capitalized operators — stable compute providers— and every 20 BTX subsidy lands with someone whose cost basis sits near the $33 breakeven and whose reference is the $399 model. Between those two numbers the rational posture is mine and hold. That's the supply construction working as intended: the float accretes to long-term holders, short-horizon speculators wash out, and coins offered below the model price meet standing absorption — the discount evaporates quickly.
Every operational question becomes a cheap simulation.
Capital decisions become simulations
Every “should we scale?” question — more vCPUs on the existing rental, a second local machine, a fleet of spot GPUs — is a one-line --add flag. You find out the breakeven price beforethe invoice, not after. Our $33/BTX number now sits in the ops runbook as the kill-switch: rentals stay EV-positive as long as price holds above it, and at the $399 model price there's a 12× cushion before that condition trips.
Free telemetry, and a self-improving model
Because every sync appends a snapshot, the twin builds a history of network hashrate for free. Today we guess --growth 1; after a few weeks of snapshots, the observed growth rate replaces the guess. The model gets sharper by existing.
Anomaly detection with a statistical spine
The twin knows the distributionof expected outcomes, which turns “hmm, no blocks lately” into math. Twenty-seven days without a block is the median wait — fine. Ninety days is P < 10% — check the miner. We have logs of a miner heartbeating “1,100 attempts, no block yet” for days; the twin answers the question those logs beg: is that bad luck or a broken rig?
A planning layer for the pool
We're mid-build on a Stratum pool for this chain. A pool is itself an exercise in variance management, and the twin already speaks that language: expected shares per miner per difficulty setting (vardiff planning), payout variance under PPLNS windows, validator throughput needed at projected miner counts. The twin becomes the pool's design-and-capacity model before the pool has its first miner.
Consensus-change rehearsal
The constants at the top of the twin mirror chainparams.cpp. When someone proposes retuning spacing or the subsidy schedule, you fork the twin's constants and show every stakeholder the revenue impact on real fleet profiles — hours of argument replaced by a table.
The pattern generalizes past mining
Strip the domain specifics and the recipe is: mirror state from whatever the system already emits (including its logs when it's down), model the known dynamics, Monte Carlo the questions that are expensive to answer for real. That works for a validator set, a fleet of scrapers, a render farm, a fulfillment pipeline. The mining version just happens to have unusually clean physics.
You are a single session away from one of these.
If your system exposes state over RPC and writes decent logs, you can build a twin in a single session. Ours is ~500 lines of stdlib Python.
Build the log-seeded fallback first, not last. A twin that only works when the real system is healthy fails exactly when you need it.
Report distributions, not means. The 13% chance of a zero-revenue month changed how we think about pooling more than any expected-value figure did.
Treat price as a dated input, not a constant.Our runs use $399.25/BTX, the btxprice.com model price at time of writing; an earlier placeholder price made the same trade look underwater. Same simulation, opposite decision — the price input deserves the same rigor as the hashrate input. That's why the next twin improvement is feeding --price live from btxprice.com instead of typing it in: the model is the shared reference the holder circle prices against, so the twin should read it at the source.
The real system is still the real system — the twin never mined a block. But it turned a five-figure rental decision into a breakeven number for the cost of a Poisson loop, and it'll answer the next question too.
Mining digital twins — questions
- What is a digital twin of a crypto mining operation?
- A live software replica of the mining stack — chain tip, network hashrate, your fleet's measured throughput — plus a forward simulator that respects the chain's consensus rules. It mirrors the real system's state and lets you run experiments the real system would charge you for: renting GPUs, joining a pool, or riding out a hashrate spike become simulations instead of invoices.
- How can the twin measure network hashrate while the node is offline?
- From the node's own debug.log. Every UpdateTip line carries height, log2_work, and the block-header timestamp — and chainwork delta over wall time is network hashrate, in the same digest-equivalent units the live getnetworkhashps RPC reports. A 500-block seed window gave 171.9 Mdig/s and 90.4 s observed spacing against a 90 s target, self-consistent to within half a percent.
- What did the twin say about renting four A6000s?
- Across 8,000 Monte Carlo trials of a 30-day rental at $0.49/hr per card with 1%/day network growth: expected ~2.1 blocks (~43 BTX), rental cost $1,411, expected revenue ~$17,100 at the $399.25/BTX btxprice.com model price, and a breakeven token price of $32.96/BTX — roughly 12× below the model. Strongly EV-positive, with one caveat the mean hides.
- Why report distributions instead of expected values?
- Because a solo miner's outcomes are lumpy. The same simulation that shows +$15,700 expected net also shows 12.7% of trials finding zero blocks — a 13% chance of losing the full $1,411 rental in a month. The distribution, not the mean, tells you whether you can stomach the variance or should be pooling.
- Why price the simulation with the btxprice.com model?
- Because that is the reference the circle of BTX holders actually prices against — BTX re-runs Bitcoin's early monetization on GPU compute (the BTC flip), and expectations inside the holder base anchor to the btxprice.com model rather than to sentiment. A twin's job is to mirror reality, and the model price is part of that reality. It also explains the supply side: with cost basis near the $33 breakeven and a $399 model reference, compute providers mine and hold — so float offered below the model price gets absorbed quickly rather than lingering.
- Does the twin get more accurate over time?
- Yes, by construction. Every state sync appends a snapshot to a JSONL file, so the twin accumulates a network-hashrate time series as a side effect of being used. Today the growth rate is a guessed --growth 1 flag; after a few weeks of snapshots the observed growth rate replaces the guess.
- Does the pattern apply beyond mining?
- Strip the domain specifics and the recipe is: mirror state from whatever the system already emits (including its logs when it's down), model the known dynamics, and Monte Carlo the questions that are expensive to answer for real. That works for a validator set, a fleet of scrapers, a render farm, or a fulfillment pipeline — mining just happens to have unusually clean physics.
Network state was mirrored at tip 148,149 from UpdateTip lines in the node's debug.log — chainwork delta over wall time, the same math getnetworkhashps uses — with the node cleanly shut down throughout. Forward economics are 8,000 Monte Carlo trials of Poisson block discovery with consensus constants mirrored from chainparams.cpp (90 s spacing, 20 BTX subsidy, 525,000-block halvings) and network hashrate compounding 1%/day. Dollar figures assume $399.25/BTX, the btxprice.com model price on 2 July 2026 — the pricing reference the BTX holder circle anchors to.
- btxprice.com — the BTX pricing model
- BTX — Mine: MatMul proof-of-work and operator launch kit
- Whyte Consolidated — 20× on Apple Silicon: tuning the BTX MatMul GPU miner
- Whyte Consolidated — Every block, on schedule: how BTX retargets difficulty with ASERT
- Whyte Consolidated — Built to Last: how BTX forged a 22 MH/s security wall in 100 days
- Whyte Consolidated — Mining pools for AI agents
For informational purposes only. Not financial, investment, or legal advice. Simulation outputs are model estimates conditional on their inputs — measured fleet throughput, a mirrored network hashrate, an assumed growth rate, and a dated token price — and actual mining outcomes will differ. The $399.25/BTX price is the btxprice.com model price as of 2 July 2026 and will move; the breakeven figure is the more durable number. Solo mining outcomes are high-variance: the simulated 12.7% zero-block probability is a real risk of total loss of rental cost in any given month. Mining profitability depends on hardware, difficulty, network growth, and market conditions, and is not guaranteed.