Executive Summary
A liquidity bootstrap pool (LBP) discovers a new token's market price by starting a weighted pool heavily skewed toward the token and letting the weight balance shift toward the paired reserve asset over a fixed window, which pushes the spot price down over time independent of trading volume. Most LBP implementations offer only a single, fixed linear weight decay. JIL Sovereign's weighted-pool engine instead treats the decay shape itself as a per-pool configuration choice among four curve types - Linear, Exponential, Logarithmic, and Step - each computing the same underlying weighted constant-product invariant but pacing the weight transition differently.
Every quote, at every point in the sale, is computed from the same core formula - price is a function of reserve balances and their current weights - so the curve selection changes only how quickly weight (and therefore price) moves through the sale window, not the pricing mechanism itself. Every individual bid is additionally re-checked against a mandatory compliance gate before it is even quoted, on top of per-wallet and total-raise caps and an anti-bot grace period at launch.
Problem Statement
A fixed linear weight-decay schedule gives every token launch the same price-discovery dynamic regardless of what distribution outcome the issuer actually wants. An issuer worried about early-window whale accumulation at the most inflated starting price has no way to front-load the weight shift to compress that window; an issuer who wants a smoother, more gradual descent has no way to back-load it either - both are stuck with the same shape.
Why a Single Fixed Curve Falls Short
- Linear-only decay: Offers no mechanism to compress or extend the highest-price window, regardless of what dynamic best fits a given token's expected demand curve.
- Fixed-shape deployments requiring custom contracts: Achieving a different decay shape without a configurable curve parameter means deploying and auditing an entirely separate pool implementation.
- Compliance checked only at launch: A compliance gate evaluated once at pool creation does nothing to stop a since-sanctioned or newly-ineligible participant from bidding mid-sale.
Technical Architecture
Selectable Curve Shapes
| Curve Type | Progress Function (t = elapsed/duration) | Effect |
|---|---|---|
| Linear | progress = t | Constant-rate weight shift across the full window |
| Exponential | progress = t² | Back-loaded - slow early shift, accelerating later |
| Logarithmic | progress = ln(1 + 9t) / ln(10) | Front-loaded - fast early shift, tapering later |
| Step | progress = floor(4t) / 4 | Four discrete tranches rather than continuous movement |
The resulting (weight_0, weight_1) pair feeds the same weighted constant-product spot-price and swap-quote formulas regardless of which curve produced it, so curve selection is purely a pacing choice layered on top of one pricing engine, not a different pricing engine per curve.
Bid-Level Protections
| Protection | Enforcement |
|---|---|
| Anti-bot grace window | Bids rejected until anti_bot_blocks have elapsed after pool start |
| Per-wallet cap | max_purchase_per_wallet, tracked cumulatively per participant address |
| Total-raise cap | max_total_raise, checked before every quote and every applied swap |
| Compliance gate | Every bid independently re-checked against the compliance engine before being quoted; fail-closed if unreachable |
Prior Art Differentiation
| Approach | Curve Shapes | Per-Bid Compliance? |
|---|---|---|
| Standard weighted LBP (fixed linear decay) | 1 (linear only) | No / launch-time only |
| Dutch auction (single fixed decay function) | 1 | No |
| JIL Sovereign | 4, per-pool selectable | Yes - every bid, fail-closed |