Polyquest: A Multi-Engine Prediction Market Protocol with Liquidity-Sensitive Market Making and Any-Token Collateral on Solana

1Introduction

A prediction market trades contracts whose payoff depends on the outcome of a future event, and the prices of such contracts are commonly read as probability estimates [1, 2]. After decades as a research instrument, the category has become a mainstream market. Industry estimates put 2025 volume at about 51 billion USD, with projections of one trillion USD by 2030 [3]; thirty-day volume across the largest venues reached 68.0 billion USD in September 2026 [4]; and markets on the 2026 FIFA World Cup alone traded about 20 billion USD, compared with 3.6 billion USD for the 2024 United States election [5]. Regulators have responded with proposed rules for event contracts [6].

This growth is concentrated in a small number of venues that share a common design: curated listings, a single dollar-denominated collateral, and either an order book fed by professional market makers or a custodial account model. The design suits large, widely followed events. It serves a second class of markets poorly: the long tail of questions posed by communities, creators and live broadcasts, which are individually small, short-lived and numerous. For these markets we identify four frictions.

• F1. Single collateral. Participants must convert into the venue's one currency before trading, and a community cannot denominate a market in its own token.
• F2. Custody. Account-based venues take deposits, which concentrates counterparty risk in the operator and adds an onboarding step before the first trade.
• F3. Curated supply. When an operator approves every market, the number of markets is bounded by the operator's review capacity rather than by demand.
• F4. Long-tail liquidity. An order book quotes only where makers choose to quote; a logarithmic market scoring rule quotes everywhere but requires a subsidy fixed before the operator knows how much volume a market will attract [7]; a parimutuel pool needs no subsidy but offers no price at entry [8].

No single mechanism removes all four (Section 2.8). Polyquest therefore composes three engines behind one interface on Solana [9], with permissionless market creation, any-token collateral and self-custody as shared properties. Engine I is a parimutuel Pool vs Pool market that needs no seed capital and suits community markets in custom tokens. Engine II is an automated market maker based on the liquidity-sensitive logarithmic market scoring rule (LS-LMSR) of Othman et al. [10], which quotes two-sided prices at every moment, bounds the seed provider's loss by a quantity fixed at market open, and deepens as volume grows; it runs Polyquest's own markets, including minute-scale live markets shown alongside a broadcast. Engine III routes orders to Polymarket's central limit order book through a per-user embedded wallet, so that users of a Solana wallet can reach external order-book liquidity without an omnibus account. A creator layer sits on top of the engines: creators open markets that bring their audiences and insights to Polyquest, and curate existing markets, including Polymarket markets, so that followers can find markets the creator has evaluated (Section 9.6).

1.1Contributions

1. Architecture. We define self-custody for a market engine, state the trust assumptions of each engine explicitly, and show how an external order book can be integrated through per-user embedded wallets and a relayer without pooling user funds, together with a creator layer for market creation and curation (Sections 3, 4 and 7 to 10).
2. Analysis of the Engine II market maker. We give an entropy decomposition of LS-LMSR prices, the exact range of the overround, a solvency margin, a bound on the seed loss that is sharper than the general bound because it credits the seed provider's own shares, saturation limits of prices, and a design requirement that rules out par minting of complete sets (Section 5 and Appendix B).
3. Integer implementation. We describe the unsigned 128-bit fixed-point evaluation of the cost function with a numerically stable log-sum-exp and an exponent cutoff, prove that solvency and the absence of profitable trade cycles hold for any deterministic approximation that dominates the largest liability, independently of the accuracy of the elementary functions, and measure a reference emulation to within a few units in the last place on $10^6$ inputs per routine (Section 6 and Appendix C).
4. Any-token execution. We keep price feeds out of the trade path and prove a bounded-execution property for a swap and a trade composed in one atomic Solana transaction (Section 7).
5. Security and economics. We analyze eighteen threats across the three engines, state six invariants of Engine II, and derive a worst-case break-even volume for a creator who seeds a market (Sections 11 and 13).
6. Evaluation at scale. We evaluate price impact, liquidity sensitivity, solvency and information aggregation in a reproducible simulation study with $10^8$ trades in 100,000 markets, single-market paths reaching $10^9$ USD of volume, and $4\times 10^7$ trading decisions across four mechanisms, and we report where the LS-LMSR underperforms its benchmarks (Section 12 and Appendix E).

1.2Scope and Status

This paper describes the design of the three engines and specifies the Engine II program, whose constants are collected in Appendix D. The program will undergo an external security audit after deployment. All quantitative results on market behavior come from simulation or from exact and fixed-point computation; the paper reports no live operational metrics. Token design is outside the scope of this paper, and none of its results depends on a token. Section 3.2 describes USDP, an SPL token that Polyquest uses as a dollar-denominated reward unit.

