sync: main → dev (94a61b3, needs conflict resolution)

.github/workflows/sync-dev-from-main.yml

@@ -0,0 +1,109 @@
+name: Sync dev from main
+
+# Purpose
+# -------
+# The workflow enforces the AGENTS.md rule "immediately fast-forward dev
+# from main after a hotfix". Every hotfix that lands on main used to
+# require a manual `git checkout dev && git merge --ff-only main && git
+# push` step; that step was skipped often enough for dev to drift 100+
+# commits behind main, silently rotting the staging environment.
+#
+# On every push to main this job:
+#   1. Tries a fast-forward of dev to main. If it succeeds, dev is now
+#      identical to main and the staging deploy fires as usual (its
+#      workflow triggers on push to dev).
+#   2. If a fast-forward isn't possible (dev has commits main doesn't),
+#      the job attempts a real merge commit. Clean auto-merge = pushed
+#      straight to dev.
+#   3. Only when git itself can't resolve the merge (real conflicts) do
+#      we fall back to opening a "sync/main-to-dev-<sha>" branch + a PR
+#      against dev. A human resolves those conflicts by merging the PR.
+#
+# The job is intentionally lenient: pushing to dev directly is normally
+# forbidden (AGENTS.md), but this bot is the one exception because it
+# only carries commits that main has already accepted.
+
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+
+concurrency:
+  group: sync-dev-from-main
+  cancel-in-progress: false
+
+jobs:
+  sync:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      pull-requests: write
+    steps:
+      - name: Checkout full history
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          ref: dev
+
+      - name: Configure bot identity
+        run: |
+          git config user.name  "ocb-sync-bot"
+          git config user.email "ocb-sync-bot@users.noreply.github.com"
+
+      - name: Try fast-forward dev → main
+        id: ff
+        run: |
+          set -e
+          git fetch origin main:refs/remotes/origin/main
+          if git merge-base --is-ancestor origin/main HEAD; then
+            echo "already-in-sync=true" >> "$GITHUB_OUTPUT"
+            echo "dev already contains origin/main; nothing to do."
+            exit 0
+          fi
+          if git merge --ff-only origin/main; then
+            git push origin dev
+            echo "ff-succeeded=true" >> "$GITHUB_OUTPUT"
+            echo "dev fast-forwarded to $(git rev-parse --short HEAD)"
+            exit 0
+          fi
+          echo "ff-failed=true" >> "$GITHUB_OUTPUT"
+
+      - name: Attempt clean merge commit
+        if: steps.ff.outputs.ff-failed == 'true'
+        id: merge
+        run: |
+          set -e
+          if git merge --no-edit --no-ff origin/main -m "sync: main → dev (auto-merge $(git rev-parse --short origin/main))"; then
+            git push origin dev
+            echo "merge-pushed=true" >> "$GITHUB_OUTPUT"
+            echo "dev auto-merged main at $(git rev-parse --short HEAD)"
+            exit 0
+          fi
+          git merge --abort
+          echo "merge-failed=true" >> "$GITHUB_OUTPUT"
+
+      - name: Open sync PR on conflict
+        if: steps.merge.outputs.merge-failed == 'true'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          set -e
+          SHORT=$(git rev-parse --short origin/main)
+          BRANCH="sync/main-to-dev-$SHORT"
+          git checkout -B "$BRANCH"
+          # Force a merge commit that stops on conflicts. We DO NOT
+          # push conflict markers to dev; instead we push a branch that
+          # a human can pull, resolve locally, and merge into dev.
+          git reset --hard dev
+          git merge --no-edit --no-ff origin/main || true
+          git add -A
+          git commit -m "sync: main → dev (CONFLICTS — resolve before merge)" || true
+          git push -f origin "$BRANCH"
+          gh pr create \
+            --repo "$GITHUB_REPOSITORY" \
+            --base dev \
+            --head "$BRANCH" \
+            --title "sync: main → dev (auto, needs conflict resolution)" \
+            --body "Automated by \`.github/workflows/sync-dev-from-main.yml\`. Fast-forward + auto-merge both failed; a human needs to resolve conflicts and merge this PR into \`dev\`. Base main SHA: $SHORT." \
+            || echo "PR already exists for $BRANCH; leaving it alone."

answers/which-prediction-market-data-api-is-the-freshest.yml

