مرکزی مواد پر جائیں
اے آئی ٹیوٹوریلز

jev-trader کے ساتھ بلاک بہ بلاک Monad مارکیٹ میکر بنائیں اور چلائیں

jev-trader انسٹال کرنے، اسے محفوظ طریقے سے ڈرائی رن موڈ میں چلانے، Jev ماڈل سے مربوط کرنے، اس کے HTTP اور SSE فیڈز کا جائزہ لینے، کوٹس اور فلز کی تشریح کرنے، اور ان لیٹنسی آپٹیمائزیشنز کو سمجھنے کا طریقہ سیکھیں جو اس کے ٹریڈنگ لوپ کو Monad کے تقریباً 300 ملی سیکنڈ کے بلاک ٹائم میں برقرار رکھتی ہیں۔

تقریباً 26 منٹ کا مطالعہ
jev-trader کے ساتھ بلاک بہ بلاک Monad مارکیٹ میکر بنائیں اور چلائیں

jev-trader کیا کرتا ہے

jev-trader Monad پر موجود Kuru MON-USDC آرڈر بک کے لیے بلاک بہ بلاک ٹریڈنگ بوٹ ہے۔ ہر نئے بلاک پر یہ لائیو آرڈر بک پڑھتا ہے، ماڈل سے پوچھتا ہے کہ خریدنا ہے یا فروخت کرنا ہے، اور منتخب سمت میں پوسٹ اونلی لمٹ آرڈر کا ارادہ بناتا ہے۔

آرڈر کی قیمت موجودہ ٹچ کے اندر QUOTE_INSIDE_TICKS ٹکس رکھی جاتی ہے۔ اگر اسپریڈ بہت تنگ ہو تو قیمت ٹچ تک محدود کر دی جاتی ہے۔ بوٹ اپنے پہلے سے موجود ریسٹنگ آرڈرز منسوخ کرتا ہے اور ایک ہی Kuru batchUpdate میں متبادل آرڈر پوسٹ کرتا ہے۔

چونکہ آرڈر پوسٹ اونلی ہوتا ہے، اس لیے اس کا مقصد فوری طور پر عمل درآمد کے بجائے بک پر موجود رہنا ہے۔ فل اس وقت ہوتا ہے جب کوئی دوسرا شریک ایسا ٹیکر آرڈر جمع کراتا ہے جو اس کی قیمت کو کراس کرتا ہے۔ اس طرح حکمت عملی اسپریڈ ادا کرنے کے بجائے اسے کما سکتی ہے، تاہم عمل درآمد، انوینٹری، گیس اور مارکیٹ کے خطرات برقرار رہتے ہیں۔

اہم خصوصیات

  • Monad کے ہر بلاک پر ایک فیصلہ: بوٹ تقریباً ہر 300 ms میں تازہ ترین بلاک پر کارروائی کرتا ہے۔
  • لائیو Kuru آرڈر بک ڈیٹا: ایک حسب ضرورت ریڈر getL2Book کو ڈی کوڈ کرتا ہے اور AMM والٹ کو بک میں شامل کرتا ہے۔
  • ماڈل کے دو اختیارات: ڈیفالٹ mock ماڈل مومینٹم ہیورسٹک استعمال کرتا ہے، جبکہ MODEL=jev TypeSafe Jev ماڈل فعال کرتا ہے۔
  • محفوظ ڈرائی رن رویہ: PRIVATE_KEY کے بغیر بوٹ حقیقی بک اور حقیقی مارکیٹ پرنٹس استعمال کرتا ہے، لیکن اپنے آرڈرز اور فلز کی نقل تیار کرتا ہے۔
  • پوسٹ اونلی آرڈر کی تبدیلی: ہر اپ ڈیٹ میں معلوم ریسٹنگ آرڈرز منسوخ کیے جاتے ہیں اور ایک ہی بیچ میں نیا پوسٹ اونلی آرڈر جمع کرایا جاتا ہے۔
  • پوزیشن اور P&L ٹریکنگ: ایونٹس پوزیشن، حقیقی اور غیر حقیقی نتائج، گیس کے اخراجات، فل کاؤنٹس اور دیگر مجموعے رپورٹ کرتے ہیں۔
  • HTTP اور SSE مانیٹرنگ: ایک چھوٹا Bun سرور تازہ ترین اسنیپ شاٹ، زیادہ سے زیادہ 1,000 تاریخی بلاک ایونٹس اور لائیو ایونٹ اسٹریم فراہم کرتا ہے۔
  • غیر متزامن تصدیقات: لائیو ٹرانزیکشنز ہاٹ پاتھ پر جمع کرائی جاتی ہیں، جبکہ رسیدیں اور متعلقہ جانچ بعد میں کی جاتی ہیں۔