1.3Organization

Section 2 reviews the mechanisms that Polyquest builds on. Section 3 states the system model. Sections 4 and 5 analyze Engines I and II, and Section 6 describes the fixed-point implementation of Engine II. Section 7 covers collateral and swap-to-bet execution, Section 8 the Polymarket integration, Section 9 the market lifecycle and Section 10 cross-chain access. Section 11 analyzes security, Section 12 reports the simulation study, Section 13 discusses fees and protocol economics, and Section 14 states limitations and future work. The appendices contain notation, proofs, algorithms, constants, the simulation configuration and a disclaimer.

2Background and Related Work

This section reviews the mechanisms from which Polyquest is assembled. We focus on three properties that matter for a permissionless venue with many small markets: who bears the risk of quoting, whether quotes are always available, and how depth responds to volume.

2.1Prediction Markets as Information Aggregators

The price of a contract that pays one unit if an event occurs is commonly read as a probability estimate [1]. Election futures markets have produced forecasts that compare favorably with contemporaneous polls over long samples [11], and Arrow et al. argued that such markets deserve regulatory room as forecasting tools [2]. The probability reading has limits: with heterogeneous beliefs and budget-constrained, risk-neutral traders, the equilibrium price identifies a quantile of the belief distribution rather than its mean [12]. Ostrovsky characterizes the securities for which dynamic trading among strategic, privately informed traders aggregates information: for separable securities, prices converge to the full-information value in every equilibrium [13]. Hanson and Oprea show that an attempted manipulation can raise accuracy, because the manipulator's predictable orders increase the return to informed trading [14].

Two design requirements follow. Aggregation needs a counterparty at every moment, so that informed traders can act when information arrives, and the cost of moving the price must be high enough to make noise and manipulation expensive but low enough to reward information. Both are properties of the market-making mechanism.

2.2Market Scoring Rules and the LMSR

A scoring rule $\mathcal{S}(\mathbf{r},i)$ pays a forecaster who reported $\mathbf{r}$ when outcome $i$ occurs; it is strictly proper if truthful reporting uniquely maximizes the expected score [15]. The quadratic rule [16] and the logarithmic rule $\mathcal{S}(\mathbf{r},i)=a_i+b\ln r_i$ are standard examples. Hanson's market scoring rule makes a proper rule sequential: each trader replaces the standing forecast, pays its score, and is paid the score of the new one [17, 7]. Payments telescope, so the operator loses at most the score range, which for the logarithmic rule started at the uniform forecast is $b\ln n$.

The logarithmic market scoring rule (LMSR) is equivalently an automated market maker selling outcome shares, each paying one unit if its outcome occurs, at the cost $C_{\text{LMSR}}(\mathbf{q})=b\ln {\sum }_i{e}^{q_i/b}$, with prices $p_i=e^{q_i/b}/{\sum }_j{e}^{q_j/b}$ that sum to one [7]. The single parameter $b$ controls both the subsidy and the price response. In a balanced binary market, buying $\Delta$ shares of one outcome moves its price from $1/2$ to $1/(1+e^{-\Delta /b})$. A small $b$ gives a thin market that is cheap to manipulate; a large $b$ gives depth but a large worst-case subsidy $b\ln n$ and slow price discovery when few traders arrive. Because $b$ is fixed at creation, depth is the same at ten units of volume or ten million, so the operator must forecast volume before the market opens. That is not feasible when anyone can create markets and most markets are small.

2.3Cost-Function Market Makers and the Convex Framework

Chen and Pennock generalize the LMSR to market makers defined by a cost function $C$: a trade $\mathbf{\Delta }$ costs $C(\mathbf{q}+\mathbf{\Delta })-C(\mathbf{q})$ and instantaneous prices are the gradient $\nabla C(\mathbf{q})$ [18]. Abernethy, Chen and Wortman Vaughan obtain the desirable properties (path independence, no arbitrage, information incorporation, expressiveness, bounded loss) from convex cost functions with gradients in the probability simplex, written as conjugates of a regularizer over prices, and connect market making to online learning [19]. Path independence means that a sequence of trades costs the same as its net trade, so splitting orders neither helps nor hurts and liability depends on the share vector alone. Translation invariance, $C(\mathbf{q}+c1)=C(\mathbf{q})+c$, makes a complete set of shares (one of each outcome, which pays exactly one unit in every state) cost exactly one unit, and is equivalent to prices summing to one. Chen and Pennock survey the resulting design space [20].

2.4Liquidity Sensitivity and the LS-LMSR

