Bitcoin chain metering: billing software licenses from the blockchain itself

This post is about a commercial model mechanism we built for the substrate's commercial licensing, not because the mechanism is the kind of thing that usually gets blog posts but because I think the mechanism is genuinely interesting from a systems-design perspective and because I have not seen anyone else do it quite this way. The mechanism is: we bill our commercial customers by scanning the public Bitcoin blockchain for events they have anchored there themselves, in the course of their own integrity workflow. The customer does not report their usage to us, and we do not run a proprietary metering service on their behalf. The blockchain is the metering ledger.

The reason this is interesting is that it solves, for free, a problem that every commercial software vendor struggles with: how do you bill a customer for usage of a self-hosted binary that runs in the customer's own infrastructure, without requiring the customer to trust your metering or you to trust the customer's reporting? Traditional answers to this problem are all unsatisfying in specific ways. Chain metering, which is the name I will use for this pattern, sidesteps the problem by using a third-party append-only log (in our case, Bitcoin) that both sides can read but neither side can manipulate.

Let me walk through what the mechanism actually is, why we designed it this way, and the specific properties it has that make it better than the traditional alternatives.

The self-hosted billing problem

First, the problem. We sell a commercial binary — a signing runtime that produces substrates — and the binary runs on the customer's own infrastructure, inside a Trusted Execution Environment that we do not have direct access to. The customer pays us per substrate they mint. To bill the customer, we need to know how many substrates they have minted during the billing period.

There are three traditional approaches to this problem, and each of them has a specific weakness.

Approach 1: Trust the customer's self-reporting. The customer's binary tracks how many substrates it has minted, and at the end of each billing period the customer sends us a usage report. We invoice based on the report. This approach works if the customer is honest and if the customer's report can be reconciled against their own internal records. It fails if the customer is not honest, or if the customer's internal records are ambiguous, or if the customer disputes the number after they see the invoice. The vendor has to trust the customer's word, and the customer has to accept that their self-reporting is the source of truth.

Approach 2: Run a hosted metering service. Every substrate minting operation phones home to a vendor-operated service that increments a counter for the customer. The counter is the source of truth for billing. This approach works if the customer is willing to let the vendor's service see their minting activity and if the network between the customer and the vendor is reliable enough that the customer is not willing to tolerate the dependency. It fails for customers who cannot send usage data to a third-party service because of data residency requirements, compliance constraints, or an aversion to vendor lock-in. It also fails if the vendor's service goes down and the customer cannot mint until it comes back up — an availability dependency that is unacceptable for many production workloads.

Approach 3: Require the customer to host a proprietary audit agent. The vendor ships a separate audit binary alongside the main commercial binary, and the audit binary runs in the customer's infrastructure, tracks usage, and periodically synchronizes with the vendor. This approach works in the sense that it gives the vendor a usage count, but it requires the customer to run another piece of software, it introduces a new attack surface, and it still depends on the customer trusting the audit agent (and the vendor trusting the customer to run it unmodified).

Each of these three approaches has been deployed in various commercial software products, and each of them is a compromise. The compromise is about whose word you trust: the customer's (Approach 1), the vendor's service (Approach 2), or an agent that the customer hosts but the vendor controls (Approach 3). None of them provides a third-party source of truth that both sides can rely on without trusting each other.

The traditional solutions to this class of problem, in other domains, use a trusted third party. Audit firms do this for financial reporting (the audit firm is the third party whose word both the company and the shareholders trust). Public notaries do it for legal documents. The SEC does it for public company filings. In each case, the third party is paid (or legally obligated) to be neutral, and both sides trust the third party enough to resolve disputes by appealing to their records.

The Bitcoin blockchain is not a trusted third party in the traditional sense — no one runs it, no one is legally obligated to maintain its integrity, and there is no appeal process. But Bitcoin is something that functions like a trusted third party for the specific purpose of "was this 32-byte value anchored in block N at time T": the blockchain's own consensus rules guarantee that once a transaction is confirmed in a block, it stays there, and anyone with access to the chain can verify the same facts about the same transaction. Bitcoin is not trusted in the sense that you trust the people running it; it is trusted in the sense that you trust the math of the consensus protocol to keep the chain honest.

