This article is a deep research report produced by OKX Ventures. Due to its length, it is divided into two parts for publication: the first part focuses on hashrate securitization, risk exposure, and derivative pricing logic; the second part will mainly analyze hashrate financial infrastructure, inferred securitization opportunities, and industry trends. This is the second part of the article.

Multiple layers of the hashrate financial market infrastructure have begun to take shape. The index consolidates dispersed GPU rentals into a unified benchmark; exchanges organize standardized risks around the benchmark; Dealers take on basis points related to specific data centers, terms, and SLAs; and capacity platforms then reintegrate financial positions back into physical hashrate. The key to which layer accumulates a sufficient number of real orders and contract references first will be closer to the pricing power in the early market.

The transaction price of the same model GPU will still vary based on cluster scale, interconnection method, region, lease term, prepayment ratio, SLA, and vendor credit. For index providers, the challenge lies in whether they can incorporate these differences so that the market is willing to use it for contract settlement, loan valuation, and derivative delivery.
Currently, three main approaches can be observed. Silicon Data, Ornn are closer to independent benchmark providers, mainly through collecting market quotes and contract data, then standardizing the data to form the benchmark; Compute Desk acts as both a hashrate intermediary and settlement service, hence being able to directly observe executed spot and forward contracts, including price, term, and actual settlement conditions; SemiAnalysis starts from electricity, chip procurement, depreciation, and data center costs to do TCO modeling, which is more suitable for asset valuation and research, but further away from financial settlement benchmarks.
The core value provided by exchanges is standardization, clearing, and distribution. For Neocloud, AI Lab, and private credit institutions, if hedging can directly access existing FCM, margin, and clearing systems, institutional adoption costs will significantly decrease. Traditional exchanges and emerging compliant platforms have therefore begun testing hashrate products: CME, ICE continue mature futures infrastructure, while Architect AX/AIX, Pluto/PMEX are trying different paths on perpetual contracts and fixed-term futures.
The cold start of hashrate futures will be much more complicated than listing a single contract. Hashrate contracts are easily fragmented. Different GPU models, regions, and cluster configurations correspond to different delivery values, making it difficult for liquidity to naturally converge into a single contract. Remote prices also heavily depend on chip delivery, electricity, and model efficiency. Traditional financial market makers lack physical order information, making it challenging to provide deep quotes over a six-month or one-year term.
Industry hedging may also not be large enough in the short term. Hyperscalers can absorb a significant amount of risk internally, while the top Neocloud has already covered a considerable portion of cash flow with long contracts. The early on-exchange market is likely to accumulate trading and speculative liquidity first, and whether industry hedging can keep up will depend on whether small and medium-sized operators and AI teams that purchase compute power on-demand begin to trade continuously and repeatedly.
Before on-exchange depth is established, a significant amount of risk is more likely to be transferred through OTC transactions. The specifics of physical hashrate, such as region, network, cluster size, SLA, and delivery time, make it challenging to fit directly into a unified exchange-traded contract.
Dealers are therefore in a very valuable position. On one side, Neocloud wishes to lock in rent in advance, and on the other side, AI Lab wishes to lock in procurement costs. Dealers can provide customized quotes to both parties, then use standard futures or other positions to manage overall price risk. When buy and sell demand are misaligned in terms of timing and specifications, Dealers also need to take orders onto their own balance sheet.
Profits from this type of business come not only from the bid-ask spread. Data center, electricity cost, network conditions, delivery constraints, and customer credit all form a basis. Continuously pricing these non-standard differences and being willing to bear the risk with capital are abilities that Dealers find more challenging to replicate. FalconX's H100 swap with Robert Leshner and Wintermute's introduction of the H100 forward can be seen as early attempts by market makers to explore hashrate forward pricing and risk transfer. Financial intermediaries are beginning to provide custom term quotes for physical hashrate and leave the unstandardized parts on their own book.
Therefore, real order flow is crucial. The index informs the market's average price, while the inquiries and transactions in a Dealer's hand are closer to what premium needs to be paid for a certain region, configuration, and term; this information directly determines how the basis is priced and where the profit stays.
For the AI Lab, the financial position locks in the price and does not guarantee that a set of required GPUs will be available at that time. This difference is especially important when there is a shortage of computing power. Without physical delivery capability, futures prices and actual data center rental prices can easily diverge.
Several different levels of attempts have emerged. Spot platforms like Vast.ai, RunPod, and Hyperbolic provide richer physical quotation and available capacity data; SF Compute allows for the resale or repurchase of reserved capacity, providing some liquidity to long-term capacity contracts; the EFP network attempts to connect standard futures with specific physical contracts, using futures to handle large-scale pricing and offline contracts to handle regional, network, and SLA specifics.
The SF Compute model is particularly noteworthy. In traditional Take-or-Pay contracts, unused capacity often approaches the sunk cost; allowing for resale transforms future capacity into a tradable right. This increases the liquidity of long-term contracts and also makes the physical market itself show clearer forward prices.
The EFP addresses another layer of the issue. AI Lab can first lock in market beta using standard futures, and when it comes to actual deployment, can then use the fulfillment network to find specific data centers and pay the corresponding basis for region, network, and SLA. This way, the financial market does not need to cram all physical differences into a single futures contract and can still serve real industry delivery.
Once GPUs are tokenized by inference service providers, financial demand begins to extend from hardware rent to operational funding and contract rights in the inference business. If inference service providers want to lock in the full gross margin, theoretically they need to simultaneously manage GPU input costs and token output prices.
The profit of the inference service provider is roughly equal to: Token realized price × Token output per GPU-hour × GPU utilization − GPU cost − Other operating costs
4.5.1 What are the demand points for the emergence of inference economic assets?
GPUs and capacity need to be purchased in advance, while API revenue occurs gradually in response to customer requests. Overestimating demand will leave idle machines and tie up cash. Large model companies and hyperscalers can absorb this volatility on their balance sheets, but small and medium-sized inference platforms often rely on prepayment from customers or external financing.
The time difference between capacity availability and demand fulfillment has given rise to four types of assets: GPU credit for upfront investment financing; prepaid service rights to reclaim future revenue in advance; capacity incentives to subsidize supply before demand formation; and model deployment assets attempting to allocate the remaining profit after deducting operating costs.
The traditional cloud market has long been using prepaid credits and reserved capacity to deal with similar supply-demand mismatch issues. For example, OpenAI's Scale Tier allows enterprises to pre-purchase specific model input and output token throughput units. This has become a standardized prepaid inference service, except that the credits are tied to the enterprise's account and cannot be freely transferred.
Crypto has added a new layer of ownership design on-chain, where the service quota originally recorded in the vendor's account can be held by a wallet, further transferred, and financed. In the future, if agents start procuring inference services themselves, such rights can also directly enter the machine's budgeting system. As programmable payments become the industry's foundational infrastructure capability in the future, the more identifiable on-chain positioning actually lies in the rights layer. Whether a future service can be independently held, transferred, financed will directly impact whether it can evolve from ordinary credits to financial assets.
Currently, on-chain inference's share at the execution layer remains small, with crypto-native inference service providers accounting for only about 0.5%–1% of the OpenRouter's daily token traffic in the past three months. This also means that the more realistic opportunities on-chain at present may lie in the financial layer, with inference services continuing to be produced by the most efficient platforms, while on-chain transactions handle the flow of funds and rights.

