Blog

Polymarket Gamma API ingestion for prediction-market articles

নালি ইঞ্জিনিয়ারিং নোট: প্রেডিকশন মার্কেট নিবন্ধের জন্য পলিমার্কেট গামা API ইনজেস্টন

নালি পলিমার্কেট গামা API-কে প্রেডিকশন-সম্পর্কিত কনটেন্টের প্রথম-পক্ষ ইনপুট প্লেন হিসেবে ব্যবহার করে, সম্পাদনা তৈরির আগে প্রকাশ্য মার্কেট মেটাডেটা ও সম্ভাবনাকে কাঠামোবদ্ধ সিগনালে রূপান্তরিত করে। এর ফলে মিসপ্রাইসিং নিবন্ধ, KBO প্রিভিউ, সোর্স উদ্ধৃতি এবং ভেরিফিকেশন পোস্ট পুনরুৎপাদনযোগ্য ও অডিটযোগ্য থাকে,伸

June 10, 20268 sources

TL;DRনালি পলিমার্কেটের গামা API-কে সব প্রেডিকশন মার্কেট ওয়ার্কফ্লোর জন্য একটি deterministic discovery-and-pricing সাবস্ট্রেট হিসেবে ব্যবহার করে, ad hoc নিউজ স্ক্র্যাপিংয়ের পরিবর্তে কাঠামোবদ্ধ মার্কেট সত্তা গ্রহণ করে। প্রতি চক্রে এটি লাইভ ইভেন্ট ও মার্কেটকে মিসপ্রাইসিং রাউন্ডআপ, KBO প্রিভিউ, উদ্ধৃতি বান্ডিল ও পরে ফলাফল যাচাইয়ের জন্য নিবন্ধ-প্রস্তুত সিগ্যালে পরিণত করে, তাই গল্প তৈরি সবসময় অনুমিত মতামতের বদলে প্রকাশ্যভাবে দেখা যায় এমন সম্ভাবনা ও মার্কেট কাঠামো থেকে শুরু হয়।

সারসংক্ষেপ

নালি প্রেডিকশন মার্কেটের মার্কেট ডেটাকে ওভারলে হিসেবে নয়, অবকাঠামো হিসেবে ব্যবহার করছে, ফলে সম্পাদনামূলক আর্টিফ্যাক্ট সরাসরি এমন একটি বাহ্যিক মার্কেট অবস্থার সাথে যুক্ত হয় যা পরে অডিট করা যায়। গামা API ইভেন্ট, মার্কেট, ট্যাগ ও দাম দেখার জন্য একটি read path দেয়, যেখানে ওয়ালেট-লেভেল কী দরকার পড়ে না। নকশার চ্যালেঞ্জ হলো এই ইনজেস্ট লেয়ারকে নির্ভরযোগ্যতার জন্য যথেষ্ট কঠোর রাখার পাশাপাশি কনটেন্ট টিমের দ্রুত টপিক আবিষ্কারের জন্য যথেষ্ট নমনীয় রাখা।

নালিতে এর অবস্থান

পলিমার্কেট গামা ইনজেস্ট বসে থাকে কাঁচা মার্কেট প্রিমিটিভ এবং প্রকাশযোগ্য সম্পাদকীয় সম্পদের মাঝে আপস্ট্রিম সীমান্তে। এটি একটি বৃহত্তর পাইপলাইনের প্রথম ধাপ:

  • ইনপুট লেয়ার: গামা থেকে ইভেন্ট, মার্কেট, ট্যাগ এবং মার্কেট স্ট্যাটাস ফেচ করা হয়।
  • ইন্টারপ্রিটেশন লেয়ার: Naly-এর অভ্যন্তরীণ স্কিমায় স্বাভাবিকীকরণ করা হয় (event_id, market_id, টোকেন আইডি, ফলাফল, সম্ভাবনা, টাইমস্ট্যাম্প, active/closed ফ্ল্যাগ)।
  • ন্যারেটিভ লেয়ার: মিসপ্রাইসিং রাউন্ডআপ ও KBO প্রেডিকশন ড্রাফটিং ফ্লোতে স্বাভাবিকীকৃত ইনপুট সরবরাহ করা হয়।
  • ভ্যালিডেশন লেয়ার: পরবর্তী নিবন্ধ সত্য যাচাই ও রেট্রোস্পেকটিভ স্কোরকার্ডের জন্য সমাধান/বন্ধ মার্কেট স্টেট সংরক্ষণ করা হয়।