@@ -1,15 +1,15 @@
 slug: which-prediction-market-data-api-is-the-freshest
 question: "Which prediction market data API publishes the freshest Polymarket data?"
 short_answer: |
-  {{best_name}} currently relays Polymarket trades the fastest at {{best_p50}} (p50, 24h) versus Polymarket's own CLOB WebSocket gateway, measured by cross correlating trade events on Polymarket, Mobula and Codex on the same rotating basket of top 20 markets by 24 hour volume.
+  {{best_name}} currently relays Polymarket trades the fastest at {{best_p50}} (p50, 24h) versus Polymarket's own CLOB WebSocket gateway, measured by cross correlating trade events on Polymarket and Codex on the same rotating basket of top 20 markets by 24 hour volume.
 
 benchmark: pm-data-freshness
 
 intro: |
-  Prediction markets produce the most time sensitive event stream in crypto. An election market settles in seconds, a sports book moves on every play, and the price tick a trading UI shows is only as fresh as the API behind it. Builders integrating Polymarket through a data provider rather than hitting the CLOB directly need to know how many milliseconds that provider adds between Polymarket publishing a trade and the provider relaying the same trade to its WebSocket subscribers. This page answers exactly that. The OpenChainBench pm-data-freshness harness holds three WebSocket subscribers in parallel: Polymarket's own CLOB gateway (the canonical T0), Mobula's PM WebSocket, and Codex GraphQL subscriptions, all subscribed to the same basket of top 20 Polymarket markets by 24 h volume, refreshed every 5 minutes. Each trade is matched across providers by a tuple of conditionId, price rounded to 3 decimals, trade size and a 5 second time bucket; the per provider lag versus Polymarket's gateway publish time is recorded as a Prometheus histogram and the leaderboard ranks by p50 in milliseconds, lower is fresher.
+  Prediction markets produce the most time sensitive event stream in crypto. An election market settles in seconds, a sports book moves on every play, and the price tick a trading UI shows is only as fresh as the API behind it. Builders integrating Polymarket through a data provider rather than hitting the CLOB directly need to know how many milliseconds that provider adds between Polymarket publishing a trade and the provider relaying the same trade to its WebSocket subscribers. This page answers exactly that. The OpenChainBench pm-data-freshness harness holds two WebSocket subscribers in parallel: Polymarket's own CLOB gateway (the canonical T0) and Codex GraphQL subscriptions, both subscribed to the same basket of top 20 Polymarket markets by 24 h volume, refreshed every 5 minutes. Each trade is matched across providers by a tuple of conditionId, price rounded to 3 decimals, trade size and a 5 second time bucket; the per provider lag versus Polymarket's gateway publish time is recorded as a Prometheus histogram and the leaderboard ranks by p50 in milliseconds, lower is fresher.
 
 methodology: |
-  Three WebSocket clients run in parallel inside the harness on a Railway europe west 4 instance. Polymarket's own gateway (`wss://ws-subscriptions-clob.polymarket.com/ws/market`, public, no auth, sub 50 ms publish latency from EU West) is the canonical T0 by construction because nothing downstream can be faster than the source. Mobula's PM WebSocket (`wss://pm-api-prod-eu.mobula.io`) requires an API key in the subscribe payload and a browser User Agent on the upgrade request (Cloudflare on the gateway silently filters the default Go HTTP UA). Codex GraphQL (`wss://graph.codex.io/graphql` with the `graphql-transport-ws` subprotocol) runs an `onPredictionTradesCreated` firehose subscription filtered client side to the Polymarket protocol marketIds in the active basket. The cross correlation key is `(conditionId, priceUSD times 1000 rounded, sizeUSD times 1 million rounded, floor(trade_time / 5s))`; the 5 second bucket absorbs minor clock skew between gateways without merging unrelated trades. Histogram buckets run 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000, 60000 ms. Providers that fail to relay a matched trade within 90 seconds are not counted toward p50, only toward their receive total, so a provider cannot look fresh on the leaderboard by silently dropping events; the success rate column surfaces that.
+  Two WebSocket clients run in parallel inside the harness on a Railway europe west 4 instance. Polymarket's own gateway (`wss://ws-subscriptions-clob.polymarket.com/ws/market`, public, no auth, sub 50 ms publish latency from EU West) is the canonical T0 by construction because nothing downstream can be faster than the source. Codex GraphQL (`wss://graph.codex.io/graphql` with the `graphql-transport-ws` subprotocol) runs an `onPredictionTradesCreated` firehose subscription filtered client side to the Polymarket protocol marketIds in the active basket. The cross correlation key is `(conditionId, priceUSD times 1000 rounded, sizeUSD times 1 million rounded, floor(trade_time / 5s))`; the 5 second bucket absorbs minor clock skew between gateways without merging unrelated trades. Histogram buckets run 10, 25, 50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000, 60000 ms. Providers that fail to relay a matched trade within 90 seconds are not counted toward p50, only toward their receive total, so a provider cannot look fresh on the leaderboard by silently dropping events; the success rate column surfaces that.
 
 limitations:
   - "Polymarket's own gateway is the canonical T0 by construction. Its row on the leaderboard sits near zero because the harness compares everything else against it, not because Polymarket has solved network latency; the displayed sub millisecond value is a floor (vector(0.5)) so the row stays visible on the linear chart axis next to the multi second Codex value."
