[ blog · comparison ]11 min read

API ของ Polymarket vs Kalshi: คู่มือเปรียบเทียบแบบเคียงข้างสำหรับนักพัฒนา (auth, CLOB, WebSocket, ข้อมูลย้อนหลัง)

Sarah Choy·เผยแพร่ 3 พฤษภาคม 2569·อ่าน 11 นาที

Polymarket และ Kalshi รันพื้นฐานเดียวกัน — สัญญาแบบใช่/ไม่ใช่บน CLOB — ผ่าน API ที่แตกต่างกันโดยสิ้นเชิง ฝ่ายหนึ่งบังคับให้ใช้ลายเซ็น EIP-712 และ wallet บน Polygon อีกฝ่ายเป็น endpoint แบบ REST ที่มี FIX เป็นทางเลือก หากคุณกำลังสร้าง agent ทำนาย, bot อาร์บิทราจ หรือมอนิเตอร์ smart money นี่คือคู่มือเปรียบเทียบเคียงข้างที่ควรมีอยู่แล้ว

สรุปสั้น

• •Polymarket ใช้คำสั่งซื้อที่ลงนามด้วย EIP-712 ส่งไปยัง CLOB บน Polygon — มีการ onboarding wallet และค่า gas
• •Kalshi ใช้การ auth มาตรฐานแบบ REST + WebSocket (อีเมล/รหัสผ่าน → token) บวกกับ FIX gateway เป็นทางเลือกสำหรับผู้ใช้สถาบัน
• •ทั้งสองเปิดเผยสมุดคำสั่งซื้อ ธุรกรรม และข้อมูลย้อนหลัง แต่ schema และความหมายของการชำระบัญชีต่างกันมากพอที่ทำให้ไลบรารี 'unified' เป็นหัวข้อที่ถูกขอมากที่สุดบน Show HN ในมุมนี้ของเครื่องมือ crypto/quant
• •อาร์บิทราจข้ามตลาดบนสัญญาที่เทียบเท่ากันคือรูปแบบการสร้างที่พบบ่อยที่สุด (bot โอเพนซอร์สกว่า 10 ตัวบน GitHub)
• •API Pick Prediction Markets Search ห่อหุ้มทั้งสองตลาดไว้ใน endpoint POST เดียวสำหรับการค้นพบสัญญาด้วยภาษาธรรมชาติ — 50 เครดิตต่อการเรียก ผลลัพธ์เชิงความหมายที่จัดอันดับแล้ว

ทำไมบทความนี้จึงมีอยู่

หากคุณเคยใช้เวลาสร้างบนตลาดทำนาย คุณย่อมรู้จักคำขอแบบคลาสสิก: 'ฉันอยากค้นหา Polymarket และ Kalshi จากสคริปต์ Python ตัวเดียวกัน และได้รายการสัญญาที่ตรงกันแบบสะอาด ๆ กลับมา' เธรดความคิดเห็นบน HN ในทุก Show HN เกี่ยวกับตลาดทำนายลงเอยที่จุดนี้อย่างหลีกเลี่ยงไม่ได้ — มีรูปแบบโพสต์ "CCXT สำหรับตลาดทำนาย" ที่เกิดซ้ำ ซึ่งบ่งชี้ว่าความต้องการมีอยู่ และโซลูชันที่มีอยู่ยังไม่ตรงเป้าเสียทีเดียว

ความยากนั้นมีจริง สองตลาดแก้พื้นฐานเดียวกัน — สัญญาทวิภาค "ใช่/ไม่ใช่" บน central limit order book — แต่เปิดเผยผ่าน API ที่แตกต่างกันอย่างมาก นี่คือมุมมองนักพัฒนาที่ใช้งานได้จริงของทั้งสอง วางเคียงข้างกัน พร้อมโค้ดที่คุณต้องใช้จริง ๆ

สองตลาด สองสถาปัตยกรรม

Polymarket

• Chain: Polygon (ชำระบัญชีด้วย USDC.e)
• Auth: การลงนาม typed-data แบบ EIP-712 ด้วย private key ของ wallet ไม่มี bearer token แบบดั้งเดิม
• การวางคำสั่งซื้อ: คำสั่งซื้อที่ลงนามแล้วส่งไปยัง CLOB API; ค่า gas จ่ายโดย Polymarket ผ่าน meta-transaction
• การค้นพบตลาด: Gamma API (REST + JSON) สำหรับเรียกดูตลาดที่ใช้งานอยู่ บวกกับ CLOB API แยกต่างหากสำหรับสมุดคำสั่งซื้อแบบเรียลไทม์
• ข้อมูลเรียลไทม์: สตรีม WebSocket สำหรับการอัปเดตสมุดคำสั่งซื้อและธุรกรรม
• ข้อมูลย้อนหลัง: REST endpoint สำหรับธุรกรรม; snapshot รายวันดาวน์โหลดแยกได้

Kalshi