پروجیکٹ کا ڈھانچہ

سورس ٹری بلاک وصولی، مارکیٹ تک رسائی، ماڈل کی جانچ، ٹریڈنگ لاجک اور مانیٹرنگ کو الگ رکھتا ہے:

  • src/config.ts ماحول کی ترتیب لوڈ کرتا ہے۔
  • src/chain.ts WebSocket newHeads اپ ڈیٹس وصول کرتا ہے، بیک اسٹاپ کے طور پر پولنگ استعمال کرتا ہے، اور صرف تازہ ترین بلاک برقرار رکھتا ہے۔
  • src/book.ts ایک eth_call کے ذریعے آرڈر بک پڑھتا اور ڈی کوڈ کرتا ہے۔
  • src/market.ts Kuru بک ریڈز، مارجن ڈپازٹس، مقامی نونسز، بیچ اپ ڈیٹس اور غیر متزامن تصدیقات سنبھالتا ہے۔
  • src/model.ts ماڈل انٹرفیس کی تعریف کرتا ہے اور JevModel اور MockModel فراہم کرتا ہے۔
  • src/trader.ts ٹریڈنگ لوپ چلاتا ہے اور پوزیشنز اور P&L ٹریک کرتا ہے۔
  • src/server.ts Bun.serve کے ذریعے اسنیپ شاٹس، تاریخ اور Server-Sent Events فراہم کرتا ہے۔

تنصیب اور سیٹ اپ

1. ماحول کی فائل تیار کریں

ریپوزٹری ڈائریکٹری سے مثال کی ترتیب کاپی کریں:

cp .env.example .env

ایپلیکیشن شروع کرنے سے پہلے بننے والی .env فائل کا جائزہ لیں۔ سب سے اہم رویہ PRIVATE_KEY کی موجودگی یا عدم موجودگی سے کنٹرول ہوتا ہے۔

اپنی پہلی رن کے لیے PRIVATE_KEY کو غیر سیٹ رہنے دیں۔ ایپلیکیشن حقیقی مارکیٹ ڈیٹا کے خلاف ڈرائی رن کرے گی اور اپنے آرڈرز براڈکاسٹ نہیں کرے گی۔

2. انحصارات انسٹال کریں

پروجیکٹ انحصارات کے انتظام اور اجرا کے لیے Bun استعمال کرتا ہے:

bun install

3. ٹریڈر شروع کریں

bun run start

ڈیفالٹ ترتیب کے ساتھ mock مومینٹم ماڈل inference کے متبادل کے طور پر کام کرتا ہے۔ اس کے بعد سرور ٹریڈر کی حالت اور ایونٹ اسٹریم کو اپنے HTTP اینڈ پوائنٹس کے ذریعے دستیاب کرتا ہے۔

فیصلہ سازی کا ماڈل منتخب کرنا

ڈیفالٹ mock ماڈل استعمال کریں

ڈیفالٹ mock ماڈل Jev کو کال کیے بغیر مکمل پائپ لائن کی جانچ کے لیے موزوں ہے۔ یہ مومینٹم ہیورسٹک کے ذریعے فیصلے کرتا ہے اور آپ کو بک ریڈز، نقلی آرڈرز، فلز، اکاؤنٹنگ اور ایونٹ اسٹریمینگ کی توثیق کرنے دیتا ہے۔

Jev ماڈل فعال کریں

Jev استعمال کرنے کے لیے .env میں یہ قدریں ترتیب دیں:

MODEL=jev
TYPESAFE_AI_API_KEY=your_api_key

ہر بلاک پر منتخب ماڈل سے HORIZON_BLOCKS کے دوران متوقع حرکت کے بارے میں پوچھا جاتا ہے۔ اس کی ڈیفالٹ قدر 100 بلاکس ہے، یعنی پروجیکٹ README کے مطابق تقریباً 30 سیکنڈ۔

