Polymarket and Kalshi Arbitrage Verifier

This is an independent data product and is not affiliated with, sponsored by, or endorsed by Polymarket or Kalshi. It does not place orders or provide financial advice.

The Actor runs with limited-permission access: default run storage and public network requests only. Its pay-per-event, non-Standby architecture meets the technical prerequisites for agentic-payment discovery when Apify marks the published Actor as eligible.

Polymarket and Kalshi Arbitrage Verifier

Find contracts that appear to describe the same event on Polymarket and Kalshi, then replace headline-price arithmetic with execution-sized evidence. The Actor walks both live order books for an equal contract quantity, applies each platform's fee model, calculates both opposite-side routes, and repeats the calculation after moving both entries one tick against the trader.

The result is deliberately called a candidate verification, not guaranteed arbitrage. Two similarly titled markets may use different observation times, sources, threshold boundaries, cancellation clauses, or settlement rules. Cross-platform legs are also non-atomic. Every output therefore includes the relevant rule excerpts, hard automated conflicts, and a mandatory manual-review flag next to conditional PnL.

What makes the output useful

• Polymarket YES and NO prices are walked through CLOB ask levels at the exact requested size rather than copied from a headline probability.
• Kalshi's bid-only book is converted correctly: a NO bid at x supplies a YES ask at 1-x, with the same displayed quantity.
• Polymarket's current Gamma fee schedule is used per market, with a conservative fallback clearly labeled when metadata is incomplete.
• Kalshi's current general taker formula is rounded up to the next cent. The coefficient is an explicit input because product-specific fee exceptions can change and are not proven by the public order-book response.
• Numbers, negation, threshold direction, and close-time differences are treated as semantic conflicts rather than hidden inside one fuzzy-match score.
• Both buy Polymarket YES + Kalshi NO and the reverse route are reported under base and one-tick adverse execution.

Example input

{
  "explicitPairs": [
    {
      "polymarketMarketId": "1234567",
      "kalshiTicker": "KXEXAMPLE-26DEC31"
    }
  ],
  "discoveryEnabled": true,
  "queries": ["Federal Reserve", "Bitcoin"],
  "contracts": 5,
  "maxCandidates": 25,
  "minSemanticScore": 0.68,
  "maxCloseDifferenceHours": 48,
  "kalshiTakerFeeRate": 0.07,
  "positiveAfterStressOnly": false
}

Leave queries empty to search the fetched active universe. Use a topic when a scheduled workflow needs lower latency and a smaller output. A higher semantic score reduces candidates but cannot prove rule equivalence. Review both rule excerpts on the exchange before acting on any record.

For deterministic verification, provide explicitPairs and set discoveryEnabled to false. Explicit pairs are always returned when both public market records exist, including when the verifier finds hard conflicts. That makes the Actor useful as a second opinion for candidates produced by other scanners rather than forcing users to trust this Actor's discovery model.

Search-ready examples

The publication bundle defines runnable tasks for broad candidate discovery, Bitcoin-focused comparison, and one-tick-stressed filtering. The exact inputs are versioned in public_tasks.json. They are discovery aids, not assertions that matching markets or executable arbitrage exist at run time.

Output contract

Each dataset row contains platform identities, contract quantity, semantic checks, fee provenance, both route calculations, one-tick stress, depth status, and an execution warning. Profit fields are named net_pnl_if_rules_equivalent_usd so downstream systems cannot reasonably mistake a conditional calculation for a guaranteed payout.

Every run also emits one free scan_summary row. It reports how many explicit pairs were requested and resolved, how many markets were fetched per platform, how many discovery matches were found, and how many pair records survived. A zero-result scan is therefore distinguishable from an upstream or Actor error.

The Actor uses public market-data endpoints only. It accepts no exchange API keys, wallet credentials, private keys, or order instructions. It never places, cancels, or simulates a user order.

Pricing

Explicit pair audits emit the verified_cross_market_pair event at $0.03 for every successfully returned pair. Automatically discovered candidates use a three-record free preview, then emit the same event at $0.03 each. There is no start fee. The launch model is Pay per event + usage, so Apify platform usage is charged separately to the runner instead of quietly consuming the creator's operating budget. Missing or failed explicit pairs emit no paid event.

Data limitations

REST books can move between platform requests. A positive stressed route is not an atomic fill promise. Kalshi may apply a product-specific fee schedule, and the public data used here does not certify that exception status. Polymarket resolution descriptions and Kalshi rules can encode different boundary or timing semantics even when titles match. This Actor is a fast, structured pre-trade audit that removes obvious false positives; final contract review and execution responsibility remain with the user.

Official mechanics referenced by the implementation: Polymarket CLOB, Polymarket negative risk, Kalshi public market data, and Kalshi order-book interpretation.