Othman, Pennock, Reeves and Sandholm call a market maker liquidity sensitive if a fixed trade moves prices less when more shares are outstanding, and show that no market maker can be path independent, translation invariant and liquidity sensitive at the same time [10]. Their liquidity-sensitive LMSR (LS-LMSR) keeps path independence and gives up translation invariance by letting the LMSR parameter grow with outstanding interest, $b(\mathbf{q})=\alpha {\sum }_i{q}_i$. Two consequences follow. Depth grows in proportion to the number of outstanding shares, so a market needs only a small seed to open and becomes deeper as it is used. Prices sum to more than one, the sum being at most $1+\alpha n\ln n$ [10], and this overround acts like a commission built into the quotes. The worst-case loss remains bounded and is set by the initial seed [10]. Section 5 derives these properties in the form used by Polyquest and sharpens the bounds.

2.5Parimutuel Mechanisms

In parimutuel betting, stakes on each outcome are pooled and the winning pool shares the losing pools pro rata, less a commission. The operator bears no risk and needs no liquidity provider, but odds are not fixed when a bet is placed: the payout ratio depends on all later bets, and racetrack data show persistent biases such as the favorite-longshot bias [8]. Pennock's dynamic parimutuel market combines a parimutuel pool with a share price that changes as shares are bought, so that early informed traders are rewarded while the operator's risk stays limited to its initial subsidy [21]. Engine I of Polyquest (Section 4) is a plain parimutuel pool.

2.6Constant-Function Market Makers and Prediction-Market AMMs

A constant-product market maker (CPMM) holds reserves $(x,y)$ of two assets and accepts any trade that preserves $xy=k$ [22]. Angeris and Chitra give conditions under which arbitrage keeps the price of a constant-function market maker close to a reference market [23]. The Gnosis conditional tokens framework lets anyone split collateral into a complete set of outcome tokens at par and merge a complete set back into collateral [24]. The fixed-product market maker (FPMM) built on it converts a buyer's collateral into complete sets and releases outcome tokens so that the product of its reserves is preserved; prices sum to one, and depth comes from liquidity providers' deposits rather than from volume [24]. Moallemi and Robinson's pm-AMM chooses the invariant so that, under Gaussian score dynamics, liquidity providers' expected loss to arbitrageurs is uniform across prices, and a dynamic variant reduces liquidity as expiry approaches [25]. Slamka, Skiera and Spann compare automated market makers experimentally and report that the choice of mechanism and its liquidity setting affect forecasting performance [26].

2.7Order-Book Prediction Markets

In a central limit order book (CLOB), makers post limit orders and takers cross them; the venue itself holds no inventory and pays no subsidy. Polymarket operates a CLOB with off-chain order matching and non-custodial on-chain settlement of signed orders against conditional-token positions [27, 24]. Depth is endogenous: it is high where professional makers are active and thin or absent elsewhere. Because complete sets can be split and merged at par, arbitrage keeps the sum of best prices close to one, but nothing guarantees that a quote exists at a given moment.

2.8Positioning

Table 2.1 summarizes the comparison along the properties discussed above.

No row dominates. Mechanisms without operator risk (parimutuel, CLOB) depend on other participants being present, while mechanisms with always-available quotes (LMSR, LS-LMSR, CPMM) put someone's capital at risk. Polyquest therefore composes three mechanisms as complementary engines. Engine I is a parimutuel pool for community markets, often denominated in custom tokens, where no subsidy is available and pro-rata payoffs are acceptable. Engine II is an LS-LMSR for Polyquest-native markets, including minute-scale live markets, which require two-sided quotes at every moment and whose subsidy must be bounded and known when the market opens; liquidity sensitivity lets such markets open with a small seed and deepen with use. Engine III routes to Polymarket's CLOB for markets in which external makers already supply depth. Sections 3 to 8 describe the architecture, each engine, and the collateral and execution layer they share.

3System Model and Architecture

This section fixes the actors, custody model, design goals and trust assumptions used in the rest of the paper, and describes how the three engines are composed behind one interface. Section 11 analyzes these assumptions against concrete adversaries.

3.1Actors

An actor is defined by the capabilities it holds, not by the organization that operates it.

• Trader. A holder of a Solana keypair, who signs every Solana transaction that moves its assets. For Engine III the trader also controls a per-user embedded EVM wallet (Section 8).
• Market creator. Any wallet that opens a market and sets its parameters (Section 9.1); it receives the fee share ${\phi }_c$. A creator can also curate existing markets, including Engine III markets, for its followers (Section 9.6).
• Seed provider. For Engine II, the account that posts the seed collateral $S=C({\mathbf{q}}^0)$ and bears the worst-case loss $L_{\max }=b_0\ln n$ (Section 5), usually the creator. Engine I needs no seed.
• Designated resolver. A role named in each market's rules whose action finalizes the realized outcome $i^{\star }$ (A2; design space in Section 9.3).
• Relayer. An EVM-side service that submits gasless Polygon transactions for Engine III users (Section 8).
• Swap venue. The Jupiter aggregator, whose routes are composed with trades for swap-to-bet (Section 7) [28].
• Bridge. Mayan, for bringing assets into Solana [29], and a USDC route that funds the Engine III wallet (Section 10).
• Price feed. A source of token prices for display and creation gating only (A5).
• Operator. The party that runs the interface and its off-chain services: indexing chain state, aggregating the Polymarket feed and constructing transactions for the trader to sign. In this role it is not a counterparty in any engine; whoever seeds an Engine II market, a creator or the operator, acts as its seed provider.

