One invoice, one cycle, one true-up.

Two requirements drive the whole deal, and both are in the PDF: 55% of the daily pool payout goes to the host’s wallet, and a monthly Hosting Fee Reconciliation goes to the miner. LineRate pulls both out with the clause attached, and it also pulls out the two terms the agreement never actually pins down.

The model already knows what it needs, and it’s a short list: pool for earnings, the supplier invoice for cost, Coinbase for the conversion, the nameplate register for the cap, and the interval meter to verify consumption. Nothing is connected that the contract doesn’t reference. Until the meter authorization lands, reconciliation stays paused rather than estimated.

The miner asked for one thing in review, and it’s the only question that matters about the invoice: which kWh figure does the rate divide by? The bill carries two, and they differ by 7.7%.

This happens every day without anyone touching it. Pool pays the miner, 55% routes to the host’s wallet, and LineRate records the Coinbase rate it used to value it. Nobody is calculating a percentage in a group chat.

The host drops the supplier invoice in, and that’s the end of their involvement. LineRate needs exactly two things out of it, total kWh, and the rate those kWh cost, and everything after that is the contract doing its own arithmetic. Nobody has to read an energy bill to agree on what’s owed.

Before any arithmetic, LineRate declares what it has and what role each input plays. The invoice contributes two values and nothing else. The harder problem is that the supplier bills February 6 to March 9, and the contract promises a monthly report. No calendar month matches, so the engine holds the invoice period and the calendar apart rather than pretending they’re the same thing.

Click any figure on the report and this is what’s underneath: the formula, every input, and where each one came from. Same inputs always produce the same output, and if a late input arrives, LineRate makes a restatement rather than quietly changing the old number.

With the two values registered and the derivation settled, the rest is arithmetic the contract already specified. Usage came in above the Exhibit E allowance, so $630.87 of real power cost falls outside the cap and stays with the host. The fee lands above what the daily 55% collected, and the gap is what settles.

Usage runs about 4.6% above rated load every cycle, against a 3% allowance, so a slice of real power cost falls outside the cap and stays with the host. The amendment moves the factor to 1.1, well clear of measured usage, but it’s effective March 4, and this invoice runs to March 9. Twenty-six days at the old factor, five at the new one. That boundary is exactly what spreadsheets get wrong.

Here’s the same invoice under v1.1. The middle column is what the amendment actually says. The right column is what you get if you ignore the effective date, a $198 error, in the host’s favor, that nobody would ever catch by eye.

Every payout, invoice, approval and restatement, hashed and attributed. When someone asks in December why this cycle’s fee moved by $433.03, this is a thirty-second answer instead of a two-day archaeology project.