Levandor

hormuz-bet — Resolution Mechanics

4 min read

For Agents

The exact structures of the Polymarket Strait-of-Hormuz ship-count markets and how each resolves. ALL of them (three recurring count structures plus one deep binary) resolve on IMF PortWatch transit-call counts for chokepoint6 (Strait of Hormuz) via the UMA optimistic oracle. The single most important operational rule: bucket boundaries shift between events, so never hard-code them and re-read each event resolution text. The settlement data source itself is documented in hormuz-bet-portwatch-data.

How the Polymarket Strait-of-Hormuz markets are structured and resolved. This is the settlement layer the whole strategy is built on.

The Resolution Reference (cited in every market)

Every one of these markets cites the same settlement reference in its rules text:

  • IMF PortWatch, Strait of Hormuz chokepoint page: https://portwatch.imf.org/pages/cb5856222a5b4105adc6ee7e880a1730
  • The settlement number is PortWatch transit calls (daily ship-transit count) for the Strait of Hormuz (portid = chokepoint6).
  • Oracle: UMA optimistic oracle (Polymarket standard). Confirmed firing correctly on already-resolved Hormuz markets.

Settlement is the PortWatch number, full stop

These markets do not resolve on physical reality, your AIS feed, news reports, or any other ship count. They resolve on what IMF PortWatch publishes for chokepoint6, as read by UMA. Model that series and its publication mechanics. See hormuz-bet-basis-risk for why using a different AIS source is a settlement trap.

Cadence

Polymarket has run these as recurring markets, roughly weekly since ~March 2026. New ship-count events keep appearing, so this is a repeating franchise, not a one-off, which is what makes a backtested, repeatable strategy worthwhile.

The Four Market Structures

Bucket boundaries are NOT stable across events

The weekly TOTAL buckets shifted between events: the May event used <20 / 20-39 / 40-59 / 60-79 / 80+; the June event used <25 / 25-49 / 50-74 / 75-99 / 100+. Never hard-code bucket edges. Always parse the specific event resolution text at trade time and at backtest-reconstruction time. The shift is presumably to track the regime (counts collapsed in the wartime period).

1. Weekly bucketed TOTAL (“How many ships transit … week of X”)

  • Structure: neg-risk multi-outcome event, ~5 mutually-exclusive buckets.
  • Resolves on: the TOTAL transit count for the named week (sum of daily PortWatch transit calls over that week), placed into whichever bucket contains it.
  • Boundaries shift per event (see warning above). Examples seen: May used <20, 20-39, 40-59, 60-79, 80+; June used <25, 25-49, 50-74, 75-99, 100+.
  • Neg-risk means the bucket prices form a (roughly) normalized distribution; exploit obvious sum-to-one and adjacent-bucket inconsistencies.

2. 7-day moving-average buckets on a single date (“Avg # ships … end of June”)

  • Structure: bucketed multi-outcome, but the resolved quantity is the 7-day moving average of daily transit calls as of a single named date.
  • Tie rule (explicit): ties resolve to the HIGHER bracket. This is stated in the rules; bake it into reconstruction and pricing.
  • Same never-hard-code caution on the bracket edges.

3. Threshold “max single-day >= N by date” (“Will __ ships transit … on any day by June 30”)

  • Structure: a set of independent Yes/No legs at thresholds 20 / 40 / 60 / 80 (not mutually exclusive; each is its own binary).
  • Resolves YES for leg N if the maximum single-day transit count reaches >= N on any day on or before the named date.
  • The legs are nested (>=80 implies >=60 implies >=40 …), so there is an internal monotonicity constraint: P(>=80) ⇐ P(>=60) ⇐ P(>=40) ⇐ P(>=20). Violations are arbitrageable.

4. The deep binary: “Strait of Hormuz traffic returns to normal”

  • Structure: single Yes/No binary.
  • Resolves YES if the PortWatch 7-day moving average >= 60.
  • Volume: ~$14.7M, vastly deeper than the thin count markets (see hormuz-bet-liquidity). This is where the real money is.
  • Resolves on the same PortWatch series as the count buckets, creating a cross-market consistency / arb constraint: the binary (MA>=60) and the average/total buckets must price a coherent joint distribution of the same underlying. See hormuz-bet-liquidity and hormuz-bet-backtesting.

Strategic Implications

  • Reconstruct, do not hard-code. Every backtest resolution must be derived by parsing the actual event text (bucket edges, which date, which statistic: weekly sum vs 7-day MA vs single-day max) and applying it to the PortWatch daily series.
  • Three different statistics off one series. Weekly TOTAL (sum), 7-day MA (average), single-day MAX (extreme). A single PortWatch daily history feeds all of them.
  • Cross-market arb is real because the deep binary and the thin buckets settle on the same number. Inconsistent joint pricing between the $14.7M binary and the thin buckets is the most capacity-friendly edge (you can size in the binary).

Graph View

Backlinks