This "trusted in a specific limited sense" property is enough for our billing use case. We do not need Bitcoin to be a general-purpose truth oracle. We only need it to be a write-only public log where we can record that a substrate was minted at a specific time, and where both sides of the billing relationship can independently verify the record.

How substrate minting already produces an on-chain record

The key insight that made chain metering a viable billing mechanism for the substrate specifically is that substrate minting already produces an on-chain record as part of the customer's own integrity workflow, independently of any billing consideration.

Here is why. A substrate is a cryptographic attestation. Its value to the customer depends on being verifiable by third parties at arbitrary points in the future — five years from now, ten years from now, or whenever someone needs to audit the customer's operations. For the attestation to be verifiable, it needs a timestamp that the customer cannot retroactively manipulate. If the customer could retroactively claim that a substrate was minted at an earlier time than it actually was, the attestation would be useless — the customer could falsify the historical record by producing substrates today with backdated timestamps.

To prevent this, substrates need to be anchored to an append-only public log with a known timestamp. Bitcoin is the obvious choice for this anchor, because Bitcoin's blockchain has the strongest immutability guarantees of any practical append-only log in existence. A substrate's 32-byte signing message gets embedded in an OP_RETURN output of a Bitcoin transaction, and once that transaction is confirmed in a block, the substrate is timestamped at the block's height. The block's height is publicly known. Anyone can query Bitcoin Core to learn which block a specific transaction landed in and when that block was mined.

The customer anchors substrates to Bitcoin for their own reasons, not for billing reasons. The anchoring is what makes the attestation valuable in the future. Without anchoring, a substrate is just a signed commitment that could have been produced at any time — the signer could claim any timestamp. With anchoring, the substrate has a provable lower bound on its age: at minimum, it was produced at or before the time of the Bitcoin block that contains its signing message. The lower bound cannot be forged because the Bitcoin block's existence cannot be forged.

This is the specific property that makes chain metering work. The customer is already doing the on-chain anchoring for their own integrity purposes. The anchoring produces a public, immutable record of every substrate they have minted. We just have to read that record and count.

The fingerprinting mechanism

To count the customer's substrates specifically, we need to be able to identify which OP_RETURN outputs on the Bitcoin chain belong to them and which belong to other customers or to unrelated parties. We accomplish this by embedding a per-customer license fingerprint in the nonce field of every substrate they mint.

The license fingerprint is generated at the time the commercial license is signed. It is derived from the customer's unique identifier, the license epoch timestamp, and a cryptographic commitment to the executed license agreement document — a specific combination of inputs that is unique per customer-license pair. The derivation uses a keyed hash function under a key we hold internally, which means:

• We can derive the customer's fingerprint from the customer's identifier at any time.
• An observer who does not have the derivation key cannot compute the fingerprint from the customer's identifier.
• An observer who sees a substrate's nonce cannot determine which customer minted it without the derivation key — the nonce is statistically indistinguishable from a uniform random 16-byte value.

The fingerprint is embedded in the substrate's nonce field at mint time, inside the TEE where the signing runtime runs. The embedding is cryptographically combined with fresh random entropy so that the resulting nonce reveals nothing about the fingerprint to outside observers, but can be recovered by the party holding the derivation key. The exact combining procedure is one of the internals we keep proprietary for defense-in-depth reasons, but the property it preserves is: to any observer without the key, the nonce looks random; to us, the nonce identifies the customer who minted the substrate.

When the substrate is anchored to Bitcoin, its 32-byte signing message ends up in an OP_RETURN output. The signing message is SHA3-256 of the substrate's canonical encoding, which includes the nonce. The signing message itself does not reveal the fingerprint — it is a hash — but we can correlate the signing message back to the customer's substrates by maintaining our own index of substrates we know about (from our own billing records) and matching incoming on-chain OP_RETURN outputs against our index.

