Polymarket Arbitrage Bible: Perbedaan yang sebenarnya terletak pada infrastruktur matematika

Judul Asli: The Math Needed for Trading on Polymarket (Complete Roadmap)

Penulis Asli: Roan

Sumber Asli:

Repost: Huoxing Caijing

Dalam proses pendirian @insidersdotbot, saya telah melakukan banyak diskusi mendalam dengan tim market maker frekuensi tinggi dan tim arbitrase. Salah satu kebutuhan terbesar adalah bagaimana mengembangkan strategi arbitrase.

Pengguna, teman, dan mitra kami semua sedang menjelajahi jalur perdagangan arbitrase Polymarket yang kompleks dan multidimensi ini. Jika Anda aktif di Twitter, saya yakin Anda pernah melihat tweet seperti “Saya mendapatkan uang dari pasar prediksi dengan strategi arbitrase XX.”

Namun, sebagian besar artikel terlalu menyederhanakan logika dasar arbitrase, menjadikannya seperti “Saya juga bisa” atau “Dengan Clawdbot bisa selesai,” tanpa menjelaskan secara sistematis bagaimana memahami dan mengembangkan sistem arbitrase sendiri.

Jika Anda ingin memahami bagaimana alat arbitrase di Polymarket menghasilkan uang, artikel ini adalah interpretasi paling lengkap yang saya temui saat ini.

Karena teks asli berbahasa Inggris banyak bersifat teknis dan membutuhkan penelitian lebih lanjut, saya telah melakukan rekonstruksi dan penambahan agar Anda cukup membaca artikel ini saja tanpa perlu berhenti mencari referensi, dan tetap bisa memahami poin-poin utama.

Arbitrase di Polymarket bukan sekadar masalah matematika sederhana

Anda melihat sebuah pasar di Polymarket:

YES harga $0.62, NO harga $0.33.

Anda berpikir: 0.62 + 0.33 = 0.95, kurang dari 1 dolar, ada peluang arbitrase! Dengan membeli YES dan NO sekaligus, total biaya $0.95, apapun hasilnya, Anda bisa mendapatkan kembali $1.00, keuntungan bersih $0.05.

Anda benar.

Tapi masalahnya—ketika Anda masih menghitung secara manual, sistem kuantitatif sudah melakukan hal yang sama sekali berbeda.

Mereka secara simultan memindai 17.218 kondisi, melintasi 2^63 kemungkinan kombinasi hasil, dan menemukan semua kontradiksi harga dalam milidetik. Saat Anda menyelesaikan dua transaksi, selisih harga sudah hilang. Sistem ini sudah menemukan celah yang sama di puluhan pasar terkait, menghitung posisi optimal setelah memperhitungkan kedalaman order book dan biaya, lalu mengeksekusi semua transaksi secara paralel, dan mengalihkan dana ke peluang berikutnya.[1]

Perbedaannya bukan hanya kecepatan. Ini adalah infrastruktur matematisnya.

Bab 1: Mengapa “Penjumlahan” Tidak Cukup—Masalah Pola Marginal

Kesalahan Pasar Tunggal

Mari lihat contoh sederhana.

Pasar A: “Trump akan menang di Pennsylvania?”

YES harga $0.48, NO harga $0.52. Totalnya tepat $1.00.

Tampaknya sempurna, tidak ada peluang arbitrase, kan?

Salah.

Tambah satu pasar lagi, dan masalah muncul.

Pasar B: “Partai Republik akan unggul lebih dari 5 poin di Pennsylvania?”

YES harga $0.32, NO harga $0.68. Total juga $1.00.

Kedua pasar ini tampak normal. Tapi ada hubungan logika di antaranya:

