What the matching loop is
When you place a bet, the placement cascade immediately (within a few seconds) tries to match you. If it doesn't fully succeed, the residual of your bet is set to waiting for an opponent. But you're not forgotten: a matching loop runs continuously and keeps searching for you.
Concretely, two mechanisms trigger it:
- Event-driven: as soon as a new bettor places a bet on the side opposite yours (at a compatible amount, on a compatible tier), the matching loop immediately attempts the cascade to pair you.
- Periodic cron: at least once per minute, the matching loop scans all the event's residuals and re-attempts the full cascade, in case a new combination has become possible (for example two small opposing bets that arrived independently but add up to match your residual).
The loop runs as long as the event is in OPEN status. It stops when the pool phase starts (a few minutes before close).
How long you can stay waiting
Until the pool phase begins. If you bet on a match starting in 3 hours, your residual can stay waiting for about 2 hours 45 minutes (the last ~15 minutes being reserved for the pool phase). For an event spanning several days, it can be several days.
When the pool phase begins, your residual automatically rolls into the pool computation. Depending on your pool acceptance preference and your minimum odds, you'll either be absorbed into the pool or refunded in full. You're never left stuck: at the end of the event, you're either matched (P2P or pool) or refunded.
What to do while you wait
1. You wait. The matching loop is working for you. No need to refresh, no need to resubmit. Push + in-app notification as soon as a match is found.
2. You cancel. At any time, as long as you're not matched, you can cancel without penalty - 100% of your KTK comes back immediately. How to cancel before matching.
3. You adjust indirectly. Cancel and place a new bet with a different amount or tier. That can speed up your matching if you pick a more liquid tier. How to change tiers.
4. You tune your pool preferences. If you want to maximize your chances of having a counterparty at event end (even if it means accepting the pool), set your acceptPool to "If needed" or "Always" and lower your minimum odds. If instead you want to play 100% P2P, raise the odds or refuse the pool. Careful: your preferences are frozen at placement time, so changing them afterwards only affects future bets, not the one in progress.
Why it's no longer "FIFO"
In the old model, the queue was strictly FIFO (first come, first matched). In the new model, the matching loop does better: it re-runs the full cascade at every tick (direct match → inter-tier → aggregation). That means your residual can be matched:
- Directly with a new opposing bet at the same tier (the FIFO equivalent).
- With an opposing bet from a neighboring tier (cascade).
- With a combination of several small opposing bets (aggregation).
This flexibility drastically shortens waiting times on events with asymmetric liquidity. In the vast majority of cases, a residual gets matched within the hour after it starts waiting.
Event edge cases
If the event starts before the pool phase (rare, but possible for "live" events): the pool phase follows immediately after betting closes, so your residual goes into the pool computation even if the event has already started.
If a new bettor arrives 1 second before the pool phase: the matching loop immediately triggers the cascade and matches you. You're not blocked by the timing.
If several opposing residuals can match at the same time: the algorithm prioritizes by residual arrival order (FIFO on the residual list), while optimizing for maximum coverage (covering as many residuals as possible in one pass).