Token House
A market for future inference
Whitepaper v1.0 — September 2026
1. The problem
AI is becoming the fastest-growing cost line in most company budgets. Unlike jet fuel, power, or interest rates, inference is not easily hedgeable, let alone tradable.
Buyers pay spot pricing that embeds real-time availability: capacity held ready, sub-second latency, and the provider's margin for holding that capacity idle between requests. A material share of enterprise inference uses none of it. Document extraction, classification, enrichment, evaluation runs and overnight agent batches are submitted in bulk and consumed asynchronously — billed at real-time rates because real-time is the only delivery mode on sale.
Four consequences follow.
No price discovery. Providers serving an identical open-weight model differ by 3–6× on published rates.
No forward curve. A buyer cannot fix a price for future delivery. Published decline figures — gateway token costs down 23.2% in August 2026 — largely measure teams migrating to cheaper models rather than a given model repricing. But same-model prices move sharply too: GLM-5.3-Flash doubled in September when its launch promotion ended. Either way, there is no instrument to lock against.
No committed deferred product. Batch APIs advertise best-effort completion within 24 hours — no contractual turnaround, no remedy. Reserved instances offer a price but lock the buyer to one provider and one model generation.
No supply-side outlet. An idle GPU-hour is destroyed, not inventoried. Operators cannot sell trough capacity without discounting their on-demand rate and cannibalising their daytime book.
The hedging instruments now reaching regulated venues do not address this: CME's compute futures settle against GPU rental indices — the price of hardware, not the price of inference.
2. The exchange
What is missing is not a cheaper provider. It is a contract — a standardised, dated, tradable claim on inference delivered at a future time, against which price can form.
Token House is the venue that lists and clears that contract.
Buyers purchase capacity on a named model build for a dated delivery window, at a price fixed when they trade. Operators sell capacity they cannot otherwise monetise, quoted in the unit they actually own. The exchange converts between the two, clears supply against demand, schedules execution across the pooled queue, and guarantees the delivery window. Settlement is physical: work goes in, results come out.
Every trade prints. Those prints are the first published price for future inference.
BUYERS OPERATORS
│ │
│ buy TE balance │ post $/GPU-hour
│ price fixed at match │ resting asks
▼ ▼
┌──────────────────────────────────────────────────────┐
│ ORDER BOOK │
│ certified throughput converts asks → $/M TE │
│ buyers take, or rest limit orders │
└──────────────────────────────────────────────────────┘
│ │
│ submit work │ capacity committed
▼ ▼
┌──────────────────────────────────────────────────────┐
│ DEADLINE (T0) — book closes │
│ queue freezes · capacity pools │
└──────────────────────────────────────────────────────┘
│
▼
SCHEDULER
batches by shape · sorts by prefix
dispatches packets across pooled capacity
│
┌───────────────┼───────────────┐
▼ ▼ ▼
committed standby operator-funded
capacity market replacement
└───────────────┼───────────────┘
▼
WINDOW CLOSE (T1)
results delivered
│
▼
SETTLEMENT · PRINT
operators paid · index published
Two tenors will be live to start with — Overnight and Weekly deadline-delivery series — on two named open-weight builds, gpt-oss-120b and GLM-5.3-Flash. The contract standard is tenor- and instrument-agnostic by construction: these are the first listings, not the product.
The rest of this document describes the contract, why it can be sold below spot, and how the exchange operates.
3. The instrument
3.1 The series
A market series is defined as:
Model / Build × Delivery Window × Delivery Date
Every series is a contract on a specific build, delivered within a specific window, on a specific date. Dating is deliberate: only dated contracts are comparable to one another, comparable prints produce a curve, and a curve is what makes a benchmark possible.
Series are listed on open-weight models only. Execution parity is unverifiable in principle for a closed model — the buyer cannot confirm what ran, and a single provider controls supply and price. Open weights make the supply base contestable, the execution standard enforceable against a published build hash, and outputs checkable against a reference deployment. This is newly practical: open-weight models crossed the majority of enterprise gateway token volume during 2026, rising from 7% in December to 56% in August.
3.2 The token equivalent
Buyers hold a balance denominated in token equivalents (TE), the exchange's unit of account:
TE = Q_out + w · Q_in
One output token is one token equivalent. One input token is w token equivalents. The convention follows normalised commodity units — a barrel of oil equivalent, a tonne of CO₂ equivalent — so that heterogeneous consumption resolves to one tradable quantity.
w is a declared convention, copied from a single named fallback provider's published input:output price ratio and fixed for the life of the series. It is a listing parameter, reviewed for each new listing, not a quantity the exchange attempts to derive from first principles.
To start, w will be determined based on the fallback provider.
3.3 Who sells, and in what unit
Two classes of seller, quoting in the unit each actually controls.
Inference providers already operate an API and price in tokens. They sell capacity directly, quoting $/M token equivalents and declaring the quantity they will serve. No conversion is involved; they know their own throughput and set their own price against it.
GPU owners hold hardware rather than an endpoint. They quote $/GPU-hour, the only unit they can price. Certification converts the ask into token equivalents for the book, and the platform shows each seller their computed floor and the buyer-facing price their ask implies before they post.
Both populate the same book. A buyer sees one supply curve in one unit and does not need to know which class filled their order.
3.4 Terms
Fixed strike at match. A buyer matches against a resting operator ask and receives a capacity balance at that price. Different buyers pay different prices depending on when they traded and against which ask. This is a forward market; you get the price you trade at.
Take-or-pay. The balance is paid for whether or not it is used.
Physical delivery. The balance is a right to inference, executed and returned. Nothing is cash-settled.
Hold-and-release billing. Charging happens at the balance level, not per request. At dispatch the exchange holds w · Q_in + Q_out,max against the balance; on completion it charges w · Q_in + Q_out,actual and releases the difference.
max_tokens therefore remains a free safety ceiling performing its normal function. A buyer who sets it generously does not overpay — they hold more of their own balance while requests are in flight, which limits their own concurrency. The incentive to set it sensibly is self-correcting and no penalty instrument is required. A failed request releases its hold in full and is charged nothing.
Expiry. Unused balance expires at the submission deadline and the matched operator is paid.
This is not a penalty. The operator blocked a window against that balance; the scheduler cannot dispatch work that does not exist; capacity released at the deadline is too late to sell into the same series. Reserved hardware that goes unused is destroyed, not returned to inventory.
The answer to expiry risk is tenor, not leniency. Forecasting one night's batch is tractable. Forecasting a month's is the problem that makes reserved capacity unpopular in the first place.
3.5 Delivery modes
| Deadline delivery | Anytime delivery | |
|---|---|---|
| Buyer submits | By the cutoff | Any time within the window |
| Buyer receives | Everything by window close | Each job within a stated turnaround |
| Scheduler receives | A complete queue | Partial flow |
| Price | Lowest | Between deadline and spot |
Deadline delivery is what a batch API attempts and does not commit to. It earns the largest discount because the scheduler holds the entire queue before execution begins — for the reasons set out in §4.
Anytime delivery preserves the buyer's option to decide later. The scheduler can only work with what has arrived, so the achievable discount is smaller and the contract is priced accordingly.
3.6 The parameter set
Every series is an instance of one schema. A new listing is a new set of parameter values, not new machinery:
| Parameter | First listings |
|---|---|
| Model / build | gpt-oss-120b and GLM-5.3-Flash, hashes pinned |
| Delivery mode | Deadline |
| Tenor | Overnight (12h) and Weekly |
| Calendar | Overnight 00Z daily; Weekly delivered Friday 00Z |
| Model specificity | Named build |
w reference |
Fallback provider, declared at listing |
| Execution envelope | Context ceiling, reasoning effort, precision floor — all pinned |
| Certification basis | Reference shape, per model × hardware × runtime |
The standard is general; the listings are deliberate.
The same primitives support deadline and anytime delivery, named-build and model-class specificity, and any tenor from hours to months. What is listed at any moment is a commercial decision about where liquidity and value sit — not a limit of the contract standard.
3.7 The first listings
Overnight and Weekly deadline-delivery series, on two named builds: gpt-oss-120b and GLM-5.3-Flash.
Why two models. They recruit different sellers rather than competing for the same supply. gpt-oss-120b fits on a single GPU with published throughput on H100 and B200, so any operator with one card can serve it — the widest possible seller base. GLM-5.3-Flash requires an eight-GPU node but carries stronger demand and a stable input weight. Listing both hedges the recruitment risk in either.
Why these tenors. Overnight captures the full density gain: a complete queue batched at per-request speeds no live provider can serve. Weekly adds supply-selection latitude — the scheduler can wait for cheaper capacity — and the spread between them is the first published price for an additional six days of patience.
Longer tenors are architecturally trivial and held back deliberately. A monthly book with a handful of participants produces an index that is noise, and the index depends on depth. Monthly lists once Weekly prints consistently.
Why the overnight window is dated daily. Every buyer globally has a window landing overnight in their own timezone once the second daily window is added, and the worst-case wait for the next deadline halves. Operators with continuous availability post into both at near-zero marginal cost, which makes the always-available operator structurally the cheapest supply.
Everything else goes to RFQ. Requests outside the standard envelope — unusual shapes, other models, bespoke tenors — are quoted bilaterally. RFQ flow is also the evidence base for what to list next: the exchange lists what buyers are already asking for, rather than guessing.
4. Why deferred inference costs less
The contract can be sold below spot because deferred work costs less to produce. Not because a provider concedes margin — because the scheduler can do things with a deferred queue that it cannot do with a live one.
Two mechanisms, and they compound.
4.1 Decode density
Generating a token requires reading the model's weights out of GPU memory. That read happens once per decode step regardless of how many requests are in flight, and every request in the batch receives a token from it. Aggregate throughput therefore rises with batch size while each individual request slows down.
Published figures for a 70B-class model on a single H100 show 304 tokens per second aggregate when each user receives 91 tokens per second, and 1,465 aggregate when each user receives 53 — a 4.8× swing in output per GPU-hour from nothing but relaxed per-request speed.
No provider publishes the operating point below that, because no provider can serve it: a human is waiting. A deferred market can. The density available at 10–20 tokens per second per request is the primary source of the discount.
The effect is stronger, not weaker, for modern mixture-of-experts architectures. A model with 320 billion total parameters and 18 billion active per token is memory-bound and compute-light. Batching amortises the memory read across far more output, and expert utilisation improves as batch size grows.
4.2 Prefill reuse
Deferrable work is not shaped like chat. Information extraction alone accounts for roughly a third of enterprise agent-platform usage, and extraction, classification, enrichment and evaluation share a profile: long input, short output, and a system prompt identical across thousands of requests.
For this shape, decode density is not where cost sits. Prefill is — and prefill carries a larger lever. Providers already price cached input at roughly one-fifth of fresh input, which establishes what the saving is worth.
An interactive provider processes requests in arrival order and receives whatever cache hits arrival order happens to produce. A market holding a complete queue can sort it by shared prefix before execution begins. Ten thousand extraction requests against one schema, reordered to run contiguously, hit cache on nearly every prefill.
Most of this gain is local to a single buyer's batch, since the shared system prompt belongs to one customer — so preserving it requires only that a batch be kept intact through to execution. Pooling adds the cross-buyer share: density from concurrent requests that no single buyer is large enough to supply alone, and the ability to rebalance mid-window when a worker falls behind.
4.3 The pricing rule
Discount scales with scheduling latitude surrendered.
A buyer who commits all work before a deadline hands the scheduler a complete queue — full batching, full prefix sorting, full supply selection. A buyer who submits continuously through the window hands over less. A buyer who needs an answer now hands over nothing and pays spot.
This is the exchange's price logic, and it is why delivery modes are separate contracts at separate prices rather than interchangeable options on one.
4.4 What this is not
It is not a volume discount. A reseller committing early can extract perhaps 20% — that is what an operator serving on demand will concede for certainty, and it is bounded by the operator's own margin.
The discount here is a lower cost of production, bounded by memory bandwidth and scheduling rather than by negotiation.
5. Market mechanics
5.1 Two units, one price
Sellers do not all price in the same unit. Inference providers quote token equivalents directly; GPU owners can only price GPU-hours, and their token-equivalent yield depends on a workload mix they never see. Buyers, meanwhile, think in dollars per million tokens.
The exchange resolves this into a single book. A GPU-hour ask is converted through certified throughput into a price per token equivalent; a provider's ask is already in that unit. Sorting every resting ask produces one supply curve, and the derived price for any quantity is the cost of walking it.
Buyers see familiar per-million-token pricing and never need to know which class of seller filled their order.
5.2 Execution
Buyers either take at the derived price, or leave a limit order — buy Q token equivalents if the derived price falls below P — held by the exchange and executed automatically as the market moves.
Limit orders carry more weight than they appear to. They give buyers price expression without either side changing units. They give the exchange a demand curve it otherwise could not observe. And because certified capacity is progressively released as the deadline approaches (§6), the derived price declines predictably through a session — with limits, a buyer waiting for a better price is a resting order rather than an absence.
Accepted operators are paid their own ask. With a visible book and competing resting supply, an operator maximises margin multiplied by the probability of allocation, which is a direct incentive to undercut.
5.3 Market structure as depth develops
Electricity markets run three tenors on three mechanisms, and the logic transfers directly. Forwards trade continuously because participants arrive at different times. Day-ahead clears in a single call auction at a fixed hour, because concentrating every participant into one moment produces the deepest book and the most defensible price — which is why the day-ahead price is the sector's reference rate. Intraday runs continuously again until gate closure, adjusting against that reference.
Token House is structurally an intraday market at launch: continuous, anchored to an external benchmark. That is correct while the book is thin, because a call auction with three participants is worse than no auction.
As depth develops, a uniform-price call auction is added at the gate, clearing the residual book and producing a single settlement price per series. It layers on top of continuous matching rather than replacing it, exactly as power markets do.
6. Certified compute capacity
6.1 Certification
Capacity sold on the exchange is certified, not asserted. Each approved combination of model, hardware and runtime is benchmarked to establish token equivalents deliverable per GPU-hour within the series envelope.
Certification is conservative: it assumes the most demanding workload shape the envelope permits, so any actual mix outperforms it.
6.2 Progressive release
That conservatism exists to cover uncertainty about workload shape, and the uncertainty falls as work is submitted. A static haircut is therefore over-provisioned against information the exchange already holds.
Certified capacity is relaxed progressively toward the deadline. As each request arrives, exact input length and declared output ceiling are known, so the GPU-time actually required is known. The difference between provisioned and required time is freed and re-certified at worst case, becoming additional sellable capacity.
1 GPU-hour sells 100 TE at worst-case certification.
Half the balance submits, requiring 0.25 GPU-hours rather than the 0.5 provisioned.
0.25 GPU-hours are freed and re-sold at worst case as 25 TE.
The unsubmitted half retains its full provision.
Because release banks only realised gains and holds worst case for everything unsubmitted, there is nothing to be gained by submitting late — remaining capacity never assumed anything better.
The dominant source of release is not workload mix but the gap between what the envelope permits and what buyers declare. A request submitted with a 2,000-token output ceiling against a 32,000-token envelope releases most of its provision immediately.
Released capacity is offered first to buyers who have already submitted against that series, at their original matched price, then to resting limit orders, then to the open book. Early submission generates the release, and this is how it is compensated.
7. Delivery and recovery
Work is dispatched in small packets rather than whole allocations. This surfaces underperforming workers quickly, limits exposure to any single failure, and allows continuous rebalancing. The scheduler owns the queue throughout; workers receive packets, never ownership of a customer's workload.
If a worker falls behind its required pace, the exchange stops assigning packets, returns unstarted work to the queue, and escalates:
Matched firm supply
→ Standby provider (standing price)
→ Operator-funded replacement
→ Withheld settlement / refund
The standby provider. One or two providers per model stand under a standing agreement, at a standing price, on short notice. They are paid that standing price; the gap between it and the buyer's price is drawn from the failed operator's cover.
A named standby does more than recover work. Cover is sized against the cost of replacing a failed operator, so replacing an open-market real-time price with a lower standing price reduces the cover requirement across the entire book — which lowers the barrier to selling and deepens supply. The recovery mechanism and the capital efficiency of the market are the same decision.
A standby market with many participants is the eventual form. A standing agreement with one counterparty is the correct form at launch, because a market needs participants and an agreement needs only a signature.
Operator-funded replacement. Every firm operator maintains an API key with a monitored credit balance. If their capacity fails, replacement executes against their key, at their cost. Recovery is funded by the party that caused the failure — automatically, with no dispute and no collection.
Settlement. An operator that does not deliver is not paid. Withheld settlement covers the remainder of any replacement cost.
No exchange capital is committed at any layer. This is deliberate. A guarantee backed by the venue's balance sheet scales with that balance sheet; this one scales with the market.
The commitment is therefore stated precisely: delivered by the window close, or refunded, with two funded recovery layers between those outcomes. Best-effort batch offers neither.
8. Risk and settlement
Buyers pay at match. Operators are paid in arrears on delivered work. Between those two facts sits the exchange's entire counterparty exposure, and it is covered by two instruments held by the operator.
Cover required = λ · (P_standby − P_operator) · outstanding capacity
Cover available = API key balance + reserve balance
Allocation cap : cover available must meet cover required
Exposure is the shortfall — the gap between replacement cost and the payment already collected — not the gross cost of replacement. Because replacement runs through a standing agreement rather than the open market, that gap is smaller than it would otherwise be, and every seller's cover requirement falls with it.
Cover instruments stack by tier. Uniform pre-funding is a barrier that keeps reliable providers out and does not match their actual risk. A tier is assigned at onboarding from seller class, identity, hardware and record, and improves with delivery history:
| Tier | Qualification | λ | Cover instruments | Revenue sweep |
|---|---|---|---|---|
| Entry | New seller, any class | 1.00 | Funded key + cash reserve | 100% |
| Established | 90 days, ≥97% delivery, ≥10 parts | 0.70 | Funded key + 4-week holdback | 50% |
| Core | 180 days, ≥99% delivery, multiple series types | 0.40 | 1–2 week holdback | 0% |
| Restricted | Delivery below threshold, or a default | 1.00 | Cash reserve at full λ | 100% |
An inference provider with verified identity and an existing delivery record may be placed above Entry at onboarding. A GPU owner with no record starts at Entry regardless of hardware. A provider with a record needs only a holdback; an operator with none needs cash for their first windows, after which the holdback takes over.
Delivery rate — work completed on time as a share of work dispatched — is measured over a rolling 90 days with a minimum of ten dispatched parts, across every series type the seller quotes. A calendar window rather than a series count matters once tenors differ: sixty series on a weekly contract would take over a year. The minimum count stops a rate being computed from three data points. Three failures before ten parts also suspends.
Demotion is one step; a default goes straight to Restricted. The reserve releases 30 days after an operator's last sold capacity, with the clock resetting on any new sale.
The fee is flat: 3% of gross, charged to the seller and deducted from their ask. It is not tiered. The tier already sets cover, holdback and allocation, and a discretionary fee on a venue that also lists is a conflict question not worth inviting. The rate is reviewed once the measurement programme establishes achievable margin.
Execution parity is enforced, not assumed. Approved build hash, minimum precision, tokenizer, context ceiling and reasoning settings are pinned in the series envelope. Workers attest to weight hashes at registration, and seeded challenge requests embedded in dispatched packets are checked against a reference deployment. An operator running a cheaper quantisation is detected rather than trusted.
9. Economics
9.1 Reference hardware
The two launch models sit at opposite ends of the hardware requirement, which is why both are listed.
gpt-oss-120b fits within a single 80 GB GPU, with published throughput on H100 and B200. Any operator with one card can serve it.
GLM-5.3-Flash requires roughly 328 GB at FP8 for weights alone, before KV cache. Four-GPU H100 configurations do not fit. Eight-GPU nodes fit with room for the large batches the economics depend on.
| Configuration | VRAM | Rate | Per GPU |
|---|---|---|---|
| 8× H100 80GB HBM3 | 637 GB | $22.00/hr | $2.75 |
| 8× RTX PRO 6000 | 768 GB | $16.72/hr | $2.09 |
| 4× H100 80GB | 320 GB | $10.42/hr | does not fit |
H100 SXM sits broadly at $2–3 per GPU-hour on marketplaces, with the full vendor range running from under $1.50 to nearly $7.00 at hyperscalers. Blackwell-class capacity remains thinly published; most providers quote it through sales conversations rather than rate cards.
9.2 The floor
An operator's floor is node cost divided by throughput. At a token equivalent weighted to the prevailing input:output ratio, the token-equivalent price tracks the output-token price:
| Buyer price per M TE | 8× H100 at $22/hr | 8× PRO 6000 at $16.72/hr |
|---|---|---|
| $0.50 | 12,200 tok/s | 9,300 tok/s |
| $0.35 | 17,500 tok/s | 13,300 tok/s |
| $0.25 | 24,400 tok/s | 18,600 tok/s |
This table is the exchange's central economic fact. At interactive density the floor sits at or above the prevailing market price, which means the discount cannot come from squeezing operators — they are already at their floor. It comes from density and hardware selection, and how far it goes is set by the achievable throughput in §4.1.
9.3 Fees
The exchange charges the seller a flat 3% of gross, deducted from their ask. The buyer's price is untouched.
This is structural rather than cosmetic. The buyer side is capped by the cost of real-time execution and benchmarked against batch; the seller side is capped by nothing. The rate is sized against seller margin, which on the table above is measured in cents per million token equivalents rather than against notional — at a $0.35 clear against a $0.28 floor, 3% takes roughly 15% of the margin. That is tolerable and will be reviewed once achievable throughput is measured.
10. The price surface
Every match is a printed transaction with a price, a size, a model and a dated window. That data does not currently exist anywhere.
The Token House Rate is published per model and per series type — Overnight, Weekly, and longer tenors as they list. Each is a volume-weighted average of matches, weighted in GPU-hour-equivalents so the index remains independent of the exchange's own certification. Published alongside it: total matched volume, high, low, residual depth at the gate, and the prevailing rental, batch and real-time benchmarks.
Methodology differs by tenor, deliberately. A short-dated series prints from a closing window before its deadline, which concentrates the sample at the moment the market is most informed and is harder to move than a trailing average on a continuously matched book. A longer-dated series trades too sparsely for a closing window to be meaningful and prints on a trailing basis over its own trading period. Each series states its own method at listing, and the method does not change once capacity has traded against it.
One listing prints a number. A grid of listings prints a surface, and the spreads within it are individually meaningful:
- Overnight against Weekly — the marginal value of six further days of latitude
- Deadline against anytime — the density and prefix premium, isolated
- Named build against model class — the price of substitution rights
- One model against another — relative cost of capability at equal tenor
- Deferred against real-time — the total value of all of it
None of these numbers is published by anyone. Existing benchmarks cover GPU rental rates and centralised provider token prices; the term structure of deferred inference does not exist. The marginal cost of publishing it is close to zero for a venue already generating the data.
11. Future development
What follows is a development path, not a feature list. Each addition has a condition.
11.1 Listings
Second overnight window (12Z) — once the first shows consistent flow. It costs operators almost nothing, since a continuously available node serves both, and halves the worst-case wait for buyers.
Monthly series — once Weekly prints consistently. Architecturally trivial; held back because a thin book produces an index that is noise, and the index is the asset.
Intermediate tenors — 24-hour and fortnightly, filling the curve between listed points once the endpoints have depth.
Anytime delivery — when RFQ flow demonstrates demand. It prices differently and is listed as its own contract, not offered as a toggle.
Model-class specificity — once a second build certifies on the same hardware, making substitution meaningful. A buyer specifies a quality threshold rather than a build, and receives whichever qualifying model is cheapest at delivery — which hedges model obsolescence, the single worst risk in any long compute commitment.
Additional models — driven by RFQ evidence rather than by selection. The exchange lists what buyers are already asking to buy.
A standby market replacing the standing agreement, once enough operators want to sell short-duration idle capacity to make a venue viable.
11.2 Trading functionality
Transferable entitlements and a secondary market. A capacity balance with a fixed strike and a dated window is a tradable claim. Once matched supply is scarce enough that an entitlement carries a bid, buyers can exit positions rather than letting them expire — which materially improves the case for buying forward.
Call auction at the gate. A uniform-price clearing on the residual book, producing a single settlement price per series rather than a synthetic closing average. This becomes the index when depth supports it.
Richer order types. Resting demand, partial fills across asks, and conditional orders tied to published benchmarks.
Expanded RFQ. Bilateral quoting for bespoke tenors, non-standard envelopes and unlisted models, feeding listing decisions.
11.3 Cash settlement
The physical market comes first. Once there is a price history worth referencing, cash-settled contracts referencing the published index become possible: a contract carrying no delivery right, used to hedge inference cost rather than to procure it.
This is what makes inference hedgeable in the sense §1 describes — an enterprise with large token spend taking a financial position against the index, without ever routing a workload through the exchange. It requires a benchmark with genuine volume behind it, which is the reason physical delivery and index publication come first.
Token House intends to operate within a regulated perimeter as the market matures.