sluicemarkets.com
Whitepaper, Version 1.0 · June 2026
Access to frontier language models is sold the way airtime once was: at fixed list prices, on prepaid balances that expire, with no mechanism to recover unused capacity. At the same time, teams and individuals routinely purchase more inference than they consume. This paper introduces Sluice, an open and OpenAI-compatible marketplace in which inference is priced by supply and demand rather than a single vendor's rate card. Holders of unused credits list them at a discount; buyers route requests through one endpoint and are matched automatically to the cheapest available supply. Balances are denominated in credits pegged to the United States dollar, fund and settle on-chain in USDC, and remain spendable across every supported model. The design yields a continuously clearing price for inference, lower costs for buyers, and a payout for sellers on capacity that would otherwise be wasted.
Keywords: inference marketplace, order book, large language models, credits, USDC settlement, OpenAI-compatible API
The market for artificial intelligence inference has grown faster than the means by which it is sold. Capacity is priced centrally, purchased in advance, and locked to a single provider. Three frictions follow from this arrangement, and together they impose a structural overpayment on buyers while stranding value held by sellers.
Every major provider publishes a rate card and charges it uniformly. No venue exists in which a buyer who requires a large volume of tokens immediately can transact with a holder who has that volume spare. Prices move only when a vendor elects to change them, rather than in response to shifts in supply and demand.1
Credits are commonly bought ahead of need, often in bulk against a discount or a usage commitment. Plans change and projects conclude, leaving balances idle or expired. That value is real, yet there is presently no liquid means of returning it to the market.
Pursuing the lowest price across providers entails reconciling multiple keys, endpoints, schemas, and billing systems. The cost of migration typically exceeds the saving, and buyers therefore overpay by default.
Each friction, taken alone, is a nuisance; taken together, they describe a market that has never been built. Supply exists, because buyers over-provision and balances go unused. Demand exists, because every team that calls a model would prefer to pay less for the same output. What is absent is the venue in which the two meet and a price clears. The remainder of this paper specifies such a venue. We describe the primitives on which it rests, the procedures by which buyers and sellers transact, the manner in which value is custodied and settled, and the incentives that keep the book liquid. Throughout, the design favours mechanisms that are simple to reason about, because a market is only as useful as it is legible to the people who use it.
Sluice is a single open order book for AI inference. It connects participants who hold surplus model capacity with those who require it, and clears their trades in real time. To a buyer, Sluice presents as one API key and one OpenAI-compatible endpoint: an existing software development kit may be pointed at it without modification, and each request is then priced against a live market and routed to the cheapest available supply. To a seller, Sluice is a venue at which to list credits that will not be consumed and to earn USDC when a buyer takes them. To the platform, Sluice is neutral infrastructure that operates the book, serves the inference, and charges a small fee upon each fill.
The system is characterised by four properties: it is open, in that anyone may buy and anyone may list supply; compatible, in that the interface mirrors a widely adopted schema so that streaming, function calling, and vision pass through unaltered; competitive, in that orders match cheapest first under transparent fees; and on-chain, in that funding, payouts, and settlement employ USDC, rendering balances portable and auditable.
Three classes of participant interact through the book. Buyers seek inference and care about price, latency, and the absence of integration overhead; they value the fact that a single endpoint hides the complexity of sourcing. Sellers hold credits in excess of their own consumption and seek to recover value rather than forfeit it; they value the ability to list, reprice, and withdraw without intermediation. The platform occupies neither side of the trade: it operates the book, serves the inference against pooled supply, enforces the rules of matching and settlement, and is compensated only when a trade clears. Because the platform does not take a directional position, its incentives are aligned with the health of the market rather than with the outcome of any individual trade.
The protocol is shaped by four goals. The first is legibility: a participant should be able to predict what an action costs and yields before taking it. The second is portability: value held in the system should be withdrawable rather than captive, which is why settlement is denominated in a transferable on-chain asset. The third is compatibility: adoption should require no rewrite, which is why the interface conforms to a schema developers already use. The fourth is neutrality: the venue should not privilege any supplier, and routing should follow price rather than relationship.
Three balances and one book describe substantially all of the protocol's behaviour.
| Element | Definition |
|---|---|
| Credits | The unit of inference. One credit is pegged to one United States dollar of model usage.2 Credits are universal: once acquired they may be spent on any supported model. |
| USDC | The settlement asset. Buyers fund accounts in USDC, sellers are paid in USDC, and credits convert to and from USDC at parity, on-chain. |
| Offers | A seller's listing of credits for a specified model at a chosen price below the dollar reference. Each model maintains its own book of offers. |
| Order book | The live set of open offers for a model, ordered by price. Buyers match against it cheapest first. |
A salient nuance is that the model tag attaches to the offer, not to the credit. The model determines which discount book a buyer transacts within; once purchased, credits are fungible and spendable across every supported model. This preserves sharp, per-model price discovery while keeping a participant's balance simple.
The decision to make credits fungible after purchase is deliberate and has consequences worth stating plainly. If credits were bound to the model under which they were bought, a participant would accumulate many small, non-interchangeable balances, and the unit of account would fracture. By separating discovery, which is per model, from spending, which is universal, the protocol keeps prices informative where they need to be and keeps balances simple where simplicity matters most. The cost of this choice is that the platform, rather than the individual seller, bears the obligation of serving whatever model the universal credit is later spent on; this is addressed by pooling supply at the platform layer, described in Section 7.
A purchase on Sluice is a market order against a single model's book; the buyer is not required to select individual offers by hand.
Select a model. Choose the model whose discounted book is to be drawn from.
Set a budget. Enter an amount of USDC to spend.
Match cheapest first. Sluice fills the lowest-priced open offers in sequence until the budget is exhausted, crediting the buyer as it proceeds.
Spend anywhere. The acquired credits are universal and are drawn down per token at the listed reference, against any supported model.
Suppose a seller lists one hundred credits for a given model at 0.80 USDC each. A buyer spends 40 USDC and receives fifty credits; the seller receives the proceeds net of fee; and the buyer may thereafter spend those fifty credits on any model. The discount was discovered within that model's book, whereas the spend is universal.
Because matching proceeds from the cheapest offer upward, a budget that exceeds the size of the lowest offer will consume successive offers at progressively higher prices. The effective price a buyer pays is therefore the size-weighted average of the offers consumed, not the price of the first offer alone. A thin book produces more price impact for a given budget; a deep book produces less. This is the familiar behaviour of an order book, and it gives sellers a clear signal: where books are thin, an offer placed at a modest discount is likely to be taken quickly, which is precisely the condition under which the protocol most needs supply.
Sellers convert idle capacity into USDC by listing it where buyers will find it. A seller selects the relevant model, lists a quantity of credits at a price below the dollar reference, and joins the book; a deeper discount fills more quickly. When buyers sweep cheapest first, the seller's credits are sold and the seller is paid in USDC, net of the platform fee. Listings may be created, repriced, and cancelled. Because settlement occurs in USDC and balances are held on-chain, a seller's proceeds are withdrawable rather than confined to a single vendor's account.
Sellers are not a separate caste of professional market makers. They are ordinary participants whose holdings exceed their consumption: a team that purchased capacity for a project that has since wound down, a user who acquired credits in a promotion, or a buyer who simply over-estimated demand. The same account may be a buyer one week and a seller the next. Lowering the barrier to listing, so that releasing surplus is as easy as acquiring it, is what allows latent supply to surface.
A seller chooses a price and a size. Pricing nearer the dollar reference preserves value per credit but risks sitting unfilled behind cheaper offers; pricing further below clears faster but concedes more of the discount to the buyer. Because offers can be repriced and cancelled without penalty, a seller may begin conservatively and adjust toward the market, observing the live board to judge where the model is trading. The protocol does not prescribe a strategy; it simply makes the trade-off visible and the adjustment cheap.
Sluice separates the three balances a participant holds so that risk and usability remain legible.
| Balance | Property |
|---|---|
| USDC | Withdrawable; deposited and paid out on-chain. |
| Credits | Spendable on inference and convertible to USDC at parity. |
| Offers | Credits committed to the book until filled or cancelled. |
Accounts are provisioned with an embedded wallet at sign-in, so that a new participant need not supply an external wallet in order to begin. Deposits, withdrawals, and conversions are recorded on-chain in USDC. Conversion between credits and USDC is one to one, which keeps the unit of inference honest and renders the value of an unused balance unambiguous.
The separation of balances also clarifies the platform's custodial posture. USDC is the only asset that enters or leaves the system, and it does so on-chain, where deposits and withdrawals are observable. Credits are an internal accounting unit redeemable against that USDC at parity, and offers are merely credits earmarked for sale. A participant can therefore reason about exposure directly: the withdrawable balance is the USDC, the spendable balance is the credits, and nothing is hidden in a denomination that cannot be exited. Provisioning an embedded wallet at sign-in removes the most common obstacle to onboarding without removing the user's ability to operate on-chain.
Sluice exposes one endpoint with an OpenAI-compatible schema, so that the request shape developers already employ functions without modification. A buyer points the base URL at Sluice and retains existing code; requests are routed to live supply automatically, drawing from the cheapest available source; streaming, function calling, and vision pass through directly; and usage is metered per token from a prepaid balance, without subscription and without rate-limit gating by plan tier. Because the marketplace abstracts the underlying supply, the buyer interacts with Sluice as a single coherent provider, while the work of sourcing, matching, and settlement occurs beneath the endpoint.
Serving inference from pooled supply, rather than from a single named provider, is what allows a universal credit to be honoured across models. It also confers a reliability benefit: when supply for a model is available from more than one source, the platform can route around a source that is unavailable or degraded without the buyer changing anything. To the developer the endpoint is constant; beneath it, the platform is free to source intelligence wherever it is cheapest and most reliable at the moment of the call. This abstraction is the technical counterpart of the market's economic promise, that a buyer should never have to manage the supply side themselves.
Each model carries its own order book, with its own depth and its own clearing price, in the manner of separate instruments on an exchange. Prices move as sellers list and buyers sweep, rather than on a vendor's schedule. The platform surfaces this as a live board reporting current prices, recent fills, and the discount available against the dollar reference, so that a buyer may observe how far below list a model trades and a seller may observe where to price in order to be filled. Discovery is thus continuous and public, which is the purpose of a market.
A model's price is not announced; it emerges. When sellers compete to be filled, the lowest offer sets the marginal price, and as that offer is consumed the next becomes marginal. When demand is strong relative to listed supply, buyers consume deeper into the book and the effective price rises, which in turn invites sellers to list. When supply is abundant, offers cluster lower and buyers pay less. Over time this feedback pushes the visible price toward the level at which the model genuinely clears, and the discount against the dollar reference becomes a real-time measure of how much surplus capacity the market is carrying for that model.
Sluice charges a small fee upon each fill. The default is two percent, taken at the moment a trade clears and routed to the platform account; sellers receive proceeds net of that fee, and buyers receive their credits.3
| Parameter | Default |
|---|---|
| Platform fee | 2.0 percent per fill |
| Credit peg | 1 credit = 1 USDC reference |
| Conversion | Credits to USDC, at parity |
| Matching | Cheapest offer first |
The incentive structure is direct. Sellers are rewarded for releasing idle capacity rather than allowing it to expire; buyers are rewarded for routing through a competitive book rather than paying list; and the platform is rewarded only when a trade occurs, aligning its interest with liquidity and volume rather than with any particular price.
Under a fixed rate card, the price a buyer pays is independent of whether the provider is over-supplied or constrained, and any surplus capacity in the system is simply lost. Under a market, the same surplus becomes downward pressure on price, and the saving accrues to buyers rather than evaporating. The platform fee is levied on the transaction rather than on the headline price, so the platform earns from the act of clearing trades and not from keeping prices high. In aggregate, the arrangement converts waste into liquidity and distributes the benefit between the two sides of the trade, while the venue is paid for the service of bringing them together.
Alongside the graphical application, Sluice provides a command-line interface to the same book, intended for participants who prefer to type rather than to click. From the prompt a participant may query a model's price, view its book, place a buy or a sell, and read a balance. The interface addresses the identical marketplace as the remainder of the product, so that a command issued there clears against the same liquidity as an order placed in the application; it constitutes a faster surface onto the market, not a separate one.
Sluice keeps onboarding light while affording the controls that a genuine marketplace requires. Identity verification is available and may be applied where it is material, for instance to higher-value flows, so that casual usage remains frictionless while the platform is able to meet its obligations as activity grows. Assistance is built in: an assistant answers common questions instantly, and a live support channel routes account-specific matters to a human, who may look up an account and follow up. Account issues, appeals, and tickets traverse a single support surface.
The intent is to scale verification with risk rather than to impose it uniformly. Low-value, everyday usage should remain immediate, because friction at the margin suppresses exactly the casual activity a young market needs; higher-value flows, by contrast, warrant proportionate checks. Support follows the same graduated logic: routine questions are answered instantly by an assistant, while anything that touches a specific account, a withdrawal, a block, a disputed charge, is escalated to a human who can act on it. The objective is a marketplace that feels effortless to ordinary participants while remaining accountable as activity and value grow.
Sluice intends to introduce a native token in the third quarter of 2026. The token is planned and not live; at the time of writing there exists no ticker and no contract, and details including supply, distribution, and timing will be published nearer the date through official channels only.
The token is being designed to deepen the market and to reward those who sustain it. The directions presently under consideration include fee alignment, in the form of discounts or rebates on trading and inference fees for participants who hold or stake; seller incentives that direct liquidity toward the books that require depth; staking, as a means of committing to the network in exchange for benefits and a share of platform activity; and governance, conferring a voice over parameters such as fees and supported markets as the protocol decentralises. The final design remains in development and may change, and nothing herein constitutes a commitment to any specific mechanism, allocation, or date.4
| Fee alignment | Discounts or rebates on trading and inference fees for participants who hold or stake. |
| Seller incentives | Rewards that direct liquidity toward the books that most require depth. |
| Staking | Committing to the network in exchange for benefits and a share of platform activity. |
| Governance | A voice over parameters such as fees and supported markets as the protocol decentralises. |
| Access | Priority features and higher limits for participants who hold. |
The capabilities described below are planned and under development. They are presented to communicate direction, not as commitments to scope or timing, and any of them may change. Each extends the live marketplace rather than departing from it, and several are natural complements to the token described in Section 12.
The central challenge for any young marketplace is depth: a book that is thin in a given model offers buyers little discount and gives sellers little reason to arrive first. To address this, Sluice plans a liquidity programme that rewards sellers for providing depth where it is most needed, directing supply toward the models and price levels at which the book is shallow. By compensating the provision of standing offers rather than merely completed trades, the programme aims to make books deeper and prices keener before organic volume alone would achieve it. This mechanism is expected to be a primary use of the planned token, aligning the incentive to supply liquidity with a stake in the network that benefits from it.
A market is more useful when its state is legible. Sluice plans a public analytics surface that reports, per model, the prevailing price and its movement, recent fills and throughput, realised discount against the dollar reference, and a measure of book depth. The intent is twofold: to give buyers the information needed to time and size purchases, and to give sellers the signals needed to price competitively. Making this data open, rather than confining it to private dashboards, reinforces the claim that price on Sluice is discovered in the open rather than administered behind a vendor's wall.
As inference volume grows, participants require visibility into their own consumption. Sluice plans a usage dashboard through which a participant can review token consumption over time, monitor the remaining credit balance, and manage API keys, including issuing and revoking them. The objective is to give developers the operational controls expected of a serious inference provider, so that spend is predictable, anomalies are visible, and access can be rotated without friction. This surface is intended to sit beside the existing buying, selling, and conversion flows rather than to replace them.
Growth in a two-sided market compounds when existing participants bring new ones. Sluice plans a referral mechanism through which a participant who introduces another may share in a portion of the resulting platform fees. Because the reward is funded from fees that arise only when real activity occurs, the mechanism is self-limiting and aligned with genuine usage rather than with vanity sign-ups. Referrals are expected to complement, not substitute for, the liquidity and analytics work above, since the most durable growth comes from a market that is both deep and visibly fair.
| Phase | Focus |
|---|---|
| Live | Open marketplace, OpenAI-compatible endpoint, per-model order books, USDC funding and withdrawals, credit conversion, embedded wallets, multilingual interface, and built-in support. |
| Next | Deeper liquidity programmes for sellers, expanded model coverage, and analytics for buyers and sellers. |
| Planned | Liquidity and seller rewards, public market analytics, a usage and key-management dashboard, and a referral mechanism (see Section 13). |
| Q3 2026 | Introduction of the planned native token and the first of its utility mechanisms. |
| Beyond | Progressive decentralisation of market parameters and broader community governance. |
This document is provided for information only. It does not constitute financial, investment, legal, or tax advice, and it is neither an offer nor a solicitation of any kind. Participation in any marketplace carries risk, including the risk of loss. Forward-looking statements, including those concerning the planned token and the roadmap, describe present intentions and may change without notice. Model availability, pricing, fees, and features are subject to change as the platform evolves. Participants are responsible for compliance with the laws and regulations applicable to them and should conduct their own diligence before participating.
Intelligence is becoming a commodity, and commodities trade. Sluice supplies to AI inference the institution it has lacked: an open and liquid market in which price is discovered, surplus is recovered, and access is cheaper because it is competitive. Buyers acquire frontier model calls at a discount, sellers realise value from the credits they will never burn, and a single book performs the clearing.
1. By contrast, an order book reprices continuously as participants post and lift offers, so the quoted price reflects current conditions rather than an administrative decision. ↩
2. The dollar peg fixes the unit of account for inference; it does not imply any guarantee of model output, latency, or availability. ↩
3. The fee is a market parameter and may be revised; the figure stated is the default at the time of writing. ↩
4. Readers should disregard any ticker or contract address claiming association with Sluice prior to an official announcement. ↩