How attribution works
This page is documentation, not marketing. If you are going to trust a number about your own money, you should be able to check how it was produced.
The problem a pool creates
A mining pool pays one wallet. It does not know, and has no reason to care, which of your machines contributed which share of that payment. Every payout arrives as a single number covering a window of time and the work of every machine you had running during it.
Attribution is the job of splitting that number back apart.
How payouts are ingested, and why overlapping windows are safe
Every sync reaches further back than the last one ended — 48 hours by default. Pools restate history: a payout can appear late, be corrected, or arrive out of order. A sync that only asked for "everything since last time" would miss all three.
Re-fetching the same payout is harmless because writes are keyed on the pool's own payout identifier. Importing the same window twice produces the same rows, not double the revenue. The same guarantee covers a CSV you upload by hand and a CSV you upload twice.
Why value is recorded at the time of receipt
When a payout lands, JouleBook records the satoshis and the fiat value at that moment, using the BTC price for the hour it arrived.
That figure never changes afterwards. If Bitcoin doubles next month, your October revenue does not double — because you did not receive it in November. Revaluing historical income at today's price produces a number that is wrong for every purpose: it is not what you earned, not what you owe tax on, and not what your margin was.
Where a price for that hour cannot be established, the payout is marked unpriced rather than valued at a nearby price and presented as certain.
The formula
For each payout, over the window it covers:
share(machine) = (hashrate × active_hours)
÷ Σ over all machines (hashrate × active_hours)
attributed_sats = floor(payout_sats × share)
Three properties matter more than the formula itself:
It is computed in integer satoshis. Not floats. A satoshi is the unit Bitcoin is denominated in, and floating-point arithmetic on money loses value in ways that compound quietly.
It always sums to exactly the payout. Flooring each share leaves a remainder of a few satoshis. That remainder is given to the largest holder, and the result is asserted equal to the payout before it is written. If it ever were not, the write would fail rather than record a fleet whose parts do not add up.
A machine that was not running gets nothing. Machines are attributed only
for the hours they were actually active within the window, from their
activeFrom and activeTo dates. Adding a machine mid-month does not
retroactively earn it revenue from before it existed.
MEASURED, ESTIMATED, and NAMEPLATE_ONLY
The formula needs a hashrate per machine. Where that comes from is recorded on every attribution and shown wherever the number appears.
| Method | What it means |
|---|---|
MEASURED | Real telemetry covered the window. The hashrate is what the machine actually did. |
ESTIMATED | Telemetry covered part of the window. Measured where it exists, nameplate elsewhere. |
NAMEPLATE_ONLY | No telemetry at all. Every machine is weighted by its rated hashrate. |
An ESTIMATED or NAMEPLATE_ONLY figure is labelled as such on screen and in
every export. It is never quietly presented as measured, because the difference
between the two is exactly the difference between a fact and an assumption.
What happens with no telemetry
Everything still works, and the answer is still useful — a fleet of identical machines splits a payout almost exactly the same way whether you measure it or assume it.
What changes is what the number can be used for. Under NAMEPLATE_ONLY, two
identical machines are indistinguishable by construction, so the attribution
cannot tell you that one of them is underperforming. That is precisely the
question telemetry answers, and it is why uptime is reported as unknown rather
than as 100% when nothing was measured.
How power cost is allocated
Power cost is not apportioned from a bill. It is computed:
kWh = watts × active_hours ÷ 1000
cost = kWh × site.powerRate
Hosting is the same shape, at the site's hosting fee per kWh. Both use the same active hours the revenue split used, so a machine that ran for a third of the month is charged for a third of the month.
Where a machine's draw was measured, the measured watts are used. Where it was not, nameplate watts are — and the resulting cost carries the same estimation label the revenue does.
What this does not tell you
It does not tell you what a machine will earn. Every figure here is derived from payouts you have already received, at prices that already happened. The break-even page projects forward, and says so.
Ready to see it against your own payouts? Start free — one site and 25 machines, permanently.