عام فیصلہ یا تو buy یا sell ہوتا ہے۔ hold نتیجہ کسی تیسرے ماڈل اسٹریٹیجی کی نمائندگی نہیں کرتا: یہ صرف اس وقت ظاہر ہوتا ہے جب ماڈل موجودہ بلاک کی آخری مہلت سے پہلے جواب نہ دے سکے۔ ایسی صورت میں decision.late کی قدر true ہوتی ہے اور اس بلاک کے لیے کوئی آرڈر پوسٹ نہیں کیا جاتا۔

ڈرائی رن موڈ میں محفوظ طریقے سے چلانا

جب PRIVATE_KEY ترتیب نہ دیا گیا ہو تو jev-trader لائیو ٹرانزیکشنز جمع نہیں کراتا۔ یہ پھر بھی حقیقی Kuru بک پڑھتا اور حقیقی ماڈل فیصلے تیار کرتا ہے۔

نقلی کوٹ کی status: "sim" ہوتی ہے۔ یہ ایک بلاک تک ریسٹ کرتا ہے اور صرف اس وقت بھرا ہوا سمجھا جاتا ہے جب حقیقی مارکیٹ پرنٹ اس کی قیمت کو کراس کرے۔ نتیجے میں آنے والے فل کی simulated: true ہوتی ہے۔

یہ موڈ درج ذیل کی توثیق کے لیے مفید ہے:

  • کیا بک اپ ڈیٹس قابلِ اعتماد طریقے سے موصول ہو رہی ہیں۔
  • کیا ماڈل کی تاخیر بلاک کے بجٹ کے اندر رہتی ہے۔
  • کوٹس کتنی بار بھرے جائیں گے۔
  • نقلی قواعد کے تحت پوزیشنز اور P&L کیسے تبدیل ہوتے ہیں۔
  • کیا ڈیش بورڈ یا کوئی دوسرا SSE کلائنٹ ہر قسم کے ایونٹ کو درست طریقے سے سنبھالتا ہے۔

HTTP اینڈ پوائنٹس کا معائنہ

mock ماڈل استعمال کرنے والا تعینات شدہ ڈرائی رن انسٹینس یہاں دستیاب ہے: https://jev-trader-production.up.railway.app۔

تازہ ترین جائزہ پڑھیں

روٹ اینڈ پوائنٹ فعال ماڈل، والیٹ، ڈرائی رن کی حالت، اور بلاک کے تازہ ترین واقعے کی رپورٹ دیتا ہے:

curl https://jev-trader-production.up.railway.app/

حالیہ تاریخ پڑھیں

ہسٹری اینڈ پوائنٹ آخری 1,000 بلاک واقعات واپس کرتا ہے:

curl https://jev-trader-production.up.railway.app/history

لائیو SSE اسٹریم کی پیروی کریں

کنکشن کھلا رکھنے اور واقعات موصول ہوتے ہی دکھانے کے لیے curl -N استعمال کریں:

curl -N https://jev-trader-production.up.railway.app/events

کلائنٹ کے کنیکٹ ہونے پر اسٹریم ایک snapshot واقعہ بھیجتی ہے، جس کے بعد ہر پراسیس کیے گئے بلاک کے لیے ایک block واقعہ بھیجا جاتا ہے۔ لائیو ٹرانزیکشن رسیدیں quote اپ ڈیٹس پیدا کرتی ہیں، جبکہ معلوم ہونے والی تکمیلیں fill واقعات پیدا کرتی ہیں۔

بلاک واقعے کو سمجھنا

بلاک واقعہ مارکیٹ کی حالت، ماڈل کے فیصلے، نئے کوٹ کے ارادے، زیرِ التوا لیکویڈیٹی، پوزیشن کی معلومات، اور مجموعی اعداد و شمار کو یکجا کرتا ہے۔ مختصر مثال یوں ہے:

