The pool phase at event end

What the pool phase is

The pool phase is a dedicated phase of an event's lifecycle, slotted between the close of new challenge placement and the final resolution. Concretely, it's a window of a few minutes just before close, during which:

• No new challenges can be started.
• No user-side cancellation is possible anymore (temporary lock).
• The system gathers all unmatched residuals and computes a mutualized pool.

It starts at a timestamp poolPhaseStartsAt = closesAt − Δ, where Δ depends on the event's duration. You see this timestamp in the event details under "Pool phase starts at."

How long the pool phase lasts

Δ is computed automatically from the event's total duration:

• Event < 1h: Δ = max(5min, 10% of the duration). Example: a 30-minute event → Δ = 5min.
• Event between 1h and 24h: Δ = a fixed 15min.
• Event between 1 and 7 days: Δ = 30min.
• Event > 7 days: Δ = 60min.

The event admin can override this value (between 5 and 120 minutes) at creation, for example for a sensitive event that needs more computation time.

What goes into the pool

When the pool phase starts, the system lists every challenge of which some part hasn't found an opponent in phase 1 (live matching). These residuals are grouped by outcome: for each outcome of the event, the sum of the residual amounts forms its mass.

• Outcome "Argentina wins": sum of the residuals placed on it = that outcome's mass.
• Outcome "France wins": sum of the residuals placed on it = that outcome's mass.

An indicative pool multiplier is computed for each outcome: an outcome's multiplier is the ratio between the pool's total mass and that outcome's mass, less the commission. The smaller an outcome's mass is relative to the total, the higher its multiplier.

The iterative computation (and why)

Each participant has a personal minimum pool multiplier preference (between 1.00 and 5.00, in steps of 0.10, default 1.20). If the multiplier computed for their outcome falls below their threshold, they refuse the pool and must be refunded.

But removing a participant changes the masses, which changes the multipliers, which can push another participant below their threshold. Hence the iterative computation:

1. Compute each outcome's multiplier with all residuals.
2. Identify the participants below their threshold.
3. If there are any, refund the most demanding one (the one with the highest threshold). On a tie, FIFO (the oldest first).
4. Recompute the multipliers with the remaining participants.
5. Repeat until convergence (everyone above their threshold) or a degenerate pool (fewer than two covered outcomes).

On convergence, everyone remaining enters the pool at the final computed multiplier. Refunded participants receive 100% of their residual with no commission whatsoever.

Atomicity and guarantees

The whole computation runs in memory, then is applied in a single atomic transaction:

• Challenge status updates (POOLED for the accepted ones, REFUNDED for the others).
• Creation of the MutualPool + PoolParticipation entries.
• User balance credits for the refunds.
• Insertion of the BET_REFUNDED transactions.
• Full audit of every iteration (debug + support).
• Event transition to the CLOSED status.

If any single element fails, everything is rolled back and the event stays in POOL_PHASE; the system retries (up to 3 times with backoff). Guarantee: no financial drift is possible - not a cent can be lost or created.

The degenerate pool case

The pool is said to be degenerate if fewer than two outcomes are covered when the pool phase starts: every residual sits on one and the same outcome, so no counterparty is possible. No multiplier can be computed. In that case:

• All residuals are refunded at 100%, with no commission.
• You get a notification "Your challenge was refunded (no counterparty in the pool)."
• The event moves directly to CLOSED.

Also: if the pool phase starts with zero residual in total (everything matched in phase 1), the pool phase is skipped and the event moves directly to CLOSED.

If the winning outcome has no stake in the pool

This case only concerns events with three outcomes or more. On such an event, an outcome with no stake does not make the pool degenerate: the pool forms as soon as at least two outcomes are covered. But if the outcome that comes true is precisely one left without a stake in the pool, nobody has won the pool: every pool participation is refunded in full, with no commission - including those placed on the losing outcomes.

• Only the pool is affected: if part of your challenge was matched in a lot during the event, that part is settled normally.
• Your pool participation can therefore come back to you even though your outcome lost. That is not an error, it is the rule.

On a two-outcome event, this case cannot happen: a pool only forms there if both outcomes have stakes. Otherwise, it is degenerate and refunded as soon as the pool phase starts.

Hybrid challenges (partially matched P2P)

A challenge can be partially matched in phase 1 and have a residual that enters the pool phase. Example:

• You stake 100K. The cascade matches 70K P2P during the event.
• 30K remain as a residual when the pool phase begins.
• The pool accepts your residual at a multiplier of 1.40 → your challenge is now "70K matched P2P + 30K in the pool at 1.40."
• If you win, you collect: the P2P winnings (70K × P2P multiplier) + the pool winnings (30K × 1.40), minus the corresponding commissions.

The pool refuses your residual? You keep the 70K matched P2P, and you get the 30K back as a refund. You see both components clearly in the challenge details.