Paper deep dive
TokenBank: Financial Infrastructure for AI Services
Cary Chang, Jialin Zhou
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 10/9/2026, 8:41:28 AM
Summary
The paper introduces TokenBank, a financial infrastructure for AI services that addresses cost uncertainty, financing needs, and service failure risks through structured contracts. It supports service-consumption rights, cash-settled forward contracts for hedging API price volatility, revenue-right financing for capital acquisition, and protection claims for service failures. Evaluation via API request replay and agent execution demonstrates that forwards can reduce mean expenditure but increase variance, while financing effectiveness depends on capital conditions and revenue sharing.
Entities (9)
Relation Signals (8)
Nexilume Research → developed → TokenBank
confidence 95% · Nexilume ResearchNX-2026-002 v1 TokenBank: Financial Infrastructure for AI Services
TokenBank → supports → Revenue-Right Financing
confidence 95% · TokenBank supports revenue-right contracts, through which an Agent or Provider can promise a defined share of future revenue in exchange for capital today.
TokenBank → supports → Service-Failure Protection
confidence 95% · TokenBank provides SLA-like protection contracts. These contracts specify which service failures are eligible for compensation
TokenBank → supports → API-Price Forwards
confidence 95% · TokenBank supports cash-settled forward contracts. An operator can choose how much future API expenditure to cover
API-Price Forwards → increases → standard deviation of expenditure
confidence 90% · forwards reduce mean expenditure by USD 304.88 but increase its standard deviation from USD 1,152.45 to USD 1,190.82.
FrugalGPT → optimizes → Inference Cost
confidence 90% · Systems such as FrugalGPT and RouteLLM show that better model selection and request execution can substantially reduce inference cost
RouteLLM → optimizes → Inference Cost
confidence 90% · Systems such as FrugalGPT and RouteLLM show that better model selection and request execution can substantially reduce inference cost
API-Price Forwards → →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:AI services incur inference costs during execution, while revenue may arrive later. Changing API prices, limited upfront capital, and service failures can limit operators' ability to sustain or expand their services. Beyond reducing per-request costs, operators need to plan future spending, fund execution before revenue arrives, and obtain compensation for specified losses. This requires clear agreements across services with different pricing and execution conditions. These agreements must distinguish rights to consume services from rights to receive payments, define obligations under uncertain costs and income, and specify which failures qualify for compensation and how much can be paid. We present TokenBank, a financial infrastructure that represents these commitments through structured contracts. It supports service-consumption rights, agreements that settle API-price differences in cash (forwards), financing through limited rights to future service revenue, and protection claims for specified service failures. Contracts specify participants, covered services, validity, ownership, fulfillment conditions, and settlement rules. Evaluation combines replay of 899,441 API requests, real model-driven agent execution, and contract API tests. In a zero-discount rising-price resampling scenario, forwards reduce mean expenditure by USD 304.88 but increase its standard deviation from USD 1,152.45 to USD 1,190.82. A controlled replication with five portfolios per capital condition finds mean contribution differences between financing and self-funding of +1.0635, -0.1406, and -0.2962 experimental USD under low, baseline, and ample capital, respectively. The evaluation distinguishes contract correctness from economic effectiveness under declared economic and failure assumptions; supplier invoices and commercial revenue are unavailable.
Tags
Links
- Source: https://arxiv.org/abs/2610.11333v1
- Canonical: https://arxiv.org/abs/2610.11333v1
Trouble viewing inline? Open PDF directly →
Full Text
211,257 characters extracted from source content.
Expand or collapse full text
Nexilume/ Technical ReportNX-2026-002 v1 TokenBank: Financial Infrastructure for AI Services Nexilume Research September 2026 Abstract AI services incur inference costs during execution, while the revenue needed to cover those costs may arrive later. Changing API prices, limited upfront capital, and service failures can therefore constrain an operator’s ability to sustain or expand a service. Reducing per-request costs addresses only part of this problem: operators also need to plan future spending, fund execution before revenue arrives, and obtain compensation for specified losses. Supporting these needs requires clear agreements across services with different pricing and execution conditions. These agreements must distinguish the right to consume a service from the right to receive payments, define obligations despite uncertain costs and income, and specify which failures qualify for compensation and how much can be paid. We present TokenBank, a financial infrastructure that represents these commitments through structured contracts. It supports service-consumption rights, agreements that settle API-price differences in cash (forwards), financing through limited rights to future service revenue, and protection claims for specified service failures. Each contract records its participants, covered services, validity period, ownership, fulfillment conditions, and settlement rules. We evaluate TokenBank through replay of 899,441 API requests, real model-driven agent execution, and contract API tests. In a zero-discount rising-price resampling scenario, forwards reduce mean expenditure by USD 304.88, while its standard deviation increases from USD 1,152.45 to USD 1,190.82. A controlled replication with five portfolios per capital condition finds mean contribution differences between financing and self-funding of +1.0635, -0.1406, and -0.2962 experimental USD under low, baseline, and ample capital, respectively. The evaluation distinguishes contract correctness from economic effectiveness under declared economic and failure assumptions; supplier invoices and commercial revenue are unavailable. ab a https://github.com/Nexilume-AI/nexus-cloud b https://cloud.nexilume.com * Correspondence: research@nexilume.comClassification: Research Manuscript 1 Introduction Large language models are increasingly delivered through APIs and embedded in Agents, applications, and automated workflows. These systems may call multiple Providers, switch among models, and accumulate substantial inference costs over long-running tasks. As their use expands, model inference is becoming an arXiv:2610.11333v1 [cs.AI] 8 Oct 2026 Nexilume ResearchNX-2026-002 economic resource as well as a computational one: Agent operators purchase API capacity, Providers monetize model access, and applications turn model calls into downstream revenue. Managing the associated cost, financing, revenue, and service risk is therefore becoming increasingly important. Most existing AI infrastructure, however, focuses on making model execution cheaper and more reliable. Caching and batching reduce repeated computation, model routers select lower-cost models, and retries or failover recover failed requests. Systems such as FrugalGPT and RouteLLM show that better model selection and request execution can substantially reduce inference cost [6,11]. Yet these techniques mainly optimize how requests are executed. They do not specify how heterogeneous AI services should be contracted, how future API spending can be hedged, how future Agent or Provider revenue can finance current usage, or how losses from unrecovered service failures should be shared. These questions become increasingly important as Agents move from short-lived demonstrations to continu- ously running services. First, AI services are not interchangeable. Different providers offer different models, capabilities, prices, latency, reliability, and usage conditions. Therefore, a contract for “AI service” must specify what service is promised, by whom, for what period, and under what conditions it is considered delivered. Second, future API cost is uncertain. An Agent may know that it will need a large amount of inference next month, but it does not know what that inference will ultimately cost. Third, payment and revenue often occur at different times. An Agent may need to pay API bills before receiving money from its own users. If part of its future revenue could be contractually promised to a financier, that future income could potentially support today’s API expenditure. Finally, API failures can still create monetary losses after retries and failover have been attempted. A failed request may lead to a refund, a lost customer transaction, or other business loss. Technical recovery determines whether the request can still be completed; a separate mechanism is needed to determine who pays for the loss when it cannot. Financial mechanisms for computing services already have substantial precedents. Service agreements describe what providers promise, cloud forward contracts manage future price risk, revenue-based financing exchanges current funding for future payments, and outage protection compensates eligible failures [2,7–9]. These mechanisms provide a starting point for AI-service markets. Our question is how to specify their different obligations and connect their payments to the services, prices, revenue, and failures they concern. This connection matters because the same operating workload affects several contracts: changing models changes API expenditure, available funding affects how much demand can be served, and recovery changes the losses remaining after a failure. Applying these mechanisms to AI services raises four design challenges. Figure 1 summarizes how the four challenges extend beyond request execution. First, contracts must distinguish what is being promised and what evidence determines payment. Access to a model, a payment based on a price difference, a share of revenue, and compensation for failure are different rights, even when they concern the same service. Second, price contracts must account for differences between planned and actual API spending. Changes in model selection or request volume can leave a contract poorly matched to the eventual bill. Third, revenue financing must connect additional funding to both recorded receipts and the income retained by each participant. Serving more requests is beneficial only when the additional earnings outweigh the associated costs and revenue sharing. Fourth, protection must distinguish service recovery from compensation. A contract must specify which remaining failures qualify, how much is payable, and which funds are available to cover the payment. We present TokenBank, a financial market infrastructure for AI services that addresses these four problems. First, to describe precisely what is being bought or sold, TokenBank defines typed service commitments. Each commitment records the service being promised, the parties involved, the period in which it is valid, the conditions for successful delivery, and how payment is determined. Depending on the product, such commitments can be created through direct agreements, requests for quotation, public listings, or order matching. Second, to reduce uncertainty in future API spending, TokenBank supports cash-settled forward contracts. An operator can choose how much future API expenditure to cover, agree on a reference price in advance, pay the associated fee, and settle the price difference in cash when the contract expires. Third, to connect future revenue with current financing, TokenBank supports revenue-right contracts, through which an Agent or Provider can promise a defined share of future revenue in exchange for capital today. These contracts grant rights only to the specified revenue and do not represent ownership of the underlying company, model, or service. Fourth, to cover losses that remain after technical recovery, TokenBank provides SLA-like protection contracts. These contracts specify which service failures are eligible for compensation, how much loss is covered, how much the buyer pays for protection, and how reserves are used to make payments. Across these products, TokenBank records ownership, contract status, service and revenue events, and the resulting transfers of money, providing a common basis for issuing, transferring, and settling AI-service contracts. Research Manuscript2 Nexilume ResearchNX-2026-002 1 AI-service operation User Requests Agent / Application Execution Layer (Cache / Routing) ... Multiple Providers / Models $ API Bills Service Revenue Service Failures AI services generate cost, revenue, and failure risk. 2 What existing baselines optimize Caching / Batching reduce repeated computation Routing select lower-cost models Retry / Failover recover failed requests Execution-centered optimization improves how requests are executed e.g., FrugalGPT, RouteLLM 3 What remains unresolved and how TokenBank addresses it TokenBank Service specification What service is promised and what counts as delivery? Typed commitments Future API expenditure How can future API spending be hedged? Cash-settled forwards Revenue timing mismatch Can future revenue support current usage? Revenue-right financing Residual failure loss Who pays when recovery still fails? Service-failure protection TokenBank complements execution optimization by addressing contracting, expenditure hedging, revenue financing, and failure-loss allocation. Figure 1. Caching, batching, model routing, and failover improve request execution. TokenBank complements these approaches with service commitments that specify what is purchased, API-price forwards, revenue-right financing, and protection against covered service failures. These mechanisms address the financial consequences of AI-service use rather than replacing execution optimization. We evaluate TokenBank through request-level API replay, real Qwen-driven Agent execution, and actual contract APIs. The separate real-model groups comprise a ten-trial retail baseline, 70 retail intervention cases, 84 initial controlled cases, 624 controlled repetition and boundary cases, and a prospectively fixed 540-case financing-capital replication. Their workloads and denominators remain distinct. For service commitments, we verify ownership, fulfillment and settlement, including an observed rounding-carry defect and its subsequent correction. For forwards, paired price and demand scenarios identify favorable and unfavorable expenditure and risk outcomes; settlement is real, but future indices remain assumed. For revenue-right financing, repeated portfolios and freshly executed capital, receipt and payment-delay boundaries show that additional capital can enable service, while revenue sharing can outweigh that growth. For service protection, local recovery changes completed service; protection redistributes eligible remaining loss subject to premiums, coverage and funded reserves. The shared upstream limits the recovery claim, and commercial prices, customer receipts and credit redemption remain explicit assumptions. The unified evaluation therefore reports both useful operating conditions and adverse outcomes. This paper makes the following contributions: •Contractible AI-service claims. We introduce a typed representation that makes heterogeneous AI services explicit economic claims with defined participants, service attributes, validity periods, fulfillment conditions, and settlement rules. The representation distinguishes rights to consume AI services from forward contracts, revenue rights, and service-protection claims, providing a common contractual foundation for their issuance, transfer, and settlement. • Hedging future API expenditure. We design and implement cash-settled forward contracts that allow Agent operators to hedge a specified portion of future API-price exposure. Our request-level replay evaluates how hedge ratio, price movements, contract fees, and basis mismatch affect realized expenditure, showing when forward contracts reduce cost and when the hedge becomes unfavorable. •Revenue-right financing for AI services. We design contractual revenue rights that allow Agents and Providers to exchange a bounded share of future revenue for current capital, without representing these rights Research Manuscript3 Nexilume ResearchNX-2026-002 as ownership of the underlying model, service, or company. Our economic replay evaluates how additional capital, served demand, and revenue sharing jointly affect participant contribution profit, identifying when financing-enabled growth is sufficient to offset the reduction in retained revenue. •Financial protection against service failures. We design SLA-like protection contracts that compensate eligible losses remaining after technical recovery, using explicit failure conditions, coverage limits, premiums, and dedicated reserves. By evaluating failover and financial protection separately, we show that failover improves request recovery, whereas protection determines how the remaining economic loss is distributed among participants. 2 Related Work Reducing the cost of executing a task and deciding how its payments and losses are shared are related but distinct problems. FrugalGPT and RouteLLM address the former by selecting sequences of models or routing requests between stronger and cheaper models [6,11]. Their savings come from changing which model calls are made. Financial contracts can instead change an operator’s payments even when those calls remain unchanged. This distinction connects TokenBank to research on service agreements, cloud procurement, revenue financing, and outage compensation. 2.1 Service Agreements and Agent Markets A service market must distinguish choosing a provider from specifying what that provider promises. WS- Agreement already provides a common structure for service terms and guarantees, but deliberately leaves application-specific measurements to the systems using it [2]. A common contract format can therefore describe a quality requirement without establishing how that quality will be verified. Agent Exchange studies the complementary allocation problem: using capability descriptions and bids to select agents and distribute task rewards [15]. Descriptions useful for selecting an agent, however, are not by themselves evidence that a promised result was delivered. For example, the number of tokens generated can establish billed usage without establishing the correctness of an answer. Connecting payment to delivery is also an explicit research problem. The Agentic Settlement Protocol proposes holding a buyer’s funds until delivery is confirmed, with defined rules for releasing payments and handling refunds [10]. TokenBank addresses a different contract-design question: the same AI service can support several agreements that require different evidence. Access to a model is checked against service terms; a payment based on a future price depends on a price observation; revenue sharing depends on recorded receipts; and compensation depends on an eligible failure. Its proposed contract representation distinguishes these obligations and their payment rules, rather than treating every transaction as the purchase of interchangeable tokens or requiring a single matching mechanism. 2.2 Cloud Procurement and Future API Spending Cloud-finance research shows that lower purchasing costs and protection against price changes need not come from the same mechanism. In the brokerage model of Rogers and Cliff, an intermediary purchases discounted long-term reservations and resells shorter contracts [13]. The potential gain comes from the gap between purchasing and resale terms, but the broker must still pay for reservations that customers do not use. Cartlidge and Clamp show how correcting reservation accounting and incorporating competing purchasing options removes the modeled commercial opportunity under the conditions they study [5]. Dynamic forward pricing addresses a different question: what future prices a provider and customer will accept given uncertain demand and their willingness to bear risk [8]. These studies distinguish the source of a discount from the value of sharing risk. For AI APIs, a further issue is whether a contract follows the costs an operator actually incurs: changing models or serving fewer requests can leave the contracted price or quantity poorly matched to the eventual bill. TokenBank uses cash-settled forwards: the parties settle the difference between an agreed contract price and a specified API reference price observed later, multiplied by the covered amount. These contracts transfer money rather than deliver reserved inference capacity. Its replay evaluates specified contract terms; it does not infer the prices that independent buyers and sellers would agree on. Accordingly, savings must be compared under consistent execution and purchasing conditions, with fees and payments by the other party included. A lower buyer bill alone does not establish that a market has created additional value. Research Manuscript4 Nexilume ResearchNX-2026-002 2.3 Revenue Sharing and Financing Earning revenue, dividing it, and using it to fund current work are different operations. Poe’s monetization API connects charges to service delivery by authorizing costs before processing and collecting payment afterward [12]. Revenue-sharing research asks how dividing those receipts changes business decisions. Cachon and Lariviere show that, under specified conditions, sharing can lead a retailer to choose prices and purchase quantities that maximize combined supplier–retailer profit. This result can fail when sales depend on costly effort by the retailer [4]. Thus, a percentage split is not merely an accounting rule: it changes how much each participant earns from additional business and can change their incentive to generate it. Financing adds a separate requirement: future revenue must be sufficiently observable to support repayment. Clarke et al. study financing repaid from a share of subsequent platform sales and find that firms can divert transactions to other payment channels to delay repayment [7]. This evidence distinguishes accurate distribution of recorded receipts from complete observation of the revenue covered by a contract. TokenBank applies defined revenue shares to Agent and Provider receipts and examines whether additional funding permits enough otherwise-unserved demand to offset the income shared with financiers. Its analysis also distinguishes customer sales from API payments passed from an Agent to a Provider, avoiding counting an internal payment as a second external sale. These mechanisms support explicit revenue contracts, while verifying revenue outside the platform and establishing that financing causes demand growth remain separate questions. 2.4 Service Failures and Financial Protection An outage, a breached service promise, and a customer’s monetary loss are not the same quantity. Amazon Bedrock’s service-level agreement ties eligibility to specified availability conditions and supporting request logs, while calculating credits from service charges rather than the customer’s downstream business losses [1]. Consequently, a credit can follow the provider’s contract correctly without covering every loss caused by a failed application transaction. Cloud-insurance research examines the other side of this promise: Mastroeni et al. relate outage models and compensation rules to the price of insurance and the amount of compensation a provider can sustainably offer [9]. Broader compensation therefore raises a funding question, not just a question of detecting failures. This distinction matters when protection is combined with retries and failover. Recovery changes which requests still fail; protection changes how the remaining losses are divided. If several services fail together, compensation obligations can also accumulate together, so successful recovery in ordinary cases does not establish that sufficient funds will be available during a larger incident. TokenBank compares the same recovery settings with and without financial protection, reporting both the buyer’s remaining loss and the balance of funds set aside for compensation. Its implementation issues billing credits, whose value depends on subsequent service use. This keeps request recovery, contractual compensation, and the ability to fund that compensation distinct, rather than treating a payment to the user as an improvement in availability. Across these areas, the contracts depend on the same operating workload. Changing models alters the bill a forward is intended to cover; admitting more work changes the revenue to be shared; and recovery changes the losses left for compensation. These dependencies motivate TokenBank’s common contract and accounting design: payments must be traced across products and participants, rather than interpreting each module’s buyer-side saving in isolation. 3 Overview An Agent operator may purchase API services before receiving customer payments, face changing API prices, and incur losses during service interruptions. These activities motivate the four challenges discussed above: specifying what is purchased, managing future prices, financing current usage, and compensating covered failures. TokenBank implements four corresponding components. Each product defines when money should move and who should receive it. Figure 2 presents the participants, contract types, and shared financial infrastructure of TokenBank. Contractual representation. The first component distinguishes the rights obtained through different trans- actions. A prepaid balance can be spent on API calls, whereas a revenue right pays its holder a share of recorded service revenue. Buying the latter does not itself provide API access. Similarly, a forward promises a price-dependent payment rather than future service delivery, while protection provides compensation only under specified conditions. Research Manuscript5 Nexilume ResearchNX-2026-002 1 Participants and Service Flow End Users (Customers) Agent / Application (Operator) Providers (Models / Services) Requests Results API Calls Responses $ API Payments Customer Revenue Service Failures External Markets Investors Liquidity Providers Other Participants 2 TokenBank Products (Contract Types) Service Commitments Use AI services PurchaseDeliveryConsumption API-Price Forwards Hedge future API expenditure AgreeSettleCash Payment Revenue-Right Financing Raise capital with future revenue InvestService RevenueDistribute Secondary Transfer (where supported) SellBuy Service-Failure Protection Cover losses after recovery IncidentClaimCompensation 3 Platform Architecture Users & Applications External Providers TokenBank Platform Contract ManagementOrder MatchingAccounts & WalletsPayment & SettlementRisk & Margin ControlRecords & Reporting Financial Infrastructure Data & Monitoring 4 Contract and Transaction Lifecycle 1. Create / Issue Define terms and participants 2. Fund / Acquire Pay, invest, or purchase rights 3. Use / Generate Events Service usage, price, revenue, or incidents 4. Settle / Allocate Compute obligations and transfer payments 5. Transfer (optional) Trade supported rights and update holdings Figure 2. Overview of TokenBank. Service commitments, API-price forwards, revenue-right financing and transfer, and service-failure protection use product-specific workflows supported by shared accounts, contract records, and settlement functions. Usage, price, revenue, and incident records provide the corresponding evidence for fulfillment and payment. Supported revenue-right transfers update the holders considered for subsequent distributions. The lifecycle summarizes available operations, not a mandatory sequence shared by all products. These differences are represented through separate, linked records. Prepaid records track purchased and remaining balances, expiration, and refund eligibility. Preorder records connect purchases to subsequent delivery. Forward contracts record pricing and payment terms; funding agreements specify capital contributions and revenue shares; and protection subscriptions identify the covered account and coverage period. For transferable rights, holding records identify their owners and distinguish available units from locked units, which are temporarily unavailable for use or transfer. Thus, each product retains the records and checks appropriate to what it promises, while account and transaction references connect it to the shared financial system. Model API-price forwards. The second component lets an operator arrange payments that offset changes in a selected API reference price. The operator first requests a quotation: a proposal specifying the fixed price and other contract terms. Confirmation of a valid, unexpired quote is followed by the required approval and activation steps. The contract identifies the two parties, the reference price to observe, the fixed price, the amount covered, the contract dates, and the fees. When payment is due, the system compares the observed reference price with the fixed price. If the observed price is higher, the seller pays the buyer the difference multiplied by the covered amount; if it is lower, the payment direction reverses. Funds held as margin—money set aside to support this obligation—are applied before checking whether the payer can cover the remaining payment. Successful settlement records the transfer and releases unused margin; insufficient funding produces a default record. The operator still purchases API services separately. The contract neither supplies tokens nor reserves capacity, so its usefulness depends on how closely its price and amount match actual API spending. Revenue-right financing. The third component allows a service publisher, meaning the operator of an Agent or Provider service, to obtain funding in exchange for a specified share of future revenue. An investment plan defines the shares assigned to the publisher, investors, and platform. Funding agreements record investor contributions, and the corresponding workflow transfers capital to the publisher’s account once funding and activation conditions are satisfied. Distribution begins when the system receives a revenue event: a record of service income to be divided. For illustration, an investor assigned 10% of a recorded $100 revenue amount receives $10. The other participants receive their configured shares, with rounding handled so that the allocations preserve the total amount. Provider distributions use the net amount supplied in the revenue record. The system also checks who is entitled to each investor share. When a funding agreement has linked revenue-right assets, their holdings determine the recipients; otherwise, the original investor remains the Research Manuscript6 Nexilume ResearchNX-2026-002 recipient. This permits the specified revenue entitlement to follow its holder without transferring ownership of the model or company. Whether financing benefits the publisher depends on whether the additional business it supports earns enough to offset the revenue shared. Service-failure protection. The fourth component determines whether a service incident qualifies for compensation and how that compensation is funded. A protection plan specifies the covered Provider or model, eligible event types, coverage periods, claim deadlines, and protection fees. It also defines the amount left to the buyer before compensation applies, the compensation rate, and the maximum payment. Monitoring records identify incidents, and gateway logs show the requests affected during each incident. The impact calculation includes failed requests and requests that used a fallback service. Recorded costs, or an amount derived from request counts when positive costs are unavailable, provide the starting amount to which the plan’s compensation rules apply. For example, a request that succeeds through a backup Provider may still contribute fallback activity to this calculation. Impact records can generate pending claims, but payment additionally requires coverage validation and approval. Approved claims are paid from the plan’s reserve, an account containing funds set aside for compensation, subject to its budget and available balance. The buyer receives service credit in its billing wallet rather than a cash withdrawal. This workflow therefore compensates covered incidents without performing retries or recovering requests itself. Its log-based impact calculation is also distinct from the experimental model of losses remaining after technical recovery. 4 Contractual Representation An AI-service transaction must specify both what a participant acquires and what establishes fulfillment. A prepaid balance and a right to future revenue may use the same accounting unit, but only the former permits eligible service consumption. TokenBank therefore distinguishes service consumption, price-dependent payments, revenue participation, and failure compensation. We call the right or payment obligation established by each product a contractual claim. The representation connects its terms, current state, and supporting records without treating the existence of a right as evidence that it has already been fulfilled. 4.1 Contract Types and Terms A claim’s type determines what can be received. A consumption claim permits use of a prepaid balance or delivery of a purchased service. A forward specifies a payment based on a reference price, the recorded price selected for the contract. A revenue right assigns part of specified service income, while a protection subscription provides compensation under defined failure conditions. These types share descriptive fields but retain different fulfillment rules. Each claim identifies the participants and their roles, the service or agreement concerned, the units of its quantities and payments, and the applicable terms. Roles are not reducible to a single owner: a service purchase identifies a buyer and seller, a forward identifies two potential payers or recipients, and revenue sharing identifies several recipients. Service references specify the Provider and model, or the Agent whose revenue is shared. A common representation identifies these services; it does not establish that different models provide equivalent results. Terms remain separate from current state. For a preorder, a purchase for later delivery, the purchased amount is a term and the delivered amount is state. The same distinction separates a promised revenue share from a recorded distribution and an approved compensation amount from its payment. Time conditions also depend on the product: prepaid balances may expire, forwards record contract dates, and protection defines coverage periods and claim deadlines. Revenue policies, the rules identifying receipts and their recipients, do not require a finite end date. Quantities retain their units, so a service quantity, a transferable right, and a monetary payment are not interchangeable merely because their numerical amounts coincide. This common description is realized through linked product-specific records, not a single contract table or a shared sequence of processing steps. Appendix A gives the complete record notation and detailed validation rules. 4.2 Evidence and Fulfillment The same observation can have different consequences for different claims. A usage record can establish consumption, whereas a revenue-sharing payment requires recorded income. Let휏identify a claim’s type,Θ 휏 Research Manuscript7 Nexilume ResearchNX-2026-002 Operation request Σ, α, e Check permission, policy, status, terms, and resources. Update state Step τ (Σ, α, e) = (Σ′, J) Create fulfillment, transfer, or payment records Transfer H s ′ = H s − q H b ′ = H b + q Reallocate existing units; retain source references and terms Check Accounting entries ∑ j∈J u credit a j − ∑ j∈J u debit a j = 0 Record debit and credit with at most one posting per operation Result Figure 3. Supported transfers change ownership while preserving source references, and financial effects are recorded through balanced accounting entries. its terms,푥 휏 its current state, and푒the supporting input or record. We summarize the product-specific rule as Φ 휏 (Θ 휏 ,푥 휏 ,푒) = 표 휏 ,(1) where표 휏 is the resulting allocation or payment obligation. This notation describes how the product routines interpret evidence; it is not a generic executable rule stored in every contract. Consumption. Prepaid use requires sufficient valid balance after excluding amounts locked against other use. A prepaid lot records a credited amount with its validity conditions; consumption draws from eligible lots and reduces their remaining balances. For a preorder, delivery records increase the fulfilled quantity without exceeding the purchased amount. These checks establish recorded consumption or delivery, not the semantic correctness of a model’s output. Price-dependent payment. A forward combines its agreed price and contractual amount with the selected reference-price observation to determine which participant owes payment and how much. This calculation establishes an obligation rather than delivering API capacity. Payment is completed separately, subject to sufficient funding. Revenue participation. A revenue event records service income submitted for distribution. The applicable policy assigns each recipient a share of the event’s recorded net amount. For example, a 10% share of a 100-unit distribution base gives an exact entitlement of 10 units. Actual allocations use the supported decimal precision and retain rounding differences for subsequent processing. The right concerns the specified receipts, not ownership of the Agent, model, or company. Failure compensation. An incident records a service disruption, and a compensation claim requests payment under a protection subscription. Coverage checks relate the incident to the protected service, coverage period, eligible event type, and submission deadline. The plan determines compensation, review authorizes an amount, and settlement checks the reserve, the account and budget set aside to fund approved claims. The resulting service credit can pay service charges rather than provide a cash withdrawal. Coverage, approval, and payment thus establish different stages of the obligation. 4.3 State Changes and Transfer An operation changes a claim only when its applicable conditions hold. For requested operation훼, supporting input 푒, and relevant system state Σ, write Step 휏 (Σ,훼,푒) = (Σ ′ ,J),(2) whereΣ ′ is the updated state andJcontains the records of fulfillment, transfer, or payment. The applicable checks concern permission, product policy, current status, contract terms, and available resources. Their role is to distinguish a valid obligation from an operation that can presently execute: a positive forward amount does not establish that its payer has sufficient funds, just as compensation approval does not establish that payment has occurred. Transfer changes a holder rather than fulfilling the underlying service or revenue obligation. It is supported for specified objects, including prepaid balances and Agent or Provider market assets, which record units of transferable rights. For a valid purchase of푞existing units, with sufficient seller units reserved, total seller and buyer holdings satisfy 퐻 ′ 푠 = 퐻 푠 − 푞, 퐻 ′ 푏 = 퐻 푏 + 푞,(3) where primes denote holdings after transfer. Thus,퐻 ′ 푠 +퐻 ′ 푏 = 퐻 푠 +퐻 푏 : transfer reallocates existing units rather than creating new ones. Settlement connects this change to the buyer-to-seller payment. Research Manuscript8 Nexilume ResearchNX-2026-002 Source references preserve the connection between the transferred right and its original terms. A receiving prepaid lot retains its source expiry and refund eligibility; transfer does not restart its validity. A derived revenue-right holding retains references to its funding agreement and revenue policy. Before distribution, holder resolution, the routine identifying recipients from these linked assets, updates the investor participants from the selected current holdings. If no matching asset exists, it uses the original investor. Recipient selection therefore follows the holdings used at settlement, not necessarily ownership when an earlier revenue event occurred. Historical allocation requires separate rules rather than merely recorded transfer timestamps. 4.4 Accounting Consistency Product rules determine why a financial change is required; accounting records establish the resulting debit and credit. For an ordinary transfer in unit푢, letJ credit 푢 andJ debit 푢 be its credit and debit entries, and푎 푗 the amount of entry 푗. Balanced posting requires ∑︁ 푗∈J credit 푢 푎 푗 − ∑︁ 푗∈J debit 푢 푎 푗 = 0.(4) Transfers spanning organizations may require checking several linked records together. This relation concerns accounting entries, not raw balance changes that may also include credit use or repayment. The workflow is shown in Figure 3. Product-level checks complement this accounting relation by bounding consumption by available balances, deliveries by purchased quantities, and compensation by available reserve funding. Recorded revenue must also be conserved across recipient allocations. Transaction controls coordinate concurrent updates and associate repeated requests with an existing operation, with the intended effect of at most one committed posting for the same operation identifier within its scope. The representation therefore connects three questions: what is promised, which evidence determines the obligation, and which records establish its fulfillment or payment. The following product sections develop the forward, financing, and protection mechanisms on this basis, keeping contractual rights, ownership changes, and completed financial transfers distinct. 5 Model API-Price Forwards Future API expenditure varies with prices, request volume, and model selection, even under a fixed execution policy. TokenBank addresses its price-related component through cash-settled forwards: contracts that exchange a payment based on an agreed price and a later reference price, rather than deliver inference capacity. Separating this payment from API procurement allows us to analyze its effect on expenditure without changing the requests executed. 5.1 Contract Formation A contract specifies two participants, a reference-price index identifying the service price to observe, a fixed price, a contractual amount, and fee, funding, and time conditions. The long participant receives payment when the reference price exceeds the fixed price; the short participant receives payment when it falls below that price. The parties establish these terms through a request for quotation, in which one participant requests terms and another supplies an offer. Acceptance must precede the quote-validity deadline, which is distinct from the contract’s recorded expiry. Activation then requires both parties to fund their service fees and margin, money reserved to support payment. The contractual amount must be interpreted with the quotation units. For example, a price per thousand tokens requires a quantity in thousands of tokens. To express the payment in expenditure units, let푃 abs and 퐾 abs be the observed and fixed prices in the original units,푞the corresponding service quantity, and푃 0 > 0a baseline price. Define 푃 = 푃 abs 푃 0 , 퐾 = 퐾 abs 푃 0 , 푁 = 푞푃 0 .(5) Then푞(푃 abs − 퐾 abs ) = 푁(푃− 퐾). Throughout the analysis,푃and퐾are dimensionless, and the notional푁, the amount scaling the price difference, represents baseline-price expenditure. This normalization relates the analytical notation to the contract’s quotation units; product inputs and charges must follow the corresponding unit convention. Research Manuscript9 Nexilume ResearchNX-2026-002 1 Contract formation A quotation and approval process establishes the terms, followed by funding and activation. Buyer (Long) Receive payment when price ↑ Seller (Short) Receive payment when price ↓ Request for quotation Specify index, fixed price, amount, fees and terms Quote and acceptance Offer terms Accept before quote-validity deadline Fund fees and margin Both parties fund service fees and margin Activate contract Record contract and start observation period Key contract terms Reference-price index The service price to observe Fixed price K In quotation units Contractual amount q Interpreted with quotation units (e.g. per 1K tokens) Fees and funding Service fee and margin requirement Time conditions Quote-validity deadline and contract expiry 2 Price observation and valuation Compare the observed reference price with the fixed price. Reference-price observation P t Latest recorded price at settlement time Contract value (to long) V t = N(P t − K) Short position: −V t • V t > 0 : long receives payment • V t < 0 : short receives payment • |V t | : amount due • P t and K are dimensionless • N = qP 0 is the notional in baseline-price expenditure units 3 Settlement and payment Use reserved margin and available funds to complete the payment. Release margin Payer’s reserved margin becomes available Check funding Margin + other available funds cover full amount? Yes No Execute payment • Transfer |V t | • Record transaction • Release unused margin Record default • Unmet funding obligation • No partial payment • May settle again after funding changes 4 Effect on API expenditure (long position) Unhedged expenditure C 0 = ∑ n r=1 c r p r c r : baseline cost of request r p r : realized price multiplier After settlement Hedged expenditure C H = C 0 − V + F + H V : contract payment (N(P * − K)) F : service fee H : funding cost over holding period Saving (for N > 0) C 0 − C H = N(P * − K − f − c) Expenditure falls when P * > K + f + c (full payment, proportional charges) 5 Price and quantity mismatch Decomposition of hedged expenditure C H = NK + (Q − N)P * + Qb + F + H • Q : realized bill at baseline prices • N : contract notional (= h 푄) • b : basis difference ( ത 푃− P * ) • F, H : fees and funding costs Key implications • b ≠ 0 when purchase prices differ from the reference (timing, model, input/output mix). • Q ≠ N causes quantity mismatch (over- or under-hedged). • Even with N = Q and b = 0, fees and funding costs still apply. • Favorable realized payments do not ensure lower expenditure variability. Figure 4. API-price forward mechanism in TokenBank. Participants agree on contract terms, fund fees and margin, and settle the resulting price-difference payment against a reference price. The forward is financially separate from API procurement. Its expenditure effect depends on contract charges and on how closely the contracted amount and reference price match realized API purchases. 5.2 Valuation and Settlement Figure 4 summarizes the forward workflow and its relationship to API expenditure. The contract creates a cash payment from the difference between an agreed price and a reference price, while API procurement remains unchanged. For reference-price observation 푃 푡 , the signed amount payable to the long participant is 푉 푡 = 푁(푃 푡 − 퐾),(6) and the short participant has the opposite amount. The sign determines payment direction and|푉 푡 |the amount due. This valuation identifies the contractual obligation; settlement executes its payment. The reference is the latest recorded price at the authorized settlement time, which need not coincide with the recorded expiry. At settlement, the payer’s reserved margin becomes available for payment. Since margin is already part of the account balance, releasing it does not create additional funds. Payment completes only when the released margin and other available funds cover the full obligation. Otherwise, the contract records default, an unmet funding obligation, without partial payment and may be settled again after funding changes. Successful settlement releases unused margin; a zero obligation requires no transfer. The platform coordinates payments and collects fees without assuming either participant’s payment obligation. Detailed margin and transaction controls are given in Appendix B. 5.3 Effect on API Expenditure Consider an operator holding the long position. For the same푛purchased requests and execution settings, let 푐 푟 ≥ 0 be request 푟’s baseline cost and 푝 푟 its realized price multiplier. Unhedged expenditure is 퐶 0 = 푛 ∑︁ 푟=1 푐 푟 푝 푟 .(7) Let푄 = Í 푟 푐 푟 denote the realized bill at baseline prices and b 푄its forecast before contract formation. The replay sizes the contract as 푁 = ℎ b 푄,(8) where the hedge ratioℎscales the amount covered relative to forecast expenditure. This is the replay’s sizing convention, not an implemented forecasting or contract-selection algorithm. Research Manuscript10 Nexilume ResearchNX-2026-002 For settlement reference price 푃 ∗ and full payment 푉 = 푁(푃 ∗ − 퐾), expenditure becomes 퐶 퐻 = 퐶 0 −푉 + 퐹+ 퐻,(9) where퐹is the operator’s service fee and퐻the modeled cost of funding the position over its holding period. Refundable margin is not itself an expense, although reserving funds may incur funding costs. For푁 > 0and proportional charges퐹+ 퐻 = 푁( 푓 + 푐), where푓is the fee and푐the holding-period funding charge per unit of normalized notional, the saving is 퐶 0 − 퐶 퐻 = 푁(푃 ∗ − 퐾− 푓 − 푐).(10) Thus, expenditure falls exactly when 푃 ∗ > 퐾+ 푓 + 푐.(11) This condition concerns realized savings under full payment, not a reduction in the amount of inference performed. The same comparison must account for both participants. If퐹 퐿 and퐹 푆 are their service fees, the long and short parties receive푉 − 퐹 퐿 and−푉 − 퐹 푆 , with negative values denoting outgoing payments. The platform receives퐹 퐿 +퐹 푆 ; these amounts sum to zero before separately modeled funding and operating costs. A favorable contract payment to the operator is therefore funded by its counterparty rather than newly created service revenue. 5.4 Price and Quantity Mismatch The contract’s reference price and amount need not match actual purchases. For푄 > 0, define the purchase-price average and its difference from the settlement reference as 푃 = Í 푟 푐 푟 푝 푟 푄 , 푏 =푃− 푃 ∗ .(12) The basis difference푏captures price mismatch, while푄−푁captures quantity mismatch in baseline-expenditure units. Substitution into Equation (9) yields 퐶 퐻 = 푁퐾+(푄− 푁)푃 ∗ + 푄푏+ 퐹+ 퐻.(13) The first term is the fixed-price component for the contracted amount; the next two retain the effects of unmatched quantity and purchase prices. Fees and funding costs complete the expenditure. Model selection, input/output-token mix, and purchase timing can produce푏 ≠ 0. In particular, a time-average reference gives equal weight to sampled prices, whereas requests concentrated in expensive periods yield a higher purchase-weighted price. Thus, using the same underlying price path does not ensure that the reference matches the bill. When푁 = 푄and푏 = 0, expenditure reduces to퐶 퐻 = 푄퐾+ 퐹+ 퐻. However,ℎ = 1covers the forecast b 푄 rather than the realized푄. If푁 > 푄, the position is overhedged: its contractual amount exceeds the baseline cost of actual purchases. Covering all forecast spending therefore need not fix realized expenditure. This decomposition motivates evaluating contract size and price alignment together with fees. Favorable realized payments alone do not establish lower expenditure variability. Appendix B.4 provides the corresponding variance relation and its assumptions. 6 Revenue-Right Financing An Agent or Provider operator may need funds to serve available demand before receiving customer payments. We call this operator the publisher. TokenBank connects current funding to rights over specified service revenue and supports subsequent transfers of these rights. The design separates capital contributed to the publisher, revenue earned from service delivery, and payments between holders. This distinction allows us to analyze whether funding supports enough additional business to compensate the publisher for sharing its revenue. Figure 5 shows the distinction among primary funding, subsequent revenue distribution, and secondary transfer of existing rights. These flows involve different payments and should not be treated as a single revenue transaction. Research Manuscript11 Nexilume ResearchNX-2026-002 A Contract formation and initial funding Publisher plan Revenue shares Investor accepts and commits capital Confirm funding and activate agreement Intermediate account Agent / Provider operator Publisher receives capital B Revenue allocation and settlement Plan shares: publisher + investor pool + platform = 100% Revenue event Recorded income Apply plan revenue shares Publisher share Publisher Platform share Platform Investor pool 1. Across agreements By capital contribution 大写 C 下标 j 设备控制 4 设备控制 4 设备 控制 4 퐶 푗 / total contributions 2. Across holders By units held in each agreement Current holders Receive allocated revenue Funded agreements Current holdings Example: a 10% investor pool, with contributions 100 : 300, gives total-revenue shares 2.5% : 7.5%. C Secondary-market transfer of existing rights Seller List & reserve rights Buyer Bid & reserve funds Match within listing Price ≤ buyer limit Settle trade Buyer → seller: payment Seller → buyer: revenue rights Update holdings Source agreement retained For later distributions Figure 5. Revenue-right financing and transfer in TokenBank. Primary investment supplies capital to an Agent or Provider operator in exchange for rights to specified future revenue. Recorded service revenue is later divided among the publisher, investor pool, and platform, with investor allocations determined from funding agreements and current holdings. Existing rights may subsequently be transferred: the buyer pays the selling holder, while future distributions follow the updated holdings. 6.1 Contract Formation and Funding A publisher plan identifies the financed service, accounting unit, and revenue shares assigned to the publisher, investors, and platform. Shares푏 푂 ,푏 퐼 , and푏 푃 are expressed in basis points, where one basis point is1/10,000 of the amount being divided: 푏 푂 + 푏 퐼 + 푏 푃 = 10,000.(14) The investor pool is the share푏 퐼 > 0reserved for investors collectively; individual allocations depend on their contributions and holdings, as defined below. These rights concern specified receipts, not ownership of the Agent, model, service, or company. A finite duration, cumulative payment cap, or principal-repayment schedule requires separate terms and cannot be inferred from the revenue share alone. An investor accepts a plan and commits an amount퐶 푗 under agreement푗. Confirmation checks funding and activates the agreement, then transfers capital to the publisher through an intermediate account. The disbursed amount퐶 settled 푗 records completed capital transfers; normal full disbursement establishes퐶 settled 푗 = 퐶 푗 . This capital settlement differs from revenue settlement, which distributes later recorded service income. Investment principal is therefore recorded as funding rather than operating revenue. Appendix C specifies the records and funding controls underlying this distinction. 6.2 Revenue Allocation and Settlement Allocation proceeds in two stages: dividing the investor pool among funding agreements, then dividing each agreement’s allocation among its current holders. At settlement time푡, letJ 휋 (푡)contain the active agreements linked to plan휋with positive recorded capital settlement. For a nonempty selected set, agreement푗has ideal share 푏 ∗ 푗 (푡) = 푏 퐼 퐶 푗 Í 푘∈J 휋 (푡) 퐶 푘 .(15) Weights use committed amounts퐶 푗 , which equal disbursed amounts in the normal completed funding path. The implementation approximates these allocations with integer basis points 푏 푗 (푡) while conserving 푏 퐼 . Research Manuscript12 Nexilume ResearchNX-2026-002 A revenue right can be subdivided into transferable units linked to its source agreement. LetH 푗 (푡)contain the selected holders of agreement 푗’s rights and 푢 푗,ℎ (푡) holder ℎ’s units. Its ideal share is 푏 ∗ 푗,ℎ (푡) = 푏 푗 (푡) 푢 푗,ℎ (푡) Í 푘∈H 푗 (푡) 푢 푗,푘 (푡) .(16) A second integer allocation divides푏 푗 (푡)among these holders. For illustration, a 10% investor pool shared by contributions of 100 and 300 units assigns ideal total-revenue shares of 2.5% and 7.5%. Holding half the first agreement’s units gives half its 2.5% share, not half the publisher’s revenue. New investments change the division within the pool while leaving its total share unchanged. Holder resolution, the lookup identifying these recipients, follows source-agreement references to current positive holdings, including supported transfers across tenants, the organizational scopes governing accounts and permissions. If no derived holding exists, it uses the original investor. Recipients are updated immediately before distribution, rather than reconstructed from ownership when income first occurred. A pending event can therefore use a later holding configuration. The lookup also does not determine agreement eligibility by comparing event time with agreement start and end dates. A revenue event records service income submitted for distribution, whether entered explicitly or captured from service usage. Its recorded net amount푅 푒 is the distribution base, not necessarily profit after operating costs. For active recipients푖with shares푏 푖 , including the publisher, investor holders, and platform, exact allocations are 푑 ∗ 푖,푒 = 푅 푒 푏 푖 10,000 , ∑︁ 푖 푏 푖 = 10,000.(17) Actual payments use a minimum increment of10 −6 accounting units. The allocation routine carries forward rounding differences and adjusts payments so that, for event amounts at the supported precision, 푑 푖,푒 ≥ 0, ∑︁ 푖 푑 푖,푒 = 푅 푒 .(18) Settlement links these payments to their revenue event and recipient accounts. Events awaiting an eligible funded investment can remain pending. Integer-share allocation, payment rounding, and wallet transfers are detailed in Appendix C.2. 6.3 Secondary-Market Transfer A secondary transfer sells an existing revenue right to another holder, rather than creating a new investment in the publisher. Transferable units retain their funding-agreement and revenue-policy references, connecting a change in ownership to the recipient lookup above. For publisher investments, creating these units requires confirmed investment and completed capital settlement. A holder creates a listing, an offer to sell a specified quantity at a minimum unit price푝 min ℓ . The units are reserved against other use, and the listing generates a sell order at that minimum price. A buyer submits quantity 푞 푏 and limit price 푝 푏 , the maximum price it accepts per right unit. Its initial payment reservation is 푊 푏 = 푞 푏 푝 푏 .(19) Reserving both sides’ commitments precedes matching; it does not itself transfer ownership or complete payment. Matching operates within a listing, prioritizing higher-priced buy orders and lower-priced sell orders, with creation time resolving ties. For sell limit 푝 푠 , the execution price, the price recorded for a trade, is 푝 ∗ 퐴 = 푝 푠 ,(20) 푝 ∗ 푃 = max푝 푠 , 푝 min ℓ ,(21) where퐴and푃identify the Agent and Provider paths. Each path requires푝 푏 ≥ 푝 ∗ , ensuring that the recorded price does not exceed the buyer’s limit. If푟 푏 ,푟 푠 , and푟 ℓ are the remaining buy, sell, and listing quantities, the matched quantity and payment are 푞 ∗ = min푟 푏 ,푟 푠 ,푟 ℓ ,(22) 푉 ∗ = 푞 ∗ 푝 ∗ .(23) Research Manuscript13 Nexilume ResearchNX-2026-002 Settlement connects the buyer-to-seller payment to an equal decrease and increase in their holdings, conserving existing units and retaining the source references used in subsequent distributions. For changes in buyer, seller, and publisher funds, excluding separately specified charges, Δ퐶 푏 =−푉 ∗ , Δ퐶 푠 = 푉 ∗ , Δ퐶 publisher = 0. (24) Thus, resale changes the holder and pays the seller without adding to the publisher’s funding. Supported cross-tenant transfers also enter subsequent holder resolution. Prices follow submitted orders, not a system forecast of future revenue; execution remains contingent on a compatible counterparty. Appendix C.3 specifies the reservation and ownership updates. 6.4 Financing and Publisher Profit Financing changes the resources available for service delivery, whereas resale changes who receives an existing revenue allocation. To isolate the first effect, let푋(퐵)be the invoice cost of requests admitted under daily budget 퐵. The replay admits the longest initial sequence of complete requests that fits each day’s budget and compares 푋 0 = 푋(퐵)with푋 1 = 푋(푎퐵)for푎 ≥ 1. Requests retain their original order and costs; additional funding can serve more of the same offered demand but does not create new arrivals. This retrospective calculation assumes daily budget resets and does not derive the multiplier푎from a particular investment. Appendix C.4 provides the workload definitions. For publisher표, let푅 표 (푋)be revenue from served work푋and푉 표 (푋)its variable cost, the modeled operating cost of that work. With investor fraction푠 표 and platform fraction푧 표 , define contribution profit as revenue remaining after these shares and variable costs: Π 표 (푋) = (1− 푠 표 − 푧 표 )푅 표 (푋)−푉 표 (푋).(25) Suppose variable costs consume a constant fraction휈of revenue, so푔 = 1− 휈remains before sharing. Let 푅 0 , 푅 1 be baseline and financed revenue,푧 0 , 푧 1 their platform fractions, and푠the financed investor fraction. The baseline has no investor share, givingΠ 0 = (푔− 푧 0 )푅 0 andΠ 1 = (푔− 푠− 푧 1 )푅 1 . For푅 0 > 0and푔− 푠− 푧 1 > 0, financing improves contribution profit exactly when 푅 1 푅 0 > 푔− 푧 0 푔− 푠− 푧 1 .(26) This condition identifies the additional revenue required to offset the smaller retained share. Once existing demand is fully served, a larger budget cannot provide that growth under the model. Increasing the sharing burden without additional revenue reduces contribution. Agent and Provider accounting. For admitted API invoice cost푋, suppose the Agent charges a markup푚 over its API expense and the Provider incurs variable cost푣푋. With푠 퐴 , 푠 푃 their investor fractions and푧 퐴 , 푧 푃 their platform fractions, the model gives 푅 퐴 = (1+ 푚)푋, 푅 푃 = 푋, Π 퐴 = (1− 푠 퐴 − 푧 퐴 )(1+ 푚)푋− 푋, Π 푃 = (1− 푠 푃 − 푧 푃 )푋− 푣푋.(27) Investor receipts are푌 퐼 = 푠 퐴 푅 퐴 + 푠 푃 푅 푃 , and platform receipts are푌 platform = 푧 퐴 푅 퐴 + 푧 푃 푅 푃 . The Agent’s API payment is the Provider’s revenue, an internal transfer rather than a second external customer sale. Cancelling this payment and the revenue-sharing transfers therefore yields Π 퐴 + Π 푃 +푌 퐼 +푌 platform = 푅 퐴 − 푣푋.(28) Sharing reallocates this contribution; additional aggregate contribution requires more revenue-generating work or changed operating costs. Investor receipts are not net returns without accounting for contributed capital, payment timing, and any retained rights. Evaluation examines these financing conditions separately from secondary-market prices, trading activity, and resale returns, which the financing replay does not measure. Research Manuscript14 Nexilume ResearchNX-2026-002 1 Protection plan and subscription Provider • Owns the model offer • Publishes protection plan • Contributes initial funding (F 0 ≥ M) Buyer • Accepts plan terms • Pays premium from billing wallet • Becomes a subscriber Protection plan π= (S, E, p, u, Δ, γ, δ, M, w, ω, A) • Covered services S • Covered incident types E • Premium p(currency u) • Coverage duration Δ • Compensation rate γ • Deductible δ • Per-claim limit M • Claim window w • Waiting period ω • Automatic approval limit A Subscription record (a, π, t s start , t s end ) • Buyer account a • Coverage period (end derived from Δ if omitted) • Premium payment increases reserve balance and budget Protection reserve • Provider contributions F t • Premium receipts P t • Budget K t • Balance B t • Locked funds L t • Payouts Q t Subscription capacity R t cap = max0, min(F t − Q t , K t − Q t , B t − L t ) Admit new subscription if R t cap ≥ (n t + 1)M 2 Incident detection and impact assessment Health monitoring • Periodic probes • Status, latency, errors • Thresholds for opening and resolving incidents Incident record • Provider and model • Incident type • Start and end time (open: current time) • Created when failure threshold is reached Gateway logs • API requests and outcomes • Costs and fallback usage • Filter by buyer, model, and API key (if specified) Impact record (s, e) • Failed-request count N s,e • Fallback count F s,e • Recorded cost C s,e Compensation base B s,e = C s,e , C s,e > 0 N s,e + F s,e ,C s,e ≤ 0 (No count-to-currency conversion) 3 Coverage check and compensation calculation Coverage conditions Active subscription Matching provider, model, event type Timing requirements: t s start + ω≤ t e start t e start ≤ t s end (if exists) t check ≤ t e start + w Apply plan rules • Deductible δ • Compensation rate γ • Per-claim limit M • Exclusion rules (may set amount to 0) Calculated amount Ĝ s,e = minM, γmax(B s,e − δ, 0) 4 Claim decision and settlement Claim creation • Auto-generated from impact record (s, e) • Or manual claim • One claim per (incident, subscription) Claim review Pending → Rejected Approved • Generated claims ≤ A may be auto-approved • Manual review records decision and approved amount Settlement For approved claim jwith amount G j : 0 < G j ≤ minK t − Q t , B t − L t • Debit reserve, credit buyer's wallet • Issue service credit (usable for API charges) • No partial payment; otherwise remain unpaid 5 Financial flows and accounting Reserve balance over time B T = B 0 + ∑ t P t + ∑ t F t add − ∑ j G j • P t : premium receipts • F t add : additional provider funding • G j : completed compensation payments Provider • Initial funding F 0 • Additional funding F t add Buyers Premium payments P t Protection reserve Balance B t Budget K t Locked L t Payouts Q t Compensation payments G j Buyer's wallet Service credit (usable for service charges) Economic effect J buyer = C retry + L+ P− G paid • Protection does not change recovery: Δp success | same recovery = 0 • Premiums and payouts cancel across buyer and reserve: J buyer + (G paid − P) = C retry + L Figure 6. Service-failure protection in TokenBank. A Provider-funded reserve and buyer protection fees support coverage under predefined plan terms. Monitoring and request records establish incident evidence, coverage and impact rules determine an eligible claim amount, and approved claims are paid as service credit subject to available reserve funding. Financial compensation is evaluated separately from retry and failover recovery. 7 Service-Failure Protection TokenBank addresses the fourth challenge by specifying which service failures qualify for compensation, how much is payable, and how payment is funded. A Provider publishes a protection plan, and buyers subscribe to its terms. An incident records a service disruption; an impact record summarizes affected requests; and a claim requests compensation based on that evidence. Approved payments draw on a reserve, an account and associated budget set aside for compensation. The following design connects these records from coverage to payment, then separates their financial effects from technical recovery. Figure 6 summarizes the protection workflow from contract formation and incident evidence to claim approval and reserve-funded settlement. Technical recovery and financial protection remain separate throughout the process. 7.1 Protection Contract and Reserve A plan identifies the protected service and specifies 휋 = (S,E, 푝,푢,Δ,훾,훿, 푀,푤,휔, 퐴),(29) whereSandEidentify covered services and incident types. The premium푝is the protection fee,푢the payment currency, andΔthe default coverage duration. The compensation rate훾applies after a deductible훿, the amount excluded before compensation. Each claim is capped at푀. The window푤limits claim submission time,휔 specifies the waiting period before coverage becomes effective, and 퐴 limits automatic approval. The publishing Provider must own the specified model offer, the model-specific service being protected. A subscription associates buyer account푎with plan휋and coverage times푡 start 푠 and푡 end 푠 ; an omitted end time is derived fromΔ. On application, the buyer accepts the terms and pays the fixed premium from its billing wallet, the account used for service payments. The payment increases the reserve’s balance and budget. Before publication, Provider funding퐹 0 must satisfy퐹 0 ≥ 푀. Subsequent admission also accounts for existing subscriptions and payments. At time푡, let퐹 푡 denote cumulative Provider contributions,푄 푡 cumulative compensation paid,퐾 푡 the recorded reserve budget,퐵 푡 its account balance, and퐿 푡 funds locked against other use. The amount used to determine subscription capacity is 푅 cap 푡 = max0, min(퐹 푡 − 푄 푡 , 퐾 푡 − 푄 푡 , 퐵 푡 − 퐿 푡 ). (30) Research Manuscript15 Nexilume ResearchNX-2026-002 These bounds respectively account for Provider funding after payouts, remaining budget, and currently available funds. For푀 > 0, let푛 푡 count active subscriptions that have not expired, including those without an end date. An active published plan admits another subscription only if 푅 cap 푡 ≥ (푛 푡 + 1)푀.(31) Premium receipts do not increase the Provider-contribution bound퐹 푡 − 푄 푡 . This rule allocates capacity for one maximum claim per counted subscription; because푀is a per-claim limit, it does not establish sufficient funding for every sequence of repeated incidents. 7.2 Incident Evidence and Coverage Periodic probes, test requests to the protected service, record status, latency, and errors. Configured numbers of consecutive unhealthy observations open an incident; consecutive healthy observations resolve it. An automatically created incident starts when the failure threshold is reached, not at the first failed observation. Its Provider, model, type, and time interval determine the scope of subsequent checks. Coverage requires an active subscription and matching Provider, model, and event type. For incident푒, the timing conditions are 푡 start 푠 + 휔≤ 푡 start 푒 ,(32) 푡 start 푒 ≤ 푡 end 푠 if an end time exists,(33) 푡 check ≤ 푡 start 푒 + 푤,(34) where푡 check is the time of the coverage check. The deadline is measured from incident start rather than resolution. For each eligible subscription, gateway logs—records of API requests, outcomes, and costs—identify failed requests or requests using a fallback service during the incident interval. Selection matches the buyer and Provider, with additional model and API-key restrictions where specified. An open incident uses the current time as its interval end. The impact record aggregates failed-request count푁 푠,푒 , fallback count퐹 푠,푒 , and recorded cost 퐶 푠,푒 . These define the compensation base, the input to the plan’s amount calculation: 퐵 푠,푒 = ( 퐶 푠,푒 ,퐶 푠,푒 > 0, 푁 푠,푒 + 퐹 푠,푒 , 퐶 푠,푒 ≤ 0. (35) The count-based branch specifies no count-to-currency conversion and must not be interpreted as a measured monetary loss. A request can contribute to both counts, and fallback activity can include successful recovery. Thus, this operational base differs from the assumed loss on unresolved requests used in Section 7.5. The calculated compensation is b 퐺 푠,푒 = min푀, 훾 max(퐵 푠,푒 − 훿, 0).(36) The rule applies the deductible and rate, then enforces the per-claim limit. A matching exclusion rule, a configured condition that disallows compensation, can set the amount to zero. Service-health observations support these coverage decisions but do not independently determine the buyer’s downstream business loss. 7.3 Claim Decision and Settlement A positive impact amount can generate a pending claim linked to its subscription and incident. An incident– subscription identifier allows repeated generation to retrieve the existing claim. Manual claims enter the same decision process after coverage checks: pending→ ( rejected, approved→ settled. (37) Review records the decision and approved amount. Ordinary manual claims apply the deductible, rate, and cap to the reviewed base. Generated claims already contain the calculated compensation, so review caps their amount without applying the deductible and rate again. A generated pending claim without an exclusion can be approved automatically when its requested amount is positive and no greater than 퐴 > 0. Approval authorizes an amount but does not complete payment. For approved claim푗with amount퐺 푗 , settlement requires the plan’s active reserve, compatible payment units, and 0 < 퐺 푗 ≤ min퐾 푡 − 푄 푡 , 퐵 푡 − 퐿 푡 .(38) Research Manuscript16 Nexilume ResearchNX-2026-002 Unlike subscription admission, this check tests the remaining budget and available balance for the particular payment. Insufficient funds leave the claim unpaid rather than producing a partial payment. Automatic approval may trigger settlement, but it does not bypass these checks. Successful settlement debits the reserve and credits the buyer’s active, currency-matched billing wallet. It issues service credit, usable for service charges rather than cash withdrawal. Wallet amounts must be exactly representable to two decimal places. Transactional record updates and claim-specific settlement identifiers coordinate concurrent operations and prevent supported retries from posting the payment twice. Settlement records retain links to the claim, incident, reserve, and accounting transaction. Over an interval ending at 푇, reserve accounting gives 퐵 푇 = 퐵 0 + ∑︁ 푡 푃 푡 + ∑︁ 푡 퐹 add 푡 − ∑︁ 푗 퐺 푗 ,(39) where푃 푡 denotes premium receipts,퐹 add 푡 additional Provider funding, and the final sum includes completed payments only. Opening reserves and additional contributions supply capital; they are not premium revenue. This distinction separates the ability to pay a claim from whether collected premiums cover compensation. 7.4 Separating Recovery from Protection The economic comparison holds routing and retry decisions fixed while varying financial protection. Let푝 1 be the initial failure probability. Conditional on failure,휌 ∈ [0, 1]is the assumed fraction of cases in which an alternative Provider cannot recover the request. In the remaining cases, its failure probability is푝 2 . For one alternate attempt, the expected unresolved fraction is 푝 unresolved = 푝 1 [휌+(1− 휌)푝 2 ].(40) The recovered fraction, measured relative to all initial requests, is푝 1 (1− 휌)(1− 푝 2 ). Here,휌is a scenario assumption, not a measured statistical correlation, and these probabilities do not define the implementation’s monitoring counters. Because compensation does not alter this recovery policy, Δ푝 success same recovery = 0.(41) This equality states the model’s separation of execution and payment, not an independently observed improvement in reliability. 7.5 Participant Economics To evaluate financial outcomes, let푈 푟 be one if request푟remains unresolved and zero otherwise, and letℓ 푟 ≥ 0 be its assumed monetary loss. The residual loss, the loss remaining after recovery, is 퐿 = ∑︁ 푟 ℓ 푟 푈 푟 .(42) The analytical protection rule uses this assumed loss rather than the operational base in Equation (35): 퐺 elig = 휒 min푀 eval , 훾 max(퐿− 훿, 0).(43) Here,휒indicates modeled eligibility, and훾and훿are the rate and deductible specified for the scenario. The cap푀 eval applies to the evaluated workload, not to each implementation claim as푀does. Actual credited compensation퐺 paid additionally depends on approval and funding. These quantities are modeled outcomes, not observed compensation payments. Let퐶 retry be recovery expenditure and푃total protection fees. Valuing usable credit at its recorded amount, the buyer’s failure-related cost is 퐽 buyer = 퐶 retry + 퐿+ 푃− 퐺 paid .(44) This is not the complete API bill. Relative to the same recovery policy without protection, the change is 푃− 퐺 paid . The reserve’s net outgoing payment is the opposite amount, giving 퐽 buyer +(퐺 paid − 푃) = 퐶 retry + 퐿.(45) Premiums and compensation therefore cancel across the buyer and reserve under this accounting convention. Payouts exceeding fees require reserve capital but do not alone establish an inability to pay. Conversely, funding a payment from initial capital does not establish that premiums cover the protection activity’s costs. Research Manuscript17 Nexilume ResearchNX-2026-002 This comparison assumes that the buyer can use the entire credit for subsequent service purchases; otherwise, its economic benefit is lower. Together, the coverage, payment, and accounting rules distinguish eligible compensation from completed transfers and changes in loss allocation from changes in request recovery. Evaluation specifies the pricing, loss, and credit-use assumptions separately from these contract workflows. 8 Evaluation We evaluate TokenBank through contract execution, request-level replay, and real-model Agent studies. The evaluation examines four questions: whether contract operations preserve payment and ownership rules; how API-price forwards affect expenditure and its variability; when additional capital supports service delivery and operator contribution; and how recovery and protection jointly determine completed services and loss allocation. Matched controls separate each mechanism’s financial effects from changes in execution, funding, and recovery. The principal findings quantify these relationships. Under the assumed rising-price path, zero-discount forwards reduce mean expenditure by USD 304.88. In the matched low-capital study, revenue-right financing increases mean operator contribution by 1.0635 experimental USD and reduces mean admission stops from 12.0 to 1.8. Under twelve controlled local faults, recovery completes nine services, and adequately funded protection settles the approved residual compensation. The following analyses relate these results to price exposure, capital availability, revenue allocation, and reserve funding. 8.1 Workloads, Controls, and Measurement Tasks, requests, and successful services. The controlled workload contains twelve constructed tasks: four each for structured extraction, order lookup, and constrained product selection. A service succeeds when both the business operation and final output meet the predefined completion rule. A case is one scheduled execution of a task under one experimental setting; it may contain several model calls. Every scheduled case enters its study denominator, including funding-admission stops, injected faults, and resource-limit outcomes. Table 1 reports task, request, response, and success counts separately for each study. Table 1. Real-model study populations. Cases count scheduled task executions; calls include all sent requests. Responses and successful services follow their respective measurement rules. Each study retains its own denominator. StudyCases Calls Responses Successes Repeated capital study540 1,0821,081456 Controlled repeats and parameter tests624 1,2471,246487 Initial controlled study8415015051 Retail contract study709309251 Retail baseline103683604 All model calls use Qwen/Qwen3-8B through Nexus and SiliconFlow. Controlled tasks use constructed local records, callable tools, and explicit completion checks. Two passes over nine calibration tasks produce seven and nine successes, respectively. The final interface enumerates category codes and orders catalog lookup before quote creation; the model selects products and generates its own responses. This configuration is fixed before the twelve evaluation tasks are executed. Repetitions characterize financial and operational effects within the same calibrated task families. The retail studies use the official retail text environment of휏 2 -Bench [3], including its model-driven customer and predefined ALL completion criterion. Task selection, execution limits, calibration passes, and protocol amendments appear in Appendix F.1; the controlled design is specified in Appendix E. Observed quantities and economic assumptions. We measure returned token usage, tool results, request identifiers, account changes, and contract settlements. Available usage is reconciled against Nexus, and payments execute through authenticated business APIs on isolated PostgreSQL research accounts. The configured Nexus charge is zero and supplier invoices are unavailable; monetary outcomes therefore use stated experimental tariffs and success-triggered receipts. Initial capital, future price indices, and local fault schedules are controlled inputs. Observed settlements and scenario-based economic valuations are reported at their respective measurement scopes. Table 2 defines the controlled-study parameters.퐵is baseline own capital,퐴additional funding, and푟 revenue per successful service. Input and output tariffs are 100 and 500 experimental USD per million tokens, Research Manuscript18 Nexilume ResearchNX-2026-002 selected before execution to represent small-task losses at the protection mechanism’s one-cent precision. The retail study uses tariffs of 1 and 5 per million tokens, with퐵 = 휇 = 0.184298,퐴 = 0.370000, and푟 = 0.368596 experimental USD. Each study retains its own tariff, rounding, and coverage conventions. Table 2. Controlled-task parameters fixed from the nine calibration tasks. Amounts are experimental USD. The repeated capital study changes the starting own balance to 0.5퐵, 퐵, or 1.5퐵 and keeps added funds 퐴 fixed. Symbol DefinitionValue 휇Mean known expense per scheduled calibration task0.127689 퐻 cal Largest amount set aside before a calibration request0.943300 퐵Baseline own capital, 휇+ 퐻 cal 1.070989 퐴Added capital, ⌈4휇⌉ 0.01 (rounded up to a cent)0.520000 푟Assumed revenue per successful service, 2휇0.255378 푑Scheduled tasks between releases of earned revenue4 Revenue-right shares: operator / investor / platform89% / 10% / 1% Control shares: operator / platform99% / 1% For real-model studies, operating contribution is the operator’s retained task revenue after sharing, less inference expense at the experimental tariff. Initial funding, fixed operating costs, and the value of outstanding rights are excluded. Investor wallet transfers and service credits, which can offset later service charges, are reported separately. Credit utilization is a scenario parameter; the observation window covers issuance rather than subsequent redemption or lifetime investment returns. Request-level replay. We replay the first two months of BurstGPT [14], retaining recorded timing and usage while applying specified prices and contracts. The dataset revision is recorded in the supplementary artifact. Removing conversation records and the incomplete final day leaves 1,261,858 API requests: 362,417 on days 0–17 for calibration and 899,441 on days 18–59 for evaluation. Timestamps, model labels, token counts, and request order are preserved. At assumed input/output tariffs of USD 3/15 per million tokens, successful first attempts cost USD 3,395.80116. The replay uses 16,137 zero-output records as failure indicators; 16,131 also lack input lengths. Compared settings share the same assumptions for unobserved first-attempt charges and calibration-based alternate-attempt lengths. Five price scenarios start from index one: constant prices, a linear rise to 1.3, a linear fall to 0.7, a seven-day rise to 1.8, and a load-dependent increase. Forward controls match execution and cache/batch settings; financing-cost controls match total funding; protection controls match recovery. The replay’s financing model assigns 10% of revenue to investors and 2% to the platform, while real-model studies assign 1% to the platform. These conventions are specified in Appendices F.1–F.3. Continuous-balance execution and matched controls. Each financing condition is executed separately so that available funds can affect request admission. Own capital starts with퐵 0 ; equal capital and revenue-right financing both start with퐵 0 + 퐴. The equal-capital control matches available funds while omitting the investor share, isolating the revenue-allocation component of financing. A controlled portfolio schedules twelve tasks against a continuous balance. Revenue is released after each group of four scheduled tasks, including tasks denied admission. Before a request, funds are reserved using input bytes and maximum output length; returned usage determines the charge and releases the unused reservation. The matched capital study crosses three initial balances (0.5퐵,퐵,1.5퐵), three financing conditions, and five repetitions, yielding5× 3× 3× 12 = 540cases. Task order and within-task arm order are shared across capital levels within a repetition, while capital-level order is randomized separately. Capital levels are informed by the earlier boundary study, and the replication protocol is fixed before its own observations. The separate 624-case study includes five repeated comparisons, seven one-factor financing conditions, and three fault-frequency runs. Missing-usage bounds and resampling. Requests without returned usage retain their reservations. Let 퐶 known be known expense,푌 ret retained revenue, and 퐻 푢 the unresolved reservation used as the declared upper bound on missing expense. Contribution satisfies Π ∈ [푌 ret − 퐶 known − 퐻 푢 , 푌 ret − 퐶 known ].(46) Treatment-minus-control bounds pair the lower treatment endpoint with the upper control endpoint, and conversely. Separately, 10,000 draws resample whole matched repetitions, preserving within-repetition pairing. Research Manuscript19 Nexilume ResearchNX-2026-002 The 2.5th percentile of lower mean bounds and the 97.5th percentile of upper mean bounds define the exploratory 95% ranges. Portfolios are the sampling units because tasks share operating funds. These ranges describe observed fixed-task repetitions; broader population coverage and multiplicity-adjusted significance are outside this design. Appendix F.1 records the timing of the missing-usage accounting protocol. 8.2 Contract Correctness and Accounting Controls Business-API tests validate payment amounts, recipients, funding checks, and idempotent execution. Revenue- right transfers are checked against subsequent recipient allocation, while repeated payment requests are checked for a single committed transfer (Table 3). All 206 backend regression tests pass. Independent decimal-arithmetic replay verifies 165 account updates across 47 accounts with zero arithmetic discrepancies. Direct ledger association covers 103 entries; five intermediate wallet-funding updates are documented through their business-operation records. These are complementary record-linkage scopes. Overlapping regression and targeted suites are counted once. Table 3. Contract validation through business APIs on isolated PostgreSQL accounts. Synthetic funds exercise payment, ownership, funding, and idempotency rules; economic outcomes are evaluated in the subsequent product studies. Rule testedResult Forward payment and retryQuantity 10 and an index change from 1.0 to 1.3 produce one 3.000000 transfer. Funding and restartA 0.060000 transfer leaves 0.040000; retry changes nothing and a further unfundable transfer is rejected. Payment after a right is soldSubsequent revenue follows the current holder rather than the former investor. Resale to multiple holdersResale to two holders across organizations preserves revenue allocation. Covered serviceA claim for a model service not covered by the contract is rejected. Payment in fullOne 60.000000 payment leaves 40.000000; another 60.000000 claim is not partially paid. Concurrent claimsExactly one competing claim is paid; the compensation funds are not overdrawn. Revenue-allocation precision. A fixed sequence of twelve receipts and twelve duplicate submissions validates revenue allocation at the supported monetary precision. The check associated with the 624-case study records fifteen exact matches between reference calculations and account changes; the capital replication adds fifteen exact matches. These checks establish the tested payment and duplicate-request behavior independently of model-task outcomes. Concurrent transaction execution. At concurrency eight, 760 operations across 19 scenarios preserve the checked accounting rules, with no unexpected operation failures, ledger discrepancies, or deadlocks. The highest scenario-level p95 latency is 2,419.98 ms. Appendix D reports the full latency distribution, reference budget, shared-host configuration, and recovery tests alongside the accounting checks. 8.3 API-Price Forwards Forwards link a separate settlement payment to the difference between the agreed and reference prices. We evaluate settlement execution and the resulting expenditure using matched model-call workloads (Equations(9) and(13)). All 84 zero-discount contracts in the initial controlled study reconcile in amount, direction, fees, and single settlement; 84 retail contracts provide a separate execution check. Notionals are fixed from calibration before task execution, and settlement applies the declared final indices to measured demand. Appendix F.2 includes funded and unfunded payment tests. Price-path and exposure design. The principal resampling study uses strike one, zero discount, and a 1.2% fee to isolate price-linked settlement from negotiated discounts. Daily bills and prices are jointly resampled in seven-day blocks; six blocks form each 42-day path, and 1,000 paths characterize the supplied trace under each assumed price pattern. Hedge ratiosℎ ∈ 0,.25,.5,.75, 1scale forecast expenditure. Forecast multipliers .5, 1, 1.5, matching or constant reference indices, and all-or-none funding of positive daily payments yield 300 settings across five price patterns. The daily payment stress is an analytical funding assumption. Research Manuscript20 Nexilume ResearchNX-2026-002 We report mean expenditure, standard deviation, mean expenditure in the 50 most expensive paths, and the fraction of paths exceeding the fixed budget of 42 calibration-mean daily bills. These measures characterize cost, variability, tail expenditure, and budget adherence within the resampled paths. Table 4. Spending with no assumed price discount, a matching reference index, the unchanged calibration forecast, and sufficient funds for payments.ℎis the fraction of forecast spending covered. Negative meanΔ퐶means lower spending than no hedge. Results come from resampled 42-day paths. Scenario ℎ Std. dev. (USD) Mean Δ퐶 (USD) Over budget (%) flat01144.71+0.0062.2 flat11144.71+26.4963.3 rise01152.45+0.0072.1 rise11190.82-304.8861.4 fall01139.84+0.0054.1 fall11100.08+357.8565.5 spike01107.94+0.0072.7 spike11164.28-304.1060.7 lagged-load 01150.50+0.0063.0 lagged-load 11150.32+25.0863.8 Expenditure reduction and budget adherence. Under rising prices, full forecast coverage reduces mean expenditure by USD 304.88 and the fraction of over-budget paths from 72.1% to 61.4%. The corresponding standard deviation is USD 1,190.82, compared with USD 1,152.45 without coverage. Under a price spike, mean expenditure falls by USD 304.10 and over-budget paths decline from 72.7% to 60.7%. Table 4 also reports the constant, falling, and load-dependent paths, separating each expenditure and variability measure for the same contract configuration. 0.00.20.40.60.81.0 Hedge ratio 1100 1120 1140 1160 1180 42-day expenditure standard deviation (USD) flat rise fall spike lagged-load 0.00.20.40.60.81.0 Hedge ratio −200 0 200 Mean expenditure change (USD) Zero-discount forwards: conditional block-resampling analysis Zero-discount forward scenarios with paired block resampling. Figure 7. Average spending and risk measures without an assumed price discount. Bills and prices are jointly resampled in seven-day blocks. This plot uses the unchanged-forecast, funded-payment settings; the full analysis covers all 300 settings. Mechanism of expenditure variability. Let퐶 0 be unhedged spending and푍 = 푉 − 푓the signed settlement net of all forward fees. The change in expenditure variance is Var(퐶 0 − 푍)− Var(퐶 0 ) = Var(푍)− 2 Cov(퐶 0 , 푍).(47) Variance decreases when2 Cov(퐶 0 , 푍) > Var(푍): larger bills must be accompanied by sufficiently offsetting net payments. In the rising-price paths,2 Cov(퐶 0 , 푍) = −85,383.2andVar(푍) = 4,522.5USD 2 , yielding a variance change of +89,905.7 USD 2 . The decomposition explains how the measured reduction in mean expenditure coexists with the observed variance response. The complete post-hoc moment analysis appears in Appendix F.2. Contract alignment and execution optimization. Price and quantity alignment connect the contract to actual purchases through Equation(13). Request-weighted purchase prices can differ from daily reference averages, Research Manuscript21 Nexilume ResearchNX-2026-002 and realized usage can differ from the calibration notional. The sensitivity study therefore varies these quantities explicitly. In the separate constant-price replay, an assumed 10% contract discount reduces expenditure by USD 155.39 (4.58%); the zero-discount control has a 0.62% expenditure increase from charges. With identical cache/batch assumptions in both arms, adding the discounted forward reduces the optimized unhedged expense by a further USD 113.04 (4.67%). A conventional forward with identical terms produces the same settlement, providing an arithmetic control. Together, these comparisons identify the financial contribution of the stated contract terms alongside execution optimization. 8.4 Revenue-Right Financing Revenue-right financing exchanges current funding for a share of future service receipts. Equation(26)identifies the additional revenue needed to cover that share and execution expense. We assess this relationship with five freshly executed portfolios for each of three financing conditions at three starting balances. Funding and settlement use the implemented contracts. Agent-issued rights are evaluated with real-model execution; the supporting request replay also analyzes Provider financing. Table 5. Five separate runs per setting. Completed services are means out of twelve. Own, Equal, and Right denote own capital, equal capital without investor sharing, and revenue-right financing. Contribution differences are experimental USD, excluding initial funding and credits. Brackets show the range due to missing usage, not variation across repetitions. Completed servicesContribution difference Capital Own Equal Right Right–ownRight–equal 0.5퐵0.0 10.4 10.21.0635-0.3049 퐵10.6 12.0 12.0-0.1406-0.3174 1.5퐵12.0 12.0 12.0-0.2962 [-0.2742, -0.0975] Capital-constrained service delivery. At0.5퐵, revenue-right financing increases mean completion from 0.0 to 10.2 services and mean operating contribution by 1.0635 experimental USD relative to own capital. Mean admission stops decrease from 12.0 to 1.8, an 85% reduction. All five low-capital contribution contrasts are positive. At퐵, mean completion rises from 10.6 to 12.0, with a contribution difference of -0.1406. At1.5퐵, all conditions complete twelve tasks and the contribution difference is -0.2962. The five baseline contrasts contain two positive and three negative values; all five ample-capital contrasts are negative. These matched conditions locate the benefit of financing where available capital constrains service delivery. Revenue growth and allocation. Let푠 푅 , 푠 푂 count successful services and퐶 푅 ,퐶 푂 denote inference expense under revenue-right and own-capital operation. Each success earns푟; both conditions pay a 1% platform share, and financing assigns 10% to the investor. The contribution difference decomposes as ΔΠ 푅−푂 = 0.89푟푠 푅 − 0.99푟푠 푂 −(퐶 푅 − 퐶 푂 ) = 0.99푟(푠 푅 − 푠 푂 )−(퐶 푅 − 퐶 푂 ) | z change before investor share − 0.10푟푠 푅 | z investor share . (48) The first term captures additional retained revenue and execution expense; the second records the investor allocation across financed receipts. This decomposition uses the system’s payment-rounding convention and the observed model executions. At ample capital, equal completion isolates the allocation cost of financing; at low capital, newly admitted work provides the revenue supporting its positive contribution. The equal-capital control matches initial funds without investor sharing. Its mean contribution exceeds the revenue-right condition by 0.3049 at low capital and 0.3174 at baseline. The ample-capital Right–equal range is [-0.2742, -0.0975]. This experimental control separates capital availability from the sharing obligation. Full missing-cost bounds and portfolio-resampling ranges appear in Appendix F.3. Advance reservations and admission. The median reservation-to-measured-charge ratio is 12.0153 in the 624-case study and 12.4382 among returned-usage requests in the capital replication. The latter records have a minimum reservation of 0.545800, compared with the low-capital opening balance of 0.535495. These observations link the financing result to the tested advance-reservation rule as well as to inference expense. The Research Manuscript22 Nexilume ResearchNX-2026-002 Figure 8. Five runs at each starting capital level. Left: completed services under the three financing settings, with mean bars. Right: contribution with revenue-right financing minus contribution with own capital. Any nonzero whiskers bound missing charges; they are not resampling ranges. Tasks within a run share funds and are not independent repetitions. diagnostic describes returned-usage records; rejected-request reservations and alternative reservation policies are outside its observed population. Supporting cohorts and operating conditions. The initial controlled study completes three additional services with revenue-right financing and records a contribution increase of 0.1463 experimental USD. The earlier five-portfolio study, including its incident-affected run, has a mean Right–own bound of [-0.5295, -0.3411]. In the one-factor sensitivity study, the low-capital condition is the one of eight displayed conditions with a positive lower contribution bound. These separate cohorts characterize the dependence on starting capital, task receipts, receipt timing, and realized execution. The retail study records one successful case among 70, with zero successes in its three financing arms. Equal capital increases scoreable completions from one to four; the revenue-right arm has no scored completion and retains 0.172938 in unresolved reservations. Consequently, this cohort characterizes admission and expenditure without success-triggered revenue. Its complete results remain in Appendix F.3. Investor cash flows and funding-charge controls. In the capital replication, the investor contributes 0.5200 and receives mean wallet transfers of 0.2540 at low capital and 0.3000 at baseline and ample capital. Outstanding entitlements and rounding remainders are tracked separately under the observation-window convention in Section 8.1. A separate replay fixes aggregate funding at USD 1,710.86. Assumed charges are USD 16.87 for own-capital opportunity cost, USD 33.98 for fixed credit, USD 11.25 for Provider credit, and USD 526.48 for revenue sharing. This comparison isolates charging rules at matched funded volume; repayment, collateral, and default-risk equivalence are outside that comparison. An equal-funded loan is also included in the synthetic accounting tests (Appendix D). Together, the growth and charge controls quantify the service revenue required by specified financing terms. 8.5 Service-Failure Protection Recovery and protection address complementary outcomes: completed service and allocation of covered residual loss. We vary local recovery through fresh task execution and apply alternative protection plans to each recorded trajectory, keeping execution fixed within a protection comparison. The fault study schedules zero, six, or twelve local faults across twelve tasks. Before each run, twelve alternative plans cross per-claim limits of 0.03/0.13, premiums of 0.01/0.10/0.60, and Provider-funded reserves of 0.13/1.56. Each plan has separate accounts and whole-claim payment checks. Policy results are reported separately. Premiums and service credits are accounted for outside the balance used for task admission. Service completion and eligible residual loss. With twelve scheduled faults, local recovery increases completion from zero to nine services; with six faults, it increases completion from six to ten (Table 6). Recovery uses an alternate local route to the same upstream Provider; common-route outages remain terminal. Compensation applies to covered terminal injected failures with known expense. Semantic task errors and Research Manuscript23 Nexilume ResearchNX-2026-002 missing usage follow separate accounting categories. Appendix F.4 reports the initial controlled and retail interventions using these definitions. For eligible residual loss퐿 푒 , premium푃, and issued credit퐺, a buyer able to use fraction푣of the credit bears 퐿 푒 + 푃− 푣퐺. Relative to the same recovery policy without protection, its benefit is 퐵 protection = 푣퐺− 푃.(49) We evaluate assumed utilization fractions푣 = 0,0.5, and1.퐿 푒 includes losses within the coverage rules. At full utilization, the benefit퐺− 푃is the reserve-funded transfer net of premiums, with execution expenditure held fixed. Table 6. Fault tests with a per-claim limit of 0.13, premium of 0.01, and initial reserve of 1.56. Loss and credit amounts are experimental USD. Paid credit is issued through the experimental contracts; benefit assumes either full use (푣 = 1) or no use (푣 = 0) of that credit. Faults / recovery Success Eligible loss Paid credit Benefit 푣 = 1 Benefit 푣 = 0 0 / no120.00000.0000-0.0100-0.0100 0 / yes120.00000.0000-0.0100-0.0100 6 / no60.29000.29000.2800-0.0100 6 / yes100.09000.09000.0800-0.0100 12 / no00.55000.55000.5400-0.0100 12 / yes90.14000.14000.1300-0.0100 Table 7. Claim limits and available funds with twelve scheduled faults and a premium of 0.01. Approved, paid, and unpaid columns report total amounts in experimental USD, not numbers of claims. Initial funds exclude the premium. Loss above the claim limit is not counted as an unpaid approved claim. Recovery Claim limit Initial funds ApprovedPaid Unpaid no0.13001.56000.5500 0.5500 0.0000 no0.13000.13000.5500 0.1300 0.4200 no0.03000.13000.3600 0.1200 0.2400 no0.03001.56000.3600 0.3600 0.0000 yes0.13001.56000.1400 0.1400 0.0000 yes0.13000.13000.1400 0.1400 0.0000 yes0.03000.13000.0900 0.0900 0.0000 yes0.03001.56000.0900 0.0900 0.0000 Reserve capitalization and settlement coverage. With twelve faults, no recovery, and a 0.13 per-claim limit, an initial reserve of 1.56 funds all 0.5500 in approved compensation. With recovery, both tested reserve levels fund all 0.1400 in approved claims (Table 7). Reducing the initial reserve to 0.13 without recovery yields 0.1300 paid and 0.4200 unpaid; reducing the claim limit to 0.03 yields 0.3600 approved. These controls distinguish the effect of coverage limits on obligations from the effect of reserves on settlement. Premiums increase both reserve balance and budget. For example, 0.13 in initial funds plus a 0.01 premium makes 0.14 available. Settlement checks the full approved amount for each submitted claim and reports unpaid amounts separately. The experiment applies per-claim full-payment checks; the analytical replay below specifies its own carry-forward schedule. Premium and credit-utilization sensitivity. At full utilization, the ample-reserve fault scenarios yield net buyer benefits of 0.0800–0.5400 with the 0.01 premium. Break-even occurs at푃 = 푣퐺; raising premiums or lowering utilization changes net value according to Equation(49). With no eligible fault or with푣 = 0, the net value equals the premium outflow. Figure 9 reports the premium sensitivity under full utilization, complementing the utilization cases in Table 6. Portfolio-level reserve sensitivity. The supporting request replay analyzes chronological liabilities under a portfolio-level payment cap and explicit carry-forward of unpaid amounts. These analytical conventions complement the per-claim settlement experiments above. At a shared-failure fraction휌 = 0.75, the replay Research Manuscript24 Nexilume ResearchNX-2026-002 Figure 9. Premium sensitivity of buyer value under full service-credit utilization, a 0.13 per-claim limit, and a 1.56 initial reserve. Net value follows Equation (49). collects USD 34.22 in premiums and pays USD 220.73, reducing modeled buyer expense by USD 186.51 under full credit utilization. Recovery is held fixed for this financial comparison. Appendix F.4 specifies claim delays, reserves, and liability limits for the analytical study. 8.6 Combined Financial Effects We evaluate the eight combinations of forwards (퐷), financing (퐹), and protection (푆) through a common accounting decomposition. Financing conditions use separate executions because funds affect admission. Forward and protection payments are applied to matched recorded trajectories through separate accounts, holding admission fixed within those comparisons. Contribution includes signed forward payments and fees; service credits are reported separately. This design evaluates combined financial accounting on measured execution. Table 8. Eight combinations for recovery-enabled runs with ample funds, at an assumed price index of 1.5 and hedge ratio of 0.5.퐷,퐹, and푆switch forwards, financing, and protection on or off. Contribution is experimental USD, excluding initial funding and service credits. Issued credits are reported separately. 퐷 퐹 푆 Success Contribution Service credit 0 0 090.60340.0000 0 0 190.59340.1400 1 0 090.97720.0000 1 0 190.96720.1400 0 1 090.37350.0000 0 1 190.36350.1400 1 1 090.74740.0000 1 1 190.73740.1400 All controlled combinations complete nine tasks. At the assumed index of 1.5 and hedge ratio of 0.5, adding the forward raises own-capital contribution from 0.6034 to 0.9772. Protection issues 0.1400 in service credit for a 0.01 premium. The all-mechanism configuration records 0.7374 in contribution and 0.1400 in credits. With ample funds and matched completion, the financing comparison measures the share of receipts allocated to investors. These results separate contract-specific payments within the combined outcome. The retail combinations retain their own execution trajectories, known expenses, and missing-usage reservations (Appendix F.5). Their eight known-cost contributions are negative; within each fixed financing trajectory, the forward and protection contrasts identify their respective settlement and fee effects. Between- financing differences also incorporate the separate model executions. Fixed-volume economic decomposition. The request replay crosses eight combinations, five price paths, and two forward discounts while holding offered work and recovery fixed. With퐹 = 0, funding has the assumed Research Manuscript25 Nexilume ResearchNX-2026-002 opportunity cost of own capital; with퐹 = 1, the stated revenue-sharing charge replaces that cost. Modeled economic expense is 퐶 = 퐶 API + 퐶 retry + 퐶 퐷,fee −푉 퐷 + 퐶 fund + 푃 푆 − 퐴 푆 , (50) Here퐶 API and퐶 retry are primary and alternate request expenses,퐶 퐷,fee the forward fee,푉 퐷 signed paid settlement,퐶 fund funding cost,푃 푆 the protection premium, and퐴 푆 paid compensation. This metric includes opportunity cost and values paid compensation at face value; initial capital is excluded. Under constant prices, the assumed 10%-discount forward reduces economic expense from USD 3,438.59 to USD 3,282.46. The all-mechanism configuration has expense USD 3,605.09, or 4.84% above baseline, because the fixed workload provides no additional admitted service to offset financing and protection charges. The decomposition attributes this difference to contract-specific costs and payments under a common workload. Together with the capital-constrained and fault studies, it identifies the operating conditions that give each financial mechanism a productive role. 9 Conclusion This paper presented TokenBank, a unified contractual and accounting infrastructure for AI services, integrating service commitments, API-price forwards, revenue-right financing, and service-failure protection. Evaluation combines request-level replay over 362,417 calibration and 899,441 evaluation requests with real-model Agent execution and PostgreSQL-backed contract experiments. Under the rising-price scenario, forwards reduce mean API expenditure by USD 304.88. In the low-capital setting, revenue-right financing increases mean contribution profit by 1.0635 experimental USD and reduces admission stops from 12.0 to 1.8. Under controlled faults, recovery completes 9 of 12 tasks in each recovery-enabled arm, while adequately funded protection settles all approved compensation. Authors and Contributors Cary Chang served as the contributor to this work, leading the conceptualization, system design, and manuscript preparation. Jialin Zhou contributed to project support. We also thank members of the broader research and developer community for discussions, feedback, and ideas that helped refine the research questions, system design, and evaluation presented in this report. References [1]Amazon Web Services. Amazon bedrock service level agreement, 2026. URLhttps://aws.amazon.com/bedrock/ sla/. Official SLA, accessed September 15, 2026. [2] Alain Andrieux, Karl Czajkowski, Asit Dan, Kate Keahey, Heiko Ludwig, Toshiyuki Nakata, Jim Pruyne, John Rofrano, Steve Tuecke, and Ming Xu. Web services agreement specification (WS-Agreement). Technical Report GFD.107, Open Grid Forum, 2007. URL https://ogf.org/documents/GFD.107.pdf. [3]Victor Barres, Honghua Dong, Soham Ray, Xujie Si, and Karthik Narasimhan. Tau2-bench: Evaluating conversational agents in a dual-control environment, 2025. URL https://arxiv.org/abs/2506.07982. [4]Gérard P. Cachon and Martin A. Lariviere. Supply chain coordination with revenue-sharing contracts: Strengths and limitations. Management Science, 51(1):30–44, 2005. doi: 10.1287/mnsc.1040.0215. URL https://pubsonline. informs.org/doi/10.1287/mnsc.1040.0215. [5] John Cartlidge and Philip Clamp. Correcting a financial brokerage model for cloud computing: closing the window of opportunity for commercialisation. Journal of Cloud Computing, 3(1):2, 2014. doi: 10.1186/2192-113X-3-2. URL https://link.springer.com/article/10.1186/2192-113X-3-2. [6] Lingjiao Chen, Matei Zaharia, and James Zou. FrugalGPT: How to use large language models while reducing cost and improving performance. https://arxiv.org/abs/2305.05176, 2023. [7]Rowan Clarke, Dominic Russel, and Claire Shi. Revenue-based financing. Working paper, October 2025 version. Earlier version circulated as FinTech and Financial Frictions: The Rise of Revenue-Based Financing, October 2025. URL https://dominicrussel.com/assets/files/CRS_RBF.pdf. [8] Anna Ye Du, Sanjukta Das, and R. Ramesh. Efficient risk hedging by dynamic forward pricing: A study in cloud computing. INFORMS Journal on Computing, 25(4):625–642, 2013. doi: 10.1287/ijoc.1120.0526. URLhttps: Research Manuscript26 Nexilume ResearchNX-2026-002 //pubsonline.informs.org/doi/10.1287/ijoc.1120.0526. Published online October 22, 2012; assigned to the Fall 2013 issue. [9] Loretta Mastroeni, Alessandro Mazzoccoli, and Maurizio Naldi. Service level agreement violations in cloud storage: Insurance and compensation sustainability. Future Internet, 11(7):142, 2019. doi: 10.3390/fi11070142. URL https://w.mdpi.com/1999-5903/11/7/142. [10]Behnam Mohammadkhani, Atul Khekade, and Ritesh Kakkad. Agentic settlement protocol: An application profile for refundable, delayed-fulfilment agent commerce on stablecoin rails, 2026. URLhttps://arxiv.org/abs/2609. 02208v1. Version 1, September 2, 2026. Design paper; measured evaluation is left to follow-up work. [11] Isaac Ong et al. RouteLLM: An open-source framework for cost-effective LLM routing.https://w.lmsys.org/ blog/2024-07-01-routellm/, 2024. Authors’ benchmark summary; paper arXiv:2406.18665. [12]Poe. Poe Bot Monetization API Documentation. Poe, 2026. URLhttps://creator.poe.com/docs/server-bots/ poe-bot-monetization-api-documentation. Official documentation, accessed September 15, 2026. [13] Owen Rogers and Dave Cliff. A financial brokerage model for cloud computing. Journal of Cloud Computing: Advances, Systems and Applications, 1(1):2, 2012. doi: 10.1186/2192-113X-1-2. URLhttps://link.springer. com/article/10.1186/2192-113X-1-2. [14] Yuxin Wang et al. BurstGPT: A real-world workload dataset to optimize LLM serving systems.https://github. com/HPMLL/BurstGPT, 2025. KDD 2025; public trace pinned in experiment manifest. [15] Yingxuan Yang, Ying Wen, Jun Wang, and Weinan Zhang. Agent exchange: Shaping the future of AI agent economics, 2025. URLhttps://arxiv.org/abs/2507.03904. Version 1. This entry cites the inspected preprint, not a later workshop version. Research Manuscript27 Nexilume ResearchNX-2026-002 A Contract Records and Detailed Validation This appendix formalizes the record structure, fulfillment conditions, and transaction constraints underlying Section 4. The definitions distinguish contractual entitlements, current ownership, and completed payments while preserving the product-specific rules for consumption, forwards, revenue rights, and protection. A.1 Record Model Let T =consumption, forward, revenue, protection.(51) A claim’s complete record description is 푐 = (휄,휂,휏,P,R,U,Θ 휏 ,푥 휏 ,L),(52) where휄identifies the record or linked record group,휂identifies its tenant context (the account and permission scope), and휏 ∈ Tis the economic type. The participant mappingPassociates roles with accounts and entities. ReferencesRidentify the service, price index, revenue policy, or protection plan;Uspecifies quantity and payment units. TermsΘ 휏 describe the obligation, state푥 휏 its status and operational quantities, andLlinks source, fulfillment, transfer, and settlement records. The claim space is C = Ä 휏∈T C 휏 ,(53) whereC 휏 contains claims of type휏. The disjoint union à preserves the type distinction even when fields or units coincide. Separate models, references, and validation routines realize this notation. Product-specific validation determines how descriptive service fields enter processing. Quality attributes specify the service terms associated with a claim. An amount푣 = (푎,푢)contains numerical value푎and unit푢. Supported units include service credits, usage units, USD, and CNY. Ordinary transfers require compatible units, while wallet and cross-organization operations use explicit accounting links. Each amount retains its unit throughout these operations. Time terms include prepaid validity and optional expiry, forward dates, revenue-policy effective times, optional funding-agreement start and end dates, and protection coverage, waiting periods, and claim windows. Any finite duration or repayment cap is specified separately from the revenue-share fraction. A.2 Product-Specific Fulfillment Rules Prepaid consumption and delivery. For prepaid lotℓ, let푟 ℓ be the remaining amount,푘 ℓ its locked amount, 푠 ℓ the validity start, and푒 ℓ the expiry, with푒 ℓ =∅denoting no expiry. For account푎and time푡, eligible lots are E 푎 (푡) =ℓ : account(ℓ) = 푎, status(ℓ) = active, 푠 ℓ ≤ 푡, (푒 ℓ =∅∨ 푡 < 푒 ℓ ), 푟 ℓ > 0. (54) Here,∨ permits either no expiry or an expiry after the current time. The available amount is 퐴 푎 (푡) = ∑︁ ℓ∈E 푎 (푡) max(푟 ℓ − 푘 ℓ , 0).(55) A request consuming 푞 > 0 units requires allocations 푧 ℓ satisfying 0≤ 푧 ℓ ≤ max(푟 ℓ − 푘 ℓ , 0), ∑︁ ℓ∈E 푎 (푡) 푧 ℓ = 푞. (56) Lots are selected by ascending expiry, with non-expiring lots last and creation time breaking ties. Insufficient balance rejects consumption; successful consumption reduces the selected balances and records the allocations and accounting transaction. For a preorder, purchased quantity푄, delivered quantity퐷, and additional delivery푑 > 0satisfy퐷+ 푑 ≤ 푄 and퐷 ′ = 퐷+ 푑. An Agent preorder becomes delivered at퐷 ′ = 푄. These quantities establish recorded service delivery. A prepaid transfer retains the source lot’s expiry and refund eligibility. Research Manuscript28 Nexilume ResearchNX-2026-002 Forward payment. For reference price푃, fixed price퐾, and notional푁(the amount scaling the price difference), the positions have values 푉 long = 푁(푃− 퐾), 푉 short =−푉 long .(57) The long account receives a positive amount and pays when that value is negative; the short account has the opposite obligation. Price and notional units must correspond as described in the forward analysis. Product checks permit forwards, constrain푁, and require future expiry within the maximum term at creation. Fees and margin, funds held to support payment, are recorded separately. Settlement uses the latest available index observation and checks funding; insufficient funds produce a default record rather than establishing a completed payment. Revenue allocation. For revenue event푒, let푅 푒 be its recorded net amount and푏 푖 the share assigned to recipient푖among푚recipients. Shares use basis points, each equal to1/10,000of the amount. The policy requires 푏 푖 > 0, 푚 ∑︁ 푖=1 푏 푖 = 10,000.(58) The exact allocation is 푑 ∗ 푖,푒 = 푏 푖 10,000 푅 푒 .(59) Both Agent and Provider settlement use the recorded net amount. At the supported decimal precision, actual distributions 푑 푖,푒 are adjusted to preserve the event amount: 푑 푖,푒 ≥ 0, ∑︁ 푖 푑 푖,푒 = 푅 푒 .(60) For successive events and a fixed participant set with fixed shares, the rounding difference carried to the next allocation is 휖 푖,푒+1 = 휖 푖,푒 + 푏 푖 10,000 푅 푒 − 푑 푖,푒 ,(61) where휖 푖,푒 is the previously accumulated difference. This records the difference between exact entitlements and finite-precision payments. Investor participants are updated before allocation using assets linked to the funding agreement; if no matching assets exist, the original investor is used. The recipient set is determined from the holdings selected at settlement time. Protection coverage and payment. For protection contract푐and incident/submission records푒, coverage is 휒(푐,푒) = 휒 active ∧ 휒 period ∧ 휒 waiting ∧ 휒 provider/model ∧ 휒 event ∧ 휒 deadline . (62) Each term denotes a passed check: active subscription, covered incident period, any waiting-period requirement, Provider or model scope, covered event type, and claim deadline. The conjunction∧requires every applicable condition to hold. For a cost-denominated compensation base퐵, let훿be the deductible (the excluded amount),훾the compensation rate, and푀the plan’s maximum amount. Incident-impact calculations and ordinary manual claims use b 퐺 = min푀, 훾 max(퐵− 훿, 0).(63) Impact records retain request costs together with failure and fallback counts. The monetary interpretation above uses a cost-denominated퐵; activity counts retain their event-count units. Automatically generated claims already contain the calculated amount; review caps that amount without applying the deductible and rate again. For approved amount퐺, let푅 budget be the reserve budget,푅 paid cumulative payments,퐵 푟 its account balance, and 퐿 푟 locked balance. Settlement requires 0 < 퐺 ≤ min푅 budget − 푅 paid , 퐵 푟 − 퐿 푟 .(64) Successful settlement credits the buyer’s billing wallet for service charges. An approved claim and an executed payment remain distinct records. Research Manuscript29 Nexilume ResearchNX-2026-002 A.3 Operation and Transaction Controls For operation 훼 on type 휏, the conditions summarized in Equation (2) are 퐺 휏,훼 = 퐺 authority ∧ 퐺 policy ∧ 퐺 state ∧ 퐺 terms ∧ 퐺 resources . (65) These check permission, whether an operation is enabled or needs approval, its current status, contract conditions, and resources such as balances, margin, or reserves. The applicable checks differ by operation. For example, an Agent preorder progresses through approval and recorded delivery, a forward can settle or default, a revenue event settles after distribution, and protection approval precedes a separate payment step. Product records retain terms, participants, status, holdings, and source links. Validation checks the required fields and conditions; transaction routines lock affected records and invoke account or wallet operations. Delivery, valuation, distribution, claim, transfer, and accounting records retain links between each operation and its outcome. Market transfers release the relevant payment reservation, post payment, decrease the seller’s total and locked units, increase the buyer’s total and available units, and record the transfer. Receiving holdings preserve selected agreement and policy references for later recipient selection. For account푎, let퐵 푎 and퐿 푎 be its balance and locked balance, and퐶 used 푎 and퐶 limit 푎 its used and permitted credit amounts. Account constraints require 0≤ 퐿 푎 ≤ 퐵 푎 ,0≤ 퐶 used 푎 ≤ 퐶 limit 푎 .(66) Product checks additionally enforce available prepaid amounts, remaining delivery quantities, distributable revenue, and reserve funding. The balanced-posting relation appears in Equation(4); cross-organization processing may require checking a linked settlement group rather than an isolated account balance. An idempotency key associates a supported operation’s retries with its recorded result. The common transfer routine rechecks this key after acquiring account locks. Alongside product-state checks, this supports at most one committed financial posting for each scoped operation key. B Forward Valuation, Funding, and Settlement This appendix specifies the records and funding rules supporting the forward mechanism. It distinguishes contractual valuation from completed payment and derives the condition under which a funded forward reduces expenditure variance. B.1 Reference, Formation, and Valuation Records Contract record. A forward contract is represented by 푓 ctr = (푎 퐿 ,푎 푆 ,I, 푁,퐾,푡 0 ,푇, 푚 0 ,푚 1 , 휙 퐿 , 휙 푆 ). (67) Here푎 퐿 and푎 푆 are the long and short accounts,Iidentifies the reference-price index,푁is the submitted multiplier,퐾the fixed price,푡 0 activation time, and푇recorded expiry. The coefficients푚 0 and푚 1 govern initial and subsequent margin, while휙 퐿 and휙 푆 govern service fees. These numerical fields use the product’s quotation and payment units. The normalized notional used in the expenditure analysis is related to the service quantity by 푁 = 푞푃 0 . This transformation defines the analytical units; submitted contract fields use the product’s quotation and payment units. Reusable product records specify the reference index, allowed notional range, maximum term, and fee and margin parameters. Individual contracts retain the selected accounts, accepted terms, funding amounts, state, and latest valuation. The benchmark-creation path associates an index with a Provider marketplace offer having a positive price in USD per thousand tokens. Observations retain their timestamps and sources. Quote confirmation checks authority, quote state and deadline, and record versions when supplied. It accepts the selected quotation and withdraws competing offered quotations. A requester choosing the buy side becomes the long account; otherwise, it becomes the short account. Funding previews estimate requirements, but activation calculates them from the accepted notional and product parameters. The coefficients used for fees and margins are stored in basis points, each equal to1/10,000, and converted to fractions under the product’s unit convention. Research Manuscript30 Nexilume ResearchNX-2026-002 Valuation selects the latest stored observation for the index within the contract’s tenant, its account and permission scope. When no observation exists, the implementation can initialize one from configured source information. The selected observation and its recorded source provide the price evidence used by the workflow. Valuation uses decimal arithmetic rounded to six decimal places and retains the selected observation, price, amount, and margin requirement. The valuation is the contract-defined price-difference amount. Funding charges and scenario-level economic outcomes are recorded separately. B.2 Margin Requirements and Funding Checks Initial funding. Activation requires sufficient funds for both margin and service fees: 푀 0 퐿 = 푚 0 푁,푀 0 푆 = 푚 0 푁,(68) 퐹 퐿 = 휙 퐿 푁,퐹 푆 = 휙 푆 푁.(69) The superscript0denotes activation. Fees go to the platform account, while margin remains reserved against other use. Product coefficients must be interpreted with the relevant notional and payment units. Subsequent requirements. For participant푗 ∈ 퐿,푆, let퐵 푀 푗,푡 be its funded margin at time푡. Given valuation 푉 푡 , maintenance coefficient 푚 1 , and notional 푁, the contract-level requirement is 푅 푡 = |푉 푡 |+ 푚 1 푁.(70) The recorded account requirement and additional amount due are 푅 푗,푡 = min푅 푡 , 퐵 푀 푗,푡 +|푉 푡 |,(71) 퐷 푗,푡 = max푅 푗,푡 − 퐵 푀 푗,푡 , 0.(72) Both participants’ calculations use|푉 푡 |under the same margin policy. The margin coefficients are configured contract parameters. A positive퐷 푗,푡 can create or update a margin call, a request for additional funding that records the amount, deadline, and status. Enabled automatic funding attempts draw on linked billing wallets after currency, availability, and balance checks. A separate default check records an unmet obligation when funded margin is insufficient. Payment remains subject to the current obligation and available funding. B.3 Settlement Funding and Idempotency Settlement accepts active or defaulted contracts and recalculates the obligation using the latest stored observation at settlement. Let퐵 푎 denote the payer’s balance,퐿 푎 its total locked balance, and푀 푎 its funded margin for this contract. After releasing the contract’s reservation, available funds are 퐴 available 푎 = 퐵 푎 − max퐿 푎 − 푀 푎 , 0.(73) This expression releases the contract’s funds while retaining other reservations; margin is not added again to the account balance. Let 퐴 푡 = |푉 푡 | be the payment due. The funding preview reports 푀 applied 푎 = min푀 푎 , 퐴 푡 ,(74) 퐶 additional 푎 = max퐴 푡 − 푀 applied 푎 , 0,(75) 푆 푎 = max퐴 푡 − 퐴 available 푎 , 0.(76) These are the portion covered by margin, the portion beyond margin, and the shortage after all available funds are considered. The second amount need not imply a shortage: existing unlocked funds can cover it. Settlement records link the payment and funding preview to the contract and accounting transaction. Contract-specific identifiers associate repeated requests with an existing settlement, and state checks prevent settling an already completed contract again. Database transactions and record locks coordinate the associated updates. Unused wallet-originated funding can return through the wallet path, subject to its currency precision. Insufficient funding produces no proportional partial payment. Research Manuscript31 Nexilume ResearchNX-2026-002 B.4 Expenditure Variability With full payment, fixed푁and퐾, scenario-independent charges퐹+ 퐻, and finite variances, the expenditure model gives Var(퐶 퐻 ) = Var(퐶 0 )+ 푁 2 Var(푃 ∗ ) − 2푁 Cov(퐶 0 , 푃 ∗ ). (77) Variance measures fluctuation across the modeled scenarios; covariance measures how expenditure and the settlement reference price move together. The contract reduces variance only when the covariance term offsets the variation added by its price-dependent payment. This relationship explains why price alignment matters independently of the agreed fixed price. The identity provides the analytical basis for comparing reference alignment and hedge ratios across scenarios. C Revenue-Right Financing: Supporting Definitions This appendix specifies the funding, revenue-allocation, and ownership rules supporting Section 6. It also defines the workload-accounting models used to distinguish additional funded service from the cost of sharing revenue. C.1 Contract Records and Capital Disbursement A publisher plan is represented as 휋 = (표,S,푢, 푏 푂 , 푏 퐼 , 푏 푃 ,D),(78) where표is the publisher,Sits Agent or Provider service, and푢the accounting unit. Shares푏 푂 , 푏 퐼 , 푏 푃 are defined in Section 6.1;Dcontains plan descriptions and source-record references. The corresponding fractions are훼 푂 = 푏 푂 /10,000,훼 퐼 = 푏 퐼 /10,000, and훼 푃 = 푏 푃 /10,000. Agent plans require positive shares for all three groups. Provider plans can omit an investor share, although financing uses푏 퐼 > 0. Provider service references identify the partner, the runtime executing its calls, and the selected model offer. An investment agreement records 푔 푗 = (휄 푗 , 휋,푎 푗 ,퐶 푗 ,퐶 settled 푗 , 휎 푗 ,L 푗 ), (79) where휄 푗 identifies the agreement and푎 푗 the investor account. The amounts퐶 푗 and퐶 settled 푗 denote committed and disbursed capital,휎 푗 is the current status, andL 푗 links funding, disbursement, and derived revenue-right records. Separate Agent and Provider revenue policies maintain the corresponding participant records. Funding agreements identify publisher investments by their participants and revenue policy. Publisher investments use immediate capital settlement at confirmation. Investment requests retain the accepted policy, publisher and investor references, and billing-wallet links. Wallet-funded amounts must fit the available balance and be exactly representable to two decimal places. Confirmation checks authority, product policy, and the supplied record version when present, under the relevant tenant contexts. A wallet bridge, the routine connecting wallet operations to financial accounts, funds the investor-side account and transfers the contribution to an intermediate settlement account called escrow. The agreement then becomes active. For an active Agent agreement with funded escrow, capital settlement transfers퐶 due 푗 = 퐶 푗 − 퐶 settled 푗 to the publisher’s funding account. Completion records퐶 settled 푗 = 퐶 푗 , the transaction, and settlement time. The Provider path similarly transfers capital and records the publisher-side receipt when funding crosses tenants. These linked records connect the investor’s outflow to the publisher’s capital receipt. Escrow connects the investor-side funding operation to the publisher’s capital receipt. Disbursement is performed for each confirmed investment. An Agent plan’s funding goal is retained as plan information. C.2 Share Allocation and Revenue Processing Integer agreement shares. Equation(15)defines ideal allocations. For푛selected agreements in deterministic order, let퐴 푗−1 = Í 푗−1 푘=1 푏 푘 , with퐴 0 = 0, be the basis points already assigned. For푗 < 푛, the stored allocation is 푏 푗 = min max1,⌊푏 ∗ 푗 ⌋, 푏 퐼 − 퐴 푗−1 −(푛− 푗), (80) Research Manuscript32 Nexilume ResearchNX-2026-002 where⌊·⌋rounds down. The second bound retains at least one basis point for every remaining agreement. The final agreement receives푏 푛 = 푏 퐼 − 퐴 푛−1 . Positive allocations require푛≤ 푏 퐼 ; the Provider routine explicitly rejects more confirmed investments than the available pool can accommodate at this precision. Holder shares use a second integer allocation with remainder assignment. An agreement with more selected holders than assigned basis points is rejected. For example, adding an active 100-unit investment to the main text’s 100- and 300-unit example changes the ideal total-revenue shares from 2.5% and 7.5% to 2%, 6%, and 2%. The pool remains 10%; the individual percentages are recalculated rather than fixed at investment creation. Revenue records and readiness. A revenue event identifies its policy, source and settlement accounts, amounts, accounting unit, and supporting service references. Agent usage capture retains request and usage identifiers together with consumer and publisher tenant references. Provider capture also retains runtime and model-offer information. The recorded billing amount is transferred to a revenue source account, and an event identifier associates repeated creation requests with that event. Let퐺 푒 be gross recorded revenue and푅 푒 the recorded net amount used for distribution. Agent creation sets푅 푒 = 퐺 푒 . Provider creation can accept a separate net amount, but the evaluated usage-capture procedures supply the same captured amount as both gross and net. This captured income is the distribution base; operating costs enter the separate contribution- profit calculation. Automatic settlement of a publisher plan with an investor allocation requires a linked active investment with positive disbursed capital. Otherwise, an event can remain pending, and confirmation of an investment can trigger later settlement. Before distribution, recipients are refreshed from the currently active funded investments and linked positive holdings. The allocation convention uses the recipient set selected at settlement. Payment precision and rounding carry. For participant푖, let푏 푖,푒 be the share used for event푒and휀 = 10 −6 the payment increment. A rounding carry휅 푖,푒 retains the signed difference between previously calculated shares and payments. The routine computes 푦 푖,푒 = 푅 푒 푏 푖,푒 10,000 + 휅 푖,푒 ,(81) 푑 (0) 푖,푒 = 휀 max(푦 푖,푒 , 0) 휀 .(82) It then adjusts payments in increments of휀to match푅 푒 . If their sum is too low, increments go to the largest unpaid remainders; if too high, increments are removed from positive payments using the corresponding remainder ordering. Deterministic participant order resolves ties. For event amounts at the supported precision, payments satisfy Equation (18), and 휅 푖,푒+1 = 푦 푖,푒 − 푑 푖,푒 .(83) For an unchanged participant identity across 퐸 events, 퐸 ∑︁ 푒=1 푑 푖,푒 = 퐸 ∑︁ 푒=1 푅 푒 푏 푖,푒 10,000 + 휅 푖,1 − 휅 푖,퐸+1 . (84) The retained difference accounts for cumulative proportional amounts and actual payments for the unchanged participant identity specified above. Recording and wallet transfers. Settlement batches select pending events, refresh recipients, allocate payments, and post transfers. Distribution records link the event, participant, account, transaction, applied share, and carry; the event then becomes settled. Event and account locks coordinate concurrent updates. Batch and event–participant idempotency keys, identifiers associating repeated requests with existing operations, prevent duplicate financial postings through the supported paths. Investor distributions can be transferred to linked billing wallets, whose amounts have two-decimal precision. For incoming distribution 푑 and retained remainder 휔, the bridge credits 푤 = 0.01 휔+ 푑 0.01 , 휔 ′ = 휔+ 푑− 푤.(85) The remainder is retained for later transfers. For cross-tenant investments, clearing and corresponding distribution records link the publisher-side allocation to the investor-side receipt. Research Manuscript33 Nexilume ResearchNX-2026-002 C.3 Transfer Records and Settlement A revenue-right asset represents a holding 푎 = (휄 푎 ,휂 푎 ,푔, 휋, ℎ,푈, 퐴, 퐿),(86) where휄 푎 identifies the asset and휂 푎 its tenant context. The references푔and휋identify the source agreement and revenue policy;ℎis the holder account. Here푔is an agreement reference, not the contribution fraction used in the economic analysis. Quantities푈, 퐴, 퐿are total, available, and locked units. The last category records units reserved against other use. Creation requires a confirmed investment and, for publisher investments, completed capital disbursement. Conversion creates a positive number of units no greater than the source investment position. Source-agreement and policy references and selected service attributes are retained. Agent investment confirmation invokes asset creation; the Provider path supplies a corresponding conversion routine. Provider listing requires a Provider-financing source-agreement reference even though the broader asset model contains additional right types. A numerical relationship between units and investment amount establishes neither a resale value nor a redemption price. Reservation and order entry. Listing 푞 ℓ units requires authority and 0 < 푞 ℓ ≤ 퐴. The holding changes to 퐴 ′ = 퐴− 푞 ℓ , 퐿 ′ = 퐿+ 푞 ℓ , 푈 ′ = 푈,(87) where primes indicate the updated state. Both creation paths open active listings and create or ensure the associated sell order at the listed quantity and minimum price. Approval follows the applicable listing workflow. Remaining listing and order quantities allow partial execution. A buy order requires an active listing, quantity no greater than its remaining units, and applicable access checks. Any supplied quote-version identifier is checked. Buyer funds are reserved according to Equation(19), subject to decimal precision and available balance. The Provider path rejects purchases by the user owning the listing, and both matching paths reject identical buyer and seller accounts. The checks apply to the account and ownership identifiers associated with the submitted transaction. The crossing checks are푝 푏 ≥ 푝 푠 for the Agent path and푝 푏 ≥ max푝 푠 , 푝 min ℓ for the Provider path. Together with Equations(20)–(21), these preserve푝 ∗ ≤ 푝 푏 . The listing-generated sell order has푝 푠 = 푝 min ℓ , so both paths use the same minimum price in that case. A positive match records the trade and reduces the remaining buy, sell, and listing quantities; holdings and payment change at settlement. Ownership and payment updates. For a trade backed by sufficient reserved seller units, settlement updates 푈 ′ 푠 = 푈 푠 − 푞 ∗ ,퐿 ′ 푠 = 퐿 푠 − 푞 ∗ ,(88) 푈 ′ 푏 = 푈 푏 + 푞 ∗ ,퐴 ′ 푏 = 퐴 푏 + 푞 ∗ .(89) The subscripts denote seller and buyer, giving 푈 ′ 푠 +푈 ′ 푏 = 푈 푠 +푈 푏 .(90) Settlement locks the relevant records, releases the needed buyer payment reservation, and posts the buyer-to-seller transfer. It creates or locates the buyer’s holding using the source right type and identifiers. The receiving holding preserves agreement and policy references. A transfer record identifies both holdings and the quantity, while the settlement record links the trade to its accounting transaction. A database transaction connects these updates within TokenBank. The Agent path blocks disputed trades and releases surplus payment reservations when a buy order is completed. The Provider path has its own settlement and reservation-release logic. State checks and settlement identifiers prevent supported retries from posting completed trades twice. Recipients after transfer. The recipient lookup follows source-agreement references to current positive holdings, including supported cross-tenant transfers. If no derived holding exists, the original investor is used with units corresponding to the agreement’s budget. Generated participant records retain the recipient account, tenant context, agreement, and asset identifier. Source links connect the receiving holding to the original investment without treating the resale payment as new publisher funding. Research Manuscript34 Nexilume ResearchNX-2026-002 For agreement푗at settlement time푡 푠 , its ideal holder fraction of total plan revenue, after the agreement-level integer allocation but before holder-level rounding, is 훼 푗,ℎ (푡 푠 ) = 푏 푗 (푡 푠 ) 10,000 푢 푗,ℎ (푡 푠 ) Í 푘∈H 푗 (푡 푠 ) 푢 푗,푘 (푡 푠 ) .(91) The ideal payment is푑 ∗ 푗,ℎ,푒 = 훼 푗,ℎ (푡 푠 )푅 푒 . Holder shares are converted to integer basis points before monetary allocation. The recipients are the holders selected at푡 푠 . Secondary-market experiments measuring order arrivals, execution rates, resale prices, and investment exit returns are outside the financing evaluation. C.4 Workload Accounting Let퐵 푡 be the operating budget and퐷 푡 the cost of serving all available demand in period푡. A divisible-work approximation admits 푋 푡 (퐵 푡 ) = min퐷 푡 , 퐵 푡 .(92) Here, served work is measured by its cost. The approximation can use fractional requests; greater funding increases service only while available demand exceeds the budget. The complete-request replay instead retains the original request order. For costs푐 푡,1 ,...,푐 푡,푛 푡 in period푡, define 푘 푡 (퐵) = max 푘 ∈ 0,...,푛 푡 : 푘 ∑︁ 푟=1 푐 푡,푟 ≤ 퐵 . (93) The case푘 = 0admits no requests. This selects the longest initial sequence fitting the daily budget and excludes later requests once the next one would exceed it. Across days, 푋(퐵) = ∑︁ 푡 푘 푡 (퐵) ∑︁ 푟=1 푐 푡,푟 .(94) Baseline and financed scenarios use푋 0 = 푋(퐵)and푋 1 = 푋(푎퐵)for푎 ≥ 1. Costs come from completed trace records, so the calculation is retrospective rather than an online predictor of output cost. Budgets reset daily by assumption, and푎is a specified budget multiplier. These definitions evaluate the amount of existing demand that can be served under each funding scenario. D Implementation Validation and Synthetic Accounting Tests This appendix evaluates whether TokenBank executes the contract and accounting rules described in the main text. Database experiments test transaction correctness and concurrent execution, while deterministic synthetic tasks test cash-flow conservation under controlled funding and failure conditions. Their contract-level assertions complement the service and economic outcomes measured by the model-driven studies. D.1 Transaction Correctness and Ledger Reconciliation The backend regression suite passes all 206 tests. A focused suite passes 20 gateway and source-routing checks, and a contract-specific suite passes seven experiments. These suites overlap with the regression tests and with previously exercised contract lifecycles; their counts are therefore not added as independent observations. The contract-specific experiments execute 80 business API calls against an isolated PostgreSQL database and record seven final accounting states. Participant identities and initial funds are controlled experimental inputs; subsequent economic operations use the implemented contract APIs. Validation links account-balance changes to wallet records, ledger entries, and cross-organization transactions. Monetary comparisons use exact six-decimal arithmetic. An independent decimal-arithmetic replay verifies 165 balance changes across 47 accounts, with no arithmetic discrepancies. Direct ledger association covers 103 entries. For credit-funded movements, the verified quantity is net position, defined as cash balance minus credit used. The five intermediate wallet-to-account funding changes are documented through their supporting wallet records. The validation therefore reports balance arithmetic and record association at their respective observation scopes. Table 3 summarizes the contract rules and assertions covered by these experiments. Research Manuscript35 Nexilume ResearchNX-2026-002 PublisherCurrent holderPlatform 0 10 20 30 40 50 60 70 Fixture USD Distribution of a 100 USD test receipt Initial reservePaid claimRemainingSecond claim unpaid 0 20 40 60 80 100 Fixture USD Full payment or rejection; no partial payout Isolated database settlements with synthetic funds; no observed customer receipts. Figure 10. Contract settlement in isolated database experiments: revenue allocation after a rights transfer (left) and dedicated-reserve payments (right). Controlled initial funds and synthetic revenue events exercise the corresponding ownership and funding rules. D.2 Recovery Semantics and Concurrent Execution Recovery tests cover bounded retries, session renewal, and a simulated 30-day idle interval. After an inconclusive health probe, a previously verified service remains degraded but eligible for routing. Services that were never verified, explicitly stopped, disabled, or definitively failed retain their respective routing restrictions. The simulated interval exercises elapsed-time state transitions under these routing rules. The concurrency experiment executes 760 operations across 19 scenarios at concurrency eight. No unexpected operation failures, ledger discrepancies, invariant violations, or deadlocks are observed. Eleven scenarios have 95th-percentile latency above the prespecified 1,500 ms budget; the largest measured value is 2,419.98 ms. Accounting assertions and latency are reported as separate measurements. The experiment uses one local Windows/Docker host while other experiments are active, so the measurements characterize this shared-host configuration. D.3 Continuous-Balance Financing Tests A separate synthetic workload tests financing without the daily budget resets used in the request-level replay. It contains 24 scripted tasks, each with three nominal calls costing USD 0.04, 0.06, and 0.05. The costs and task outcomes are specified inputs rather than public-benchmark measurements. The operator starts with USD 0.60, and financing supplies an additional USD 0.60 from a separately tracked investor. Only successful synthetic tasks generate receipts, set to 1, 1.5, 2, or 3 times the USD 0.15 reference task cost. A revenue right allocates 10% of gross receipts to the investor. An equal-funded loan control instead requires repayment of principal plus 1% at the end of the sequence. These terms are experimental assumptions, not market quotations. Each condition re-executes the task sequence under its available-cash constraint. Capital injections are excluded from contribution profit; investor receipts and outstanding obligations are recorded separately. The trajectories validate continuous cash-flow accounting under the specified funding and revenue-allocation terms. D.4 Per-Claim Protection Tests The protection tests exercise per-claim payment and reserve accounting. The parameters are a USD 0.10 cap per claim, a USD 0.20 initial reserve, and a USD 0.01 premium per covered synthetic task. A claim is paid in full up to its cap or rejected when available reserve funds are insufficient; partial payment is not assumed. Scripted incidents include timeout, rate limiting, primary-path outage, and common-path outage. Tool errors and incorrect answers are excluded from coverage. Recovery-enabled conditions permit one alternate attempt. A residual covered failure requests USD 0.15 before application of the claim cap. These eligibility assignments are controlled inputs, not coverage labels inferred from BurstGPT. The trajectories test payment and reserve accounting; actual API claim validation is assessed separately by the PostgreSQL experiments above. D.5 Factorial Accounting Checks The synthetic workload also crosses the eight combinations of forwards (퐷), financing (퐹), and protection (푆) with recovery enabled or disabled and four receipt multipliers, yielding 64 conditions. Eight equal-funded loan Research Manuscript36 Nexilume ResearchNX-2026-002 05001000150020002500 p95 operation latency (ms) core prepaid enterprise credit ledger funding liquidity structured price lock structured derivatives agent financing agent exchange sla protection provider financing provider exchange enterprise credit capture agent marketplace billing data marketplace billing provider micro accrual cross organization settlement idempotency stampede exact balance exhaustion opposing transfers PostgreSQL: 40 operations per scenario, concurrency 8 Prespecified 1,500 ms budget 760 operations; no unexpected failures; 11 scenarios exceed the latency budget. Figure 11. Concurrent transaction latency across the 19 tested scenarios. The reference line marks the prespecified 1,500 ms budget; red bars indicate scenarios above that budget. 1.001.251.501.752.002.252.502.753.00 Assumed revenue / reference task cost 4 6 8 10 12 14 Completed fixture tasks Own capital 1.001.251.501.752.002.252.502.753.00 Assumed revenue / reference task cost −1 0 1 2 Contribution profit (fixture USD) Equal-capital loan Revenue right Synthetic tasks: continuous balances without daily resets Synthetic task sequences with continuous balances. Figure 12. Financing outcomes for synthetic task sequences with continuous balances. Scripted task counts and contribution quantify the accounting effects of the specified funding and receipt assumptions. controls bring the total to 72. Event-level cash flows are recorded for every condition, and conservation is checked across the operator, investor, reserve, service-receipt accounts, and assumed customer payer. These checks validate cash-flow conservation across combined financial operations, using a synthetic population separate from the model-driven task studies. Research Manuscript37 Nexilume ResearchNX-2026-002 0246810 Eligible claim sequence 0.000 0.025 0.050 0.075 0.100 0.125 0.150 Reserve after attempt (fixture USD) 0246810 Eligible claim sequence 0.00 0.02 0.04 0.06 0.08 0.10 Unpaid eligible amount (fixture USD) No recovery Recovery Synthetic claims: capped compensation and full-payment checks Synthetic claim sequences with per-claim limits and finite reserves. Figure 13. Reserve balances and payment outcomes in deterministic protection tests. Each submitted claim is checked against its cap and available funds. The horizontal axis indexes eligible claims separately for each condition: 12 without recovery and 3 with recovery. E Controlled Agent Evaluation: Experimental Design The controlled study isolates the effects of financing, recovery, and protection within a tractable service workflow. It uses real model inference and executable business tools, while fixing customer requests, local business records, and economic assumptions. The task split, completion criteria, parameter-selection rules, and treatment structure were specified before evaluation. The tool interface was finalized during calibration, as described below. Completed outcomes are reported in Appendix F, with controlled and retail outcomes reported under their respective study denominators. E.1 Workload and Completion Criteria Each task combines a fixed customer request, constructed local business records, Qwen/Qwen3-8B inference through Nexus and SiliconFlow, and callable business tools. Neither a model-driven customer nor a model-based judge is used. A task generates a receipt only when the requested operation and its final output both satisfy the completion rule. Table 9. Controlled task families and completion criteria. Each family contains three calibration tasks and four evaluation tasks. FamilyModel-directed operationCompletion criterion ExtractionExtract a reference, quantity, and city; sub- mit the record Submitted fields and final JSON match the request. Order lookupInvoke the order-lookup toolThe requested order is retrieved and final JSON matches its state. Product selectionQuery the catalog; select and quote an itemThe quoted item is the cheapest eligible in-stock item; quantity, total, and final JSON are correct. The workload contains 21 tasks: nine for calibration and 12 for evaluation, with distinct identifiers and business records. Initial ordering is determined by SHA-256 hashes of task identifiers. The shared-template design targets these task families. Every scheduled case remains in its study denominator, including errors and funding-admission stops. The model configuration uses temperature zero, disabled thinking, a 512-token output limit, and per-task limits of six logical requests, 18 physical requests, and 600 seconds. A logical request is an intended model call; its retries count as additional physical requests. The first response must invoke a tool; subsequent responses may invoke tools or finish the task. Separate executions retain the variability of remote inference at this configuration. E.2 Calibration and Workflow Configuration Before economic parameters are fixed, all nine calibration tasks must reach a terminal outcome, at least two of the three tasks in each family must succeed, and returned usage must reconcile with Nexus records. This criterion establishes workload readiness before the economic parameters are fixed. Research Manuscript38 Nexilume ResearchNX-2026-002 Two calibration passes use the same nine task identifiers, business records, split, and initial ordering. The final interface enumerates valid category codes and exposes dependent operations in the order catalog lookup, quote creation, and final output. This configuration is selected using calibration tasks; the model selects the product and supplies its own responses. Evaluation tasks are first executed after calibration is complete. The resulting study evaluates a calibration-informed, constrained service workflow. Appendix F.1 reports both calibration passes and their measurements. E.3 Measurement and Operating-Capital Model Returned input and output token counts and request latency are measured. Under the economic-valuation conventions in Section 8.1, each request is assigned the following laboratory expense at the supported precision: 푐 푖 = round 10 −6 100푛 in 푖 + 500푛 out 푖 10 6 ! .(95) Here 푛 in 푖 and 푛 out 푖 are returned token counts. Amounts are in experimental USD. The prespecified scale makes small-task losses representable at cent precision; fees, rounding, and coverage are interpreted at this fixed scale. Requests with unknown usage retain their reservations under the stated cost-bound convention. Let휇be the mean known calibration expense per scheduled task and퐻 cal the largest conservative single- request reservation observed during calibration. Reservations are derived from the serialized UTF-8 payload, a framing allowance, and the maximum output allowance. The operating parameters are 퐵 = 휇+ 퐻 cal , 퐴 = ⌈4휇⌉ 0.01 , 푟 = 2휇,(96) where퐵is initial operator capital,퐴is additional funding,푟is the receipt per successful task, and⌈·⌉ 0.01 rounds up to cents. These symbols follow Table 2. Receipts are paid after every four scheduled tasks; denied tasks still advance this schedule. Balances evolve continuously and never reset between tasks. The revenue-right condition allocates receipts as 89% to the operator, 10% to the investor, and 1% to the platform through the implemented accounting procedures. Funding principal is excluded from contribution; interim investor transfers and outstanding rights are tracked separately. Changing receipts on an already observed trajectory provides a conditional accounting sensitivity. An operational comparison requires fresh execution whenever the change can affect task admission. E.4 Treatments and Outcome Measures Financing. Own-capital, equal-capital, and revenue-right portfolios each execute the 12 evaluation tasks. The equal-capital control separates the benefit of additional available funds from the cost of sharing revenue. Outcomes include completed services, admission stops, continuous balances, operator contribution, and investor cash flow. Known operator contribution is retained customer receipts minus known inference expense; injected capital is excluded, and unknown expense and outstanding receivables are reported separately. Productive growth requires both additional completed services and positive incremental contribution, rather than contract approval alone. Recovery and protection. Four additional portfolios cross own-capital or revenue-right financing with recovery disabled or enabled. Their ample operating capital,100휇+ 퐻 cal , separates recovery from a binding funding constraint. A fixed schedule injects timeout, rate limiting, primary-path outage, or common-path outage before the second logical Agent request. Recovery uses an alternative local path while holding the model and supplier fixed. The measured recovery scope is therefore local-path continuation. Incident reachability, subsequent responses, and completed services are distinct outcomes. Protection is applied to the same execution trajectory without changing task completion or operating capital. Only covered terminal injected failures generate claims; incorrect answers do not. Eligible loss is known incurred laboratory expense rounded down to cents. The claim cap is퐿 = max(0.01,⌈휇⌉ 0.01 ), the premium ismax(0.01,⌈0.01휇⌉ 0.01 ), and the funded and scarce reserves are12퐿and퐿. The contract API determines approval, rejection, and settlement, including funding checks. Payments are service credits, not cash or replenishments of operating capital. Requested, approved, paid, and unpaid amounts and the remaining reserve are reported separately. Forwards. Contracts are approved before evaluation, with strike one, zero discount, and calibration-fixed notional푁 ℎ = 12휇ℎforℎ ∈ 0.25, 0.50, 0.75, 1. The no-contract control usesℎ = 0. Terminal indices Research Manuscript39 Nexilume ResearchNX-2026-002 퐼 ∈ 0.5, 1, 1.5are assumed price scenarios rather than market observations. The contract fee rate is 0.012. Fees, both counterparties’ settlements, and unpaid amounts are reconciled to API records. Conditional expenditure applies scenario prices to realized demand, subtracts signed forward payments, and adds fees. Realized demand may differ from the calibration notional; applying prices after execution does not change the observed admission decisions. Combined comparisons and pairing. The seven execution arms produce 84 scheduled task–arm cases. A fixed pseudorandom schedule varies arm order within each task. Combinations of forwards (퐷), financing (퐹), and protection (푆) reuse a trajectory only when the financial operation cannot alter available operating funds or recovery. Financing and recovery changes therefore require distinct executions. Protection-adjusted service value is distinguished from cash contribution. One chronological portfolio per arm defines the unit for descriptive comparison. E.5 Verification and Scope of Inference Request identifiers link outcomes and token usage to contract operations and ledger changes. Contract operations use authenticated business APIs on a dedicated PostgreSQL database. Independent decimal accounting checks amounts and balances exactly; effectiveness results require successful reconciliation. Restart handling preserves completed operations and settled claims, while incomplete interruptions remain visible. Seven offline checks assess the workload implementation separately from the model-driven effectiveness measurements. Table 10. Measurement scope of the controlled evaluation. ComponentMeasurement and interpretation Model and tool executionResponses, returned usage, and completed operations are observed on the controlled task set. Business records and faults Constructed records and local fault schedules define the controlled execution conditions. Prices and receiptsExperimental tariffs, success-triggered receipts, and terminal price indices define the scenario valuation. Contract settlementAccount changes and service-credit payments are observed in isolated database experiments and reconciled independently. Study populationFixed task families define the repeated-study population; calibration, con- trolled evaluation, and retail cohorts retain separate denominators. F Supplementary Evaluation Methods and Results This appendix provides the workload definitions, cohort-specific results, and sensitivity analyses supporting the main evaluation. The organization follows the three financial mechanisms and their combined accounting. Request replay characterizes expenditure under specified scenarios, model-driven execution measures service and capital outcomes, and synthetic contract tests validate accounting rules. Each study retains its own population and measurement scope, as defined in Section 8.1. F.1 Workloads, Calibration, and Measurement Table 1 summarizes the evaluation cohorts. The protocols below specify their selection, execution, and accounting rules. Calibration and development attempts are reported separately from evaluation outcomes. F.1.1 Request-Level Replay Data and pricing. We use the first two months of BurstGPT [14], with the dataset version recorded in the supplementary artifact. Removing conversation records and the incomplete final day leaves 1,261,858 API requests. Days 0–17 provide 362,417 calibration requests, and days 18–59 provide 899,441 evaluation requests. Replay preserves timestamps, model labels, token counts, and original request order. All requests remain in the offered workload, although budget-constrained conditions may admit only a subset. No arrivals or duplicate requests are added. Research Manuscript40 Nexilume ResearchNX-2026-002 The reference tariff is $3 per million input tokens and $15 per million output tokens, yielding $3,395.80116 for successful first-attempt requests. This amount is a reference-tariff valuation. Of 16,137 zero-output records, 16,131 also lack input lengths. Zero output supplies the failure indicator; unobserved first-attempt charges use the same assumptions in paired conditions, and alternate-attempt lengths are estimated from calibration data. The trace supplies request timing and usage; task correctness and contractual coverage are assessed in the separate model-driven and contract studies. Matched conditions. The principal combined comparison fixes the offered requests, provides sufficient funding access, and models one alternate attempt after a primary failure. Only financial contracts vary. Separate experiments examine budget-limited service growth and changes in technical recovery. Forward comparisons hold requests, prices, and cache/batch settings equal; financing-cost comparisons hold the funded amount equal; protection comparisons hold the recovery policy equal. This matching isolates financial-contract effects from model selection, caching, and failover. Prices are scenario assumptions expressed relative to the reference tariff. The paths include a constant value of 1, linear changes from 1 to 1.3 or 0.7 over 42 days, a seven-day increase to 1.8, and an increase triggered by the preceding five-minute arrival count. Calibration defines bursts as 1,299 requests per five-minute window and long inputs by a 2,527-token threshold. Each paired baseline faces the same path. Financing and shared-failure stresses are examined separately; combined stresses describe joint outcomes rather than isolated mechanism effects. F.1.2 Controlled Agent Cohorts Calibration and initial study. The controlled workload contains 12 evaluation tasks: four each for structured extraction, order lookup, and constrained product selection. It uses Qwen/Qwen3-8B through Nexus and SiliconFlow, constructed business records, and controlled local faults, without a customer-simulation or judge model. Appendix E defines its completion criteria and treatment structure. The first calibration pass succeeds on 3/3 extraction tasks, 3/3 lookup tasks, and 1/3 selection tasks; all 23 responses match Nexus records. The second pass uses the explicit category codes and dependency-ordered interface described in Appendix E. All nine tasks succeed, and all 21 responses reconcile exactly. Task identifiers, records, split, and initial ordering are unchanged. The final workflow is selected using these calibration observations before any evaluation-task model calls. Both passes retain their measurements and separate calibration status. The initial study completes all 84 scheduled task–arm cases, with 51 successful services and 150 responses from 150 physical requests. Usage is available for every returned response, totaling 49,086 input and 5,323 output tokens. Median client request latency is 4.53 seconds, including network effects. Monetary valuation follows the prespecified laboratory tariff of 100/500 experimental USD per million input/output tokens and the assumed business receipts defined in Section 8.1. Calibration fixes휇 = 0.127689,퐻 cal = 0.943300, 퐵 = 1.070989,퐴 = 0.52, and푟 = 0.255378. Receipts are delayed until each block of four scheduled tasks, and balances never reset between tasks. Capital effects therefore depend on the request-reservation policy as well as the laboratory tariff. Each arm provides one chronological portfolio for descriptive comparison. Repeated portfolios and parameter sensitivity. A protocol fixed before inference specifies five separately executed portfolios with randomized orders of the same 12 controlled tasks. Each compares own capital, equal capital, and revenue rights, together with recovery enabled or disabled under ample own capital. Seven additional portfolios vary one financing factor at a time, and three vary fault frequency. Accounts are isolated, model responses are newly obtained, and completion rules and calibration remain fixed. The repeated-task design measures financial outcomes under controlled operating conditions. All 624 scheduled cases reach a terminal outcome. The 1,247 physical requests yield 1,246 responses and 487 successful services. There is one request with unknown returned usage, 39 funding-admission stops, no infrastructure interruptions, and 98 terminal injected-fault failures. Available response usage matches Nexus records, totaling 436,701 input and 43,028 output tokens. Unknown usage is handled by the reservation bounds below. Admission uses input-byte and maximum-output reservations, with unused amounts released after measured usage is known. The median reservation-to-measured-charge ratio of 12.0153 characterizes the advance-funding requirement in this study. Missing-usage accounting. A request without returned usage retains its reservation, making those funds unavailable to later tasks. Let퐻 푢 be the unresolved reservation,퐶 known known expense, and푌 ret retained Research Manuscript41 Nexilume ResearchNX-2026-002 portfolio receipts. Under the reservation bound, feasible contribution lies in [푌 ret − 퐶 known − 퐻 푢 , 푌 ret − 퐶 known ].(97) Treatment-minus-control bounds subtract the upper control endpoint from the lower treatment endpoint, and conversely. Known-expense contribution and the interval covering unresolved usage are reported separately. For the earlier repeated-portfolio cohort, these bounds are a retrospective analysis of the unresolved request in the second portfolio. The execution protocol, task list, and recorded outcomes are unchanged, and all affected portfolios remain in that cohort. The same accounting rule is prespecified for the subsequent capital replication. Matched capital replication. A separate five-block protocol was fixed after inspection of the earlier single- portfolio boundary results but before collection of its own observations. Each block freshly executes own-capital, equal-capital, and revenue-right arms at initial capital0.5퐵,퐵, and1.5퐵, giving5× 3× 3× 12 = 540scheduled cases. Each block shares task order and randomized within-task arm order across capital conditions; capital- condition order is randomized separately. Calibration, model, tariff, receipts, delay, and reservation policy remain unchanged. The fixed randomization seeds are recorded in the supplementary artifact. The replication records 1,082 physical requests, 1,081 responses, 456 successful services, 84 admission stops, one request with unknown usage, and no infrastructure interruptions. Every scheduled case has an outcome. Contribution excludes principal and bounds unresolved usage rather than assigning zero cost. Exploratory 95% percentile envelopes jointly resample the five matched blocks across conditions using 10,000 draws. Repeated economic portfolios are the sampling units. The earlier incident-affected study retains its separate observations and denominator. F.1.3 Retail Task Studies Environment and task selection. The retail studies use a fixed version of the official text environment of 휏 2 -Bench [3]; its revision is recorded in the supplementary artifact. SHA-256 ordering partitions 114 tasks into 22 calibration and 92 evaluation tasks. The baseline takes the first five evaluation tasks, each twice, with selection fixed independently of pilot rewards. These identifiers also appear in preliminary integration trials. The baseline is a repeated evaluation of this custom subset, with its prior integration exposure recorded separately from task selection. The official instructions, tools, and ALL completion criterion are used. All model roles employ Qwen/Qwen3- 8B through Nexus and SiliconFlow. The customer is model-driven, with no scripted responses substituted. Applicable model-based evaluator checks use the same model, rather than the upstream default judge. Execution limits. Execution is serial, with temperature zero, thinking disabled, a 2,048-token output cap per request, 30 requests per role per task, a 600-second between-call deadline, 60 orchestrator steps, and a limit of 10 consecutive tool errors. Transport timeouts are bounded by the remaining task time. Transient transport, routing, rate-limit, and server failures permit at most three physical requests per logical call, with two- and four-second backoff. Each physical request consumes the request limit and has a distinct identifier; uncertain prior usage remains unknown. Tools execute only after a complete response and are not replayed. Authentication is renewed before requests at 20-minute intervals. Baseline outcomes and reconciliation. The baseline records ten attempted trials: nine receive an official score, four succeed, and one is unscored. Across all attempts, 368 requests yield 360 responses; eight have no usage in a completed client response. Seven logical calls require retries, all of which eventually return a complete model response, and three authentication renewals are recorded. These are naturally observed incidents rather than randomized treatment effects; usage of preceding failed attempts remains unknown. For operational success across all attempted trials, 10,000 bootstrap draws over task means give a descriptive 95% percentile interval of [10.0%, 70.0%]. Repetitions remain within task clusters. Operational success counts completed successful tasks; unscored trials retain missing official rewards, and tool outcomes remain in the recorded trajectories. All 360 returned responses link to successful gateway records, with exact agreement in token counts, selected source, and configured wallet charges. Conditional financial analyses apply the assumed 1/5 input/output tariff per million tokens to returned Agent usage under the measurement conventions in Section 8.1. Simulated-customer and evaluator usage enter the experimental budget separately from operator expense; unresolved usage retains its accounting bounds. Research Manuscript42 Nexilume ResearchNX-2026-002 Table 11. Real fixed evaluation model usage by role. Simulated-user and evaluator costs belong to the experimental budget rather than Agent operating expenditure. Latency covers returned responses; task duration also includes failed attempts and retry delays. RoleResponses Input tokens Output tokens Mean latency (s) Agent2371,658,41713,7969.87 Simulated user121157,6227,0099.49 Evaluator29,6041804.19 AgentSimulated userEvaluator 0 250 500 750 1000 1250 1500 1750 Observed tokens (thousands) Input Output 26/026/125/025/172/072/121/021/1 108/0108/1 Task ID / repetition 0 50 100 150 200 Agent tokens (thousands) Green: success; red: task failure; gray: unscored Observed model responses and task outcomes; supplier invoices unavailable. Figure 14. Retail baseline token usage and task outcomes. Repeated attempts are paired by task identifier; task success follows the official completion rule. Retail contract interventions. The contract study schedules 70 cases: ten previously unexecuted retail tasks, each in seven execution arms. Independent calibration uses five tasks twice each. Within-task arm order follows a fixed pseudorandom schedule. Every scheduled outcome is retained, and each arm constitutes one chronological economic portfolio. At the assumed 1/5 input/output tariff, known calibration Agent cost per attempt is휇 = 0.184298. The initial balance is퐵 = 휇, additional capital is퐴 = ⌈2휇⌉ 0.01 = 0.370000, and the success receipt is2휇 = 0.368596 experimental USD. Balances evolve continuously. Before each physical Agent request, a conservative reservation covers the UTF-8 prompt bound and output allowance. Returned usage determines the charge and release of unused funds; unknown usage retains its hold. Simulator and judge expenses are separate, and principal is not revenue. Contract approvals, funding checks, and transfers use authenticated business APIs on isolated PostgreSQL accounts with disclosed initial funds. Actual inference passes through Nexus and SiliconFlow, and returned usage is reconciled to gateway requests. A fixed task-specific schedule injects local faults before the third logical Agent request. The study measures contract and execution outcomes under this controlled local-fault schedule and the declared economic assumptions. Table 12. Outcomes of all prespecified task attempts under the official completion rule. Tool-error counts and total evaluation time are reported separately. Task/repetition Outcome Tools (errors) Agent tokens Seconds 26/0Success10 (2)140,455373.7 26/1Success10 (2)128,610247.7 25/0Success10 (4)126,529385.0 25/1Unscored17 (6)223,946600.0 72/0Failure10 (9)197,961515.1 72/1Failure14 (6)147,962314.7 21/0Failure18 (9)225,862518.2 21/1Success15 (5)187,367436.2 108/0Failure12 (10)145,018245.5 108/1Failure9 (3)148,503328.1 Research Manuscript43 Nexilume ResearchNX-2026-002 Pinned retail tasks Official tools and evaluator Nexus gateway SiliconFlow / Qwen3-8B Observed evidence Outcome, tokens, latency Conditional economics Assumed prices and revenue Isolated contract APIs Transfers, approvals, claims Accounting evidence Receipts and balance proofs Separate evidence streams: measured tasks do not imply actual customer revenue. Live calls and database fixtures are measured separately; economic inputs remain assumptions. Figure 15. Measurement organization connecting model-driven execution, database contract experiments, and scenario- based economic valuation. All 70 cases terminate, with 54 reaching an Agent request. Of 23 officially scored cases, one succeeds. The remaining 47 are unscored: 24 encounter funding-admission stops, 20 terminate at injected incidents, and three reach task-resource limits. Calibration separately yields nine scored failures and one unscored attempt without changing task selection. The study obtains 925 complete responses from 930 physical requests, all reconciled to gateway records. Five requests have unknown usage, with their reservations reported separately from known expense. These outcomes use the intervention cohort’s own task population and denominator. F.2 Forward Settlement, Price Mismatch, and Risk Decomposition The analyses support Section 8.3 by reconciling settlements on measured Agent demand and quantifying expenditure responses to price paths, funding availability, and contract-to-bill alignment. F.2.1 Settlement on Measured Agent Demand Controlled workload. All 84 forward contracts in the initial controlled cohort reconcile in signed payment, fee, and settlement count. Contracts are approved before evaluation with zero discount and calibration-fixed notionals. Declared terminal-price scenarios are applied to measured demand, with the same trace retained in the no-contract control. This pairs actual settlement execution with conditional expenditure analysis. Figure 16. Conditional expense versus hedge ratio on the own-capital recovery trajectory under the declared terminal-price scenarios. Retail workload. Before any intervention task, we form zero-discount contracts at strike one with notionals ℎ푛휇,ℎ ∈ 0.25, 0.5, 0.75, 1and푛 = 10. The 84 arm–hedge–index contracts use declared final indices 0.5, 1 and 1.5; these are scenarios, not observed provider price changes. Settlement occurs after the workload within the ten-day validity window, leaving the observed task-admission decisions unchanged. A separately recorded 1.2% experimental fee is transferred through the ledger. Both counterparties use adequate disclosed test funds. Research Manuscript44 Nexilume ResearchNX-2026-002 0.00.20.40.60.81.0 Calibration-fixed hedge ratio 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 Conditional expense (experimental USD) Index 0.5 Index 1 Index 1.5 Figure 17. Zero-discount forward comparison on the recovery-enabled own-capital arm’s measured returned demand. Calibration-fixed notionals and declared price indices determine actual API settlements and fees, which enter the conditional expenditure calculation. 0.51.01.52.02.53.0 Assumed price/index multiplier 0 1 2 3 4 5 Conditional expenditure (currency units) Matched movement h=0 h=0.5 h=1 0.51.01.52.02.53.0 Assumed price/index multiplier −3 −2 −1 0 1 2 3 Conditional expenditure (currency units) Output-only price movement h=0 h=0.5 h=1 Assumed tariffs applied to observed returned Agent usage. Figure 18. Paired forward scenarios applied to measured returned Agent usage. Declared price and notional scenarios compare matched and output-only movements to characterize settlement alignment with operating expense. Actual API settlements are compared exactly withℎ푛휇(퐼− 1)and both account balances, one settlement per contract. The zero-hedge and nonzero-hedge controls use measured returned demand, allowing realized usage to vary relative to the calibration notional. The associated block-resampled analysis characterizes the declared price-path scenarios. F.2.2 Expenditure Sensitivity and Exposure Mismatch Conditional expenditure on the retail baseline. For identical measured demand in each price scenario, let 퐶 푠 denote its conditional cost,푃 푠 the signed paid settlement, and푓the fee. Then퐶 퐷 푠 − 퐶 푠 = 푓 − 푃 푠 . The scenario analysis of the ten-trial retail baseline uses zero strike discount, hedge ratios 0, 0.25, 0.5, 0.75 and 1, and a declared nominal exposure of 0.25 per scheduled attempt, varied by factors 0.5, 1 and 1.5. This is an exposure sensitivity, not a forecast fitted to evaluation outcomes. We compare matched price/index movement, output-only price movement, and an unchanged index. Under full settlement, a unit-strike forward with a 1.2% nominal fee reduces expenditure above an index of 1.012. This threshold identifies the price movement needed to offset fees. Buyer and seller funding stresses report paid and unpaid obligations separately; the BurstGPT block analysis supplies the corresponding conditional path-risk measures. Payments under matched execution. The reference forward covers 80% of the calibration-mean daily expenditure, with fees and holding-period funding charges of 1% and 0.2% of the contracted amount, respectively. Contract prices assume zero or 10% discount. Under constant prices and the assumed 10% discount, modeled expenditure falls by $155.39 (4.58%). The contract covers about 52% of realized base expenditure, explaining why the reduction is smaller than the assumed discount. The buyer receives $176.58 Research Manuscript45 Nexilume ResearchNX-2026-002 from the seller and pays $21.19 in fees and funding charges. With no discount, expenditure instead increases by 0.62%. The financial effect complements execution optimization. Under identical assumed cache and batch eligibility, ordinary optimization reduces the unhedged invoice to $2,418.20. Adding the discounted forward reduces expenditure by a further $113.04 (4.67%). The ordinary optimization uses 25% batch-cost eligibility, 40% input-cache hits, and 5% cache writes, with a 50% batch discount and input-price multipliers of 0.1 for cache hits and 1.25 for writes, applied identically in both arms. Its separate $977.60 saving is attributed to caching and batching. An ordinary forward with identical terms gives the same payment, serving as an arithmetic consistency control for the financial calculation. Price and demand mismatch. With otherwise unchanged contract settings, gradually rising prices reduce buyer expenditure by 11.39%, while gradually falling prices increase it by 3.53%. These paths differ from the constant-price sensitivity: keeping the price 30% below the reference throughout evaluation increases discounted forward expenditure by 15.75%. The cases must not be interpreted as the same price treatment. Actual purchases use each request’s five-minute price, whereas settlement uses the daily average of the reference prices. This difference, together with forecast usage errors, prevents a contract from exactly offsetting the bill. For example, the burst/long-input class has $4.02 of reference expense against approximately $83.53 of committed notional. Its stable-price net benefit of $7.35 reflects contractual exposure exceeding realized demand. These class allocations are analytical portfolio breakdowns, with settlement scaled by the committed notional. 0.00.51.01.5 Hedge / forecast (above 1 is leveraged) −5 0 5 10 15 20 Net cash reduction (%) Hedge-ratio sensitivity; assumed 10% discount flat rise fall spike 0.60.81.01.21.4 Multiplier on fixed demand forecast 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4 Terminal price / base Forecast bias x price path −20 −15 −10 −5 0 5 10 15 20 Net cash reduction (%) Figure 19. Forward expenditure sensitivity to the covered amount, forecast error, and assumed price path. Exposure scales the signed settlement while the executed workload remains fixed. The forecast comparison uses only preceding days. Predictions use the fixed calibration mean, the mean of all preceding days, the mean of the preceding seven days, or the value seven days earlier. Their weighted absolute percentage errors are 78.70%, 103.77%, 97.75%, and 142.23%, respectively; this metric divides total absolute prediction error by total actual expense. Figure 19 varies the covered amount and forecast bias explicitly. These measurements quantify the forecast and exposure ranges used in the contract-to-bill sensitivity analysis. F.2.3 Variance Decomposition Forℎ = 1, matched reference, unscaled forecast, and funded settlement, the 1,000 paired paths yield Table 13. Here푍is signed settlement net of charges and퐶 0 is unhedged expenditure, as in Equation(47). Sample moments use denominator푛− 1. Variance and covariance columns use USD 2 ; the final column is the paired change in mean expenditure in USD. The post-hoc decomposition relates net-payment variation and covariance to the measured expenditure response. Research Manuscript46 Nexilume ResearchNX-2026-002 Table 13. Mechanism of risk changes in conditional resampled paths. Negative variance change is favorable; mean expenditure and variance are distinct outcomes. ScenarioVar(푍) 2 Cov(퐶 0 , 푍)Δ Var ΔE[퐶] flat0.00.0+0.0 +26.49 rise4522.5-85383.2 +89905.7 -304.88 fall4522.593585.4-89063.0 +357.85 spike47158.8-80862.3 +128021.1 -304.10 lagged-load0.2413.1-412.8 +25.08 F.3 Capital Constraints and Financing Sensitivity The matched capital replication is the principal financing comparison. Supporting studies examine repeated controlled portfolios, individual parameter changes, retail tasks, and request-level replay. Together, they characterize financing effects across operating conditions, with the largest matched-capital benefit observed under capital scarcity. Each cohort retains its observations and denominator. F.3.1 Matched Capital Replication Admission and matched-capital outcomes. At0.5퐵, revenue-right financing reduces mean admission stops from 12.0 to 1.8 and raises mean contribution by 1.0635 experimental USD, with positive contrasts in all five portfolios. Own-capital and revenue-right admission stops are 1.4/0.0 at퐵and 0.0/0.0 at1.5퐵. Table 14 reports all capital contrasts, missing-cost bounds, and exploratory whole-block resampling ranges. Capital levels were selected from the earlier boundary experiment, and the replication protocol was fixed before its own observations. Interpretation follows the portfolio-level sampling convention in Section 8.1. Matched capital sensitivity and investor cash flows. The fifth matched block at1.5퐵includes an equal-capital task that succeeds after a retry following an upstream server error. The unresolved usage of the earlier request retains a 0.883600 reservation. Its contribution contrasts use the prespecified cost-bound accounting rule. The low-minus-baseline difference in the financing-versus-own-capital contribution contrast has mean 1.2041 and exploratory matched-block envelope [0.9975, 1.4106]. The ample-minus-baseline difference in the financing-versus-own-capital contribution contrast has mean -0.1556 and exploratory matched-block envelope [-0.2587, -0.0524]. The investor contributes 0.5200 and receives mean wallet transfers of 0.2540 at low capital and 0.3000 at baseline and ample capital. Accrued entitlements and rounding remainders are tracked separately. These are observation-window cash flows with rights still outstanding, using the scope defined in Section 8.1. The separate repeated-portfolio study below retains its incident-affected portfolio and unresolved-usage bound. The capital replication adds matched evidence under the same tariff and reservation conventions. Reservation-policy dependence. The 1,081 requests with returned usage have reservations ranging from 0.545800 to 0.943300 experimental USD, with a median reservation-to-known- charge ratio of 12.4382. The Table 14. Contribution contrasts in the matched capital replication. The mean column reports missing-usage bounds where non-degenerate. The envelope is the exploratory whole-block 95% resampling range, not another bound on a single missing request. The last column counts definitely positive/negative blocks out of five. Units are experimental USD; principal and credit are excluded. Capital ContrastMean / cost bound Resampling envelope +/− blocks 0.5퐵 Right–own1.0635[0.9506, 1.1786]5/0 0.5퐵 Right–equal-0.3049[-0.3324, -0.2806]0/5 0.5퐵 Equal–own1.3684[1.2642, 1.4894]5/0 퐵Right–own-0.1406[-0.2657, -0.0155]2/3 퐵Right–equal-0.3174[-0.3507, -0.2835]0/5 퐵Equal–own0.1769[0.0506, 0.3138]4/1 1.5퐵 Right–own-0.2962[-0.3294, -0.2632]0/5 1.5퐵 Right–equal [-0.2742, -0.0975][-0.2965, 0.2676]0/4 1.5퐵 Equal–own [-0.1987, -0.0220][-0.5741, 0.0000]0/2 Research Manuscript47 Nexilume ResearchNX-2026-002 low-capital opening balance is 0.535495. These returned-usage records characterize the tested advance-funding requirement relative to the opening balance. Their population excludes rejected-request reservations; financing outcomes are interpreted under this fixed reservation policy. F.3.2 Repeated Controlled Portfolios Whole continuous portfolios are the replication units because their tasks share operating funds. All five paired differences are reported. Exploratory 95% envelopes use 10,000 paired-portfolio draws and the lower 2.5th and upper 97.5th percentiles of the mean cost bounds. Without missing usage, this reduces to percentile resampling of the observed contrasts. Remote-model variation, provider incidents, and their effects on later admission remain part of each realized portfolio outcome. Table 15. Fresh portfolio contrasts. An asterisk identifies financing arms with unplanned request errors or missing usage. Brackets bound unresolved usage under the reservation limit. Recovery compares local recovery with none. Monetary values are experimental USD. Portfolio Own tasks Right tasks Δ tasksΔ profit Recovery Δ tasks 111121-0.16709 2*91-8 [-2.1573, -1.2153]9 312120-0.30659 4101220.06329 510122-0.07999 Revenue-right minus own-capital contribution has known-expense mean -0.3411, mean cost-bound range [-0.5295, -0.3411], and exploratory portfolio envelope [-1.3612, -0.0394]. Revenue-right minus equal-capital contribution has known-expense mean -0.5855, mean cost-bound range [-0.7739, -0.5855], and exploratory portfolio envelope [-1.7097, -0.2845]. Local recovery adds nine completed services in every one of the five portfolios, providing consistent descriptive outcomes under the fixed local-fault schedule. Figure 20. Every observed whole-portfolio contrast. Whiskers bound unresolved usage under the reservation limit; dashed lines are known-expense means, not task-level confidence estimates. Research Manuscript48 Nexilume ResearchNX-2026-002 F.3.3 Income, Capital, and Receipt-Delay Sensitivity Seven cells change one factor relative to the first repeated portfolio: receipt multiples 1/1.5/3 (baseline 2), own-capital multiples 0.5/1.5 (baseline 1), or receipt delays 1/6 tasks (baseline 4). Additional investor capital stays fixed. All tasks are executed again, so funds affect admission and completion rather than being applied to copied successes. The same task order is used across boundary cells. Each cell is one descriptive scenario portfolio. Contribution excludes initial capital, and outstanding rights are accounted for separately. Table 16. Fresh financing boundaries: completed service counts and contribution differences. The profit difference compares revenue rights with own capital. Equal funding isolates capital availability from the investor share. ConditionOwn Equal Right Δ profit Right–equal Baseline111212 -0.1670-0.3065 Receipt multiplier 1101212 -0.1826-0.2081 Receipt multiplier 1.5111212 -0.2085-0.2298 Receipt multiplier 3111212 -0.2487-0.4597 Capital multiplier 0.501111 1.1919-0.2277 Capital multiplier 1.5121212 -0.3065-0.2516 Delay (tasks) 1121212 -0.3082-0.3065 Delay (tasks) 6101212 -0.1478-0.3065 At the 0.5 capital multiplier, financing completes eleven additional services and raises contribution by 1.1919 experimental USD. This is the one of eight displayed conditions with a positive lower-bound contrast. The scenario grid identifies the dependence on capital, receipts, and delay; the subsequent matched replication evaluates the low-capital condition across five portfolios. Figure 21. Financing can change service completion and retained contribution differently. Each bar is a fresh scenario comparison. F.3.4 Initial Controlled Financing Study Table 17. Fresh financing executions; 12 scheduled tasks per arm. All monetary values are experimental USD. Profit excludes capital injection and uses known expense. ArmSuccess Budget stop Expense Retained Profit Own capital93 1.16922.2754 1.1062 Equal capital120 1.47493.0339 1.5590 Revenue right120 1.47492.7274 1.2525 Research Manuscript49 Nexilume ResearchNX-2026-002 Table 18. Fresh financing interventions. Money is in experimental USD; receipts and tariffs are assumptions. Capital injections are excluded from contribution profit. Arm Scored Successes Budget stops Known cost Held funds own109 0.147368 0.000000 equal406 0.515037 0.000000 right009 0.342738 0.172938 Relative to own capital, the revenue-right arm completes +3 additional services and changes known-cost operator contribution by 0.1463 experimental USD. The equal-capital arm identifies the effect of the same capital availability without the investor’s revenue share. These realized portfolio contrasts quantify the additional service and retained contribution under the initial study’s capital, tariff, and receipt schedule. The equal-capital comparison separates this capital effect from the investor allocation. The investor pays 0.5200 and receives 0.3000 in wallet transfers, with 0.3065 accrued distribution. Rounding remainders not yet credited to wallets are tracked separately. Cash flows use the observation-window convention, with outstanding rights reported separately. Figure 22. Continuous operating funds, completed services, contribution and investor cash flow. Source: the controlled cohort’s reconciled ledger and task records. F.3.5 Retail Financing Interventions The own-capital control, equal-capital control, and revenue-right arm receive퐵,퐵+ 퐴, and퐵+ 퐴respectively. Only the last arm transfers퐴from an investor’s separate research Billing Wallet through an approved investment. Its contractual terms allocate 89% to the operator, 10% to investors, and 1% to the platform. Revenue-split execution is validated by the separate contract tests; this retail batch records no success-triggered revenue event. Controls pay the same 1% platform share. Thus the equal-capital control holds initial available funds equal when comparing revenue sharing. Each arm executes fresh tasks because admission changes subsequent execution. Table 18 reports task outcomes, known inference expense and retained reservations. Experimental contribution profit is retained hypothetical receipts minus known inference expense; unknown-request usage remains outside this measured amount. Ending operating balances also subtract retained uncertain-request reservations. Research Manuscript50 Nexilume ResearchNX-2026-002 0255075100125150 Operating-account mutation 0.0 0.1 0.2 0.3 0.4 0.5 Experimental USD balance own equal right ownequalright 0 2 4 6 8 10 12 14 Task-arm cases Official successes: 0 / 0 / 0 Officially scored Funding admission stop Other unscored ownequalright 0.0 0.1 0.2 0.3 0.4 0.5 Experimental USD / held capital Known reference expense Unknown-usage reservation Figure 23. Operating balances, admission and scoring outcomes, and measured expenditure across financing conditions. Known expense and unresolved request reservations are shown separately. 0.000.250.500.751.001.251.501.752.00 Assumed receipt per success −1 0 1 2 3 4 5 6 Conditional contribution profit Own / equal capital, same workload 10% revenue share, same workload 0.60.81.01.21.41.61.82.0 Assumed receipt per success 2 4 6 8 10 Additional successes required (expected) No finite threshold at: 0.05, 0.10, 0.25 Conditional threshold; growth not measured Stationary cost per success is assumed; missing usage is excluded. Figure 24. Same-workload financing cost and conditional growth requirement. The right panel gives the analytical break-even requirement under stationary cost per success. The investor wallet transfers 0.370000 to the operator and receives 0.000000 during observation; its revenue rights remain outstanding. The three financing arms record zero successful services in this fixed retail sequence. Thus, the cohort characterizes admission, expenditure, and capital retention before success-triggered revenue is realized. Admission and receipt formation. Equal capital increases scoreable completions from one to four. The revenue-right arm has no scored completion and retains 0.172938 after two missing-response requests and a task-time limit. These reservations enter later admission and are reported separately from incurred expense. Known-cost contribution equals the negative of measured expense because success-triggered receipts are zero. Varying assumed receipts over 1, 1.5, 2, or 3 times휇leaves this fixed trajectory’s revenue unchanged. Cross-arm differences include model variability and path dependence, with unresolved expense bounded separately. F.3.6 Analytical Financing Comparisons Sharing costs and break-even growth. For the same completed workload, let푅be assumed receipts generated only by successful tasks and퐶its conditional operating cost. Own-capital and equal-capital controls yield 푅− 퐶, while a revenue share훼yields(1− 훼)푅− 퐶before additional fees. The allocation assigns훼푅to the investor while excluding capital injections from contribution. The assumed receipt grid spans 0.05, 0.10, 0.25, 0.50, 1 and 2 per successful task with훼 = 0.1. The post-hoc analysis gives the additional successes needed to offset that allocation under stationary cost per success. A finite break-even threshold requires a positive retained incremental margin. This analytical threshold complements the freshly executed capital-constrained comparisons against both controls. Additional funding under constrained demand. The financing replay admits complete requests in their original daily order, stopping when the next request would exceed the budget. It does not select later, cheaper requests. Initial daily budgets are the calibration invoice’s 50th, 75th, and 90th percentiles: $3.05370, $41.65998, and $166.25893. Budgets reset daily; costs are known retrospectively from the trace. This experiment evaluates Research Manuscript51 Nexilume ResearchNX-2026-002 the consequence of a larger budget, not an online admission policy or a causal estimate of demand created by investment. The Agent charges a 50% markup over its API expense, and the Provider’s variable cost is 60% of its API revenue. Financing assigns 10% of each publisher’s revenue to investors and 2% to the platform; the self-funded baseline has no modeled revenue sharing. Contribution profit is the revenue remaining after these shares and modeled variable costs, excluding fixed costs and the initial capital contribution. Table 19. Contribution-profit change when financing doubles the daily budget. Each row compares the same demand at the stated initial budget with and without financing. Full requests are preserved. Initial budget Budget ($/day) Agent (%) Provider (%) 50th percentile3.05370+21.23+32.59 75th percentile41.65998-8.11+0.50 90th percentile166.25893-19.17-11.59 Table 19 shows that the benefit depends on the initial capital constraint. At the lowest budget, additional service offsets revenue sharing; at higher budgets, insufficient unserved demand remains. At the lowest budget, the matched approximation permitting fractional requests yields 21.17% for the Agent, compared with 21.23% for complete requests. The observed reversal is therefore primarily associated with available capital, not request rounding. With no added service, the same sharing terms reduce Agent and Provider contribution profit by 36% and 30%, respectively. Under the stated margins, breaking even requires revenue growth above 56.25% for the Agent and 42.86% for the Provider. 1.01.52.02.53.0 Financed budget / initial budget 0 5 10 15 20 25 30 Investor revenue share (%) Agent: p75 initial budget 1.01.52.02.53.0 Financed budget / initial budget 0 5 10 15 20 25 30 Investor revenue share (%) Provider: p75 initial budget −75 −50 −25 0 25 50 75 Contribution-profit change (%) −80 −60 −40 −20 0 20 40 60 80 Contribution-profit change (%) Figure 25. Contribution-profit changes at the 75th-percentile initial budget, varying additional funding and investor share. Zero-change contours show where additional service revenue offsets sharing for each publisher. Equal-funded-amount alternatives. To separate funding availability from funding charges, a second comparison holds the total funded amount at $1,710.86. Half of each day’s positive cash requirement is assigned 30 days of financing. Assumed charges are 12% annual opportunity cost for own capital—the modeled cost of committing the operator’s own funds—12% interest plus a 1% initial fee for fixed credit, 8% interest for Provider credit, and 10% of modeled operating receipts plus a 1% initial fee for revenue sharing. Receipts are 1.5 times the primary API invoice. Resulting charges are $16.87, $33.98, $11.25, and $526.48, respectively. The funded total is the sum of financing amounts, not peak outstanding debt. This comparison isolates the stated charging rules at equal funded volume. Repayment obligations, collateral, and default risk are outside its modeled variables. Together, the growth and charge comparisons characterize additional service under capital scarcity and the cost of specified terms at fixed volume. Investor transfers use the observation-window convention; secondary-market valuation is a separate analysis. Research Manuscript52 Nexilume ResearchNX-2026-002 F.4 Protection: Execution Evidence and Analytical Reserve Sensitivity The main text reports the fault-frequency, premium, and reserve study. The initial controlled and retail interventions below report contract eligibility, approval, and settlement. The final subsection develops an analytical reserve-sensitivity study with its own stated scenario parameters. Alternative policy wallets are evaluated separately, with each wallet’s payments reported for the corresponding policy. F.4.1 Controlled Recovery and Loss Allocation Table 20. Twelve scheduled cases per fault arm. Reached counts injected incidents. Funded and scarce columns are actual service-credit payments, not cash income. ArmSuccess ReachedLoss Funded Scarce Own / no recovery012 0.5600 0.5600 0.1400 Own / recovery912 0.1400 0.1400 0.1400 Right / no recovery012 0.5400 0.5400 0.1200 Right / recovery912 0.1400 0.1400 0.1400 Local recovery achieves 9/12 successful services in both recovery-enabled arms through alternate paths to the same Provider. Funded policies settle all approved compensation, totaling 1.3800 in service credits across the four arms. Scarce-reserve policies pay 0.5400 and leave 0.8400 approved but unpaid. Eligibility is restricted to covered terminal injected failures; task execution and operating capital remain fixed within each protection comparison. Claims, reserves, and wallet credits are reconciled separately, and each payment passes a whole-claim funding check. Figure 26. Completed services and reserve-funded loss allocation under controlled local faults. Monetary values use the stated laboratory tariff. F.4.2 Retail Recovery and Protection Interventions Four fresh fault arms cross financing off/on with recovery off/on. They start with ample operating capital (100휇, plus퐴for financing) to separate recovery from capital scarcity; any admission failure is still reported. The schedule repeats timeout, rate limit, primary-route outage, common-route outage, and no fault across ten tasks. Injections require the third Agent call to be reached. For transient or primary-only adapter faults, recovery permits a real continuation request to the same configured Nexus/SiliconFlow endpoint; common-route outages terminate the task. Recovery is a controlled continuation branch at the same configured endpoint. The model, supplier, and bounded transport-retry settings remain identical across arms; the recovery switch controls only the injected local incident. Post-incident responses, scoreable completions, official task success, and inference expense are reported as separate outcomes. Protection fees and payouts use a separate research wallet, leaving operating capital fixed. Accordingly, S=0 and S=1 share the same execution trajectory. Terminal injected failures may generate a claim for known incurred experimental Agent expense, rounded down to cents; wrong answers, missing usage, and infrastructure errors do not automatically qualify. Claims pass actual coverage review and reserve checks. The funded and scarce-reserve plans share per-claim terms but use separate financial accounts. Whole-claim settlement requires Research Manuscript53 Nexilume ResearchNX-2026-002 Table 21. Retail fault interventions and service-credit settlements. Off/on denotes local recovery. Eligible loss excludes semantic task errors and unknown usage. ArmSuccesses Faults Residual cost Eligible Funded paid Scarce paid Own / off080.356410 0.0800000.080000 0.030000 Own / on181.511219 0.0200000.020000 0.020000 Right / off080.426050 0.0800000.080000 0.030000 Right / on081.063093 0.0200000.020000 0.020000 own-r0own-r1right-r0right-r1 0 2 4 6 8 10 Tasks / reached incidents Post-incident response Officially scored Official success own-r0own-r1right-r0right-r1 0.00 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 Experimental USD / service credits Eligible residual Funded credit payout Scarce credit payout Figure 27. Post-incident responses, scored completions, official task success, and redistribution of covered residual expense. Recovery changes executions; protection transfers service-credit value. Amounts are reconciled across task outcomes, claim decisions, reserve accounts, and service-credit records. sufficient remaining reserve budget and available account balance. Payouts are Billing Wallet service credits, reported separately from cash. Recovery and coverage have different observed effects. Each recovery-enabled arm encounters eight scheduled incidents: six permit a returned post-incident Agent response and two common incidents terminate the task. Both recovery-disabled arms terminate at all eight incidents. This measures execution continuation under the controlled adapter policy. Official successes change from zero to one in the own-capital pair and remain zero in the revenue-right pair. Known Agent expenses are 0.356410/1.600688 and 0.426050/1.063093 for recovery off/on, respectively, providing the execution-cost component of the financial comparison. Without recovery, each funded plan pays eight claims totaling 0.08 service credits. Its scarce-reserve counterpart pays 0.03 and leaves five approved claims totaling 0.05 unpaid; no partial settlement occurs. With recovery, both reserve conditions pay the two common-incident claims totaling 0.02 per arm. The 0.01 premium is paid once per plan and also increases reserve budget. These matched plans quantify how reserve funding and local recovery jointly determine paid compensation. Coverage is limited to the specified terminal injected failures; semantic task-error expense is reported separately under the controlled protocol. Economic interpretation. Under the explicit assumption that issued service credits are usable at face value, let퐿be total residual economic loss after recovery,푝the premium and푋the actual payout for its covered and eligible portion, the operator bears퐿+ 푝− 푋and the protection provider bears푋− 푝before administration costs. Their combined loss remains퐿: protection transfers economic loss, while recovery changes its occurrence. This participant-level conservation relation connects the conditional economic analysis to the separately reconciled intervention outcomes. F.4.3 Analytical Reserve Sensitivity Recovery and portfolio-level coverage. Protection comparisons use identical retry settings. Primary failures use zero-output trace records; alternate failures use the calibration rate of 0.2190846%. A parameter휌specifies the fraction of primary failures attributed to a persistent shared cause that alternate attempts cannot remove. The remaining failures use the assumed alternate failure rate. These parameters define the analytical shared-failure and recovery scenario. Research Manuscript54 Nexilume ResearchNX-2026-002 In the fixed-volume control with휌 = 0.75, one alternate attempt costs $25.91 and increases expected successful API responses from 883,304 to 887,329.41. Adding financial protection leaves that count unchanged by construction. The modeled plan charges a 1% premium, meaning the protection fee, and uses an initial reserve and total liability cap each equal to 10% of the calibration-predicted 42-day invoice. Claims become due after seven days, unpaid amounts carry forward, and replay continues through day 49. At $0.10 loss per unresolved call, the pool collects $34.22 and pays $220.73. The $186.51 reduction in buyer expense is matched by payments exceeding protection fees by the same amount, before reserve capital and operating costs. This reserve-funded transfer is evaluated at fixed execution, separating loss allocation from computational expenditure. Reserve sufficiency and claim timing. With휌 = 0.75, a 1% fee, and no claim delay, an initial reserve equal to 10% of the predicted invoice funds all capped claims. This result identifies a sufficient capitalization level for the stated scenario. At 5%, the first shortfall occurs on day 10 and $76.41 remains unpaid; with zero initial reserve, $186.77 remains unpaid. The chronological sensitivity varies initial reserves, fees, and claim lags of zero, seven, or thirty days, carrying unpaid obligations beyond the final request. The liability cap is fixed from calibration. Initial capital and premium receipts are tracked separately in the reserve accounting. 010203040 Day after test start 0 100 200 300 400 500 Available reserve (USD) Chronological reserve: 1% premium, no delay initial 0% of forecast bill initial 5% of forecast bill initial 10% of forecast bill initial 25% of forecast bill 010203040 Day after test start 0 25 50 75 100 125 150 175 200 Unpaid due credits (USD) Budget cap fixed from calibration, not future bill Figure 28. Reserve sufficiency under different initial-capital levels, with휌 = 0.75, a 1% protection fee, and no claim delay. Panels report available reserves and unpaid capped claims; initial capital is accounted for separately from premium receipts. The analytical estimates are conditional on the portfolio-level cap, claim-lag schedule, and carried-forward unpaid obligations specified above. Zero-output records supply the failure indicator; claim eligibility and credit utilization are scenario assumptions. Compensation reduces modeled economic expense under the assumption that the corresponding credit is usable at its recorded amount. F.5 Combined Financial Mechanisms Section 8.6 reports the controlled combinations. The retail and fixed-volume request comparisons below retain their own execution, pricing, and valuation assumptions. Forward and protection settlements are applied with the associated operational-admission trajectory held fixed. Retail workload: measured execution with paired financial combinations. The eight D/F/S cells reuse the recovery-enabled own-capital and revenue-right executions for F=0 and F=1. Financing has fresh executions; D and S settle in separate wallets after or outside operational admission. At the declared 1.5 price scenario and ℎ = 0.5, Table 22 reports conditional contribution excluding credits,푅 retained − 1.5퐶+푃 fwd − 푓 − 푝, where푃 fwd is the signed forward payment,푓the forward fee, and푝the protection premium. Service-credit compensation is reported separately from cash contribution. The scenario price is applied after execution with admission fixed, so the eight cells characterize paired financial accounting on the two observed financing trajectories. Each contribution is calculated from its component cash flows under the same scenario. At the rising index, D adds a net 0.449687 after fees, while S exchanges a 0.01 premium for 0.02 in service credits. All eight known-cost contributions remain negative, as reported in Table 22. Within each financing trajectory, the paired contrasts isolate these payment components. Cross-financing contrasts also Research Manuscript55 Nexilume ResearchNX-2026-002 Table 22. Eight combinations: actual task outcomes and contract payments under an assumed price scenario. DFS Successes Known-cost contribution Service credit 0001-2.0361220.000000 0011-2.0461220.020000 1001-1.5864350.000000 1011-1.5964350.020000 0100-1.5946400.000000 0110-1.6046400.020000 1100-1.1449520.000000 1110-1.1549520.020000 include differences in task outcomes, measured usage, and unresolved reservations. The common accounting representation preserves these distinct contributions to the combined outcome. Fixed-volume request replay. The eight퐷/퐹/푆combinations cross five price paths and two forward discounts, yielding 80 configurations with the same requests and recovery policy. Funding uses modeled own-capital opportunity cost when퐹 = 0and the stated revenue-sharing charges when퐹 = 1. Economic expense is defined by Equation(50); it is distinct from a commercial cash invoice or the real-model contribution excluding service credits. Table 23. Fixed-volume comparison under constant prices. Codes indicate whether 퐷, 퐹, and 푆 are enabled. ConfigurationForward discount Economic expense ($) 000: baseline—3,438.59 100: forward only 0%3,459.88 100: forward only 10%3,282.46 111: all three10%3,605.09 Under fixed-volume demand, the assumed 10%-discount forward reduces economic expense from $3,438.59 to $3,282.46. The all-mechanism configuration has expense $3,605.09, or 4.84% above baseline (Table 23), because financing and protection charges are not accompanied by additional admitted work. The decomposition separates individual-contract terms and combination-dependent effects; these sum to the total 111-minus-000 difference. This fixed-volume control complements the capital-constrained growth experiments by identifying the demand condition needed to offset financing charges. G Supplementary Execution Cohorts and Measurement Accounting This appendix records preliminary execution cohorts separately from the retail evaluation. The cohorts use distinct configurations or repeat previously inspected tasks. Their configuration, completion counts, and available usage records establish the provenance of the supplementary measurements; they are excluded from evaluation denominators. G.1 Preliminary Retail Cohorts Table 24 summarizes the preliminary retail cohorts and the scope of their recorded outcomes. A scored trial has an official task outcome. An unscored trial retains its execution records without an imputed task score. Unattempted scheduled trials are recorded separately. Final evaluation task selection remains unchanged. The corresponding request records and configuration details are retained in the supplementary artifact. Preliminary observations are reported at their own cohort scope and are not pooled with completed evaluation trials. G.2 Grounding and Reasoning Configurations Four additional batches reuse the same two retail calibration tasks, retaining every scheduled attempt. Both the Agent and simulated customer use Qwen/Qwen3-8B through Nexus and SiliconFlow. The official retail tools Research Manuscript56 Nexilume ResearchNX-2026-002 Table 24. Preliminary retail cohorts and recorded measurement scope. These cohorts are separate from the final baseline estimate. ConfigurationRecorded measurement scope Direct-provider pilotTen scored trials and no successful tasks. Gateway-format pilotTen Agent requests and ten returned simulated-customer responses; the customer responses match gateway records. Authenticated pilotThree scored trials with no successes, three unscored trials, and four unattempted scheduled trials; all 181 returned responses reconcile with gateway records. Fixed-schedule pilotTwo scored trials, including one success. Recovery configuration pilotTwo scored trials, including one success. Shortened pilotNo completed trial. Local-host pilotForty-nine returned model responses; all ten scheduled trials remain unscored. and ALL completion criterion remain unchanged. Additional Agent and customer instructions define a custom execution protocol. Table 25. Supplementary configuration batches, each scheduling two tasks. Request counts include all model roles; scored tasks have an official outcome. Returned usage is accounted for separately from task scores. ConfigurationRequests Responses Scored Successes Grounding535220 Reasoning, 60 s timeout6000 Reasoning, 240 s timeout6000 Reasoning, final batch212120 The grounding configuration adds general reminders about identifier provenance and customer-scenario fidelity. It uses temperature zero, a 600-second task deadline, and 30 requests per role. The reasoning configuration uses temperature 0.6, a 1,024-token reasoning budget, a 2,048-token output setting, a 1,200-second task deadline, and 40 requests per role. These are joint configuration comparisons rather than an isolated reasoning-mode intervention. All 21 returned usage records in the final batch match Nexus records exactly. G.3 Usage Accounting and Study Populations Across the four batches, 86 physical requests yield 73 complete responses, four scored outcomes, and no successful tasks. Thirteen requests have no returned usage, including one in the grounding batch. Returned usage and unresolved request records are accounted for separately. Monetary interpretation follows the experimental-valuation conventions in Section 8.1. The records distinguish model responses, tool execution, official task outcomes, and financial settlement. The controlled study in Appendix E uses fixed customer requests and explicit operation-level completion rules. Its observations retain a separate study population, as do the retail evaluation, calibration passes, and supplementary batches reported here. Research Manuscript57