In practice, the matching procedure is efficient. Our Bitcoin chain scanner watches the public chain for new blocks, extracts OP_RETURN outputs from each block's transactions, and for each OP_RETURN output runs a fast fingerprint-matching routine against the set of active customers. Matches are recorded in our billing database, with the customer ID, the block height, the transaction ID, and the block time. At the end of each billing period, we sum the matches per customer and produce an invoice.

The scanner is read-only. It does not require any cooperation from the customer beyond the customer's own normal Bitcoin anchoring behavior. The customer does not send us usage reports, does not expose any API to us, and does not run any additional software for our benefit.

The self-enforcing property

Now for the interesting property, the one that makes chain metering fundamentally different from the traditional alternatives. Under chain metering, the customer cannot under-report usage without simultaneously failing to anchor their own substrates, and failing to anchor substrates defeats the customer's own integrity workflow.

Let me walk through the attack model carefully.

Suppose a dishonest customer wants to pay us less than they actually owe. They have to reduce the count we see for their fingerprint. The count we see is the number of OP_RETURN outputs on the Bitcoin chain that match their fingerprint during the billing period. To reduce the count, the customer has two options:

Option A: Mint substrates but don't anchor them. The customer's runtime produces substrates as normal, but instead of broadcasting the anchoring transactions to Bitcoin, the customer silently drops them. The substrates exist in the customer's local storage, but they are not on the public chain. When we scan the chain, we do not see the fingerprints for the dropped substrates, so we do not bill for them.

The problem with this attack is that the unanchored substrates have no timestamp. The customer cannot prove when they were minted, because the whole point of the anchoring was to establish a provable timestamp. A third-party verifier (a regulator, an auditor, a counterparty in a dispute) who later asks "was this specific computation attested at this specific time?" gets an answer of "the customer says so, but there is no public record." Without the public record, the attestation is worth much less than a fully anchored attestation. In most of the use cases the substrate is used for — regulated financial attestation, legal evidence chains, audit trails — an unanchored substrate is effectively useless. The customer would be trading a real long-term asset (a verifiable timestamped attestation) for a short-term cost reduction (a smaller bill from us). The trade is bad economics from the customer's perspective, and a rational customer would not take it.

Option B: Anchor to Bitcoin under a different fingerprint. The customer could try to produce substrates that do not carry their own fingerprint — maybe by reverse-engineering the runtime to embed a different fingerprint, or a random value instead. These substrates would be anchored to Bitcoin (so the customer gets the timestamp benefit) but would not match the customer's fingerprint when we scan, so we would not bill for them.

The problem with this attack is that it requires breaking the TEE protection of the licensed runtime. The license fingerprint is embedded inside the runtime at distribution time, and the runtime runs inside a TEE where the customer cannot inspect or modify it. To substitute a different fingerprint, the customer would need to either break the TEE (side-channel attacks against SGX, SEV-SNP, or Nitro, which are possible but require specialized expertise and are actively detected by the hardware manufacturers) or reverse-engineer the runtime well enough to rebuild it with a different fingerprint (which is a felony in most jurisdictions as a violation of the license agreement, and detectable because the resulting substrates would not verify under our published public key set).

Both versions of this attack require active adversarial engineering against a TEE-protected runtime, and both are detectable in principle. This is not zero-risk from our perspective — a determined adversary with enough resources might succeed — but it is the kind of attack that is rare in commercial software licensing relationships, and it is much more effort than the billing savings would justify for any commercial customer that I can imagine.

The remaining option is just to pay. The customer mints substrates normally, anchors them normally, and pays the invoice. Every economically rational customer will converge to this option because the alternatives are either worthless (Option A, unanchored substrates have no value) or legally and technically risky (Option B, modifying the runtime is a breach of contract and a technical challenge).

This is the self-enforcing property. The billing mechanism does not require us to trust the customer's honesty, because the customer has strong self-interested reasons to anchor honestly. The billing mechanism does not require the customer to trust our accounting, because the customer can independently verify the billing count by running their own chain scanner against the same public data we do. Disputes are structurally impossible as long as both sides are reading the same chain. If both sides compute different counts, one of them has a bug in their scanner, and the bug can be identified by comparing the two implementations against the same block data.

