Metering, FinOps & tokenomics
Metering in System9 is provable, not asserted. Every metered event, a kernel execution, a stored gigabyte, a function invocation, an agent run, a crypto operation, is recorded into a hash-chained meter audit chain with gap detection, so every line on a bill has a hash-chained record behind it that a customer can verify themselves, and it works offline. On top of that ledger sits FinOps: rate cards, budgets, chargeback, rollups, and cost-anomaly analytics. And where value changes hands, the Data Exchange, a separate double-entry ledger books each read as a buyer debit against a seller credit. All of it is denominated in Compute Units, and none of it moves real money.
From a metered event to a verifiable chain
Metering is designed so it can never interfere with a customer operation: the per-service collector never raises, computing Compute Units from CPU, memory, I/O, network, and per-service custom dimensions. Records drain to an fsync'd write-ahead log for crash safety, are enriched with topology and rate context, and are committed into a per-cell, hash-chained meter audit chain, each record carrying a per-record HMAC, the chain sealed by a signed chain head (position and last hash) that a party holding only the public key can verify off-cell.
Figure F1: the metering path. A metered event is costed into Compute Units by a collector that never raises, drained through a crash-safe WAL, attributed along the full topology and organizational hierarchy, and committed to a per-cell hash-chained chain sealed by a signed head (green). A gap or a head that moved backward feeds the enforcement ladder (amber) rather than being ignored; the head also seals signed offline bundles and feeds the FinOps rollups.
Table equivalent
| Stage | What it does | Property |
|---|---|---|
| Collector | Costs the event into Compute Units; never raises | Metering cannot break the operation it measures |
| Write-ahead log | fsync'd drain of collected records | Crash safety: nothing lost on failure |
| Attribution | Tags cell, node, org, cost centre, workspace, clean room, agent, entity, rate card | Consumption is attributable per agent, per run, per cell |
| Meter audit chain | Per-record HMAC, prev-hash linkage, signed head | Tamper-evident; a tampered record breaks the chain |
| Gap detection | Detects a missing position or a backward head | Rollback and replay are defended, not ignored |
| Offline bundle | Signed export of the chain and its head | Verified on import; offline estates stay accountable |
Compute Units, and what they are not
The Compute Unit is the platform's unit of account for measured consumption, kernel execution time weighted by class, storage by peak GB-month, function invocations (with the isolation tier as an attribute), agent runs and inference, crypto operations, clones and ETL runs, and cross-zone transfer, each attributed along the topology and the organizational hierarchy. A Compute Unit is a unit of account, not a currency and not a claim on a bank.
Two distinctions are load-bearing and must never be blurred:
- Charged Compute Units are not cost of goods. The metered Compute Units a customer is charged and the inference-event cost the platform incurs as its own cost of goods are different quantities. They are never summed and one is never presented as the other.
- Infrastructure count is not a meter. Cells, nodes, and service groups cost nothing. Splitting an estate across twenty cells in five regions for residency or resilience costs nothing, only the work does. That inverts the usual cloud incentive, where the safest architecture is the most expensive one.
The edge follows the same rule from the other direction: edge and local operations are observed and governed, but recorded with zero charged units, metered for visibility, never billed as core consumption.
The billing shape: overage is billed, never blocked
Licensing is usage-driven with a deliberate philosophy, overage is billed, not blocked. Feature flags are hard gates; resource limits are soft; concurrent kernels are an advisory throttle that queues rather than rejects. A cell whose work exceeds its entitlement keeps working and accrues the overage rather than stalling the customer mid-operation.
| Dimension | Behaviour |
|---|---|
| Compute Units (kernel execution time × class) | Overage billed, never blocked |
| Storage (GB-month, peak measured hourly) | Overage billed, never blocked |
| Active users per month | Overage billed, never blocked |
| Cells, nodes, service groups | Free infrastructure: unlimited |
Double-entry settlement: the exchange's accrual
Consumption metering answers "what did it consume?" Settlement is a separate ledger with a different shape. Underneath the Data Exchange sits a signed, hash-chained, double-entry accrual ledger, denominated in Compute Units. Every metered cross-org read books two entries, a buyer debit against a seller credit, so the ledger can never go one-sided, and a tampered value on either side breaks both gates. Accrual is idempotent on the event id, so a replay does not double-count.
Usage metering is single-sided accounting of consumption; the double-entry ledger is the exchange's settlement ledger. They are related mechanisms with the same tamper-evidence property, but they are not the same ledger, and usage metering is not double-entry.
FinOps: the financial layer over the meter
FinOps reads the metered record and turns it into cost intelligence: usage aggregation and pivot queries, platform and customer rate cards, budgets with warning and exceeded thresholds and forecasting, chargeback computation and reports with CSV-safe export, a per-agent cost estate, and a registry of cost-anomaly rules, idle resources, daily cost spikes, storage-growth runaway, egress and cross-region traffic spikes, unallocated chargeback, Compute-Unit burn trajectory, and meter-chain gaps among them. Where a rollup summarises a group of inference events, the anomaly analysis names the offender (carrying a magnitude and a lever ratio) so the output is not "you spent a lot" but "this sub-agent, on this model, is burning this proportion."
This sits alongside the four distinct cost questions the platform keeps separate: what is charged (metering and FinOps), what is allowed to spend (the budget governor, enforced pre-flight), where the tokens went (token and inference transparency, lineage-attributed), and what is being wasted (inference cost intelligence over the telemetry). Only the first is billing.
Across the deployment matrix
- Single-cell, the meter chain and its signed head are local artifacts on the cell; FinOps rolls up that cell's own records.
- Multi-cell, each cell keeps its own hash-chained chain and signed head; cross-cell reporting runs through a designated proxy node, and peer bundles are authenticated twice, a per-peer HMAC and an Ed25519 signature from the node's converged identity key.
- Sovereign / air-gapped, metering runs with no phone-home; offline estates emit signed metering bundles verified on import, and settlement accrual and its verification run locally with no payment processor in the path.
- Cloud-enabled, the same chain and the same accrual model; online payout remains scaffold, not a shipped capability.
Related topics
- Metering and attribution, the attributed, device-signed metering contract and its edge verify half.
- Settlement and accrual, the double-entry accrual ledger of the exchange.
- Audit and tamper-evidence, the chain contract this ledger follows.
- Monitoring & logging, the telemetry the FinOps cost intelligence reads over.