• การชำระบัญชี: USD ผ่าน ACH และการโอนเงิน (ต้องมีบัญชีธนาคารสหรัฐฯ)
• Auth: อีเมล + รหัสผ่าน → bearer token หรือ API key (สถาบัน)
• การวางคำสั่งซื้อ: REST POST แบบ authenticated มาตรฐานไปยัง /portfolio/orders
• การค้นพบตลาด: REST endpoint สำหรับ event, ตลาด และ series; schema สะอาด
• ข้อมูลเรียลไทม์: WebSocket และ FIX (สถาบัน) สำหรับ fill, สมุดคำสั่งซื้อ, ticker
• ข้อมูลย้อนหลัง: REST endpoint สำหรับธุรกรรม; ข้อมูลการตัดสินและการชำระบัญชีตลาดตรงไปตรงมา

เคียงข้างกัน

โค้ดที่ใช้งานได้: hello-world ในแต่ละตลาด

Polymarket: แสดงรายการตลาดที่ใช้งานอยู่

import requests

# Gamma API — no auth required for browsing
r = requests.get(
    "https://gamma-api.polymarket.com/markets",
    params={"active": "true", "limit": 25, "order": "volume"},
)
markets = r.json()
for m in markets[:5]:
    print(m["question"], "→", m["outcomePrices"])

Polymarket: วางคำสั่งซื้อที่ลงนาม (โครงร่าง)

# Full order placement requires py-order-utils + a Polygon wallet
# This is the structural sketch — not runnable without wallet setup
from py_order_utils.builders import OrderBuilder
from py_order_utils.signer import Signer

signer = Signer(private_key="0xYOUR_PRIVATE_KEY")
builder = OrderBuilder(
    exchange_address="0x...",
    chain_id=137,
    signer=signer,
)

order = builder.build_signed_order({
    "maker": signer.address(),
    "tokenId": "...",        # the yes/no token ID for the market
    "makerAmount": "1000000", # USDC.e in atomic units
    "takerAmount": "1500000",
    "side": "BUY",
    "feeRateBps": 0,
    "nonce": 0,
    "expiration": 0,         # 0 = no expiry
})

requests.post(
    "https://clob.polymarket.com/order",
    json={"order": order, "owner": signer.address(), "orderType": "GTC"},
)

Kalshi: เข้าสู่ระบบและวางคำสั่งซื้อแบบ limit

import requests

# Step 1 — login
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/login",
    json={"email": "you@example.com", "password": "..."},
).json()
token = r["token"]
headers = {"Authorization": f"Bearer {token}"}

# Step 2 — list markets in an event
r = requests.get(
    "https://api.elections.kalshi.com/trade-api/v2/markets",
    params={"event_ticker": "POTUS-2028", "limit": 25},
    headers=headers,
).json()
print(r["markets"][:5])

# Step 3 — place a limit buy on the "Yes" side at 60 cents
r = requests.post(
    "https://api.elections.kalshi.com/trade-api/v2/portfolio/orders",
    headers=headers,
    json={
        "ticker": "POTUS-2028-DEM",
        "type": "limit",
        "action": "buy",
        "side": "yes",
        "count": 100,            # 100 contracts
        "yes_price": 60,         # 60 cents
        "client_order_id": "abc123",
    },
)
print(r.json())

API Pick: การค้นพบด้วยภาษาธรรมชาติข้ามทั้งสอง

import requests

r = requests.post(
    "https://www.apipick.com/api/search/prediction-markets",
    headers={"x-api-key": "pk_yourkey"},
    json={"query": "Federal Reserve rate cuts before end of 2026"},
)
for hit in r.json()["results"][:5]:
    print(hit["title"], "@", hit["venue"], "→", hit["url"])

# Returns ranked matches across Polymarket + Kalshi.
# 50 credits per call (~$0.05), only on HTTP 200.

สามรูปแบบใช้งานจริงในโปรดักชันที่เวิร์กจริง

1. bot อาร์บิทราจข้ามตลาด

รูปแบบที่พบบ่อยที่สุดบน GitHub: whitelist ที่คัดสรรด้วยมือว่า "สัญญา Polymarket ตัวนี้ชำระบัญชีบนผลลัพธ์เดียวกับสัญญา Kalshi ตัวนี้" bot จะเฝ้าดูสมุดคำสั่งซื้อทั้งสอง คำนวณความน่าจะเป็นโดยนัย และเข้าสถานะเมื่อ spread ข้ามเกณฑ์ที่กำหนด ตัวอย่าง: ImMike/polymarket-arbitrage และ realfishsam/prediction-market-arbitrage-bot

ส่วนที่ยากคือ whitelist "Fed จะลด 25 bps ในการประชุมเดือนธันวาคมหรือไม่" ดูเหมือนกันสำหรับมนุษย์ แต่แหล่งที่มาของการตัดสินและถ้อยคำที่แน่นอนต่างกัน ตัวจับคู่อัตโนมัติผิดบ่อยพอที่ bot จริง ๆ จะใช้การแมปที่มนุษย์คัดสรร

2. มอนิเตอร์ smart money