Customer-side verifiability

The flip side of chain metering is that the customer can independently verify the bill. The customer, holding their own copy of the license fingerprint derivation key (distributed to them as part of the licensing materials), can run the same matching routine against the same blocks we scan, and compute the same count. If our invoice says 2,847,000 substrates for the billing period, the customer can run their own scanner, produce their own count, and check that the numbers match.

In a traditional billing relationship, a dispute over a bill is resolved by one party showing their records to the other party and negotiating. Under chain metering, a dispute is resolved by both parties running the same public-data calculation and agreeing on the result. The resolution does not require sharing private records, does not require trusting the other party's word, and does not require an appeal to an external authority. Both sides have the same evidence, and both sides apply the same algorithm to the evidence.

This property is useful for several reasons beyond the absence of disputes. It means:

• The customer cannot be overbilled by accident. If our billing system has a bug that adds extra substrates to the count, the customer will notice when their independent count disagrees with our invoice. They have a mechanism to detect billing errors at the moment the invoice arrives, rather than having to trust our internal accounting to be bug-free.

• The customer has a complete audit trail. The customer's own scan produces a list of every substrate they minted during the billing period, with the block height, transaction ID, and timestamp for each one. This is a higher-quality audit trail than most commercial software billing systems produce, because it is anchored to an immutable public source. A regulator who later asks the customer "show me every substrate you minted in Q3 2026 and where they were anchored" can be satisfied with a printout of the chain-scanner output.

• The customer can plan capacity by chain-observing their own usage. Instead of relying on internal metrics (which might be lossy or delayed), the customer can watch the Bitcoin chain in real time for their own anchoring transactions and build capacity planning on the on-chain data directly. This is the same source of truth we use, which eliminates a class of capacity-planning errors.

• The customer's historical record survives vendor changes. If we go out of business, get acquired, change pricing, or make any other operational change, the customer's historical substrates remain on the Bitcoin chain forever. The audit trail is independent of our continued existence. This is a stronger long-term guarantee than most commercial software licensing relationships provide.

Dispute resolution without disputes

In two decades of commercial software experience, I have seen many billing disputes. The usual pattern is that the vendor's billing system produces a number, the customer looks at the number and thinks it is too high, and then there is an argument about which counts are correct. The argument eventually resolves, but the resolution process is expensive for both sides — engineering time on both sides, legal time sometimes, and a lot of back-and-forth communication. Disputes are expensive even when they are good-faith.

Chain metering structurally eliminates disputes by making the billing count a deterministic function of public data. There is no dispute to have, because both sides are reading the same data and applying the same algorithm. If the numbers disagree, one side has a bug, and the bug can be found by reviewing the scanner implementation. The dispute is not a business negotiation; it is a software debugging session, and software debugging sessions are much less expensive to resolve than business negotiations.

This is not a hypothetical benefit. In our internal discussions with prospective customers, the self-enforcing billing property has been one of the most well-received aspects of the commercial model. Customers do not have to trust us, which is freeing. They do not have to trust their own internal metrics (which are often dodgy), which is also freeing. They just have to trust Bitcoin, and every commercial customer who has considered the substrate has already made the decision to trust Bitcoin for their own integrity workflow, so the trust is already in place.

The data residency property

One more property of chain metering is worth highlighting because it matters for a specific category of customers.

Many of the substrate's target customers are subject to data residency regulations — GDPR in the European Union, GLBA and HIPAA in the United States, various country-specific data protection laws, and export controls for defense and national security applications. These regulations typically require that sensitive customer data not leave the customer's own infrastructure, which rules out hosted metering services that would see the customer's substrate minting activity.

