Summary
Bets are successfully placed on-chain (state: Accepted), but roughly 25% of them transition to Canceled anywhere from 0.2 to 10 minutes later. The bet/orders/{id} response has error: null and errorMessage: null in every case, so there's no way to determine the trigger from the API response alone.
Environment
Chain: Polygon (PolygonUSDT)
Core contract: 0xf9548be470a4e130c90cea8b179fcd66d2972ac7
Integration: direct REST API + @azuro-org/toolkit (createBet, getBet, getBetTypedData, getBetFee)
Most notable case
Five separate bets were placed on the same conditionId + outcomeId over a ~50-minute window. The displayed odds (1.26) never changed during this entire window on our side. Every single bet was individually Accepted and then individually Canceled — each cancellation has its own distinct tx hash (i.e. this is not a single mass-cancellation transaction for the whole condition), and result stayed null for all of them (full refund, not a loss settlement).
betId conditionId outcomeId odds amount created (UTC) canceled (UTC) delay
347484 300610060000000000304223180000000000005560488228 499 1.26 40.61 2026-07-30T10:39:05 2026-07-30T10:48:56 9.8 min
347493 300610060000000000304223180000000000005560488228 499 1.26 81.21 2026-07-30T10:47:59 2026-07-30T10:49:00 1.0 min
347498 300610060000000000304223180000000000005560488228 499 1.26 81.21 2026-07-30T10:51:17 2026-07-30T10:51:32 0.3 min
347504 300610060000000000304223180000000000005560488228 499 1.26 121.82 2026-07-30T11:00:26 2026-07-30T11:02:47 2.4 min
347521 300610060000000000304223180000000000005560488228 499 1.26 40.19 2026-07-30T11:17:29 2026-07-30T11:19:50 2.4 min
A sixth bet on a different condition (347531, conditionId ...5700805118, outcomeId 7048, odds 1.5) was also canceled after just 0.2 minutes.
For comparison, a normal successfully-resolved bet from the same session (betId 347393) is included below — it took ~2.5 hours to resolve normally with result: Lost, as expected.
What we've already ruled out on our side
Odds staleness / slippage: we checked minOdds against the odds shown at bet time; the value did not appear to move on our end during the whole window.
maxBet / minBet limits: checked via POST /bet/calculation before placing — amounts were within maxBet.
Duplicate-bet detection: this doesn't look like the documented "duplicate bet" rule, since (a) each cancellation is a separate transaction, not one batch cancellation for the condition, and (b) the amounts and timestamps are all clearly distinct, spread over 50 minutes, not near-simultaneous.
expiresAt too short: not applicable here — these bets reached Accepted (i.e. were successfully mined on-chain) before being canceled, so the on-chain deadline check isn't the trigger for the later cancellation.
Questions
What's the actual trigger for these cancellations? Is it a Reinforcement/potential-loss-limit reconciliation, a condition status change (Stopped/Removed), or something else?
Is there a way to get the real cancellation reason via the API? Right now error/errorMessage are always null for these.
Why would odds stay static (1.26) for ~50 minutes on a condition where individual bets keep getting canceled — is this expected behavior for a specific condition state, and is there a way to detect that state client-side before placing a bet, to avoid this entirely?
Happy to provide the full raw bet/orders/{id} JSON responses and/or subgraph query results for any of the above betIds if useful.
Summary
Bets are successfully placed on-chain (state: Accepted), but roughly 25% of them transition to Canceled anywhere from 0.2 to 10 minutes later. The bet/orders/{id} response has error: null and errorMessage: null in every case, so there's no way to determine the trigger from the API response alone.
Environment
Chain: Polygon (PolygonUSDT)
Core contract: 0xf9548be470a4e130c90cea8b179fcd66d2972ac7
Integration: direct REST API + @azuro-org/toolkit (createBet, getBet, getBetTypedData, getBetFee)
Most notable case
Five separate bets were placed on the same conditionId + outcomeId over a ~50-minute window. The displayed odds (1.26) never changed during this entire window on our side. Every single bet was individually Accepted and then individually Canceled — each cancellation has its own distinct tx hash (i.e. this is not a single mass-cancellation transaction for the whole condition), and result stayed null for all of them (full refund, not a loss settlement).
betId conditionId outcomeId odds amount created (UTC) canceled (UTC) delay
347484 300610060000000000304223180000000000005560488228 499 1.26 40.61 2026-07-30T10:39:05 2026-07-30T10:48:56 9.8 min
347493 300610060000000000304223180000000000005560488228 499 1.26 81.21 2026-07-30T10:47:59 2026-07-30T10:49:00 1.0 min
347498 300610060000000000304223180000000000005560488228 499 1.26 81.21 2026-07-30T10:51:17 2026-07-30T10:51:32 0.3 min
347504 300610060000000000304223180000000000005560488228 499 1.26 121.82 2026-07-30T11:00:26 2026-07-30T11:02:47 2.4 min
347521 300610060000000000304223180000000000005560488228 499 1.26 40.19 2026-07-30T11:17:29 2026-07-30T11:19:50 2.4 min
A sixth bet on a different condition (347531, conditionId ...5700805118, outcomeId 7048, odds 1.5) was also canceled after just 0.2 minutes.
For comparison, a normal successfully-resolved bet from the same session (betId 347393) is included below — it took ~2.5 hours to resolve normally with result: Lost, as expected.
What we've already ruled out on our side
Odds staleness / slippage: we checked minOdds against the odds shown at bet time; the value did not appear to move on our end during the whole window.
maxBet / minBet limits: checked via POST /bet/calculation before placing — amounts were within maxBet.
Duplicate-bet detection: this doesn't look like the documented "duplicate bet" rule, since (a) each cancellation is a separate transaction, not one batch cancellation for the condition, and (b) the amounts and timestamps are all clearly distinct, spread over 50 minutes, not near-simultaneous.
expiresAt too short: not applicable here — these bets reached Accepted (i.e. were successfully mined on-chain) before being canceled, so the on-chain deadline check isn't the trigger for the later cancellation.
Questions
What's the actual trigger for these cancellations? Is it a Reinforcement/potential-loss-limit reconciliation, a condition status change (Stopped/Removed), or something else?
Is there a way to get the real cancellation reason via the API? Right now error/errorMessage are always null for these.
Why would odds stay static (1.26) for ~50 minutes on a condition where individual bets keep getting canceled — is this expected behavior for a specific condition state, and is there a way to detect that state client-side before placing a bet, to avoid this entirely?
Happy to provide the full raw bet/orders/{id} JSON responses and/or subgraph query results for any of the above betIds if useful.