Why the betting liquidity pool loses stability
Thin liquidity — a pool held by a few providers — looks functional right up until the first large bet. A bet sized at a few percent of its depth eats the best levels, and slippage moves the actual odds away from what the user saw. They leave for another source, and the remaining liquidity becomes even more imbalanced.
A liquidity provider calculates yield from fees and rarely accounts for impermanent loss.
When odds move, the pool composition diverges from external prices: arbitrageurs buy up the cheaper asset and return it after the shift, and the pool retains an overweight of the falling asset.
Betting fees do not always cover this gap, and the first to exit the pool is the one who calculates faster than others.
The second group of problems is settlement-related. The outcome for an event arrives with a delay from the source, odds are recalculated based on stale state during this time, and payouts sit in “processing” status.
A desync of odds between the pool and external venues opens simple arbitrage: a bet is taken at our price while already knowing the determined outcome.
Next we break down how this is closed: pricing by pool depth, limits on bet size relative to liquidity, cross-confirmation of outcomes, and a payout queue with a reserve fund.
Measurable effect: what changes in settlement and payouts
A liquidity pool is not a single payout function but a chain: record the outcome, take the price at a given moment, recalculate shares, and distribute accruals. While these steps live in scripts around the exchange interface, each link breaks in its own way. When the rules are described in a contract, each link becomes measurable.
Settlement time and availability. Previously, the result for an event was assembled over hours: exporting trades, reconciling with logs, manually recalculating shares.
In a contract-based pool, settlement runs in a single pass: the result appears within a minute after outcome confirmation, and intermediate states are available at any time. A participant sees what their share is made up of without contacting support.
Share of disputed settlements. A dispute is almost never about the event outcome but about the arithmetic: whose rate, at which second, with what tolerance.
The fixation moment, price source, and deviation threshold are specified in the pool rules; for thin pairs, we take an aggregated source such as Chainlink and fix the median over a window. The share of disputed requests falls from tens of percent to isolated cases.
Slippage and depth. Position size is limited by the exposure limit per outcome, entry and exit run against the reserved part of the pool.
Slippage on a typical operation is reduced severalfold: a large entry no longer moves the quote so much that the payout to the first participant eats into the second participant’s share.
Failure classes that go away. Double accrual, payout at a stale price, a stuck settlement when an external service is unavailable are separate failure classes, not “rare bugs.” They are closed by idempotent accrual, a hard window for price fixation, and a backup source.
Comparison of pool schemes: automatic, managed, hybrid
The pool scheme determines who quotes prices, where depth comes from, and how the liquidity provider fee is calculated. When launching betting, the real choice is between three configurations — and each breaks under its own load pattern.
| Variant | When it fits | Limitations |
|---|---|---|
| Automatic pricing by formula from reserve balances | Steady flow of trades, no dedicated operator, need for uninterrupted operation | On thin liquidity, a one-sided imbalance moves the price away from the market, and arbitrage drains the reserve |
| Managed pool with an operator | Volatile pairs, a narrow circle of participants, need for manual quote adjustment | Reaction depends on a human, and the lag between market movement and the new price grows |
| Hybrid settlement scheme with an external liquidity source | Need for depth at launch and protection from sharp moves | More complex accounting of shares and accumulated fees, plus dependence on an external provider |
Where each scheme breaks
The automatic one cannot tolerate gaps between reserves: as soon as one side of the pool is emptied, the settlement price stops reflecting the market, and liquidity providers record a loss instead of income.
The managed scheme withstands volatility but loses on volume — the operator physically cannot keep up with re-quoting at a high trade frequency.
The hybrid settlement scheme covers both extremes if the external liquidity source is synchronized with internal accounting. During desync, participant shares and accrued liquidity provider fees diverge, and reconciliation turns into manual review.
That is why the scheme is fixed before launch: changing the model affects already distributed shares and accrual history.
Stages of work: from mechanics audit to handover of regulations
A betting liquidity pool is a bundle of contracts, an outcome oracle, and payout settlement. An error in any layer becomes visible on live money, so the stages proceed strictly sequentially: the next starts only after verification of the previous one.
- Audit of pool mechanics. We analyze bet acceptance, calculation of the liquidity provider share, and system behavior when the pool becomes imbalanced to one side. The result is a map of bottlenecks with a risk assessment for each.
- Fund flow diagram. We document the contours — bet acceptance, payout reserve, provider rewards — and how funds move between them. The diagram becomes a shared point of truth for development and verification.
- Outcome settlement setup. We determine the result source, how many confirmations are required, and by what rule settlement closes when data diverges. This is where most disputed situations arise.
- Implementation and internal verification. We cover edge scenarios: zero liquidity, event cancellation, a sharp increase in bet volume.
- Testing on historical data. We run the mechanics on past events and real bet profiles, compare payout calculation with the expected one, and observe pool behavior during volatile periods.
- Documentation handover and launch. We deliver a description of the contours, settlement policy, deployment procedure, rollback plan, and maintenance checklists.
After handover, your team runs the pool independently: decisions are fixed in regulations, not held in engineers’ heads.
Flow diagrams, rights matrix, and settlement regulations
The settlement loop outlives both the team that built it and the contractor that configured it: administrators, signers, and pool composition change.
That is why we deliver every artifact in a form readable without access to chats and private channels — from it, a new engineer or your auditor can reconstruct the logic of fund movement.
- Fund flow diagram — from pool funding to reward accrual and withdrawal: at which step the balance changes, which contract is called, where funds are held in an intermediate state.
- Role diagram — depositor, parameter operator, treasurer, observer: which operations each role signs and where its authority ends.
- Access rights matrix — a “role × operation” table: fee change, limits, pause, logic update, withdrawal of collected fees. For critical operations, the signature threshold and the circle of key holders are specified, alongside a parameter change log: who, when, and why they changed the rate.
- Disputed outcome review policy — how we record divergence (a balance snapshot at settlement time and an event log), within what period we respond, who makes the decision, and how the case is closed with an entry in the log.
- Emergency stop instruction — step-by-step pause procedure, the fate of accrued but not withdrawn rewards, and bringing the pool back into operation with invariant checks.
- Settlement logic update policy — a run on a pool copy, change window, state migration, and a pre-described rollback to the previous version.
- Settlement loop documentation — accrual formulas and rounding rules, state snapshot procedure, behavior at boundaries: zero liquidity, sharp withdrawal by a large participant.
Case: turnover grew, share of disputed settlements fell severalfold
A pool for blockchain-based sports betting launched on a mixed scheme: liquidity sat in several wallets, and odds were calculated by a settlement module based on a rate that the operator entered manually.
On peak weekends, the pool could not close large positions in time, payouts were delayed by up to 9 hours, and discrepancies between the recorded rate and the market price were reviewed manually.
The share of disputed settlements reached 7.4% of all events in the season. Each dispute meant a halted withdrawal, correspondence, and retroactive recalculation; liquidity providers moved their volume away because they did not understand how the price was formed.
What was changed
The pool was split into a core and a reserve for large payouts — a drawdown in one market no longer moved the price of the entire pool.
The rate and payout events were tied to the Chainlink oracle, and a divergence corridor was set: when it is exceeded, bet acceptance on the market closes automatically, and settlement runs at the last confirmed price.
Payouts were moved to batch settlement with deterministic ordering and an event log: resending does not create a second payout, and a stuck transaction is raised automatically. A dashboard for each market shows depth, slippage, and the share of rejected bets.
What became
Over two seasons, pool turnover grew 4.5x, and depth on the busiest markets stays within 3% of target. The share of disputed settlements fell to 0.8% — the remaining cases are almost always related to operator input error, not settlement logic.
Average payout time is 40 seconds, and the 99th percentile stays within 4 minutes even during peak hours.
How does oracle-based settlement differ from multisig settlement?
Oracle-based settlement takes the outcome from an external source — a public exchange order book or a set of quotes from several venues. Multisig is based on a decision by a group of confirmers: the transaction goes through only after the key threshold is reached.
The first scheme fits where the outcome is an unambiguous number; the second fits where the result requires interpretation: event recognition, disqualification, a legal fact.
Oracle confirmation latency consists of the source update interval and the dispute window — settlement fits within minutes and does not depend on human presence.
Multisig waits for each threshold participant’s signature: while keys are being collected, the pool holds an open position, and the quote becomes stale. In a market with short rounds, such a pause turns into a systematic loss on time.
The cost of confirmation is also of a different nature. Oracle — payment for requests and a subscription to a quote stream; it is predictable and does not grow with the number of bets.
Multisig is cheaper for infrequent settlements but requires maintaining a set of keys, monitoring rotation, and paying confirmers.
Trust: with an oracle, the risk lies in the source — data manipulation or venue failure; with multisig, it is collusion by confirmers, and the threshold only raises its price but does not remove it.
The settlement scheme is chosen based on settlement frequency and outcome verifiability. For price and sports markets — an oracle with an aggregate of several sources, outlier rejection, and a backup data channel.
For event-based ones — threshold multisig with key rotation, a dispute window, and a bond. In a hybrid scheme, the oracle closes the round, and multisig acts as an appeal within the dispute window.
Questions about oracles, exposure, and fees
The oracle provides the event result, but several technical caveats lie between result publication and payout. They are rarely visible in tests and surface after the pool launch, when bets are already in it.
Exposure is calculated as a net position for each outcome separately, not for the market as a whole.
The limit per outcome is set in the pool parameters: when it is reached, bet acceptance for that outcome closes, and odds are recalculated based on the actual distribution of funds.
What happens to open bets during a disputed outcome?
Payout settlement is frozen, and funds remain in the pool contract. The resolution window is extended for the appeal period, the result is fixed by the oracle’s decision; on timeout, the rule for returning the bet principal applies.
When is the pool fee charged?
At the moment of payout settlement, not when the bet is accepted. It is not withdrawn to a separate wallet but remains in the pool and increases the liquidity providers’ share — yield is calculated upon settlement.
How can a new market be added without stopping the pool?
A market is a separate entry in the contract registry with a shared liquidity pool. It is added by an administrator transaction, receives an outcome limit, and connects to the same oracle; open bets on other markets are not affected.
What happens to contracts when settlement logic changes?
The update goes through a proxy contract: the implementation changes, and the pool state and open bets are preserved. The logic version is recorded at the moment of the bet — already accepted ones are settled under the previous rules.
Let’s discuss the task and come back with an estimate and plan
To return with a scope estimate rather than generalities, we need the task statement in your logic: which network and staking type, whose token is accepted into the pool, how rewards are accrued, and what happens on exit from the pool.
The more specifically the economics are described, the more accurately we will break the work down by stage.
We will separately discuss access and data — their absence usually delays the start. A test environment, access to contracts, and an understanding of who on the customer side accepts the result are enough. From this, we assemble the scope of work, implementation plan, and effort estimate.
- Task statement: network, staking type, participant roles, entry and exit scenarios for the pool.
- Economics: reward source, protocol fee, distribution procedure among liquidity providers.
- Access and data: repositories, test environment, nodes, access to contracts and keys with a described storage model.
- Constraints: deposit and withdrawal limits, reporting requirements to pool participants.
- Scope of work: contracts, wallet integration, position monitoring, security checks.
- Implementation plan: stage order, acceptance points, mainnet rollout, post-launch support.
As a result, you receive a work plan with stages, acceptance points, and areas of responsibility. Describe the task in free form — we will return with an estimate and a breakdown of contentious points.