4.5.2 Attempting to Assetize the Four Types of Inference
Currently, at Inference Capital Markets, there are four directions for assetizing equity.

GPU Credit
GPU credit was the first to scale, partly because it already had external funders and partly because its financial product structure closely resembles traditional credit assets, making it easier for institutional capital to understand.
A typical GPU loan still follows a traditional asset financing structure: the GPU is held by a Delaware SPV, the lender establishes a lien through a Loan and Security Agreement, UCC-1, and data center lien waiver. On-chain records the loan shares, repayments, and revenue distribution; in case of default, debt enforcement still goes back to offline contracts, equipment control, and the court system.
After the borrower deploys the GPU, downstream customers continue to pay for the computing power, and this cash flow supports the repayment of the loan. As long as the subscription contract continues to be fulfilled, the loan has a clear source of repayment.

However, GPU credit is also one of the easiest directions to be absorbed by traditional capital. As future Senior loans have standard terms, interest rates, LTV, and legal recourse, the capital cost for banks, insurance funds, and private credit funds will be much lower than that of on-chain funds. Large, investment-grade, well-structured loans will ultimately most likely enter traditional bank syndicates, ABS, or private credit funds.
The positions that can be held on-chain for the long term are mainly in the part of TradFi that has high service costs, such as: initiating loans for small and medium-sized operators, cross-border stablecoin funding, loan share distribution, real-time device and utilization monitoring, and taking on the initial loss of the junior or mezzanine layer. A possible future structure is that on-chain protocols are responsible for discovering borrowers, monitoring assets, and organizing the initial capital; once the loan performs well, the Senior portion is sold to traditional funds, while the on-chain platform continues to hold service fees, subordinate risks, and data relationships.
Prepaid Service Rights
Prepaid Service Rights address the issuer's current funding needs. The platform sells future API capacity in advance, receives cash upfront, and then continues to perform in the future. As the term lengthens, the platform's risk assumed by the buyer becomes more apparent. Will the model still be competitive in a few years? How low will the service price drop? Can the purchasing power of credits be maintained? All of these factors will affect today's valuation.
Therefore, these types of products are more likely to gradually move towards standardized capacity contracts. The terms will be shorter, the service standards will be clearer, and the model can also be replaced according to agreed rules. The clearer the contract, the easier it is for prepaid service rights to form a relatively independent market price.
Furthermore, there is also a reverse selection issue. Platforms that have the best models, the strongest customer demand, and the most stable pricing power usually lack the motivation to issue long-term, transferable inference rights. They prefer to retain the ability to price differently for customers, earn revenue from unused credits, and adjust prices at any time. Those that often need to sell long-term service rights in advance are platforms that need financing and user acquisition but whose future competitiveness has not yet been proven.
Capacity Incentives
Capacity Incentives address the early supply organization issue in the inference network. Nodes need to pre-configure GPUs and models, and also bear maintenance costs. When the demand side has not yet stabilized, nodes lack sufficient incentive to come online early; network token issuance can provide the supply side with a period of income guarantee, allowing the network to first obtain available capacity.
Whether the long-term viability can be achieved depends on whether external customer payments can gradually cover node revenue. The protocol can verify that a reasoning task has been executed once and can also verify that a node has used a specified model, but the computation itself does not generate economic value. Token issuance can purchase a period of supply, but customer demand still needs real orders to prove it.
A more reasonable incentive mechanism may gradually link with actual revenue. Customers first pay for tasks with stablecoins, nodes complete the reasoning, receive income after validation, and the protocol then provides additional rewards based on external revenue, gradually reducing subsidies as the network matures. This approach allows issuance to bear the bootstrapping cost while providing the market with a clearer signal: how much of the node's revenue comes from customers and how much still comes from capital subsidies. In the long term, what capacity incentives truly need to achieve is the transition from using tokens to purchase supply to sustaining supply through customer revenue. After this transition occurs, the network truly begins to have an economic foundation independent of the token market cycle.
Single-Model Revenue Right
The model revenue right is most similar to the crack spread mentioned earlier:
Model deployment residual profit = API revenue - GPU cost - network, storage, and engineering costs - customer acquisition and subsidies
For many Model Tokens, the main benefit to holders is buyback and staking incentives, not necessarily a legally enforceable revenue right. Without a clear contractual relationship between API revenue and Token value, it is difficult to establish a stable valuation anchor.
Model lifespan further exacerbates this issue. Models are updated rapidly, and by the time an asset completes financing and deployment, the underlying model may have been surpassed by a new alternative. As a result, a single model is hardly able to support a long-term financial asset.
A more likely development direction is to gradually expand the underlying unit to a workload strategy. For example, a coding inference strategy can continuously switch underlying models, adjusting routing based on quality and cost. In this way, holders undertake a set of ongoing inference strategies, and the asset's lifespan follows customer demand and workload.
Furthermore, if such products are to enter the institutional market in the future, there needs to be a clear legal entity, audited API revenue, and a clear cash flow waterfall. Without these foundations, the valuation of Model Tokens will still heavily depend on future usage and the issuer's buyback policy.
4.5.3 Router Provides Demand-Side Risk Management before Token Futures
Router is an underestimated layer in DeFi.
Businesses ultimately care about how much a task will cost. The specific model used is often just an implementation detail in many scenarios. A Router can continuously compare different models and providers, reallocating traffic when prices change. The underlying services were initially highly heterogeneous, but after Router scheduling, fungibility will gradually increase.
This will directly impact the scale of demand-side derivatives. Many cost fluctuations can first be absorbed through model switching and software optimization. The remaining exposures that cannot be addressed in these ways are the ones that require financial tools to intervene.
Router also has a crucial data advantage: it can see real invoices. Public API prices are often a poor representation of a business's actual procurement costs. Router can see how much a customer actually paid and what level of service quality that price corresponds to. Over time, this data has the opportunity to form a workload cost index adjusted for quality.
Furthermore, Router can provide businesses with a cost ceiling directly. For example, a company can lock in a budget for coding workload for the next three months in advance. In the background, Router manages model selection and capacity procurement, only resorting to GPU derivatives when necessary to handle remaining risks. Customers ultimately gain budget certainty without having to manage model baskets, futures positions, and basis risk themselves. This type of product may be more aligned with corporate procurement habits than a generic token futures contract. Router can keep the underlying complexity internal and offer customers a more stable and predictable price.
While Tokens themselves have not yet established a unified standard, Router can continue to seek alternative supply around a specific workload. As transactions accumulate to a certain scale, the workload itself may become a new unit of pricing.

