How Are Live-Camera Betting Markets Settled?
The camera is the oracle: Lukk, by Adkuu, freezes a hashed rule before the first bet, signs the deciding frames, and refunds every stake if the camera cannot tell.
Live-camera betting markets are settled by the camera itself. On Lukk, by Adkuu, the settlement rule is frozen and hashed before the first bet is accepted; when the window closes, the deciding frames are locked, signed and published with the result, and either a deterministic counter or a vision judge applies the frozen rule to them. Markets settle within seconds of close, and if the camera cannot tell, the market is voided and every stake is refunded in full. The operator receives each result as a signed webhook or through a pull endpoint, in one of three states: won, lost or refunded.
The rule is frozen before the first bet
Every Lukk market carries a rule_hash: a hash of the exact settlement contract (what counts, which zone, which window, what resolves YES) computed before acceptance opens and pinned to every ticket. The same hash appears in the B2B feed snapshot, so an operator can show the player what they are betting on and later prove the result was graded against that rule and no other. Because the rule cannot change after the first bet, there is no judgement call to argue about at settlement, only a check that the rule was applied. Lukk's own vocabulary for this is "evidence-resolved": the market is resolved by evidence that was specified in advance.
Who decides: deterministic tracker or vision judge
Lukk's vision layer tracks every car, bus, bird and pedestrian in frame and what each is doing, and draws its detection boxes over the video so players see exactly the pixels the oracle judges. Two kinds of judge sit on top of that layer:
- A deterministic counter or tracker settles questions that reduce to counting or ordering tracked objects: how many people were on the crossing, which tracked object reached a line first, whether a bus crossed before the light changed.
- A vision judge settles questions that need a reading of the scene rather than a count: whether the crane was lifting at zero, whether a penguin dived into the pool.
The same deterministic tracker also issues the in-flight veto during the one-to-three-second acceptance delay. If a decisive event happens between a player's tap and acceptance, the ticket is refused (in_flight_event) rather than filled on an outcome that is already known.
Signed evidence frames and replay
When the window closes, the deciding frames are locked, signed with ed25519 and published together with the result. An evidence replay sits behind every result, so a player, an operator's trading desk or an auditor can watch the frames that decided the market with the rule hash beside them. Every resolution is logged and replayable; post-settlement corrections are rare and audit-driven, and they are the exception that the replay exists to catch. This is why Adkuu describes Lukk markets as "camera-settled" and "replayable resolutions" rather than using the language of RNG fairness certificates: the proof is the footage, not a seed.
Void means a full refund, never a re-grade
If the camera cannot tell (an occlusion, a feed drop, a frame in which the rule cannot be applied), the market is voided and every stake is refunded. A void is always a full refund and never a re-grade to the most likely outcome. Voids are reported to the operator in the refunded state and are distinct from a "Neither" outcome, which is a real result on a multiple-choice market (for example "Which lands first — a cardinal, a blue jay, or neither?") and pays whoever backed it.
Timing: seconds after close, holds on larger payouts
| Moment | What happens |
|---|---|
| Before the window begins | Acceptance closes, so even someone standing at the camera has not seen the outcome when bets stop |
| During the window (a minute or two, inside a round of about 90 seconds) | The tracker and the signed frame pipeline run; nothing can be placed |
| Window closes | Deciding frames locked, signed and published; judge applies the frozen rule |
| Within seconds of close | Most markets settle, with a median under five seconds |
| Larger payouts | A short verification hold before credit, run from the risk desk alongside exposure limits and circuit breakers |
| Rarely, after settlement | An audit-driven correction, logged against the replay |
The hold is the only place where settlement waits for a person, and it applies to payout size, not to the result.
What the operator receives
The operator's platform never grades anything. It receives settled tickets and moves money through its own wallet:
- Signed webhooks. Each settlement arrives with the header
X-Lukk-Event: settlement, signed with HMAC-SHA256 (X-Lukk-Signature) using the operator's API key, delivered at-least-once with exponential backoff. The schema is versioned aslukk.webhook.v1. - A pull endpoint.
GET /api/v1/b2b/settlementsreturns the same results with page totals for netting, for operators who prefer to reconcile in batches or need to backfill after an outage. - Three states.
won,lostandrefunded(void). Winnings and refunds arrive through the operator'screditendpoint, which is queued and retried until delivered;rollbackand a daily two-partyreconcileclose the loop, and Lukk alarms on any divergence without ever auto-adjusting. - An idempotency key on every money movement, with amounts as decimals to two places in the operator's currency.
For the shape of the markets being settled, see What question types do live-camera betting markets use?; the integration contract is summarised for operators at lukk.gg/operators and illustrated step by step on How it works.
Sources
- CCTV betting: Accessible innovation or an integrity nightmare waiting to happen?
- What Is Betting on Traffic and Where to Gamble on CCTV Traffic Footage?
- Rush Hour: live traffic betting reshapes the iGaming market
Last verified: October 10, 2026.