How is an event resolved?

AUTO mode: resolution without a human

For major sports events, we use reliable external APIs: API Sports, football-data.org, ESPN API, and other trusted sources depending on the discipline.

When a match ends, the API sends us the result. Our system computes a confidence score on that result (cross-checking multiple sources whenever possible). If confidence is ≥ 95%, resolution is automatic. No human intervention.

Examples:

• Real Madrid vs Barcelona: API Sports returns "Real Madrid 2-1 Barcelona". Confidence score 99% (official La Liga source). Automatic resolution.
• Lakers vs Celtics: ESPN API returns "Lakers 112-108 Celtics". Score 98%. Automatic resolution.

Typical timeframe: less than one minute after the end of the match. The delay is mostly the time it takes the API to refresh its data.

SEMI-AUTO mode: suggestion + admin validation

For events where automatic confidence is insufficient (between 70% and 95%), or for non-sports topics (politics, crypto, culture), we use semi-auto mode.

The algorithm proposes a resolution based on the best available sources. A Ktkarena admin validates before publication. The process:

1. The event moves to FETCHING status as soon as the deadline passes.
2. The algorithm looks for the result across the configured sources.
3. Status moves to SUGGESTED with a suggestion sent to the admin.
4. The admin verifies within a few minutes (or a few hours for complex cases).
5. Status moves to MANUALLY_RESOLVED (with admin validation) or AUTO_RESOLVED if the admin accepts it as is.

Typical timeframe: 5 minutes to 4 hours depending on complexity.

Examples:

• French presidential election: multiple sources (Le Monde, AFP, Constitutional Council). The admin validates after final confirmation.
• Bitcoin price at a given moment: CoinGecko + Binance sources. The admin verifies the exact timestamp.

MANUAL mode: admin entry with evidence

For events with no automatically verifiable external source, the admin enters the result by hand, with supporting evidence archived.

That evidence can be:

• An official screenshot of the result.
• A link to the official announcement.
• A photo of the reference document.
• A press article from a reliable source.

The evidence is permanently archived in the database. In case of a dispute, it can be reviewed. Valid dispute types.

Typical timeframe: 24 hours to 7 days depending on complexity.

Examples:

• Miss Cameroon pageant: no API. The admin waits for the pageant's official announcement and enters the result with the official photo.
• Local amateur match: the admin relies on the club's official Facebook accounts or a press release.

An event's lifecycle: from DRAFT to RESOLVED

Even before resolution, every event follows a complete lifecycle:

Event lifecycle: DRAFT (created by the admin) → OPEN (betting open) → POOL_PHASE (temporary lock, computing the mutualized pool for unmatched residuals) → CLOSED (betting closed, awaiting resolution) → RESOLVED (result published, winnings distributed).

This atomic phase computes, at the end of the event, who enters the mutualized pool and who gets refunded according to their preferences. You receive a notification as soon as it completes.

The state machine: PENDING → RESOLVED

Every event goes through this sequence of states:

PENDING (before deadline)
   ↓
FETCHING (retrieving the result)
   ↓
SUGGESTED (result proposed)
   ↓
   ↓ → AUTO_RESOLVED (confidence ≥ 95%, auto-published)
   ↓ → MANUALLY_RESOLVED (admin validated)
   ↓ → DISPUTED (dispute in progress)
   ↓ → CANCELLED (event canceled for an external reason)

You can track the status of your bets in real time in the app. The status is displayed transparently, with a timestamp at every transition.