Under chain metering, the customer's actual data never reaches us. What we see is only the on-chain anchoring transactions, which contain no data beyond the substrate's 32-byte signing message (a hash) and, inside that hash, the fingerprint that identifies the customer. We do not see the input to the computation, the output, the canonical encoding, or the raw signature bundle. We see a hash and nothing else. The hash is a commitment to the substrate's contents, but it does not reveal those contents, because hashing is a one-way operation.

For data residency compliance, this is exactly the property the customer needs. Their data stays in their infrastructure. The public anchoring transaction contains only a cryptographic commitment, which is not data subject to residency regulations (it is a hash, not personal data). The commitment is on a public blockchain, which is in one sense everywhere and in another sense nowhere — but critically, no data ever moved.

A customer can deploy the substrate in a jurisdiction with strict data residency rules and still pay us for usage, because the usage tracking mechanism is compatible with the data residency rules. This is a significant operational advantage over traditional commercial billing mechanisms that require the customer to expose their usage activity to a hosted service.

The broader pattern

Chain metering as a billing mechanism is interesting beyond the specific substrate use case, because it is an example of a broader pattern: using an append-only public log as a coordination mechanism between parties who do not trust each other.

This pattern is not new. Certificate Transparency (Google's public log for TLS certificates) uses it for a different purpose — keeping certificate authorities honest about what certificates they have issued. Sigstore uses it for software artifact attestation. Various blockchain-based notary services use it for document timestamping. The general principle is: if you need both sides of a relationship to agree on some historical fact, and neither side trusts the other, use a public log that both sides can read to record the fact.

For software licensing specifically, chain metering is a novel application of the pattern as far as I know. Most commercial software licensing uses either trusted self-reporting (Approach 1), hosted services (Approach 2), or audit agents (Approach 3). Chain metering is a fourth option that has specific properties the other three do not have: self-enforcement (because the customer's own workflow produces the billing record), customer-side verifiability (because the billing count is a deterministic function of public data), dispute elimination (because both sides read the same source of truth), data residency compliance (because no customer data ever reaches the vendor), and vendor-independence (because the billing record survives any vendor changes, including vendor exit).

The cost of chain metering is that it requires the customer to be anchoring to a public blockchain as part of their normal workflow, which is a specific assumption that does not fit every software product. For the substrate, the customer is going to be anchoring to Bitcoin anyway (it is the reason the substrate is valuable), so chain metering is a free feature on top of the anchoring they were already doing. For a different software product that does not involve on-chain anchoring, chain metering would require the customer to add a new behavior purely for billing purposes, which is a harder sell.

If you are building commercial software that already involves on-chain anchoring for integrity purposes, I recommend considering chain metering as a billing mechanism. The self-enforcement and verifiability properties are worth the engineering cost of the chain scanner, and the customer-facing story is much cleaner than any of the traditional alternatives.

Closing

Chain metering is the commercial model mechanism I am most proud of from the substrate's design process. It is not the most technically deep part of the system — the three-family signing is more cryptographically interesting, and the Merkle aggregation is more mathematically elegant. But chain metering is the part that best exemplifies the broader design principle: wherever possible, use a third-party public log to eliminate the need for trust between the parties in a commercial relationship.

The substrate could have been billed using traditional commercial metering, and it would have been simpler to implement on our side. It would also have been worse for customers, worse for us in dispute-resolution cost, and worse for the long-term credibility of the commercial relationship. By routing the billing through Bitcoin, we buy a set of properties — self-enforcement, customer-side verifiability, data residency compliance, vendor-independence — that are hard to get any other way, and we buy them at relatively low engineering cost on our side.

For the bitcoin-dev community, I hope the post is useful as an example of what Bitcoin can be used for beyond peer-to-peer payments. The blockchain is a general-purpose coordination mechanism for parties who need shared truth without shared trust. Commercial software billing is a specific application of that coordination mechanism, and I suspect it will not be the last novel application to emerge as more commercial vendors figure out how to route their trust requirements through public chains.

The next post in this series is the pricing-structure post — specifically, how the substrate's commercial pricing is organized around flat rates for Bitcoin-native use cases and volume-tiered rates for other use cases, and why that structure matches the underlying economics of the substrate's cost of production. See you there.