June 10, 2026 অনুযায়ী, এটি বিশেষভাবে সক্রিয় কৌশলগুলোর সাথে সামঞ্জস্যপূর্ণ যা বিশ্বস্ত, উদ্ধৃতি-প্রস্তুত পূর্বাভাস প্রমাণ চায়: prediction calibration visibility, repeatable content sourcing এবং পরে verification workflows।

প্রযুক্তিগত কার্যপ্রণালী

Polymarket তিনটি API সংজ্ঞায়িত করে, যেখানে Gamma ইভেন্ট/মার্কেট ব্রাউজিং ও মেটাডেটার জন্য public discovery plane, আর order book/trade-style ডেটা প্রকাশ করে CLOB এবং user/positions ডেটা দেয় Data API (docs)। Polymarket docs অনুযায়ী Gamma ও Data public, তবে order অপারেশনের জন্য CLOB-এ private/trading surfaces-এ authentication লাগে।

Naly শুধু public endpoint দিয়েই একটি শক্তিশালী দৈনিক ফ্লো বাস্তবায়ন করতে পারে:

  1. সক্রিয় প্রার্থী মার্কেট আবিষ্কার করুন মাধ্যমে GET /events সহ active=true, closed=false, pagination (limit, offset), এবং ঐচ্ছিক ordering filters।
  2. উপাদান মার্কেটে প্রসারিত করুন event-level payload ব্যবহার করে, কারণ ইভেন্টগুলোর সাথে সংশ্লিষ্ট মার্কেট থাকে এবং আলাদা market lookup-এর তুলনায় কম API কল লাগে।
  3. সুনির্দিষ্ট সত্তা টার্গেট করুন যখন কোনো পরিচিত ইভেন্ট বা মার্কেট আগে থেকেই চিহ্নিত, তখন slug-based কল ব্যবহার করুন।
  4. মূল্য স্বাভাবিকীকরণ করুন ম্যাপিং দ্বারা outcomes এবং outcomePrices arrays index-by-index করে নামযুক্ত সম্ভাবনায় রূপান্তর করুন।
  5. অডিট আর্টিফ্যাক্ট সংরক্ষণ করুন উভয়ই normalised row এবং raw snapshot হিসেবে, যাতে প্রতিটি নিবন্ধে প্রতিটি উৎস-উৎপন্ন সংখ্যা ট্রেস করা যায়।
  6. ডাউনস্ট্রিম জেনারেশন গেট করুন freshness + schema check-এ; পুরোনো বা অসম্পূর্ণ snapshot ব্যবহার-পূর্বে refresh-এর জন্য চিহ্নিত হবে।

Gamma ডকুমেন্টেশন ঠিক এই অপারেশনাল কাঠামোই বর্ণনা করে: discovery-এর জন্য public endpoint যেমন /events, /markets, /public-search, /tags, এবং /series পেজিনেশন ও filtering সহ উপলব্ধ, যেখানে pagination এবং filtering সাপোর্ট করা হয় limit/offset, tag_idএবং সংশ্লিষ্ট ফিল্টার দিয়ে। এছাড়া এটি তিনটি সরাসরি retrieval pattern-এরও পরামর্শ দেয়: slug lookup, tag-based discovery এবং বিস্তৃত স্ক্যানের জন্য event enumeration। Naly-এর জন্য event-first প্যাটার্নই সর্বাধিক সাশ্রয়ী যখন বড় দৈনিক candidate তৈরি করা হয়, কারণ প্রতিটি ইভেন্ট অনেকগুলো মার্কেট রেকর্ড বের করতে পারে।

বাস্তবে, Naly-এর জন্য একটি minimal source-of-truth রেকর্ডে থাকা উচিত:

  • ইভেন্ট ও মার্কেট আইডি
  • মার্কেট question
  • clobTokenIds (প্রয়োজনে CLOB-এর সাথে downstream price reconciliation-এর জন্য)
  • outcomes এবং outcomePrices
  • enableOrderBook
  • active, closed, এবং সময় ক্ষেত্র (start/end timestamps)
  • ফেচ টাইমস্ট্যাম্প এবং সোর্স URL

যদিও গামা ইতিমধ্যেই একটি শক্তিশালী সম্ভাব্যতার বেসলাইন দিতে পারে, একটি দ্বিতীয় refinement path ঐচ্ছিক: যখন Naly ছোট ইন্টারভালের intraday আপডেট চায়, তখন পরে CLOB endpoint যেমন /price, /pricesঅথবা /book যুক্ত করা যেতে পারে।

সাহিত্য কী বলে

প্রেডিকশন মার্কেট নিয়ে গবেষণা এই data-first পদ্ধতিকে সমর্থন করে কিন্তু ব্যাখ্যার চারপাশে guardrail যোগ করে।

  • prediction markets-এ market data model শুধুই তখনই কার্যকর যখন সেটি calibrated এবং সঠিকভাবে ব্যাখ্যা করা হয়; দামগুলো প্রসঙ্গ ছাড়া সর্বজনীন সম্ভাবনা নয়। ২০২6 সালের একটি Polymarket ও Kalshi-র গবেষণায় ডোমেইন ও time horizon ভেদে সুসংগঠিত calibration pattern পাওয়া গেছে, যেখানে কিছু ক্ষেত্রে উল্লেখযোগ্য underconfidence দেখা যায়।
  • আরেকটি 2026 lifecycle-focused গবেষণায় বলা হয়েছে যে অর্থবহ বাজার বিশ্লেষণের জন্য synchronized multi-layer data engineering দরকার: market metadata, trading events এবং resolution signal-কে স্পষ্টভাবে লিংক করতে হয় এবং পৃথক pull-এর বদলে সময়কালীন consistency check চালাতে হয়।
  • পূর্ববর্তী কাজগুলো দেখায়, বাজারের মূল্যপ্রবাহে ধারাবাহিক নিলামধর্মী গতিতে trader information পরিবাহিত হয়, তাই Naly মার্কেট প্রাইসকে collective-forecast signal হিসেবে ব্যবহার করতে পারে, তবে সময়ের সাথে outcome যাচাই অব্যাহত রাখে।
  • Forecasting literature যেখানে বাজার মূল্যকে অন্যান্য পদ্ধতির সাথে তুলনা করে (যেমন survey-based forecasting), সেগুলো দেখায় prediction market শক্তিশালীভাবে predictive হতে পারে, কিন্তু outcome verification এবং model discipline বজায় না রাখলে নয়।

Naly-এর জন্য বাস্তব পরিণতি সরল: provenanceসহ সবকিছু ingest করুন, কোনো একক price snapshot-কে চূড়ান্ত সত্য মনে করবেন না, এবং আলাদা করুন readiness (data freshness + integrity) story quality (editorial framing) থেকে।

ডিজাইন trade-off

Naly উদ্দেশ্যপ্রণোদিতভাবে ingestion-এ reliability-কে speed-এর ওপর অগ্রাধিকার দেয়।

  • Gamma-only বনাম Gamma+CLOB: Gamma দ্রুত স্থিতিশীল discovery ও public context দেয়; CLOB যোগ করলে microstructure richness বাড়ে, কিন্তু authentication এবং endpoint জটিলতা বৃদ্ধি পায়।
  • দৈনিক snapshot বনাম continuous streaming: একটি deterministic scheduled pull audit এবং reproduce করা সহজ, কিন্তু sub-minute regime shift miss করতে পারে।
  • Event-first pull বনাম market-first pull: event-first ডুপ্লিকেট কল কমায় ও প্রসঙ্গগত কভারেজ বাড়ায়; market-first কিছু সীমিত কাজের জন্য payload size কিছুটা কম দেয়।
  • Wide schema বনাম strict schema: বিস্তৃত JSON-first schema ইন্টিগ্রেশন দ্রুত করে কিন্তু schema drift risk বাড়ায়; strict normalization আগে drift ধরতে সাহায্য করে কিন্তু migration overhead বাড়ায়।
  • Generalized fields বনাম domain-specific fields: shared fields ব্যবহার করলে বিভিন্ন নিবন্ধে পুনরায় ব্যবহার সহজ হয়; domain-specific extension (যেমন sport-specific confidence windows) যোগ করলে সাথে সাথে precision বাড়লেও দীর্ঘমেয়াদে maintenance ভেঙে যেতে পারে।

Naly-এর user trust ও retention লক্ষ্য বিবেচনায়, strict reproducibility এবং citation quality-কে সঙ্গে সঙ্গে latency অপ্টিমাইজেশনের ওপর প্রাধান্য দেওয়া উচিত।

ব্যর্থতার ধরণ

সবচেয়ে বড় ব্যর্থতার ধরন অপারেশনাল, অ্যালগরিদমিক নয়।

  • pagination বাগের কারণে ডেটা অনুপস্থিতি: যদি limit এবং offset polled উইন্ডো পরিবর্তিত হয়, ডুপ্লিকেট বা ফাঁক দেখা দিতে পারে। প্রতিকার: pagination cursor checkpoint করুন এবং idempotent upserts নিশ্চিত করুন।
  • ডিফল্ট closed=false ঐতিহাসিক প্রসঙ্গ ফসকে যাওয়া: open-market pulls resolved আইটেম বাদ দেয় যদি closed=true এগুলিকে স্পষ্টভাবে requested না করা হয়। প্রতিকার: verification কাজের জন্য পৃথক historical backfill path চালান।
  • Slug instability: প্রোডাক্ট URL এবং মানুষের পড়ার উপযোগী slugs drift করতে পারে। প্রতিকার: অভ্যন্তরীণভাবে primary ID-কে অগ্রাধিকার দিন এবং slug-কে দ্বিতীয়িক key হিসেবে রাখুন।
  • Semantic field drift: outcomes/outcomePrices ব্যাখ্যা ভেঙে যেতে পারে যদি schema order-এর ধারণা ভুল হয়। প্রতিকার: ingest সময়ে array alignment এবং length check নিশ্চিত করুন।
  • Public API-র সাময়িক অনুপস্থিতি বা throttling: public endpoint ব্যর্থ হতে পারে বা আংশিক payload ফিরিয়ে দিতে পারে। প্রতিকার: exponential backoff দিয়ে retry, repeated failure হলে poison-queue এবং পূর্বের snapshot ধরে রাখা।
  • দেরিতে resolution এবং stale narrative: যাচাই নিবন্ধ settlement পরিষ্কার হওয়ার আগে ছাপা হতে পারে। প্রতিকার: publish-state-এর অংশ হিসেবে settlement status রাখুন এবং immutable correction log দিয়ে পরে আপডেট করুন।

Naly-এর trust-first কৌশল অনুযায়ী পাইপলাইনকে fail closed হওয়া উচিত: unverified market state নিয়ে নিবন্ধ প্রকাশের চেয়ে প্রকাশ বিলম্বিত করা ভালো।

বাস্তবায়ন নোট

প্রদত্ত runtime stack ব্যবহার করলে বাস্তবায়ন সরাসরি ও সহজ থাকে:

  • Next.js server handlers (next@16.0.7) ব্যবহার করে ingestion endpoint এবং scheduled job হোস্ট করুন।
  • Neon-এ normalised row persist করুন drizzle-orm@^0.44.7 over @neondatabase/serverless@^1.0.2 স্পষ্ট unique constraints সহ মার্কেট শনাক্তকারকগুলিতে।
  • Vercel Blob-এ raw payload snapshot সংরক্ষণ করুন (@vercel/blob@^2.0.0) অডিটেবিলিটি ও পোস্ট-মর্টেম diffing-এর জন্য।
  • markdown source generation এবং article assembly ইনজেস্ট কোরের বাইরে রাখুন; ব্যবহার করুন marked@^17.0.1 নিরাপদ transformation-এর জন্য এবং ai@6.0.0-beta.105 এবং @anthropic-ai/claude-agent-sdk@^0.2.15 শুধু তখনই যখন data integrity check পাস হয়।
  • ব্যবহার করুন tsx@^4.21.0/typescript@^5.9.3 ঐতিহাসিক উইন্ডো ব্যাকফিলের সময় reproducible one-off replays-এর জন্য।

June 10, 2026 অনুযায়ী স্থাপত্যে তিনটি কঠিন আউটপুটকে প্রাধান্য দিতে হবে: raw snapshot immutability, internal schema-তে deterministic projection, এবং source API URL থেকে চূড়ান্ত নিবন্ধ উদ্ধৃতি পর্যন্ত verification-কেন্দ্রিক audit trail।

References

Sources