3.2Assets and Custody

Each Engine I or Engine II market is denominated in one collateral token $\mathcal{T}$, an SPL mint [30]. Market collateral is held in accounts owned by the Polyquest programs and moves only as program logic permits: on a trade, a fee transfer or a redemption. Engine II positions are outcome shares from per-outcome share mints, held in the trader's own token accounts; Engine I records each trader's stakes $w_{u,i}$ on-chain; Engine III positions are conditional-token positions held by the trader's embedded wallet on Polygon.

Polyquest never takes custody of user deposits and operates no omnibus account in which funds of different users are pooled. Engines I and II satisfy Definition 3.1 relative to the program code. Engine III satisfies property (i) only relative to assumption A4, because its signing is automated; Section 8.3 states which parties this places in the trust boundary.

USDP. Polyquest consolidates its various user rewards into USDP, an SPL token denominated in US dollars that functions as a points balance within the platform (unrelated to other assets that share the ticker). USDP is not a stablecoin: Polyquest does not guarantee its redemption at 1 USD or its exchange for USDC at 1:1. A USDP pool can be created on a decentralized exchange, but the price in such a pool is set by its traders, not by Polyquest. The future uses of USDP follow Polyquest's reward policy and are outside the scope of this paper.

3.3Design Goals

• G1. Self-custody. No user deposit passes through an operator-controlled account (Definition 3.1).
• G2. Permissionless market supply. Any wallet can open a market; quality is controlled ex post (Section 9.5).
• G3. Any-token collateral. A market may be denominated in any registered SPL mint, and a trader may pay with a token other than the collateral (Section 7).
• G4. Bounded seed risk. Where an automated market maker supplies liquidity, the seed provider's loss is bounded by a quantity fixed at market open.
• G5. One interface over heterogeneous liquidity. Parimutuel pools, a cost-function market maker and an external order book appear in one feed.

3.4Trust Assumptions

• A1. Solana provides safety and liveness: transactions execute atomically and in some total order, and valid transactions are eventually included [9, 31].
• A2. The designated resolver of a market reports the outcome defined by that market's rules and resolution source.
• A3. Swap routes execute within the slippage bound $s$ stated in the transaction, or the transaction fails (Section 7.3).
• A4. For Engine III, the embedded-wallet provider manages keys as documented, the component authorized to request signatures stays within its policy, and the relayer is live (Section 8.3).
• A5. Price feeds are used only for display and creation gating, never to price a trade.

A5 is a design constraint rather than an assumption about a third party: a manipulated or stale feed can affect which markets are admitted and what is displayed, but not a trade price or a market's solvency (Section 7.2).

3.5Architecture

Figure 3.1 shows the components. On Solana, the Engine I and Engine II programs hold market state and collateral. The Engine II program is written with Anchor [32] under program ID 4tjbrvyzZ4PVuCnLKhrbbpcKd4ghnT6xxWPLQ2Mav68z; its state accounts are Market, Registry and CollateralEntry. On Polygon, Engine III uses Polymarket's order book and settlement contracts through the trader's embedded wallet. The interface reads both chains, tags each market by engine (for example "LS-LMSR" and "CLOB") and builds transactions, but signs no Solana transaction and holds no funds.

Table 3.1 shows that the engines are complementary. Engine I needs no seed and no price source, which suits long-tail markets in community tokens. Engine II provides continuous two-sided quotes at a bounded cost to the seed provider, which suits short and live markets. Engine III gives access to external order book liquidity without Polyquest acting as counterparty or custodian.

4Engine I: Pool vs Pool (Parimutuel) Markets

Engine I is a parimutuel market. Each outcome has its own pool, traders stake collateral into outcome pools, the ratio of the pools sets the implied odds, and at resolution the winning pool shares the losing pools pro rata. The mechanism has a long history in racetrack betting [8] and was studied as a prediction market design by Pennock [21]. We give a formal model, prove two properties of the fee rule, and discuss the limitations that motivate Engine II.

4.1Model