วาฬบน Polymarket มองเห็นได้บน on-chain มอนิเตอร์จะเฝ้าดู Polygon เพื่อหากระแสคำสั่งซื้อขนาดใหญ่ในตลาดเฉพาะ เปิดเผยสถานะใหญ่ ๆ และทำเครื่องหมายการเคลื่อนไหวราคาที่รวดเร็วก่อนที่พาดหัวข่าวจะไปถึง API ข่าว จับคู่กับ News Search เพื่อยืนยันว่าการเคลื่อนไหวที่ปรากฏนั้นขับเคลื่อนด้วยข่าวหรือเป็นการเก็งกำไรล้วน ๆ

3. ฟีดทำนายสำหรับ agent LLM

การดึงราคา Polymarket / Kalshi ปัจจุบันเข้าสู่ context ของ agent LLM ทำให้โมเดลให้คำตอบที่มีพื้นฐานจากความน่าจะเป็นได้: "ตลาดเดิมพันปัจจุบันบ่งชี้ความน่าจะเป็น ~65% ของ X" นี่คือกรณีใช้งานการค้นพบที่ API Pick ครอบคลุม — เมื่อมีคำถามภาษาธรรมชาติจาก agent ให้คืนสัญญาที่จัดอันดับแล้วเพื่อให้ agent อ้างอิงราคาในคำตอบได้

กับดักที่พบบ่อย (รวบรวมจากความคิดเห็นบน HN)

• การลงนาม EIP-712 ของ Polymarket — ลายเซ็นคำสั่งซื้อเป็นแบบ deterministic แต่ข้อผิดพลาดจากเครื่องมือพบได้บ่อย ใช้ py-order-utils แทนการเขียนเองตั้งแต่ต้น การขาดทุนของ bot ในช่วงแรกส่วนใหญ่มาจากลายเซ็นที่ไม่ตรงกันซึ่ง API ปฏิเสธอย่างเงียบ ๆ
• Rate limit ของ Kalshi — เอกสารระบุไว้ที่ 100 req/sec แต่ต่ำกว่านั้นสำหรับบาง endpoint ในวันที่มี event คึกคัก (คืนเลือกตั้ง, FOMC) ใส่ logic retry-with-backoff ไว้ใน client ของคุณ
• การพุ่งของค่า gas ใน Polymarket — ค่า gas บน Polygon อาจพุ่งสูงในวันที่มีปริมาณการเทรดมาก Polymarket อุดหนุนการวางคำสั่งซื้อส่วนใหญ่ผ่าน meta-transaction แต่การชำระบัญชีและการถอนเงินผู้ใช้เป็นคนจ่าย คำนึงถึงเรื่องนี้ในการคำนวณ P&L
• ความไม่ตรงกันของการชำระบัญชี — สิ่งที่ดูเหมือนเทียบเท่ากันบางครั้งกลับชำระบัญชีต่างกัน อ่านข้อกำหนดแหล่งที่มาของการตัดสินของทั้งสองสัญญาเสมอก่อนเทรดแบบจับคู่
• การหลุดการเชื่อมต่อ WebSocket — ทั้งสองตลาดมีอาการ WebSocket สะดุดเป็นประจำ logic การเชื่อมต่อใหม่พร้อมการเล่นซ้ำด้วยหมายเลขลำดับเป็นสิ่งที่ต่อรองไม่ได้สำหรับ bot ในโปรดักชันทุกตัว

เลือกอย่างรวดเร็ว

ทิศทางที่กำลังมุ่งไป

ตลาดทำนายกำลังได้รับความสนใจจากกระแสหลักในปริมาณที่ไม่ธรรมดาในตอนนี้: ปริมาณการเทรดที่ใหญ่ขึ้นรอบ ๆ การเลือกตั้งสหรัฐฯ, event FOMC, กีฬา และคำถามเกี่ยวกับการทะยานของ AI; การอินทิเกรตที่กว้างขึ้นกับเว็บไซต์ข่าวที่แสดงความน่าจะเป็นโดยนัย; และคลื่นของเครื่องมือสำหรับนักพัฒนา (Show HN, repo บน GitHub) ที่ลงเอยที่ธีมเดียวกัน — 'ควรมีใครสักคนเขียน CCXT สำหรับตลาดทำนาย'

เราไม่คิดว่าไลบรารีการส่งคำสั่งแบบรวมศูนย์สไตล์ CCXT คือรูปแบบที่ถูกต้อง ความแตกต่างใน auth, การชำระบัญชี และระบอบการกำกับดูแลนั้นลึกเกินกว่าจะ abstract ออกมาอย่างสะอาดได้โดยไม่โกหกผู้ใช้ แต่ปัญหา การค้นพบ — เมื่อมีคำถามภาษาธรรมชาติ ให้หาสัญญาที่มีอยู่แล้ว — แก้ได้ด้วยการค้นหาเชิงความหมาย และนั่นคือสิ่งที่ API Pick Prediction Markets Search ทำ หาสัญญาให้เจอ; แล้วไปวางคำสั่งซื้อที่ตลาด

เขียนโดย

Sarah Choy

CEO, API Pick

Sarah Choy เป็น CEO ของ API Pick เธอเขียนเกี่ยวกับการสร้าง API พร้อมใช้งานจริงสำหรับ AI agent และเวิร์กโฟลว์ LLM