Bill per call without the monthly argument
Readings land every hour from the gateway and the client. A mismatch raises a ticket the same day, not six weeks later.
- Hourly windows
- Both-sided readings
- Prefunded vault optional
Orbitmeter turns usage into signed readings from both sides, closes the window on a schedule you set, and settles what nobody challenged. No month-end invoice, no argument from memory.
Units this window
54,791
Settles at close
$23.01
| Batch | Source | Units |
|---|---|---|
| b-4417 | provider | 18,420 |
| b-4418 | customer | 18,411 |
| b-4419 | provider | 17,960 |
b-4417 and b-4418 differ by 9 units. Below tolerance, no ticket raised.
Usage is counted for a month, billed at the end, and questioned when the number lands. By then the logs have rotated.
The provider counts requests at the gateway. The customer counts them at the client. Nobody agreed which one wins.
Between the first unit delivered and the payment received, one side is lending the other money without saying so.
Metering, disputes, proration and payout logic get written again for each new customer contract.
Both parties sign what is counted, how often it is read and what a unit costs. The meter definition is the contract, not an appendix to it.
Readings arrive from either side on a fixed cadence. Each one is signed and sequenced, so a gap is visible immediately rather than at month end.
At the end of each window the readings are totalled, the dispute period opens, and anything unchallenged settles on Canton.
The same six pieces cover an API meter, a substation and a container terminal. Only the unit changes.
MeterAgreement
What gets counted and at what price
Holds the unit definition, the reading cadence, the price schedule and the parties. Changing it needs both signatures.
ReadingBatch
Signed usage, in sequence
A numbered batch of readings with the submitter's signature. Missing sequence numbers surface as gaps, not silence.
SettlementWindow
The period that closes
Totals the batches, applies the price schedule and produces one amount. Windows can be hourly, daily or monthly.
DisputeTicket
The disagreement, on the record
Either party can challenge a window before it settles. The ticket names the readings in question and pauses only that part.
PayoutSplit
Who gets which slice
Splits one settlement across resellers, partners or infrastructure providers by rules agreed up front.
MeterVault
The funds behind the meter
Holds the collateral or prefunded balance a window draws from, so settlement does not depend on a bank transfer clearing.
Readings land every hour from the gateway and the client. A mismatch raises a ticket the same day, not six weeks later.
Meter readings from substations become signed batches. Settlement follows the same window everyone already reconciles against.
Terminal and carrier each submit counts. The window closes on what both submitted, and the difference is visible before invoicing.
The window still closes, but it closes as single-sourced and is flagged that way. Most teams start single-sourced and add the second feed once they trust the numbers.
No. A vault is optional. Without one, the window produces a settled amount and your existing payment rail pays it.
Only the challenged readings pause. The rest of the window settles on schedule, so one argument does not hold up a whole month.
Testnet only. We are running pilots with two infrastructure providers and are not taking production volume yet.
We will model it as a meter, replay the usage, and show what both sides would have signed at the time.