{
  "block": 105488269,
  "mid": 0.022636,
  "bestBid": 0.022628,
  "bestAsk": 0.022644,
  "spreadBps": 7.07,
  "decision": {
    "action": "buy",
    "probabilities": { "buy": 0.77, "sell": 0.23, "hold": 0 },
    "upIn10": 0.77,
    "latencyMs": 81,
    "late": false
  },
  "quote": {
    "side": "buy",
    "price": 0.022629,
    "size": 200,
    "status": "sent",
    "capped": false
  }
}
  • mid، bestBid، اور bestAsk مشاہدہ کی گئی مارکیٹ کو بیان کرتے ہیں۔
  • spreadBps موجودہ اسپریڈ کو بیسس پوائنٹس میں ظاہر کرتا ہے۔
  • decision.action ماڈل کی منتخب کردہ سمت ہے۔
  • decision.probabilities ماڈل کے خرید اور فروخت کے امکانات برقرار رکھتا ہے۔
  • upIn10 خرید کے امکان کے برابر ہے۔
  • decision.latencyMs ماڈل کی جانچ میں لگنے والے وقت کی رپورٹ دیتا ہے۔
  • quote اس بلاک کے لیے آزمائے گئے آرڈر کی تفصیل دیتا ہے۔
  • quote.cancel منسوخی میں شامل پہلے سے زیرِ التوا آرڈرز کی شناخت کرتا ہے۔
  • resting اپ ڈیٹ کے بعد بوٹ کے معلوم بڈ اور آسک سائز درج کرتا ہے۔
  • position سمت، سائز، داخلے کی قیمت، اور غیر حقیقی نتائج کی رپورٹ دیتا ہے۔
  • totals بلاکس، فیصلوں، کوٹس، تکمیلوں، ریورژنز، تاخیر والے بلاکس، ماڈل کی لاگت، گیس، اور P&L کا مجموعہ رکھتا ہے۔

پوزیشن اور فنڈنگ کی حدیں

اگر پوزیشن کی حد مطلوبہ سمت کو روک دے، یا لائیو مارجن فنڈز اس کے لیے ناکافی ہوں، تو کوٹ مخالف سمت پر رکھا جاتا ہے۔ اس صورت میں quote.capped کی قدر true ہوتی ہے۔ ماڈل کے اصل امکانات میں کوئی تبدیلی نہیں ہوتی، جس سے صارفین ماڈل کے فیصلے اور حقیقت میں کوٹ کی گئی سمت میں فرق کر سکتے ہیں۔

لائیو کوٹ کی تصدیق کو سمجھنا

لائیو ارسال کیے جانے والے ٹرانزیکشنز کے نتائج کا انتظار نہیں کیا جاتا، تاکہ ٹریڈنگ لوپ رسید کا انتظار نہ کرے۔ اس لیے ابتدائی بلاک واقعے میں status: "sent" کے ساتھ ایک intent شامل ہوتا ہے۔

رپورٹ کیا گیا gasMon گیس کی حد کو آخری معلوم بیس فیس اور ترجیحی فیس سے ضرب دے کر نکالا جاتا ہے۔ پروجیکٹ کے مطابق Monad گیس کی پوری حد وصول کرتا ہے، اس لیے ٹرانزیکشن کامیاب ہو یا ریورٹ، اسے حقیقی لاگت تصور کیا جاتا ہے۔

رسید عموماً ایک یا دو بلاکس بعد آتی ہے اور ایک الگ کوٹ واقعہ پیدا کرتی ہے:

event: quote
data: {
  "block": 105488269,
  "quote": {
    "status": "placed",
    "orderId": 100295812,
    "gasMon": 0.0357
  }
}

لائیو کوٹ ان میں سے کسی ایک حالت تک پہنچ سکتا ہے:

  • placed: ٹرانزیکشن کامیاب ہو گئی اور اس میں آرڈر آئی ڈی شامل ہے۔
  • reverted: شامل کیے جانے سے پہلے بُک جمع کرائی گئی قیمت سے گزر گئی، یا مطلوبہ منسوخی ایسے آرڈر کو ہدف بنا رہی تھی جو پہلے ہی مکمل ہو چکا تھا۔
  • lost: 10 بلاکس کے بعد کوئی رسید نہیں ملی۔

فل واقعات کو سمجھنا

بوٹ کے اپنے آرڈر رکھنے والے ٹرانزیکشن میں فلز نہیں ہوتے۔ یہ اس وقت ہوتے ہیں جب کسی دوسرے ٹریڈر کا ٹیکر آرڈر کسی زیرِ التوا آرڈر کو ہٹ کرتا ہے۔ بوٹ متعلقہ Trade لاگ کو اسی eth_getLogs پولنگ کے عمل کے ذریعے شناخت کرتا ہے جو ماڈل کو مارکیٹ کی معلومات فراہم کرتا ہے۔

event: fill
data: {
  "block": 105488271,
  "fill": {
    "side": "buy",
    "size": 200,
    "price": 0.022629,
    "txHash": "0x…",
    "orderId": 100295812,
    "simulated": false
  }
}

فل کا txHash ٹیکر ٹرانزیکشن سے متعلق ہوتا ہے۔ فل پراسیس ہونے پر اسٹریم پوزیشن کے تازہ ڈیٹا، حقیقی P&L، اور فل کے مجموعی اعداد و شمار کی بھی عکاسی کرتی ہے۔

لائیو ٹریڈنگ کی طرف منتقلی

PRIVATE_KEY سیٹ کرنے سے ایپلیکیشن ڈرائی رن کے رویے سے لائیو ٹرانزیکشن جمع کرانے کے رویے میں تبدیل ہو جاتی ہے۔ ایسا کرنے سے پہلے ماحول کی کنفیگریشن، مارجن فنڈنگ، پوزیشن کی حدود، ٹریڈ سائز، کوٹ کی جگہ، فیس کی حد، اور RPC کی قابلِ اعتماد کارکردگی کی تصدیق کریں۔

لائیو موڈ حقیقی پوسٹ اونلی Kuru آرڈرز جمع کراتا ہے اور حقیقی گیس لاگت عائد کرتا ہے۔ مکمل ورک فلو کو پہلے ڈرائی رن موڈ میں آزمائیں، اور فنڈ شدہ کلید فعال کرتے وقت محتاط حدود استعمال کریں۔

پروجیکٹ میں بیان کردہ بنیادی حکمتِ عملی کی ترتیبات یہ ہیں:

  • آرڈر سائز کے لیے TRADE_SIZE_MON۔
  • ٹچ کے مقابلے میں جگہ مقرر کرنے کے لیے QUOTE_INSIDE_TICKS۔
  • ماڈل کے پیش گوئی کے دورانیے کے لیے HORIZON_BLOCKS۔
  • ٹائپ-2 ٹرانزیکشن فیس کی حد کے لیے MAX_FEE_GWEI۔
  • آرڈر بک پڑھنے کے لیے READ_RPC_URL۔
  • ٹرانزیکشن جمع کرانے کے لیے RPC_URL۔

بوٹ 300 ملی سیکنڈ کی حد کیسے پوری کرتا ہے

ہاٹ پاتھ کو عین دو RPC راؤنڈ ٹرپس کے گرد ڈیزائن کیا گیا ہے:

  1. ایک eth_call، READ_RPC_URL کے ذریعے موجودہ آرڈر بک پڑھتا ہے۔
  2. ایک eth_sendRawTransaction، دستخط شدہ اپ ڈیٹ کو RPC_URL کے ذریعے جمع کراتا ہے اور قبول ہوتے ہی واپس آ جاتا ہے۔

لوپ جان بوجھ کر کئی ممکنہ طور پر مہنگے آپریشنز سے گریز کرتا ہے:

  • ہر بلاک کے لیے eth_estimateGas نہیں چلایا جاتا؛ گیس کی حد ہارڈ کوڈ کی گئی ہے یا اسٹارٹ اپ پر ایک بار اخذ کی جاتی ہے۔
  • eth_sendRawTransactionSync استعمال نہیں کیا جاتا، کیونکہ یہ ٹرانزیکشن کے تجویز کیے جانے تک انتظار کرتا ہے۔
  • ہاٹ پاتھ میں گیس کی قیمت تلاش نہیں کی جاتی؛ ٹرانزیکشنز جامد قسم-2 فیس سیٹنگز استعمال کرتی ہیں، جن میں 2 gwei ترجیحی فیس اور MAX_FEE_GWEI کی حد شامل ہے۔
  • فیصلہ سازی کے لوپ میں رسید کا انتظار نہیں کیا جاتا۔
  • وault یا فیس کی ایسی جانچیں شامل نہیں کی جاتیں جو آرڈر میں تاخیر کر سکیں۔

README کے مطابق ڈرائی رن mock-model بینچ مارک میں بک پڑھنے کے لیے تقریباً 18 ms p50 اور پورے لوپ کے لیے 100 ms p50 درکار ہوتے ہیں، جبکہ تقریباً 80 ms mock inference متبادل کے حصے میں آتے ہیں۔

توثیق اور بینچ مارکنگ

کسٹم بک ریڈر کا بینچ مارک

درستگی اور تاخیر کے موازنے کے لیے شامل کردہ بینچ مارک چلائیں، جو کسٹم ریڈر کا SDK کے ساتھ تقابل کرتا ہے:

bun run scripts/bench-read.ts

ٹرانزیکشن انکوڈنگ کی آف لائن تصدیق

ڈرائی انکوڈنگ اسکرپٹ کسی ٹرانزیکشن کو براڈکاسٹ کیے بغیر خرید اور فروخت کے ٹرانزیکشنز پر دستخط کرتا ہے، پھر جانچتا ہے کہ تیار کردہ calldata، SDK سے مطابقت رکھتا ہے:

bun run scripts/dry-encode.ts

لائیو موڈ فعال کرنے سے پہلے یہ خاص طور پر مفید ہے، کیونکہ کارکردگی پر مرکوز مارکیٹ ماڈیول ہاتھ سے انکوڈ کردہ batchUpdate calldata استعمال کرتا ہے۔

آپریشن کے لیے جدید نکات

  • دیر سے آنے والے فیصلوں پر نظر رکھیں: decision.late اور totals.lateBlocks کو ٹریک کریں۔ ماڈل کا دیر سے جواب آنے کا مطلب ہے کہ اس بلاک کے لیے کوئی آرڈر پوسٹ نہیں کیا گیا۔
  • ارادے کو تصدیق سے الگ رکھیں: status: "sent" کو پلیس کیے گئے آرڈر کے طور پر نہ سمجھیں۔ بعد میں آنے والے quote ایونٹ کا انتظار کریں، جس میں placed، reverted، یا lost شامل ہو۔
  • کیپ شدہ کوٹس ٹریک کریں: جب capped درست ہو، تو جمع کرائے گئے سائیڈ کا غیر تبدیل شدہ ماڈل احتمالات کے ساتھ موازنہ کریں تاکہ سمجھ سکیں کہ عمل درآمد سگنل سے کیوں مختلف ہوا۔
  • SSE اسنیپ شاٹ استعمال کریں: نئے مانیٹرنگ کلائنٹس کو پہلے snapshot ایونٹ سے آغاز کرنا چاہیے، پھر آنے والی بلاک، کوٹ، اور فل اپ ڈیٹس لاگو کرنی چاہییں۔
  • دونوں RPC راستوں کی پیمائش کریں: سست ریڈز فیصلوں میں تاخیر کرتے ہیں، جبکہ سست سبمیشنز اس امکان کو کم کرتی ہیں کہ مارکیٹ کے حرکت کرنے سے پہلے کوئی کوٹ پہنچ جائے۔
  • چارج ہونے والی گیس کی حدود کا حساب رکھیں: ریورٹ ہونے والی ٹرانزیکشن کی بھی قابلِ ذکر لاگت ہو سکتی ہے، اس لیے صرف فلز کا جائزہ لینے کے بجائے gasMon، gasUsd، اور ریورژن کے مجموعوں کی نگرانی کریں۔
  • ڈرائی رن پرنٹس سے توثیق کریں: سمیولیٹڈ فلز کا انحصار حقیقی پرنٹس پر ہوتا ہے جو آرڈر کی قیمت کو عبور کرتے ہیں۔ اس لیے ڈرائی رن موڈ فوری فل کے مفروضے سے زیادہ حقیقت پسندانہ ہے، اگرچہ یہ اصل قطار کی پوزیشن اور عمل درآمد سے پھر بھی مختلف رہتا ہے۔

نتیجہ

jev-trader لائیو Kuru بک ریڈر، mock یا Jev فیصلہ سازی ماڈل، بہتر بنایا گیا Monad ٹرانزیکشن سبمیشن، پوزیشن اکاؤنٹنگ، اور SSE مانیٹرنگ سروس کو یکجا کرتا ہے۔ PRIVATE_KEY کے بغیر آغاز کریں، اسنیپ شاٹ اور ایونٹ اسٹریم کا جائزہ لیں، اہم راستے کا بینچ مارک لیں، اور لائیو عمل درآمد پر غور کرنے سے پہلے انکوڈنگ کی تصدیق کریں۔ پروڈکشن میں تصدیقات، تاخیر والے بلاکس، کیپس، ریورژنز، انوینٹری، P&L، اور گیس کے اخراجات کی مشترکہ نگرانی کریں۔