Before resolution, the interface displays the implied probability ${\hat{\pi }}_i=W_i/W$ and the decimal odds $o_i=W/W_i$ before fees. Under Eq. (4.1), a unit staked on outcome $i$ returns, if $i$ wins,

The fee is thus charged on the transfer from losing to winning traders, not on the returned stake. Figure 4.1 illustrates the settlement flow for $n=3$.

4.2Budget Balance and the Losing-Side Fee Rule

Proposition 4.3 matters for markets with a heavy favorite. Under a gross-pool fee, a trader who backs an outcome with implied probability above $1-\phi$ and is right still loses money, which is difficult to explain to retail users and penalizes accurate reporting. The losing-side rule avoids this by construction, and a one-sided market ($W=W_{i^{\star }}$) returns every stake in full with no fee.

4.3Price Discovery Without a Quote

A parimutuel market quotes no price at entry. The payout ratio ${\mu }_i$ of Eq. (4.3) is determined by the pools at ${\tau }_c$, not at the time of the stake. A stake $x$ into pool $i$ moves the implied probability from $W_i/W$ to $(W_i+x)/(W+x)$ and lowers the payout ratio of everyone already in pool $i$ to

while raising ${\mu }_j$ for every $j\ne i$. Early stakers therefore carry odds drift that they cannot hedge within the market, and a trader who stakes just before ${\tau }_c$ observes nearly final pools and possibly more information about the outcome. This late-entry advantage, together with the favorite-longshot bias documented in racetrack pools [8], limits the quality of parimutuel odds as forecasts. Pennock's dynamic parimutuel market makes the payout depend on the price at the time of purchase to address this [21]. We keep Engine I in its classical form and serve markets that need a quoted price with Engine II instead. A close time that precedes the public observability of the outcome (Section 9.2) removes the most damaging form of late entry.

4.4Cold Start and Empty Pools

A parimutuel pool is only informative once several pools hold stake. The first trader in an empty market faces the widest odds drift: every later stake in the same pool dilutes its payout through Eq. (4.4), and nothing guarantees that stake on other outcomes will follow. Polyquest offers early-bettor liquidity incentives to offset this cold start; we treat them as an external subsidy and do not model them.

If the realized outcome has an empty pool ($W_{i^{\star }}=0$), Eq. (4.1) is undefined: no trader holds a claim on the losing stake. The disposition of stakes in this case must be fixed by the market's rules before trading opens, because otherwise the resolver's report would trigger a transfer that no rule defines. We do not prescribe a rule here.

4.5Suitability for Community Markets

Engine I is used most heavily for community and custom-token markets, and its properties explain why. By Proposition 4.2, payouts are funded entirely by stakes, so a creator can open a market without seed capital and no party bears market-maker risk. All accounting is in units of $\mathcal{T}$, so the engine needs no price source, and a volatile token's value can move without affecting the market's ability to pay. The payout rule is simple enough to be stated in one sentence. The cost is the absence of a quote, odds drift and the cold start, which are the properties that Engine II is designed to remove.

5Engine II: The Liquidity-Sensitive LMSR Market Maker

This section develops the mathematics of Engine II. We state the cost function used by the Polyquest program, derive its prices, and prove the properties on which the implementation relies: homogeneity, a two-sided bound on the overround, solvency, a fixed worst-case seed loss, bounded exponents, and the behavior of trades under rounding. Longer proofs are in Appendix B. Every inequality stated here was also checked numerically at 50 to 80 significant digits (Appendix B.6).

5.1Model and Cost Function

A market has $n\le 8$ mutually exclusive and exhaustive outcomes. The state is the vector $\mathbf{q}\in {\mathbb{R}}_{\ge 0}^n$ of outstanding shares, seed shares included; a share of outcome $i$ pays one collateral unit if $i^{\star }=i$.

Because $b(0)=0$, prices are undefined at the origin; the seed fixes both the initial prices and the initial liquidity $b_0$. We use three auxiliary quantities throughout: the scaled quantities $z_i=q_i/b(\mathbf{q})$, the weights $w_i=e^{z_i}/{\sum }_j{e}^{z_j}$, and the Shannon entropy $\mathcal{H}(\mathbf{w})=-{\sum }_i{w}_i\ln w_i\in (0,\ln n]$. Since ${\sum }_i{z}_i=1/\alpha$, the vector $\mathbf{z}$ ranges over the simplex $\{\mathbf{z}\ge 0:{\sum }_i{z}_i=1/\alpha \}$, and every quantity below depends on $\mathbf{q}$ only through $\mathbf{z}$ and the scale $b(\mathbf{q})$. We also write $\rho =(n-1)e^{-1/\alpha }$.

5.2Prices

The proof is in Appendix B.1. Equation (5.3) splits each price into the LMSR price $w_i$ at the current liquidity and a surcharge $\alpha \mathcal{H}(\mathbf{w})$ common to all outcomes. We checked Eqs. (5.3) and (5.4) against central finite differences of Eq. (5.2) at 300 random states; the largest discrepancy was $8.3\times 10^{-27}$. The displayed probability ${\pi }_i=p_i/{\sum }_j{p}_j$ follows directly:

The display is thus the LMSR weight vector shrunk toward the uniform distribution; it preserves the ranking of outcomes, and the shrinkage decreases as the market concentrates on one outcome, to a limit that is negligible for small $\alpha$ but not for large $\alpha$ and $n$ (Proposition 5.10).

5.3Homogeneity and Liquidity Sensitivity

Homogeneity is the precise sense in which the LS-LMSR is liquidity sensitive.

A trade of fixed size therefore moves prices $\lambda$ times less when $\lambda$ times more shares are outstanding. In an LMSR, by contrast, prices depend only on the differences $q_i-q_j$ and depth is fixed by $b$ regardless of volume. Figure 5.1 compares the two at equal worst-case loss.

5.4Overround

The upper bound is the one given by Othman et al. [10]; Eq. (5.7) and the lower bound are proved in Appendix B.3. For small $\alpha$ the lower bound is negligible: $\underline{\sigma }\approx n(n-1)(1+\alpha )e^{-1/\alpha }$, which is $4.3\times 10^{-9}$ for $n=2$ and $1.2\times 10^{-7}$ for $n=8$ at $\alpha =0.05$. At $\alpha =0.20$ and $n=8$, however, it is $0.43$: the overround never falls below 43 percent. Table 5.1 lists the maximal overround, and Figure 5.2 shows how the overround decays as a market concentrates.

5.5Solvency and Bounded Seed Loss

The capacity has derivative $\partial K_i/\partial q_i=p_i-1$, so buying outcome $i$ consumes its headroom while $p_i<1$ (see Proposition 5.11 for the complementary case).

Othman et al. bound the market maker's loss by $C({\mathbf{q}}^0)=S$ [10]; Eq. (5.11) is sharper because it credits the seed provider with the $x_0$ seed shares it holds, which always redeem for $x_0$. Two consequences are worth stating. By Proposition 5.3(ii), $S=x_0{\sum }_i{p}_i({\mathbf{q}}^0)$, so $L_{\max }/x_0=\alpha n\ln n$ equals the maximal overround. And because $K_{i^{\star }}$ is homogeneous of degree one, the market maker's result turns positive once outstanding interest is large enough in a given direction, since then $K_{i^{\star }}(\mathbf{q})>L_{\max }$.

5.6Bounded Exponent, Capacity at Saturation and Price Limits

The implementation evaluates exponents relative to the leader and clamps them at $z_{\max }=42$ (Section 6). By Lemma 5.9 the clamp can bind only if $1/\alpha >42$, that is $\alpha <1/42\approx 0.024$, which is reachable within the allowed range. At $\alpha =0.01$ the smallest relative weight is $e^{-100}\approx 3.7\times 10^{-44}$, far below the WAD resolution $10^{-18}$.

The proof is in Appendix B.4. The price floor is therefore of order $n{e}^{-1/\alpha }$ rather than $e^{-1/\alpha }$, and the displayed probability of the leader cannot exceed $\bar{\pi }$. Table 5.2 shows that the ceiling is irrelevant in practice for $\alpha \le 0.05$ but binding for $\alpha =0.20$ with many outcomes.

The ceiling $\bar{p}>1$ is not an artifact of the limit.

The proof is in Appendix B.4. For $n=2$ and $\alpha =0.05$ the threshold is $Y=39x_0$, and numerically the crossing occurs at $39.0x_0$; for $n=8$ it is $153x_0$. Buying beyond this point costs more than the largest possible payout, so no rational trader does it, and solvency is unaffected. Along the same path the capacity $K_1$ is smallest at the crossing, about $1.1\times 10^{-8}{x}_0$ for $n=2$ and $\alpha =0.05$, and then grows again with asymptotic slope $\alpha \ln (1+\rho )$ per share. The headroom thus approaches zero at saturation in relative terms, $K_1/q_1\to \alpha \ln (1+\rho )$, which is below $10^{-9}$ for $\alpha \le 0.05$ and $n\le 8$. Implementations must not assume $p_i\le 1$.

5.7Trading

A trade $\mathbf{\Delta }$ costs

negative for sells. The program charges a buyer $\lceil \kappa {\rceil }_{\epsilon }$ and refunds a seller $\lfloor -\kappa {\rfloor }_{\epsilon }$, rounding in favor of the pool.

Both proofs are in Appendix B.5. All statements hold in exact arithmetic; Section 6 bounds the effect of the fixed-point approximation $\tilde{C}$.

5.8Choosing $\alpha$

For a target worst-case loss $L_{\max }$, Proposition 5.8 fixes $b_0=L_{\max }/\ln n$ independently of $\alpha$ and $x_0=L_{\max }/(\alpha n\ln n)$. The parameter $\alpha$ then trades off four quantities. (i) The overround, bounded by $\alpha n\ln n$ (Table 5.1). (ii) Depth growth: $b(\mathbf{q})=b_0+\alpha ({\sum }_i{q}_i-n{x}_0)$, so each new outstanding share adds $\alpha$ to the liquidity parameter. (iii) Locked seed: $S=L_{\max }(1+1/(\alpha n\ln n))$, of which only $L_{\max }$ is at risk; smaller $\alpha$ locks more collateral. (iv) Numerical range: for $\alpha <1/42$ the exponent clamp of Section 6 can bind, and the price floor of Table 5.2 falls to the order of the WAD resolution $10^{-18}$ and below.

The default $\alpha =0.05$ satisfies $\alpha >1/42$, so the clamp never binds and every relative weight is at least $e^{-20}\approx 2.1\times 10^{-9}$, well inside WAD precision. For a binary market the maximal overround is $2\times 0.05\times \ln 2\approx 6.9$ percent and falls below 3 percent once ${\pi }_1\ge 0.9$ (Remark 5.6). The display ceiling is within $2\times 10^{-7}$ of one for every $n\le 8$, whereas $\alpha =0.20$ caps the leader's displayed probability at 0.986 for $n=2$ and 0.704 for $n=8$. With $L_{\max }$ fixed, the binary seed is $x_0\approx 14.4L_{\max }$. The maximal overround grows as $n\ln n$, reaching 83 percent for $n=8$ at the default; a target $v$ corresponds to $\alpha =v/(n\ln n)$, but at $n=8$ even $\alpha =0.01$ gives 16.6 percent, so the permitted range cannot deliver a small spread for markets with many outcomes. Section 12 compares the LS-LMSR with the LMSR and the CPMM in simulation.

6Fixed-Point Implementation on Solana

This section describes how the Engine II program evaluates the cost function of Section 5 in integer arithmetic, shows that the approximation $\tilde{C}$ cannot compromise solvency, and measures its accuracy on a reference emulation of the design written for this paper (Appendix C), not on the program itself.

6.1Number Format and Determinism

State transitions must be bit-identical on every validator, and every amount that moves collateral must be rounded in a known direction. Solana supports only a subset of floating-point operations, emulated in software at higher compute cost [31], and a 53-bit significand cannot represent every 64-bit token amount, so directed rounding could not be enforced exactly. Polyquest therefore uses unsigned 128-bit fixed point with scale $\mathrm{WAD}=10^{18}$, storing $x\ge 0$ as $\lfloor x\cdot \mathrm{WAD}\rceil <2^{128}\approx 3.4\times 10^{38}$, with hand-written exp and ln. Shares and balances stay on the collateral grid $\epsilon =10^{-d}$, one grid unit being $g=10^{18-d}$ WAD units, which requires $d\le 18$.

6.2Elementary Functions

Both functions use range reduction followed by polynomial or series evaluation [33] (Algorithms C.1 and C.2). For exp we write $x=k\ln 2+r$ with $|r|\le \frac{1}{2}\ln 2$, reducing at scale $10^{36}$ so that the error does not grow with $k$, evaluate the degree-16 Taylor polynomial of $e^r$ in Horner form (truncation error below $10^{-22}$) and shift by $k$ bits. For ln we write $y=2^{k}m$ with $m\in [1/\sqrt{2},\sqrt{2})$, form $s=(m-1)/(m+1)$ as one rounded quotient ($|s|<0.172$) and sum 12 terms of $\ln m=2\mathrm{atanh}s=2{\sum }_{j\ge 0}{s}^{2j+1}/(2j+1)$ (truncation error below $10^{-20}$). After reduction every product in the Horner loops is below $5\times 10^{35}$ and fits in 128 bits, and trip counts are fixed, so no input makes evaluation more expensive.

6.3Stable Evaluation of the Cost Function

Eq. (5.2) cannot be evaluated directly, since $e^{q_i/b}$ reaches $e^{1/\alpha }=e^{100}$ at $\alpha =0.01$. We factor out the leading outcome:

Each weight $e^{-u_i}$ lies in $(0,1]$, the leader's is exactly one, so $\Omega \in [1,n]$, and $u_i\le 1/\alpha$ by Lemma 5.9. Algorithm C.3 forms each weight as the reciprocal $\lfloor {\mathrm{WAD}}^2/\tilde{\exp }(u_i)\rfloor$ of an exponential with nonnegative argument, after clamping $u_i$ at $z_{\max }=42$. The constant lies between two limits of the format: at $u=\ln 10^{18}\approx 41.45$ the reciprocal floors to zero, and near $u=47.28$ the WAD value of $e^u$ overflows 128 bits. The clamp binds only if $\alpha <1/42\approx 0.024$, which the allowed range includes. When it binds, the computed weight is zero, as it already is for every $u>41.45$, while the true weight is below $e^{-42}<6\times 10^{-19}$, less than one WAD unit; the clamp only keeps the argument of exp in range.

The liquidity parameter $b=\alpha Q$, $Q={\sum }_j{q}_j$, is never rounded on its own: $u_i$ is the single quotient $\lfloor (q_{\max }-q_i){\mathrm{WAD}}^2/(\alpha Q)\rfloor$, which makes $u_i\le 1/\alpha$ exact in integers (Invariant 11.4), and $b\ln \Omega$ is one rounded quotient of $\alpha Q\Lambda$ with $\Lambda =\tilde{\ln }\Omega$. Displayed prices, which never move collateral, evaluate Eq. (5.4) in the same weights as $p_i=q_{\max }/Q+\alpha \ln \Omega +(e^{-u_i}-{\sum }_j{q}_j{e}^{-u_j}/Q)/\Omega$.

6.4Rounding Policy and Solvency

The cost of a trade is the difference $\tilde{\kappa }=\tilde{C}({\mathbf{q}}^{\prime })-\tilde{C}(\mathbf{q})$ of two complete evaluations on states. A buy pays $\lceil \tilde{\kappa }{\rceil }_{\epsilon }$, and at least one grid unit; a sell receives $\lfloor -\tilde{\kappa }{\rfloor }_{\epsilon }$ and reverts if $-\tilde{\kappa }<0$; the seed is $S=\lceil \tilde{C}({\mathbf{q}}^0){\rceil }_{\epsilon }$ (Algorithms C.4 and C.5).

These results carry Proposition 5.12 over to integer arithmetic without any error bound in their hypotheses: the accuracy of exp and ln affects the price a trader pays, never the vault's ability to pay. They hold for any implementation that evaluates $\tilde{C}$ on the full state, never incrementally, and satisfies Lemma 6.1.

6.5Overflow and Headroom

SPL token amounts are 64-bit integers [30], so an amount becomes at most $(2^{64}-1)\cdot 10^{18-d}\le 1.84\times 10^{37}$ WAD units, the worst case being $d=0$. Outcome shares are SPL tokens on the same grid, so $Q\le 8\times 1.84\times 10^{37}=1.48\times 10^{38}$: a headroom factor of 2.31 below $2^{128}$ at $d=0$, and $2.31\times 10^d$ in general ($2.3\times 10^6$ for a six-decimal stablecoin). Also $\tilde{C}\le q_{\max }+\alpha Q\ln n\le 8.0\times 10^{37}$ (factor 4.3) and exponentials stay below $e^{42}\mathrm{WAD}\approx 1.7\times 10^{36}$. Products of two WAD quantities need not fit in 128 bits ($\alpha Q$ alone reaches $3.0\times 10^{55}$), so three products use a 256-bit intermediate (mul-div): the exponent numerator $(q_{\max }-q_i){\mathrm{WAD}}^2\le 1.8\times 10^{73}$, the product $\alpha Q\Lambda \le 6.1\times 10^{73}$ and the price accumulator ${\sum }_j{q}_j{e}^{-u_j}\cdot \mathrm{WAD}\le 1.5\times 10^{56}$, all at least 1,800 times below $2^{256}\approx 1.16\times 10^{77}$. Tokens with very large supplies and any $d\le 18$ therefore need no special cases.

6.6Outcome Limit

A trade evaluates Algorithm C.3 on the new state, and on the old state unless its value is cached; each evaluation costs $n$ exponentials, one logarithm and $O(n)$ wide mul-divs. The work is linear in $n$, and the per-transaction compute budget [31], shared with the swap route in swap-to-bet (Section 7.4), limits Engine II on Solana to $n\le 8$; the EVM sibling allows 32. We report no compute-unit measurements of the program. Budget orders (Proposition 5.13) should be solved by the client and enforced by the payment bound ${\kappa }_{\max }$ rather than bisected on-chain.

6.7Measured Accuracy and Property Tests

We implemented Algorithms C.1 to C.5 as a bit-exact integer emulation in Python that checks every stored value against 128 bits and every wide product against 256 bits. Table 6.1 and Figure 6.1 compare it with mpmath at 50 significant digits on $10^6$ random inputs per routine, drawn across the domain on which each routine is used. These are measurements of the reference emulation, not of the program itself.