If this pathway proves successful, Router will gradually extend from a traffic allocation tool to procurement and risk management. Its most valuable long-term assets will become increasingly evident: real orders, actual transaction prices, and the ability to manage costs and quality across different models. The price standard for workloads is likely to first take shape at this layer before entering the index and derivatives markets.
4.5.4 The Crypto Window Before Standardization
When a right does not yet have a unified specification, traditional financial processing costs can be high. The contract amounts are relatively small, and structures are fragmented, but on-chain experimentation with new forms of ownership can occur more rapidly. In the future, if Agents start directly holding and executing service contracts, the value of such infrastructure will further increase.
Once a certain type of asset class reaches maturity, large funds will gradually enter the banking and institutional markets. Senior GPU Credit has already been able to observe this trend. After the standardization of futures contracts, exchanges and institutional market makers will also enter. During this window of opportunity, on-chain protocols should accumulate real order flow (customer and transaction data), and their contract standards and performance data will gradually form barriers to entry.
Products that have already emerged today roughly correspond to different stages of risk unit standardization:

The earliest products still heavily rely on the credit of a single company. As contracts gradually allow for service substitution, the issuer's risk will decrease. It is only when the market can reliably define a basket of workloads of similar quality that the demand-side index will have a chance to form. Futures and options need to be built on top of such stable risk units.
Agents may further expand the use cases of on-chain contracts. If in the future software starts autonomously purchasing inference services, what is currently a single enterprise API contract will be broken down into a large number of machine-executed real-time procurement decisions. Service ownership, budget constraints, performance verification, and more will all become part of the design scope of financial infrastructure.
The ultimate goal of the financialization of the inference layer is to gradually transform highly customized AI services into rights that the capital markets can understand and price. The pricing power in the early market will depend on who first defines these rights.
By 2026, traditional financial institutions such as CME and ICE will intensively enter the computational power pricing and derivatives markets, and the market infrastructure has already begun to take shape. Rather than focusing on what products the exchanges announce, we are more concerned with the pace of two directional changes.
Firstly, debt is penetrating more deeply into AI infrastructure. When GPUs and data centers rely more on external financing, rental fluctuations will directly impact DSCR, LTV, and refinancing conditions. Lenders also have a stronger incentive to incorporate price risk into covenants, requiring operators to lock in a portion of future cash flows in advance. CoreWeave's financing path has already shown how contract coverage affects credit pricing; if similar financing structures continue to spread, private credit and banks are likely to become significant drivers of computational hedging.
Secondly, an increasing amount of computational demand is starting to appear in the public procurement market. Open-source models have lowered the barrier for companies to deploy their own models, and third-party clouds, Neocloud, and inference platforms are taking on increasing workloads. The more marginal demand the public market bears, the easier it is for GPU rental rates to establish continuous price discovery, exposing more enterprises directly to rental price fluctuations.
The market is still early. GPU iterations are fast, with high regional, network, cluster, and contract term non-standardization. Early trades are likely to remain concentrated in OTC, where Dealers first take on client demand and basis. A key adoption signal to watch for is whether industrial clients have started hedging continuously and repeatedly.

Industrial clients' risks usually have a defined term. Half-year training projects, one-year capacity contracts, multi-year GPU loans all require a price for the corresponding term. Fixed maturity futures are closer to enterprise risk management in this regard and are also easier to connect to physical contracts with specific models, regions, and SLAs through EFP.
Therefore, perpetual futures are more suitable for near-term price discovery and trading liquidity, while fixed maturity futures are better suited for enterprise hedging, term pricing, and physical settlement.
In the short term, we believe that Brokers/Dealers who control physical order flow and midstream platforms that manage algorithmic order flow and scheduling will more quickly capture business value. The current market still frequently pays a high premium for "whether there is mining capacity," and the value brought by grabbing a card is still far higher than optimizing the hedging cost by a few tens of basis points. Whoever knows where there is available capacity, who is grabbing capacity, and is willing to take orders on their balance sheet has the opportunity to earn matchmaking fees, bid-ask spread, and basis premium simultaneously.
As the market trades gradually standardize, the value of price indices will increase. Once a benchmark is widely referenced in numerous contracts, both switching costs and network effects will rapidly rise.
Further down the line, once standard contracts and industrial hedging reach a sufficiently large scale, exchanges will fully benefit from the scale effects of clearing, margin, and liquidity networks.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia