Limitations & honest tradeoffs

DekantPM makes specific choices that buy real on-chain tractability at the cost of theoretical generality. Here's the unvarnished list.

Single-bin resolution

Continuous markets resolve to exactly one bin. The bin containing the resolved value pays $1 per token; every other bin pays $0.

This means a curve that placed 40% of its mass in bin 2 and 39% in bin 3 - clearly a "right idea" bet - pays out fully on whichever of the two contains the actual value, and zero on the other. There's no smooth gradient between bins.

For most use cases this is fine because:

• A typical distribution buy spreads stake across 5-12 bins near the peak.
• Even if the resolved value lands in a bin adjacent to the peak (not the peak itself), the trader still earned some payout - just less than if they'd nailed the peak.

But: a trader whose curve straddled exactly two bins of equal mass receives a roughly binary outcome from a small movement in the resolved value. This is the "bin boundary" problem. Designers can mitigate by picking [a, b] with finer bins; traders can mitigate by drawing slightly wider curves.

Fixed N per market

The number of bins N is set at market creation and cannot be changed. There's no way to subdivide a bin midway through the market or merge bins.

This forces an upfront design tradeoff:

Most real markets land at N = 32 or N = 64 - fine enough for sub-percent resolution on price questions, coarse enough to keep liquidity meaningfully concentrated.

Normal-distribution-only

The distribution-buy primitive uses a Gaussian PDF for weights. Other shapes (skewed, bimodal, uniform-with-spike) are not directly expressible.

A trader who wants a non-Gaussian belief - e.g., "either ETH stays flat at $3,000 OR it pumps to $5,000+, but nothing in between" - has two workarounds:

1. Compose multiple distribution buys. Place one buy with μ = 3000, σ = 100 and a second with μ = 5500, σ = 200. The combined position is a sum of two Gaussians and reads as a bimodal curve. (You pay two trade fees.)
2. Place discrete buys on individual bins. For very specific shapes, just buy the bins you care about one at a time.

Neither is as efficient as a native non-Gaussian primitive, but both work.

Discretization approximation error

The bin discretization integrates the Gaussian PDF using bin centers, not exact integration over each bin's interval. For very narrow Gaussians (σ small relative to the bin width (b−a)/N), this introduces noticeable error.

Concretely: if σ ≈ (b−a)/(2N), the curve has roughly one bin width of standard deviation. The PDF varies dramatically across each bin, and using only the center as a sample gives ~5-10% weight error on the affected bins. The protocol does not warn about this; the trade still succeeds.

Mitigation: don't draw curves with σ smaller than 2-3 bin widths. The trading UI displays a "Sharp / Focused / Wide / Hedged" label for σ partly to discourage absurdly tight bets.

No dynamic fee adjustment

Fees are set once by superadmin and remain constant for the market's life. There is no mechanism that raises fees during high-volatility periods or lowers them during low volume.

This is a design simplification, not a fundamental limitation. A future version could implement Curve V2-style dynamic fees if the data justified it.

No partial resolution

Markets resolve atomically: either the oracle posts a value and the market is fully resolved, or the market sits in PendingResolution until they do. There's no mechanism to resolve part of a market early (for example, paying out some of the curve while keeping the rest active).

For long-dated markets, this means LPs and traders are locked in until the oracle acts. The mitigation is choosing reasonable deadlines and reliable oracles.

Oracle trust

Final resolution comes from a role-gated oracle PDA. The protocol does not currently support multi-oracle consensus, dispute resolution, or data-feed verification. Picking the right oracle for a given market is the market designer's responsibility.

For mainnet, the protocol team will operate the default oracle for canonical questions (e.g., "ETH closing price on date X") using vetted data feeds. Custom markets can specify any oracle PDA.

Single-collateral

Every market settles in USDC. There is no mechanism for SOL-collateralized markets, BTC-collateralized markets, or multi-collateral pools. This keeps the math clean (no FX risk inside the AMM) at the cost of forcing every trader through USDC.

Compute-unit ceiling

Distribution buys on 256-bin markets are within the Solana per-transaction CU budget but use a meaningful fraction of it. Any change that adds per-bin computation (more sophisticated weight functions, on-chain analytics) risks bumping individual instructions past the limit.

The current 256-bin ceiling is the largest the protocol can support without splitting trades across transactions. Making the ceiling higher would require batching or precomputing weights off-chain.

What this list isn't

The whitepaper at pa-ya.github.io/dekantpm goes through these tradeoffs from the math side. This page is the practitioner's version: what to actually watch out for when designing markets or sizing distribution trades.

If a limitation here surprises you, that's worth flagging - open an issue at the GitHub repo.