The flat Bitcoin rate commitment: no volume discounts, no gatekeeping, no application form
This post is about a specific commercial commitment we have made for the substrate's Bitcoin-native use cases, and why the commitment is structured the way it is. I am not going to quote specific numbers in this post — the published pricing is in the whitepape
This post is about a specific commercial commitment we have made for the substrate's Bitcoin-native use cases, and why the commitment is structured the way it is. I am not going to quote specific numbers in this post — the published pricing is in the whitepaper and on the pricing page — but I want to explain the structure of the commitment, because the structure is unusual enough for commercial software infrastructure that it benefits from explanation.
The short version of the commitment is this: every substrate mint costs the same flat rate, regardless of computation type. There are no volume tiers. There is no hyperscale discount. There is no application process to qualify for a lower rate. The rate a hobbyist pays for minting one substrate a month is the same rate that a hyperscale exchange or a national payment processor pays for minting a billion substrates a month. Every user gets the same unit price for every computation type — Bitcoin, biometrics, documents, AI inference, everything — enforced by the licensed binary at mint time, with no sales team involvement and no contract negotiation.
For commercial software infrastructure, this is an unusual commitment. Most commercial pricing is volume-tiered, and the biggest customers get the lowest per-unit prices. Our commitment is the opposite: no tiers at all, for anyone, on any computation type. In this post I want to explain why we made that commitment and why I think the flat-rate structure is the right approach for post-quantum infrastructure.
Why flat pricing for everyone
The substrate supports 28 computation type bytes covering many different attestation domains: biometric authentication, fraud scoring, HTTP API response attestation, AI inference provenance, capture-time media authenticity, legal evidence chains, Bitcoin UTXO attestation, document version control, and several others. Every one of these gets the same flat per-mint rate. No tiers. No computation-type surcharges. No negotiated discounts.
The reasoning starts with the Bitcoin community's cultural expectations, but we realized it applies to everyone:
The Bitcoin community reacts against volume discounts. Bitcoin itself is designed to be egalitarian in its fee structure — a transaction from a millionaire pays the same per-byte fee as a transaction from a hobbyist. There is no "institutional rate" on the Bitcoin network, no negotiated discount for large customers, no VIP line. This is not an accident; it is a core cultural value of the Bitcoin ecosystem. Anything that looks like "big customers pay less per unit than small customers" is read as a violation of that value, and the reaction is typically strong. Commercial software vendors who have tried to apply standard enterprise volume discounts to bitcoin-community products have generally found that it does not land well.
The Bitcoin community values simplicity in pricing. "One number, flat, forever" is a pricing model the community understands and trusts. "Call sales for volume pricing" is a pricing model the community reads as obfuscation. The gap between the two is not about the math — volume discounts are not inherently dishonest — but about the mental model. The community prefers pricing that can be verified from a published document, rather than pricing that depends on a relationship with a sales representative. Anything with a volume negotiation phase adds friction at every customer touchpoint.
The Bitcoin community prefers automatic determinations over gatekept approvals. If there is a discount for "Bitcoin-community users," the question immediately arises: who decides who qualifies? If the answer is "a sales rep reviews each application," the community reads this as a gatekeeping structure that will be used to exclude people the sales rep does not like. If the answer is "the discount is automatic based on a public rule," the community accepts this because there is no gatekeeper. The substrate's flat Bitcoin rate is the automatic-determination answer: the rate applies to any substrate whose computation type is in the public Bitcoin-Native Set, and the determination is made by the licensed binary at mint time, not by a person after the fact.
These three expectations combine to make the standard enterprise volume-tiered structure inappropriate for the substrate. A substrate sold at a volume-tiered rate would face adoption friction across every customer segment — not just Bitcoin. A flat rate that is the same for everyone, for every computation type, sidesteps the friction entirely. The substrate is simply too useful to be greedy about.
One rate, every computation type
The mechanism is simple: when a customer mints a substrate, the licensed binary decrements one credit from the customer's balance. Every credit costs the same. The computation type byte does not affect the price. A substrate minted with computation type 0x06 BitcoinUtxo costs the same as one minted with 0x0C ApiResponse or 0x10 DocumentVersion or 0x0D AiInference. One price. Every type.
This removes every human judgment from the pricing process. There is no sales negotiation. There is no legal review of "does this customer qualify for a lower rate." There is no edge case where someone has to decide whether a specific use case gets a discount. The rule is: one mint, one credit, one price. Period.
The append-only Bitcoin-Native Set
The Bitcoin-Native Set is the specific list of computation type bytes that qualify for the flat Bitcoin rate. The list is initialized with one value (the BitcoinUtxo computation type, which is the canonical type for Bitcoin UTXO attestation) and grows over time as new Bitcoin-native computation types are registered in the substrate's broader append-only computation type registry.
The set is append-only. We cannot remove a computation type from the set once it is added. We also cannot reassign a computation type — once a byte is assigned a meaning in the registry, the meaning is frozen, so the set's composition at any historical time is fully determined by the registry state at that time.
The rule for what qualifies as "Bitcoin-native" is documented publicly: a computation type qualifies if its canonical use case is infrastructure that operates on the Bitcoin blockchain or a Bitcoin-native Layer 2 protocol (Lightning Network, RGB, BitVM, Ordinals, and equivalent ecosystems). The rule is simple enough that a person looking at a new computation type proposal can usually determine whether it qualifies in about thirty seconds. The determination is published alongside the type's addition to the registry, so the community can see the reasoning and object if they disagree.
Over time, we expect the set to grow substantially. Lightning channel attestation is a natural future addition. RGB client-side validation state is a natural future addition. Ordinals inscription provenance is a natural future addition. BitVM execution traces are a natural future addition. Each of these, once registered, would automatically receive the flat Bitcoin rate for all customers using them. We do not need to do anything case-by-case; we just need to add the type to the registry and update the Bitcoin-Native Set publication.
This forward-compatible structure is important because it means the commitment scales with the Bitcoin ecosystem. As the ecosystem develops new infrastructure patterns that the substrate can attest, the substrate's pricing commitment automatically extends to cover those patterns. We do not get to decide in retrospect that a new Bitcoin-native computation type is "too hyperscale" for the flat rate; the rate applies to any type in the set, regardless of who is minting under it.
No volume discounts, period
One of the specific design decisions worth spelling out is that we do not offer volume discounts on the Bitcoin rate, even to the largest customers. This is an unusual commitment because it means that a hyperscale customer minting billions of substrates per month pays the same per-mint rate as a hobbyist minting one per month, and a commercial vendor that could offer a better unit price to the hyperscale customer is choosing not to.
The reason we are not offering volume discounts is straightforward: the substrate's underlying cost structure does not have a strong volume component. The per-mint signing cost is approximately constant (the three-family bundle cost). The per-mint storage cost is approximately constant (74 bytes of persistent footprint). There is no meaningful economy of scale at the unit level — producing ten million substrates per month is not significantly less expensive per-unit than producing one thousand. The costs that do scale with volume (support, compliance certification maintenance, infrastructure overhead) are real but small relative to the unit price, and they apply to all customer tiers.
Because the underlying cost structure does not have strong economies of scale, the economic justification for volume discounts is weak. In most commercial pricing, volume discounts reflect the vendor's lower per-unit cost of serving large customers — the vendor is passing on some of the savings. Under the substrate's cost structure, there are no savings to pass on, so a volume discount would be the vendor taking a smaller margin to please the large customer, not a reflection of genuinely lower costs.
A discount that is not reflected in underlying cost structure has a specific name in pricing theory: it is called price discrimination. Price discrimination can be economically rational for the vendor (it extracts more surplus from customers with higher willingness-to-pay while still serving customers with lower willingness-to-pay), but it has social and cultural costs that are specific to the substrate's target market. The bitcoin community reads price discrimination as unfair, and unfairness-reading is a strong negative signal in commercial relationships.
The flat rate is our commitment to not engage in price discrimination on the Bitcoin side. Every customer pays the same price, regardless of their size or their negotiating leverage. This is not because we are incapable of charging more to larger customers — we could — but because we believe the flat rate is better for the Bitcoin ecosystem and for our commercial relationship with it.
Why a flat rate works for us commercially
I want to address the obvious commercial question: if we are not charging more to larger customers, are we leaving money on the table? Yes, in the naive sense. But the commercial argument for the flat rate is not that we capture maximum per-customer revenue. The commercial argument is that the flat rate lowers the friction to adoption, which increases total customer count, which is worth more than the per-customer markup we would get from volume-tiered pricing.
Here is the rough economic calculation. Under a volume-tiered structure, large customers pay less per unit than small customers, and the vendor's per-customer revenue is higher for large customers (because volume × discounted rate > the smaller volume × standard rate). But the adoption friction for small customers is higher, because small customers face a pricing model that feels "not designed for them." Many small customers simply do not adopt, because they read the volume-tiered structure as signaling that the product is aimed at a different audience.
Under a flat-rate structure, large customers pay more per unit than they would under a volume-tiered structure (because there is no discount), but the adoption friction for small customers is zero — the pricing model is simple, the rate is published, and there is no sense of being "the wrong size for this product." Small customers adopt, and the total customer count is much higher.
For a commercial product whose economics depend on ecosystem adoption as much as on per-customer revenue, the flat-rate structure can produce higher total revenue than the volume-tiered structure, because the customer count grows faster than the per-customer revenue shrinks. This is especially true in the Bitcoin ecosystem, where ecosystem effects are strong: projects that adopt the substrate bring other projects with them, developer tooling improves for everyone, the substrate becomes a de-facto standard that more customers feel obligated to support, and the commercial flywheel accelerates.
The flat rate is a bet that ecosystem adoption is more valuable to us than per-customer margin maximization. We believe this bet is correct across every segment of the product. The substrate is infrastructure — it needs to be everywhere, adopted by everyone, from hobbyists to hyperscale. Tiered pricing would optimize for per-customer revenue at the cost of adoption velocity. Flat pricing optimizes for adoption velocity, which is what infrastructure needs.
What the flat rate does not do
To be honest about the limits of the commitment, there are several things the flat rate does not do, and I want to acknowledge them.
The flat rate is universal across all computation types. Whether you are minting Bitcoin UTXO attestations, API response attestations, AI inference provenance, document version attestations, or medical record access events — every mint costs the same. There is no computation-type surcharge and no preferred-type discount.
The flat rate does not cover non-mint costs. The flat rate is a per-mint rate, and it covers the cost of minting a substrate. It does not cover optional commercial services like managed hosting, 24/7 support, compliance certifications, custom integration engineering, or dedicated success engineering. Customers who want those services negotiate them separately, and the flat rate does not apply to those negotiations. The flat rate is a floor, not a ceiling.
The flat rate does not guarantee specific performance characteristics. A customer running the substrate on a Raspberry Pi will get different throughput than a customer running it on bare-metal Graviton4 — not because we charge them differently, but because the hardware is different. The flat rate is the unit price; the hardware the customer runs on is their own responsibility. If they need a specific performance tier, they have to provision appropriately.
The flat rate does not guarantee free support. We offer community-tier support for free-tier customers (the free developer allowance of a certain number of mints per month), but commercial customers beyond the free tier are expected to subscribe to a support plan if they want responsive service. The support plan is separate from the per-mint rate. A customer can pay the flat rate for Bitcoin substrates and receive only community-tier support unless they opt into a higher support plan.
The flat rate is not a price guarantee against future changes. We reserve the right to adjust the flat rate in the future, with notice, if circumstances change significantly. Reasons we might adjust the rate include: a fundamental change in the substrate's cost structure (unlikely in the short term), a major cryptanalytic event that requires parameter upgrades (which would affect signing cost), or a strategic commercial decision that the rate is wrong. The rate is "flat" in the sense that it is the same for everyone at any given time, not in the sense that it is frozen for eternity. For customers who want a specific rate locked in for a specific contract duration, we offer multi-year commitments that fix the rate for the commitment period.
Each of these limits is worth stating because commercial commitments that are not clearly scoped end up being misunderstood, and misunderstandings create friction. The flat rate is what we describe it as: a per-mint rate that is the same for every customer, applied automatically to substrates whose computation type is in the Bitcoin-Native Set. It is not a guarantee of free support, not a guarantee against future adjustments, not a replacement for enterprise services, and not a universal rate across all substrate use cases. Within its specific scope, it is exactly what it claims to be.
The commitment as a public signal
Beyond the economic case for the flat rate, there is a signaling case worth mentioning. Commercial vendors who publish flat-rate pricing are communicating something specific to the market: that they are willing to trade per-customer margin for ecosystem adoption, that they have a cost structure that does not require volume discrimination, and that they are aligned with the community's cultural expectations about pricing.
For the Bitcoin ecosystem specifically, publishing a flat rate is a public signal that we are building for the ecosystem, not just extracting from it. Extraction-framed vendors do not publish flat rates. Extraction-framed vendors publish contact-sales pages and negotiate per-customer. A published flat rate says: "we have done the math, we have decided what the price is, and we are not adjusting it based on who you are." This signal is valuable to the community because it is unusual, and because the unusual-ness signals commitment.
Signaling alone would not be enough to justify a pricing commitment that was bad economics for us. But combined with the underlying economic case (that ecosystem adoption is worth more than per-customer margin for this specific segment), the signaling effect tips the decision firmly in favor of the flat rate. We get both: a pricing structure that serves the Bitcoin ecosystem culturally, and a commercial outcome that we believe is better for us than the alternative.
Closing
The flat Bitcoin rate is a specific commercial commitment, deliberately structured to match the cultural expectations of the Bitcoin ecosystem and the underlying cost structure of the substrate. It is automatic, determined by the computation type byte of the substrate being minted, enforced by the licensed binary at mint time, and the same for every customer regardless of size. It is not a volume discount structure. It is not a negotiation framework. It is not a gatekeeping mechanism. It is a published commitment that applies to everyone who mints a substrate in the Bitcoin-Native Set.
For the Bitcoin community, the commitment is meant as a gesture of good faith and an economic alignment with how the ecosystem expects commercial software to be priced. For our commercial model, the commitment is an economic bet that ecosystem adoption is worth more than per-customer margin maximization in this segment. Both framings point to the same commitment, which is why we made it.
The substrate's non-Bitcoin-native pricing follows a different structure that looks more like standard enterprise software pricing, for customer segments where the cultural expectations are different. I will cover that in a later post in this series. For this post, the takeaway is that the Bitcoin-native flat rate is a specific commitment, deliberately structured, designed to be legible and fair to the Bitcoin community, and backed by an underlying cost structure that makes the commitment economically sustainable.
The next post in this series is about why we open-sourced the verifier and nothing else. See you there.
Build with the H33 Substrate
The substrate crate is available for integration. Every H33 API call now returns a substrate attestation.
Get API Key Read the Docs