@@ -20,11 +20,9 @@ limitations:
 
 faq:
   - q: "Which Polymarket data API has the lowest latency right now?"
-    a: "{{best_name}} currently leads at {{best_p50}} (p50 over the last 24 hours), measured as wall clock time from Polymarket's own CLOB WebSocket publish to provider relay on the same trade. The leaderboard re sorts every minute on fresh Prometheus samples, so the answer reflects the actual measured lag on the active market basket, not a marketing claim. Mobula's edge cached relay typically clocks tens of milliseconds; Codex's on chain Polygon indexer carries a structural floor near 2 seconds because it ingests block confirmations."
+    a: "{{best_name}} currently leads at {{best_p50}} (p50 over the last 24 hours), measured as wall clock time from Polymarket's own CLOB WebSocket publish to provider relay on the same trade. The leaderboard re sorts every minute on fresh Prometheus samples, so the answer reflects the actual measured lag on the active market basket, not a marketing claim. Codex's on chain Polygon indexer carries a structural floor near 2 seconds because it ingests block confirmations."
   - q: "What does freshness delta mean for a prediction market API?"
     a: "The bench connects to Polymarket's own CLOB WebSocket and to each provider's WebSocket simultaneously, subscribes to the same markets, and for every trade event records how many milliseconds the provider takes to relay the event after Polymarket itself publishes it. Lower is better. Polymarket's own gateway publish time is the canonical T0 because by construction nothing downstream can be faster than the source. The cross correlation key (conditionId, price, size, 5 s bucket) survives minor clock skew between gateways without merging unrelated trades."
-  - q: "Is Mobula's PM WebSocket faster than Codex?"
-    a: "Yes, by a structural margin, because the two providers do fundamentally different things under the hood. Mobula's PM WebSocket is an edge cached relay of Polymarket's own gateway, so its p50 delta is roughly the network round trip between the two gateways plus a few milliseconds of bookkeeping. Codex ingests the on chain Polygon confirmation of each trade, which adds Polygon block time (around 2 seconds) before any trade can be relayed. For a live UI, Mobula's path wins on freshness; for on chain reconciliation or settlement workflows, Codex's chain indexed path is what you actually want. The leaderboard surfaces both numbers honestly."
   - q: "Why not include Polymarket REST polling on this bench?"
     a: "Freshness is a WebSocket question. REST polling at 1 second cadence would have a floor freshness near 500 ms (poll interval divided by 2) plus round trip time, dominated by how often you poll. The Polymarket gateway WebSocket exists for exactly this reason, to avoid that floor. Adding REST as a row would make the leaderboard noisy without changing the conclusion: WebSocket beats polling by definition for real time data."
   - q: "Are these numbers comparable to Kalshi or Limitless?"
@@ -40,5 +38,5 @@ related:
   - which-crypto-price-api-is-the-fastest
 
 seo_title: "Which prediction market data API is the freshest in 2026?"
-seo_description: "{{best_name}} leads at {{best_p50}} (p50, 24h) versus Polymarket's CLOB gateway, with Mobula and Codex measured live by OpenChainBench on the top 20 Polymarket markets by volume."
+seo_description: "{{best_name}} leads at {{best_p50}} (p50, 24h) versus Polymarket's CLOB gateway, with Codex measured live by OpenChainBench on the top 20 Polymarket markets by volume."
 status: live