Pemilihan presiden AS tidak dihitung secara nasional sekaligus, melainkan berdasarkan negara bagian. Setiap negara bagian adalah medan perang independen, siapa yang mendapatkan lebih banyak suara di negara bagian itu, dia memenangkan semua suara elektoral di sana (winner-takes-all). Trump adalah kandidat Partai Republik. Jadi, “Partai Republik menang di Pennsylvania” dan “Trump menang di Pennsylvania”—adalah hal yang sama. Jika Partai Republik menang lebih dari 5 poin, itu berarti Trump juga menang di Pennsylvania dan kemenangan besar.

Dengan kata lain, YES di pasar B (kemenangan besar Partai Republik) adalah subset dari YES di pasar A (Trump menang). Kemenangan besar pasti berarti menang, tapi menang tidak selalu berarti kemenangan besar.

Hubungan logika ini menciptakan peluang arbitrase.

Ini seperti Anda bertaruh dua hal—“Apakah besok akan hujan” dan “Apakah besok akan ada bada petir.”

Kalau ada bada petir, pasti hujan (badai adalah subset dari hujan). Jadi, harga “Badai YES” tidak bisa lebih tinggi dari “Hujan YES.” Jika harga pasar melanggar logika ini, Anda bisa membeli murah dan menjual mahal secara bersamaan, mendapatkan “profit tanpa risiko,” itulah arbitrase.

Ledakan Indeks: Mengapa Pencarian Brutal Tidak Mungkin

Untuk pasar dengan n kondisi, secara teori ada 2^n kombinasi harga.

Terdengar bisa dilakukan? Mari lihat kasus nyata.

Turnamen NCAA 2010 [2]: 63 pertandingan, masing-masing ada hasil menang/kalah. Jumlah kombinasi hasil adalah 2^63 = 9.223.372.036.854.775.808—lebih dari 9 kuadriliun. Ada lebih dari 5000 pasar.

Berapa besar angka 2^63? Jika Anda memeriksa 1 miliar kombinasi per detik, butuh sekitar 292 tahun untuk memeriksa semuanya. Itulah sebabnya “pencarian brutal” di sini sama sekali tidak mungkin.

Periksa satu per satu? Secara komputasi, tidak realistis.

Lihat juga Pemilihan Presiden AS 2024. Tim riset menemukan 1.576 pasangan pasar yang mungkin bergantung satu sama lain. Jika setiap pasangan memiliki 10 kondisi, maka perlu memeriksa 2^20 = 1.048.576 kombinasi per pasangan. Dikalikan 1.576 pasangan, komputer Anda sudah selesai sebelum hasil pemilihan keluar.

Pemrograman Integer: Mengganti Enumerasi dengan Constraints

Solusi sistem kuantitatif bukan “mengenumerasi lebih cepat,” melainkan “tidak enumerasi sama sekali.”

Mereka menggunakan Integer Programming untuk mendeskripsikan “hasil yang sah.”

Contoh nyata: Pasar pertandingan Duke vs Cornell. Setiap tim punya 7 kondisi (jumlah kemenangan 0-6), total 14 kondisi, 2^14 = 16.384 kombinasi.

Tapi ada constraint: mereka tidak bisa menang lebih dari 5 pertandingan, karena kalau lebih, mereka akan bertemu di semifinal (hanya satu yang bisa maju).

Bagaimana Integer Programming mengatasi ini? Dengan tiga constraint:

· Constraint 1: Dari 7 kondisi Duke, tepat satu yang benar (Duke hanya bisa punya satu jumlah kemenangan akhir).

· Constraint 2: Dari 7 kondisi Cornell, tepat satu yang benar.

· Constraint 3: Jumlah kemenangan Duke dan Cornell tidak bisa keduanya lebih dari 4 (misalnya, Duke menang 5 dan Cornell menang 6 tidak mungkin bersamaan).

Tiga constraint linier ini menggantikan 16.384 pemeriksaan brute-force.

Dengan kata lain, pencarian brute-force seperti membaca setiap kata dalam kamus untuk menemukan satu kata. Sedangkan Integer Programming seperti langsung membuka halaman yang sesuai huruf awalnya. Anda tidak perlu memeriksa semua kemungkinan, cukup mendeskripsikan “hasil yang sah seperti apa,” lalu biarkan algoritma mencari yang melanggar aturan.

Data nyata: 41% pasar mengandung arbitrase [2]

Dalam studi mereka, tim riset menganalisis data dari April 2024 sampai April 2025:

• Memeriksa 17.218 kondisi

• 7.051 kondisi mengandung arbitrase pasar tunggal (41%)

• Deviasi harga median: $0.60 (seharusnya $1.00)

• 13 pasangan pasar terverifikasi memiliki arbitrase lintas pasar yang bisa dimanfaatkan

Deviasi median $0.60 menunjukkan pasar sering menyimpang 40%. Ini bukan “hampir efisien,” ini “skala besar bisa dimanfaatkan.”

Bab 2: Proyeksi Bregman—Menghitung Arbitrase Optimal

Menemukan arbitrase itu satu hal. Menghitung arbitrase optimal adalah hal lain.

Anda tidak cukup “mengambil rata-rata” atau “menyesuaikan harga sedikit.” Anda harus memproyeksikan kondisi pasar saat ini ke ruang yang bebas arbitrase secara sah, sambil mempertahankan struktur informasi harga.

Mengapa “jarak garis lurus” tidak cukup

Ide paling intuitif adalah: cari harga “sah” terdekat dari harga saat ini, lalu lakukan transaksi selisih harga.

Dalam bahasa matematis, minimisasi jarak Euclidean: ||μ - θ||²

Tapi ini punya masalah fatal: memperlakukan semua perubahan harga sama saja.

Dari $0.50 naik ke $0.60, dan dari $0.05 naik ke $0.15, keduanya kenaikan 10 sen. Tapi maknanya sangat berbeda.

Mengapa? Karena harga mewakili probabilitas tersirat. Dari 50% ke 60% adalah penyesuaian pandangan yang lembut. Dari 5% ke 15% adalah perubahan keyakinan besar—kejadian yang hampir tidak mungkin tiba-tiba menjadi “agak mungkin.”

Bayangkan Anda menimbang berat badan. Dari 70 kg ke 80 kg, Anda bilang “agak gemuk.” Tapi dari 30 kg ke 40 kg (kalau Anda dewasa), itu berarti “dari hampir mati ke malnutrisi parah.” Perubahan 10 kg ini sangat berbeda maknanya. Sama halnya dengan harga—semakin dekat ke 0 atau 1, perubahan kecil berarti informasi besar.

Bregman Divergence: Jarak yang Tepat

Market maker Polymarket menggunakan LMSR (Logarithmic Market Scoring Rule)[4], di mana harga secara esensial mewakili distribusi probabilitas.

Dalam struktur ini, ukuran jarak yang benar bukan Euclidean, melainkan Bregman Divergence.[5]

Untuk LMSR, Bregman Divergence menjadi KL Divergence (Kullback-Leibler)[6]—ukuran “jarak” antara dua distribusi probabilitas berdasarkan teori informasi.

Anda tidak perlu menghafal rumusnya. Yang penting dipahami adalah:

KL Divergence secara otomatis memberi bobot lebih besar pada perubahan harga ekstrem. Dari $0.05 ke $0.15, perubahan ini lebih “jauh” dalam pengukuran KL daripada dari $0.50 ke $0.60. Ini sesuai intuisi kita—perubahan harga ekstrem mengandung informasi yang lebih besar.

Contoh nyata: di pasar prediksi @zachxbt terakhir, Axiom melampaui Meteora dengan perubahan harga ekstrem sebagai indikator utama.

Keuntungan arbitrase = Jarak proyeksi Bregman

Ini adalah salah satu kesimpulan inti dari makalah asli:

Profit maksimum yang bisa diperoleh dari transaksi adalah jarak proyeksi Bregman dari kondisi pasar saat ini ke ruang tanpa arbitrase.

Dengan kata lain: semakin jauh harga menyimpang dari ruang yang sah, semakin besar potensi keuntungan. Proyeksi Bregman memberi tahu Anda:

1. Apa yang harus dibeli/jual (arah proyeksi)

2. Berapa banyak (pertimbangan kedalaman order book)

3. Berapa banyak yang bisa didapat (jarak proyeksi = keuntungan maksimum)

Peringkat teratas arbitrase dalam setahun meraup $2.009.631,76.[2] Strateginya adalah memecahkan masalah optimisasi ini lebih cepat dan lebih akurat dari yang lain.

Bayangkan Anda berdiri di atas gunung, di kaki gunung ada sungai (ruang tanpa arbitrase). Posisi Anda saat ini (harga pasar) berjarak dari sungai.

Proyeksi Bregman seperti menemukan “jalur terpendek dari posisi Anda ke sungai”—bukan garis lurus, tapi jalur yang mempertimbangkan medan (struktur pasar). Panjang jalur ini adalah keuntungan maksimal yang bisa Anda raih.

Bab 3: Algoritma Frank-Wolfe—Mengubah Teori Jadi Kode yang Bisa Dieksekusi

Sekarang Anda tahu: untuk menghitung arbitrase optimal, Anda harus melakukan proyeksi Bregman.

Tapi masalahnya—menghitung proyeksi Bregman secara langsung tidak praktis.

Mengapa? Karena ruang tanpa arbitrase (poli marginal M) memiliki jumlah vertex yang eksponensial. Metode optimisasi konveks standar membutuhkan akses ke seluruh constraint, yang berarti enumerasi semua hasil sah. Kita sudah bahas, ini tidak mungkin dalam skala besar.

Inti Algoritma Frank-Wolfe

Kehebatan algoritma Frank-Wolfe [7] adalah: tidak mencoba menyelesaikan seluruh masalah sekaligus, melainkan mendekati jawaban secara bertahap.

Cara kerjanya seperti ini:

Langkah 1: Mulai dari himpunan hasil sah yang kecil dan diketahui.

Langkah 2: Optimasi di himpunan kecil ini, cari solusi terbaik saat ini.

Langkah 3: Gunakan Integer Programming untuk menemukan hasil sah baru, tambahkan ke himpunan.

Langkah 4: Periksa apakah sudah cukup dekat dengan solusi optimal. Jika belum, kembali ke langkah 2.

Setiap iterasi, himpunan hanya bertambah satu vertex. Bahkan setelah 100 iterasi, Anda hanya melacak 100 vertex—bukan 2^63.

Bayangkan Anda di labirin besar mencari jalan keluar.

Metode brute-force mencoba semua jalan. Frank-Wolfe seperti berjalan sembarang, lalu di setiap simpang bertanya “pemandu” (solver integer programming): “Dari sini, jalur mana yang paling mungkin menuju keluar?” Kemudian melangkah ke sana. Anda tidak perlu menjelajahi seluruh labirin, cukup membuat pilihan tepat di setiap titik penting.

Solver Integer Programming: “Pemandu” di setiap langkah

Setiap iterasi Frank-Wolfe memerlukan penyelesaian masalah linear integer. Secara teori, ini NP-hard (artinya tidak ada algoritma cepat yang diketahui).

Tapi solver modern, seperti Gurobi[8], sangat efisien untuk masalah dengan struktur baik.

Tim riset menggunakan Gurobi 5.5. Waktu penyelesaian nyata:

• Iterasi awal (beberapa pertandingan selesai): kurang dari 1 detik

• Menengah (30-40 pertandingan selesai): 10-30 detik

• Akhir (lebih dari 50 pertandingan selesai): kurang dari 5 detik

Mengapa di akhir lebih cepat? Karena hasil yang feasible semakin terbatas, variabel lebih sedikit, constraint lebih ketat, proses penyelesaian lebih cepat.

Masalah gradien meledak dan Barrier Frank-Wolfe

Algoritma Frank-Wolfe standar punya masalah: saat harga mendekati 0, gradien LMSR cenderung ke negatif tak hingga, menyebabkan ketidakstabilan.

Solusinya adalah Barrier Frank-Wolfe: tidak mengoptimasi di seluruh poli M, melainkan di versi yang sedikit “dikurangi” (dengan parameter ε). Parameter ini secara adaptif mengecil selama iterasi—awal jauh dari batas, kemudian mendekati batas asli secara akurat.

Penelitian menunjukkan, 50-150 iterasi sudah cukup konvergen.

Performa nyata

Dalam makalah disebutkan [2]:

Pada 16 pertandingan NCAA pertama, FWMM (Market Maker Frank-Wolfe) dan Market Maker linier sederhana (LCMM) performanya hampir sama—karena solver NP-hard ini masih lambat.

Tapi setelah 45 pertandingan, proyeksi selama 30 menit pertama berhasil diselesaikan.

Sejak saat itu, FWMM menunjukkan performa 38% lebih baik dalam penetapan harga dibanding LCMM.

Titik baliknya adalah saat ruang hasil menyusut ke tingkat di mana integer programming bisa diselesaikan dalam waktu trading.

FWMM seperti pelajar yang pemanasan di awal, tapi setelah masuk ke ritme, bisa mengalahkan lawan. LCMM adalah pelajar yang stabil tapi terbatas kemampuannya. Perbedaan utama: FWMM punya “senjata” yang lebih kuat (proyeksi Bregman), hanya butuh waktu untuk “mengisi peluru” (solver selesai).

Bab 4: Eksekusi—Mengapa Setelah Hitung Masih Bisa Rugi

Anda sudah mendeteksi arbitrase. Menghitung arbitrase optimal. Sekarang, Anda harus mengeksekusi.

Ini adalah bagian di mana sebagian besar strategi gagal.

Masalah Eksekusi Non-Atomik

Polymarket memakai CLOB (Central Limit Order Book)[9]. Berbeda dari DEX, transaksi di CLOB dilakukan secara berurutan—Anda tidak bisa menjamin semua order terjadi sekaligus.

Rencana arbitrase Anda:

Beli YES, harga $0.30. Beli NO, harga $0.30. Total biaya $0.60. Apapun hasilnya, Anda bisa mendapatkan kembali $1.00. Keuntungan $0.40.

Tapi kenyataannya:

· Submit order YES → transaksi di harga $0.30 ✓

· Order Anda mengubah harga pasar.

· Submit order NO → transaksi di harga $0.78 ✗

· Total biaya: $1.08. Return: $1.00. Hasil nyata: rugi $0.08.

Satu order terpenuhi, yang lain tidak. Anda terekspos risiko.

Itulah mengapa makalah ini hanya menghitung peluang dengan selisih harga > $0.05. Spread lebih kecil dari itu akan dimakan risiko eksekusi.

VWAP: Harga Transaksi Rill

Jangan anggap Anda bisa langsung transaksi di harga tawaran. Hitunglah VWAP (Volume Weighted Average Price)[10].

Tim riset menghitung VWAP dari semua transaksi YES dan NO dalam satu blok Polygon (sekitar 2 detik). Jika |VWAP_yes + VWAP_no - 1.0| > 0.02, dianggap sebagai peluang arbitrase [2].

VWAP adalah “harga rata-rata yang sebenarnya Anda bayar.” Jika Anda ingin membeli 10.000 token, tapi order book hanya punya $0.30 untuk 2.000 token, $0.32 untuk 3.000, dan $0.35 untuk 5.000, maka VWAP Anda adalah (2000×0.30 + 3000×0.32 + 5000×0.35) / 10000 = $0.326. Lebih mahal dari harga “optimal” $0.30.

Keterbatasan Likuiditas: Berapa Banyak Bisa Dapat

Meskipun ada deviasi harga, keuntungan Anda terbatas oleh kedalaman order book.

Contoh nyata [2]:

Pasar menunjukkan arbitrase: total harga YES = $0.85. Potensi keuntungan: $0.15 per dolar. Tapi kedalaman order book hanya $234. Jadi, keuntungan maksimal: $234 × $0.15 = $35.10.

Untuk arbitrase lintas pasar, Anda harus punya likuiditas di semua posisi sekaligus. Nilai terkecil menentukan batas maksimum.

Ini sebabnya, dalam platform kuantitatif, menunjukkan pengaruh harga order terhadap harga eksekusi sangat penting.

Bab 5: Sistem Lengkap—Apa yang Sudah Diterapkan

Teori bersih. Produksi nyata berantakan.

Ini gambaran sistem arbitrase yang benar-benar berjalan [2].

Pipeline Data

Data real-time: WebSocket dari API Polymarket [9], menerima update order book (harga/volume), push transaksi, event pembuatan/penyelesaian pasar.

Data historis: Menggunakan API node Alchemy Polygon untuk query event kontrak—OrderFilled (eksekusi transaksi), PositionSplit (pencetakan token baru), PositionsMerge (penghancuran token).

Tim riset menganalisis 86 juta transaksi [2]. Volume sebesar ini membutuhkan infrastruktur, bukan sekadar skrip.

Ada juga rencana open-source API trading cepat, jika ingin mencoba model trading ini, DM saya.

Layer deteksi dependensi

Untuk 305 pasar pemilihan AS, ada 46.360 pasangan kombinasi yang perlu dicek. Analisis manual tidak mungkin.

Tim riset memakai metode cerdas: pakai LLM (Large Language Model) DeepSeek-R1-Distill-Qwen-32B untuk screening awal.

Input: deskripsi kondisi dua pasar. Output: JSON kombinasi hasil sah.

Lalu dilakukan tiga tahap verifikasi: apakah setiap pasar punya tepat satu kondisi benar? jumlah kombinasi sah kurang dari n×m (ada dependensi)? subset dependensi memenuhi syarat arbitrase?

Hasil: 40.057 pasangan independen (tanpa arbitrase) → 1.576 pasangan bergantung (potensi arbitrase) → 374 memenuhi syarat ketat → 13 diverifikasi manual bisa dimanfaatkan [2].

Akurasi LLM di pasar multi-kondisi kompleks adalah 81.45%. Cukup untuk screening awal, tapi sebelum eksekusi harus diverifikasi manual.

Mesin optimisasi tiga lapis

· Lapisan 1: Constraint linier sederhana (LCMM). Pemeriksaan cepat aturan dasar—“jumlah probabilitas = 1”, “jika A mengandung B, P(A) tidak boleh melebihi P(B)”. Dalam milidetik selesai, mengeliminasi kesalahan harga yang jelas.

· Lapisan 2: Proyeksi Integer Programming (Frank-Wolfe + Gurobi). Inti dari sistem. Parameter: Alpha=0.9 (ambil minimal 90% dari arbitrase yang tersedia), ε awal=0.1 (10% penyusutan), threshold konvergensi=1e-6, batas waktu=30 menit. Iterasi biasanya 50-150 kali. Waktu tiap iterasi: 1-30 detik.

· Lapisan 3: Verifikasi eksekusi. Sebelum submit order, simulasi transaksi di order book saat ini. Periksa: likuiditas cukup? slippage berapa? keuntungan setelah slippage berapa? apakah melebihi ambang minimum ($0.05)? Jika semua lolos, baru eksekusi.

Manajemen posisi: Versi modifikasi dari rumus Kelly

Rumus Kelly standar [11] menyarankan berapa proporsi dana yang harus diinvestasikan. Tapi dalam arbitrase, perlu penyesuaian risiko eksekusi:

f = (b×p - q) / b × √p

di mana b adalah persentase keuntungan arbitrase, p adalah probabilitas eksekusi sempurna (estimasi dari kedalaman order book), q=1-p.

Batas atas: 50% dari kedalaman order book. Lebih dari itu, order sendiri bisa menggerakkan pasar secara signifikan.

Hasil akhir

Dari April 2024 sampai April 2025, total keuntungan yang diambil:

Arbitrase kondisi tunggal: beli murah di kedua sisi $5.899.287 + jual tinggi di kedua sisi $4.682.075 = $10.581.362

Rebalancing pasar: beli semua YES $11.092.286 + jual semua YES $612.189 + beli semua NO $17.307.114 = $29.011.589

Arbitrase lintas pasar: $95.634

Total: $39.688.585

10 pemain teratas meraup $8.127.849 (20.5% dari total). Peringkat pertama: $2.009.632 dari 4.049 transaksi, rata-rata per transaksi $496[2].

Ini bukan lotere. Bukan keberuntungan. Ini sistem matematis yang dieksekusi secara sistematis.

Realitas terakhir

Saat trader masih membaca “10 Tips Prediksi Pasar,” sistem kuantitatif sedang melakukan apa?

Mereka menggunakan integer programming untuk mendeteksi dependensi 17.218 kondisi. Menggunakan Bregman proyeksi untuk menghitung arbitrase optimal. Menjalankan algoritma Frank-Wolfe untuk mengatasi gradien meledak. Menggunakan VWAP untuk memperkirakan slippage dan mengeksekusi order secara paralel. Secara sistematis mengekstraksi keuntungan sebesar $40 juta.

Perbedaannya bukan keberuntungan. Melainkan infrastruktur matematis.

Makalahnya terbuka [1]. Algoritmanya sudah diketahui. Keuntungannya nyata.

Pertanyaannya: sebelum $40 juta berikutnya diambil, bisakah Anda membangunnya?

Kamus Cepat

• Pola Marginal (Marginal Polytope) → Ruang semua harga “sah.” Harga harus berada di ruang ini agar bebas arbitrase. Bisa dipahami sebagai “wilayah harga yang sah.”

• Integer Programming → Menggunakan constraint linier untuk mendeskripsikan hasil sah, menghindari enumerasi brute-force. Mengubah 2^63 pemeriksaan menjadi beberapa constraint [3].

• Bregman / KL Divergence → Ukuran “jarak” antara dua distribusi probabilitas, lebih cocok untuk harga/probabilitas. Perubahan ekstrem di dekat 0 atau 1 diberi bobot lebih tinggi [5][6].

• LMSR (Logarithmic Market Scoring Rule) → Mekanisme penetapan harga yang digunakan market maker Polymarket, harga mewakili probabilitas implisit [4].

• Algoritma Frank-Wolfe → Algoritma optimisasi iteratif, tiap langkah menambahkan satu vertex baru, menghindari enumerasi hasil yang eksponensial [7].

• Gurobi → Solver integer programming terkemuka di industri, “pemandu” setiap iterasi Frank-Wolfe [8].

• CLOB (Central Limit Order Book) → Mekanisme pencocokan transaksi di Polymarket, order dieksekusi berurutan, tidak atomik [9].

• VWAP (Volume Weighted Average Price) → Harga rata-rata yang sebenarnya Anda bayar, memperhitungkan kedalaman order book. Lebih realistis daripada harga terbaik [10].

• Rumus Kelly → Menunjukkan proporsi dana yang harus diinvestasikan, menyeimbangkan risiko dan imbal hasil [11].

• Eksekusi Non-Atomik → Masalah di mana beberapa order tidak bisa dieksekusi bersamaan. Satu terpenuhi, yang lain tidak = risiko terekspos.

• DeepSeek → Model bahasa besar untuk screening awal dependensi pasar, akurasi 81.45%.