دیباچہ

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

یہ مضمون اس ثالثی حکمت عملی کی ترقی کے دوران درپیش عملی مسائل اور حل کی دستاویز کرتا ہے۔صرف سیکھنے اور حوالہ کے مقاصد کے لیے؛ اس کی کوئی عملی سرمایہ کاری کی قدر نہیں ہے۔。

حکمت عملی کی بنیادی منطق

ڈیلیوری کنٹریکٹ اور اسپاٹ پرائس کے درمیان قیمت کا فرق ہے، جو عام طور پر ایک خاص اوسط کے ارد گرد اتار چڑھاؤ ہوتا ہے۔ جب قیمت کا فرق بہت زیادہ ہٹ جاتا ہے تو نظریاتی طور پر ثالثی کے مواقع موجود ہوتے ہیں۔

ابتدائی خیال سادہ تھا:

• جگہ اور ترسیل کے معاہدوں کے درمیان قیمت کے پھیلاؤ کی نگرانی کریں۔
• جب قیمت کا فرق معیاری انحراف سے 2 گنا زیادہ ہو جائے تو پوزیشن کھولیں۔
• جب قیمت کا فرق اپنی اصل قیمت پر واپس آجاتا ہے تو پوزیشنوں کو بند کرکے منافع حاصل کریں۔

بہت اچھا لگتا ہے، ٹھیک ہے؟ لیکن عملی طور پر، آپ کو معلوم ہوگا کہ صرف “پوزیشن کھولنے” کے قدم کو سنبھالنے کے لیے بے شمار تفصیلات موجود ہیں۔

پہلا نقصان: قیمت کا استحکام پھیلتا ہے۔

ابتدائی طور پر، ہم نے قیمت کے پھیلاؤ کے انحراف کو براہ راست اشارے کے طور پر استعمال کیا، لیکن ہم نے پایا کہ بعض اوقات قیمت کا پھیلاؤ مسلسل بڑھتا رہتا ہے اور اپنی سابقہ ​​حالت میں واپس نہیں آتا ہے۔ بعد میں، ہم نے محسوس کیا …قیمت کے تمام اسپریڈز مستحکم نہیں ہیں۔。

خاص طور پر جیسے جیسے ڈیلیوری کی تاریخ قریب آتی ہے، پھیلاؤ کا رویہ بدل سکتا ہے۔ لہذا، ADF ٹیسٹ کو اس بات کا تعین کرنے کے لیے شامل کیا گیا کہ آیا اسپریڈ سیریز ساکن ہے۔

function adfTest(series, maxLag=null){
  const n = series.length;
  if(n<10) throw new Error('series too short');
  if(maxLag===null) maxLag = Math.floor(12*Math.pow(n/100, 1/4));
  
  // ... ADF检验的核心计算逻辑
  
  const res = ols(rows, Ys);
  const tstat = tStat(res.beta, res.cov, 1);
  return { tStat: tstat, pValue: pval, usedLag: p };
}

ابتدائی طور پر، ہم نے ٹیسٹوں کا ایک گروپ شامل کیا، بشمول ویرینس ریشو ٹیسٹ، ہاف لائف ٹیسٹ، اور KS ٹیسٹ، لیکن ہم نے پایا کہ بہت زیادہ ٹیسٹوں نے پوزیشنیں کھولنے کے مواقع کی تعداد کو نمایاں طور پر کم کر دیا۔ آخر میں، ہم نے اسے صرف ADF ٹیسٹ تک آسان کیا اور p-value کی حد کو 0.1 پر سیٹ کیا۔

زیادہ اہم بات یہ ہے کہ ایک اضافی شامل کیا گیا۔مسلسل ناکامی کاؤنٹر：

if (!adfPass) {
  stationarityFailCount[deliverySymbol] = (stationarityFailCount[deliverySymbol] || 0) + 1;
} else {
  stationarityFailCount[deliverySymbol] = 0;
}

let consecutiveFails = stationarityFailCount[deliverySymbol];
let canTrade = consecutiveFails < CONFIG.consecutiveFailThreshold;

اگر ٹیسٹ لگاتار تین بار ناکام ہو جاتا ہے تو تجارت ممنوع ہے۔ جب مارکیٹ غیر معمولی حالت میں ہو تو یہ اندھا دھند پوزیشنوں کو کھولنے سے روک سکتا ہے۔

دوسرا نقصان: حقیقی وقت کے منافع اور نقصان کے اعدادوشمار کے ارد گرد الجھن

فیوچر اکاؤنٹ کے لیے منافع اور نقصان کا حساب لگانا آسان ہے۔ صرف USDT میں تبدیلیوں کو دیکھیں۔ لیکن سپاٹ اکاؤنٹس مختلف ہیں؛ ان میں USDT اور cryptocurrency دونوں شامل ہیں۔ آپ اس کا حساب کیسے لگاتے ہیں؟

یہاں ایک تفصیل ہے جسے آسانی سے نظر انداز کیا جاتا ہے:اسپاٹ گڈز رکھنے کی قیمت ٹریڈنگ کے ساتھ بدل جائے گی۔مثال کے طور پر، اگر آپ ایک سکہ 100 USDT میں خریدتے ہیں، اسے 90 USDT میں بیچتے ہیں، اور پھر اسے 85 USDT میں واپس خریدتے ہیں، تو آپ کی قیمت کی بنیاد اب ابتدائی 100 USDT نہیں ہے۔ سکے کی قیمت کا حساب لگانے کے لیے پوزیشن کھولنے کے وقت منجمد قیمت کو استعمال کرنے سے منافع اور نقصان کی حقیقی صورت حال کی عکاسی نہیں ہوگی۔

صحیح طریقہ ہے۔آرڈر آبجیکٹ سے لین دین کی اصل اوسط قیمت نکالیں۔：

let openSpotPrice = (openSpotOrder && openSpotOrder.AvgPrice) ? 
  openSpotOrder.AvgPrice : record.openSpotPrice;
let closeSpotPrice = closeSpotOrder.AvgPrice || currentPair.spotPrice;

پھر، واپسی کی شرح کا حساب اصل لین دین کی قیمت کی بنیاد پر کیا جاتا ہے:

// 正套：买现货+卖期货
if (record.direction === 'positive') {
  spotReturnRate = (closeSpotPrice - openSpotPrice) / openSpotPrice;
  deliveryReturnRate = (openDeliveryPrice - closeDeliveryPrice) / openDeliveryPrice;
} else {
  // 反套：卖现货+买期货
  spotReturnRate = (openSpotPrice - closeSpotPrice) / openSpotPrice;
  deliveryReturnRate = (closeDeliveryPrice - openDeliveryPrice) / openDeliveryPrice;
}

let totalReturnRate = spotReturnRate + deliveryReturnRate;
let requiredUSD = openSpotPrice * record.spotAmount;
let actualTotalPnl = totalReturnRate * requiredUSD;

منافع اور نقصان کے حساب کتاب کی منطق کو یہاں نوٹ کریں:

• باقاعدہ سیٹاس وقت، اسپاٹ مارکیٹ لمبی تھی اور فیوچر مارکیٹ مختصر تھی، اس لیے اسپاٹ مارکیٹ کے لیے منافع/نقصان = (اختتامی قیمت - کھلنے کی قیمت) / کھلنے کی قیمت، اور فیوچر مارکیٹ کے لیے منافع/نقصان = (اوپننگ پرائس - بند ہونے کی قیمت) / اوپننگ پرائس۔
• معکوساس وقت، اسپاٹ ٹریڈنگ میں شارٹنگ شامل ہوتی ہے جبکہ فیوچر ٹریڈنگ میں مخالف سمتوں میں لمبا جانا شامل ہوتا ہے۔

آخر میں، ہر لین دین کا اصل نفع یا نقصان کل نفع یا نقصان تک جمع کیا جاتا ہے:

accumulatedProfit += actualTotalPnl;
_G('accumulatedProfit', accumulatedProfit);

تیسرا بڑا نقصان: لیکویڈیٹی ٹریپ

یہ اصل سر درد ہے۔ 10 سال کے آپریشن کے بعد، کیا موجد مقداری پلیٹ فارم کے پاس مستقبل کے معاہدوں کے لیے ثالثی کی اتنی کم حکمت عملی کیوں ہے؟ جواب آسان ہے:ڈیلیوری کنٹریکٹ مارکیٹ میں ناکافی لیکویڈیٹی。

سوال 1: سنگل ٹانگ کا لین دین

ثالثی کوئی پریوں کی کہانی نہیں ہے جہاں آپ بیک وقت پوزیشنیں کھولتے ہیں۔ حقیقت یہ ہے:

• اسپاٹ آرڈر پر عمل ہو چکا ہے، لیکن فیوچر آرڈر ابھی باقی ہے۔
• یا فیوچر آرڈر پر عمل کیا گیا تھا، لیکن اسپاٹ آرڈر کو منسوخ کر دیا گیا تھا۔

یہ “ایک ٹانگوں والے خطرے” کی ایک بہترین مثال ہے۔ ایک ٹانگ اندر ہے، لیکن دوسری ابھی تک باہر ہے۔ جب قیمت میں اتار چڑھاؤ آتا ہے، تو یہ ثالثی نہیں ہوتی بلکہ یک طرفہ پوزیشن ہوتی ہے۔

اس کا حل شامل ہونا ہے۔رول بیک میکانزم：

if (!deliveryOrder) {
  Log('❌ 期货卖单失败，回滚现货');
  exchanges[0].CreateOrder(pair.spotSymbol, 'sell', -1, spotAmount);
  addCooldown(pair.deliverySymbol, pair.coin, '期货卖单失败，已回滚现货');
  return false;
}

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

سوال نمبر 2: مارکیٹ آرڈرز کو بھی رد کیا جا سکتا ہے۔

اس سے بھی زیادہ مضحکہ خیز بات یہ ہے کہ بعض اوقات مارکیٹ کے آرڈر بھی ناکام ہوجاتے ہیں۔ یہ ایکسچینج رسک کنٹرولز یا مارکیٹ کی ناکافی گہرائی کی وجہ سے ہو سکتا ہے۔ مختصر میں، حکم صرف کے ذریعے نہیں جائے گا.

تو میں نے یہ کیا۔مارکیٹ آرڈر کا دوہری طریقہ کار + حد آرڈر：

function createOrderWithFallback(exchange, symbol, direction, amount, limitPrice, orderType, maxRetry = 3) {
  let useMarketOrder = (limitPrice === -1);
  
  // 先尝试限价单
  if (!useMarketOrder) {
    orderId = exchange.CreateOrder(symbol, direction, limitPrice, amount);
    if (!orderId) {
      Log(`❌ 限价单提交失败，改用市价单`);
      useMarketOrder = true;
    }
  }
  
  // 限价单失败则用市价单
  if (useMarketOrder && !orderId) {
    orderId = exchange.CreateOrder(symbol, direction, -1, marketAmount);
  }
  
  // ... 检查订单状态，失败则重试
}

سسٹم زیادہ سے زیادہ 3 بار دوبارہ کوشش کر سکتا ہے، ہر کوشش کے ساتھ مارکیٹ آرڈر کو حفاظتی جال کے طور پر استعمال کرتا ہے۔

سوال 3: اسپاٹ بائنگ آرڈرز میں اماؤنٹ ٹریپ

یہ خرابی خاص طور پر اچھی طرح سے پوشیدہ ہے اور اضافی احتیاط کی ضرورت ہے۔ فیوچر مارکیٹ آرڈر کی مقدار ہے…سکوں کی تعدادتاہم، اسپاٹ مارکیٹ آرڈر خریدتے وقت آرڈر کی گئی مقدار…USDT کی رقم！

یہاں، ایک تبادلوں کی منطق کو خاص طور پر شامل کیا گیا ہے:

function getActualAmount(useMarket) {
  if (isSpotBuy && useMarket) {
    // 现货市价买单：需要用USDT金额
    let currentPrice = getDepthMidPrice(exchange, symbol);
    let usdtAmount = amount * currentPrice;
    Log(`  💡 现货买单转换: ${amount.toFixed(6)} 币 → ${usdtAmount.toFixed(4)} USDT`);
    return usdtAmount;
  }
  return amount;
}

حد کے آرڈرز میں استعمال ہونے والی کریپٹو کرنسی کی مقدار خود بخود مارکیٹ آرڈرز کے لیے USDT میں تبدیل ہو جاتی ہے۔

چوتھا نقصان: ثالثی کے مواقع کا وہم

ایک اور مایوس کن مسئلہ یہ ہے کہ ایک ثالثی سگنل کا پتہ چلا ہے، اور آپ پوزیشن کھولنے کے لیے تیار ہیں، لیکن جب آپ آرڈر دیتے ہیں تو موقع پہلے ہی ختم ہو چکا ہوتا ہے۔

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

تو اسے شامل کیا گیا۔ثانوی تصدیق کا طریقہ کار：

// 开仓前重新获取实时价格并验证套利机会
Log('🔄 重新获取实时Depth盘口价格并验证套利机会...');

let realtimeSpotPrice = getDepthMidPrice(exchanges[0], pair.spotSymbol, true);
let realtimeDeliveryPrice = getDepthMidPrice(exchanges[1], pair.deliverySymbol, true);

let realtimeSpread = realtimeDeliveryPrice - realtimeSpotPrice;
let realtimeSpreadRate = realtimeSpread / realtimeSpotPrice;

// 重新计算实时Z-Score
let realtimeZScore = (realtimeSpreadRate - mu) / (sigma || 1e-6);

// 验证：实时Z-Score是否仍然满足开仓条件
if (absRealtimeZ < CONFIG.zScoreEntry) {
  Log('❌ 套利机会已消失！');
  Log('  取消开仓，避免亏损');
  return false;
}

اصل میں آرڈر دینے سے پہلے، اصل وقت کی قیمت کو دوبارہ حاصل کریں، Z-Score کا دوبارہ حساب لگائیں، اور صرف اس صورت میں آرڈر پر عمل کریں جب آپ تصدیق کرتے ہیں کہ موقع ابھی بھی موجود ہے۔

پانچواں نقصان: مستقبل کے عہدوں سے متعلق میراثی مسائل۔

بعض اوقات، جب کوئی حکمت عملی دوبارہ شروع کی جاتی ہے یا پچھلی پوزیشن بند کر دی جاتی ہے، تو فیوچر اکاؤنٹ میں بقایا پوزیشنیں ہو سکتی ہیں۔ اگر ان پر توجہ نہیں دی جاتی ہے تو، نئی پوزیشنیں پرانی پوزیشنوں کے ساتھ اوورلیپ ہو جائیں گی، جس کی وجہ سے یہ پوزیشن کنٹرول سے باہر ہو جائے گی۔

تو اسے شامل کیا گیا۔پوزیشن کھولنے سے پہلے زبردستی لیکویڈیشنمنطق:

// 检查期货现有仓位并平仓
let existingPosition = getPositionBySymbol(pair.deliverySymbol);

if (existingPosition && Math.abs(existingPosition.Amount) > 0) {
  Log('⚠️ 检测到该合约的现有仓位，执行平仓操作...');
  
  let closeDirection = existingPosition.Type === PD_LONG ? 'closebuy' : 'closesell';
  let closeAmount = Math.abs(existingPosition.Amount);
  
  let closeOrder = createOrderWithFallback(
    exchanges[1],
    pair.deliverySymbol,
    closeDirection,
    closeAmount,
    -1,
    '期货'
  );
  
  if (!closeOrder) {
    Log('❌ 平仓现有持仓失败，终止开仓');
    addCooldown(pair.deliverySymbol, pair.coin, '平仓现有持仓失败');
    return false;
  }
}

پوزیشن کھولنے سے پہلے، پہلے اسے چیک کریں۔ اگر کوئی پوزیشنیں باقی ہیں تو انہیں بند کر دیں تاکہ یہ یقینی بنایا جا سکے کہ آپ کا اکاؤنٹ صاف ہے۔

چھٹا بڑا نقصان: ٹکر ڈیٹا کا وقفہ جال

یہ پوری حکمت عملی کی ترقی کا عمل ہے۔سب سے زیادہ پوشیدہ اور سب سے زیادہ مہلکمسائل میں سے ایک۔

حکمت عملی کے چلنے کے بعد، ایک عجیب رجحان دیکھا گیا:

• ایک ثالثی سگنل کا پتہ چلا ہے، اور یہ پوزیشن کھولنے کا وقت ہے۔
• زیادہ سے زیادہ حد آرڈر کی قیمت کا حساب ٹکٹ کی قیمت سے قیمت کے فرق کو جوڑ کر اور گھٹا کر کیا جاتا ہے۔
• نتیجتاً، آرڈر زیر التواء رہا، پورا ہونے کا انتظار۔
• طویل انتظار کے بعد کوئی لین دین مکمل نہ ہونے پر آرڈر منسوخ کر دیا گیا۔

اس کے بجائے مارکیٹ آرڈرز استعمال کرنے کی کوشش کریں؟ نتیجہ اور بھی برا تھا:

• مارکیٹ آرڈر کو کامیابی کے ساتھ انجام دیا گیا۔
• تاہم، لین دین کی قیمت متوقع ثالثی پھیلاؤ سے بالکل مختلف تھی۔
• ثالثی کا موقع جس کی منصوبہ بندی کی گئی تھی لین دین مکمل ہونے کے بعد غیر منافع بخش نکلا۔

بالکل کیا ہوا؟ ایکسچینج کے لائیو ٹریڈنگ ڈیٹا کا بار بار موازنہ کرنے کے بعد، آخرکار مسئلہ دریافت ہوا:

ٹکر بمقابلہ گہرائی: ڈیٹا کے درمیان بنیادی فرق

ٹکر ڈیٹا حالیہ لین دین کی اصل قیمت کی عکاسی کرتا ہے۔یہ ٹھیک لگتا ہے، لیکن کم لیکویڈیٹی والی منڈیوں کے لیے جیسے ڈیلیوری کے معاہدے، مسائل پیدا ہوتے ہیں:

时间轴：
10:00:00 - 有人以50000成交了1张合约 → Ticker价格更新为50000
10:00:05 - 盘口挂单：买49800 / 卖50200（但没有成交）
10:00:10 - 盘口挂单：买49850 / 卖50150（但没有成交）
...
10:05:00 - Ticker价格仍然是50000（因为5分钟内没有新的成交）

کیا آپ نے مسئلہ محسوس کیا ہے؟50,000 کی ٹکر کی قیمت 5 منٹ پہلے ہی تاریخ تھی۔تاہم، موجودہ مارکیٹ کی اصل قیمت (آرڈر بک کی قیمت) ⁴⁹⁸⁵⁰⁄₅₀₁₅₀ ہو سکتی ہے۔

اگر آپ ثالثی کے مواقع کا حساب لگانے اور حد کے آرڈر دینے کے لیے 50,000 کی ٹکر قیمت استعمال کرتے ہیں، تو:

1. فیصلے کی غلطیثالثی سگنلز کا حساب پرانی قیمتوں کی بنیاد پر کیا جاتا ہے۔
2. آرڈر ناکام ہو گیا۔حد آرڈر پر قیمت اصل مارکیٹ کی قیمت سے بہت دور ہے، جس سے لین دین کو مکمل کرنا ناممکن ہو جاتا ہے۔
3. مارکیٹ کا نقصانلین دین پر مجبور کرنے کے لیے مارکیٹ آرڈر کا استعمال کیا گیا تھا، لیکن اصل قیمت اس سے بالکل مختلف تھی جس کی توقع تھی۔

ڈیلیوری کے معاہدوں کے ٹکرز خاص طور پر ناقابل اعتبار کیوں ہیں؟

ترسیل کے معاہدوں کی لیکویڈیٹی اسپاٹ کنٹریکٹس کی نسبت بہت زیادہ خراب ہے:

• سپاٹ مارکیٹہر سیکنڈ میں بڑی تعداد میں لین دین ہوتے ہیں، اور ٹکر کی قیمت تقریباً حقیقی وقت میں بہت کم وقفے کے ساتھ اپ ڈیٹ ہوتی ہے۔
• ڈیلیوری کا معاہدہلین دین ہونے میں کئی منٹ یا اس سے بھی زیادہ وقت لگ سکتا ہے۔ ٹکر کی قیمت بہت کم ہے۔

کمزور لیکویڈیٹی والے معاہدوں کے لیے، ٹکر کی قیمت اور آرڈر بک کی اصل قیمت کے درمیان انحراف ہوسکتا ہے:

• عمومی حد: 0.1% - 0.5%
• اتار چڑھاؤ کی مدت: 1% - 3% یا اس سے بھی زیادہ

ثالثی کی حکمت عملیوں کے لیے، یہ انحراف مہلک ہے۔ متوقع قیمت کے فرق کا فائدہ صرف 0.5% ہو سکتا ہے، لیکن لین دین کی اصل قیمت بالکل مختلف نکلتی ہے۔

حل: ٹکر کو ڈیپتھ ڈسک ڈیٹا سے تبدیل کریں۔

چونکہ ٹکر ناقابل اعتبار ہے، آئیے استعمال کریں…گہرائی (آرڈر بک گہرائی) ڈیٹا：

function getDepthMidPrice(exchange, symbol, logDetail = false) {
    let depth = exchange.GetDepth(symbol);
    if (!depth || !depth.Bids || depth.Bids.length === 0 || 
        !depth.Asks || depth.Asks.length === 0) {
        Log(`❌ 获取${symbol}盘口失败`);
        return null;
    }
    
    let bestBid = depth.Bids[0].Price;  // 最优买价
    let bestAsk = depth.Asks[0].Price;  // 最优卖价
    let midPrice = (bestBid + bestAsk) / 2;  // 中间价
    
    if (logDetail) {
        let spread = bestAsk - bestBid;
        let spreadRate = spread / midPrice * 100;
        Log(`📊 ${symbol} 盘口: Bid=${bestBid.toFixed(2)}, Ask=${bestAsk.toFixed(2)}, Mid=${midPrice.toFixed(2)}, Spread=${spread.toFixed(2)} (${spreadRate.toFixed(3)}%)`);
    }
    
    return midPrice;
}

گہرائی کے اعداد و شمار کے فوائد:

• حقیقی وقتآرڈر بک کی موجودہ حقیقی حیثیت کو ظاہر کرتا ہے، بغیر کسی وقفے کے۔
• درستگیآپ کا آرڈر ان آرڈر بکس کے ساتھ ملایا جائے گا، اور یہ صحیح مارکیٹ قیمت ہے۔
• آپریبلٹیآرڈر بک کی قیمتوں کی بنیاد پر شمار کیے گئے محدود آرڈرز پر عمل درآمد کا امکان زیادہ ہوتا ہے۔

حکمت عملی کا دوہری قیمتوں کا نظام

بالآخر اپنایاٹکر + گہرائی کا ہائبرڈ حل：

1. تاریخی ڈیٹا کی ترتیب کو برقرار رکھنے کے لیے ٹکر کا استعمال کریں۔

// 用Ticker更新历史价差序列（保持连续性）
let spotTicker = exchanges[0].GetTicker(pair.spotSymbol);
let deliveryTicker = exchanges[1].GetTicker(pair.deliverySymbol);

pair.spotPrice = spotTicker.Last;
pair.deliveryPrice = deliveryTicker.Last;
pair.spread = pair.deliveryPrice - pair.spotPrice;

// 历史序列用于ADF检验、Z-Score计算
priceHistory[pair.deliverySymbol].push({
    time: Date.now(),
    spreadRate: pair.spread / pair.spotPrice,
    spread: pair.spread,
    spotPrice: pair.spotPrice,
    deliveryPrice: pair.deliveryPrice
});

ٹکر اب بھی تاریخی ڈیٹا کے لیے کیوں استعمال ہوتا ہے؟ کیونکہ یہ ضروری ہے۔ڈیٹا کا تسلسلاگر تاریخی اعداد و شمار کو بھی گہرائی کا استعمال کرتے ہوئے پیش کیا جاتا ہے، تو ترتیب کتاب کی قیمتوں میں اتار چڑھاو تاریخی ترتیب میں وقفے کا سبب بنے گا، جس سے شماریاتی تجزیہ کی درستگی متاثر ہوگی۔

2. حقیقی وقت کے فیصلے اور پوزیشن کھولنے کی تصدیق کے لیے گہرائی کا استعمال کریں۔

// 开仓前用Depth重新验证套利机会
let realtimeSpotPrice = getDepthMidPrice(exchanges[0], pair.spotSymbol, true);
let realtimeDeliveryPrice = getDepthMidPrice(exchanges[1], pair.deliverySymbol, true);

// 基于Depth价格重新计算Z-Score
let realtimeSpread = realtimeDeliveryPrice - realtimeSpotPrice;
let realtimeSpreadRate = realtimeSpread / realtimeSpotPrice;
let realtimeZScore = (realtimeSpreadRate - mu) / (sigma || 1e-6);

// 二次验证：套利机会是否仍然存在
if (Math.abs(realtimeZScore) < CONFIG.zScoreEntry) {
    Log('❌ 套利机会已消失（基于Depth实时价格）');
    return false;
}

3. گہرائی کا استعمال کرتے ہوئے حد آرڈر کی قیمت کا حساب لگائیں۔

// 基于Depth价格和平均价差计算限价单价格
let spreadDeviation = realtimeSpread - avgSpread;
let adjustmentRatio = Math.min(
    Math.abs(spreadDeviation) * CONFIG.limitOrderSpreadRatio,
    spreadStd * 0.5
);

if (direction === 'positive') {
    spotLimitPrice = realtimeSpotPrice + adjustmentRatio;
    deliveryLimitPrice = realtimeDeliveryPrice - adjustmentRatio;
} else {
    spotLimitPrice = realtimeSpotPrice - adjustmentRatio;
    deliveryLimitPrice = realtimeDeliveryPrice + adjustmentRatio;
}

اس طرح سے شمار کی جانے والی حد آرڈر کی قیمت اصل آرڈر بک پر مبنی ہے، جس سے عمل درآمد کا امکان بہت زیادہ بڑھ جاتا ہے۔

4. گہرائی کا استعمال کرتے ہوئے حقیقی وقت کے منافع اور نقصان کا حساب لگائیں۔

function calculateUnrealizedPnL(record, currentPair) {
    // 优先用Depth价格计算实时盈亏
    let currentSpotPrice = getDepthMidPrice(exchanges[0], currentPair.spotSymbol);
    let currentDeliveryPrice = getDepthMidPrice(exchanges[1], currentPair.deliverySymbol);
    
    // Depth获取失败才回退到Ticker
    if (!currentSpotPrice || !currentDeliveryPrice) {
        currentSpotPrice = currentPair.spotPrice;
        currentDeliveryPrice = currentPair.deliveryPrice;
    }
    
    // 计算盈亏...
}

اصل جنگی اثرات کا موازنہ

ٹکر کے استعمال میں مسائل:

检测到套利信号（基于Ticker）
→ 计算限价单价格
→ 下单等待
→ 长时间不成交（价格已经不对了）
→ 改用市价单
→ 成交价格和预期差很多
→ 套利失败或微利

گہرائی کے استعمال کے بعد بہتری:

检测到套利信号（基于Ticker历史）
→ 用Depth重新验证（机会仍在）
→ 基于Depth计算限价单价格
→ 下单，价格贴近盘口
→ 较快成交
→ 成交价格符合预期
→ 套利成功

قیمت کی حد کے آرڈر کی قیمتوں کی اصلاح

اگر ہم حد کے آرڈرز استعمال کرنے جا رہے ہیں، تو ہم قیمت کیسے طے کریں گے؟ اگر ہم اسے بہت زیادہ جارحانہ انداز میں ترتیب دیتے ہیں، تو لین دین نہیں ہوگا؛ اگر ہم اسے بہت زیادہ قدامت پسندی سے طے کرتے ہیں تو ہمیں اچھی قیمت نہیں ملے گی۔

گہرائی کی قیمت کی بنیاد پر، یہاں نقطہ نظر یہ ہے:موجودہ قیمت کے پھیلاؤ اور اوسط قیمت کے پھیلاؤ کے درمیان انحراف کی بنیاد پر متحرک طور پر ایڈجسٹ کریں۔。

let spreadDeviation = realtimeSpread - avgSpread;
let adjustmentRatio = Math.min(
  Math.abs(spreadDeviation) * CONFIG.limitOrderSpreadRatio,
  spreadStd * 0.5
);

// 限制调整幅度在合理区间
let minAdjustment = realtimeSpotPrice * 0.0005;
let maxAdjustment = realtimeSpotPrice * 0.005;
adjustmentRatio = Math.max(minAdjustment, Math.min(maxAdjustment, adjustmentRatio));

اگر یہ مکمل سیٹ ہے (قیمت کے بڑے فرق کے ساتھ):

• جگہ خریدنے کی قیمت = گہرائی مڈ پوائنٹ + ایڈجسٹمنٹ کی حد
• فیوچر سیلنگ پرائس = ڈیپتھ مڈ پوائنٹ - ایڈجسٹمنٹ رینج

یہ آرڈر بک سے بہت دور رہنے سے گریز کرتے ہوئے قیمت کے موافق فرق پر ٹرانزیکشنز کو مکمل کرنے کی اجازت دیتا ہے اور اس کے نتیجے میں لین دین چھوٹ نہیں جاتا۔

ٹھنڈک کا دورانیہ

پوزیشن کھولنے کی کوئی بھی ناکام کوشش مارکیٹ میں کسی مسئلے کی نشاندہی کرتی ہے، جس کی وجہ ناکافی لیکویڈیٹی یا ضرورت سے زیادہ اتار چڑھاؤ ہو سکتا ہے۔ ایسے معاملات میں، فوری طور پر دوبارہ کوشش نہیں کرنی چاہیے، بلکہ پرسکون رہنا چاہیے۔

لہذا، ہر ناکام تجارتی جوڑے پر ایک جرمانہ شامل کیا گیا تھا۔10 منٹ کا کول ڈاؤن：

function addCooldown(deliverySymbol, coin, reason) {
  pairCooldowns[deliverySymbol] = Date.now() + CONFIG.cooldownDuration;
  Log(`⏸️ ${deliverySymbol} 进入10分钟冷却期`);
  Log(`   原因: ${reason}`);
  _G('pairCooldowns', pairCooldowns);
}

کولنگ آف پیریڈ کے دوران، اس تجارتی جوڑے کے لیے کوئی پوزیشن نہیں کھولی جائے گی تاکہ بار بار ناکامیوں اور لین دین کی فیس ضائع ہونے سے بچا جا سکے۔

موجودہ کوتاہیاں اور بہتری کے شعبے

یہ حکمت عملی ابھی تک صرف ایک کام جاری ہے، اور بہت سے ایسے شعبے ہیں جن کو بہتر بنایا جا سکتا ہے:

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

2. رسک کنٹرول کی اصلاح موجودہ سٹاپ لاس کا طریقہ نسبتاً آسان اور سیدھا ہے، اور آپ غور کر سکتے ہیں:

• متحرک سٹاپ نقصان (اعتدال کی بنیاد پر ایڈجسٹ)
• وقت پر مبنی سٹاپ لاس (زیادہ سے زیادہ ہولڈنگ ٹائم کی وجہ سے جبری لیکویڈیشن)
• زیادہ سے زیادہ واپسی کنٹرول

3. Slippage مینجمنٹ حد کے آرڈرز کے لیے قیمتوں کا تعین کرنے کی حکمت عملی کو زیادہ ذہین بنایا جا سکتا ہے، جیسے آرڈر بک کی گہرائی اور حالیہ لین دین کے حجم جیسے عوامل کی بنیاد پر متحرک طور پر ایڈجسٹ کرنا۔

4. ڈیپتھ ڈیٹا کی مزید ایپلی کیشنز یہ آرڈر بک کے عدم توازن کا تجزیہ کر سکتا ہے، قیمت کے رجحانات کا اندازہ لگا سکتا ہے، اور ثالثی کی کامیابی کی شرح کو بہتر بنا سکتا ہے۔

خلاصہ کریں۔

ثالثی کی حکمت عملی دلکش لگتی ہے، لیکن عملی طور پر، یہ واضح ہے کہ مثالی اور حقیقت کے درمیان بے شمار نقصانات ہیں۔

• اسٹیشنریٹی ٹیسٹنگ کے نقصانات
• منافع اور نقصان کے اعدادوشمار میں نقصانات
• ناکافی لیکویڈیٹی کا نقصان
• سنگل ٹانگ کے لین دین کے نقصانات
• مارکیٹ آرڈر کی ناکامی کے نقصانات
• جگہ خریداری کی رقم میں نقصانات
• ثالثی کے مواقع کو ختم کرنے کا نقصان
• بقایا عہدوں کا گڑھا ۔
• سب سے مہلک خامی ٹکر میکانزم میں وقفہ ہے۔

خاص طور پر، ٹکر ڈیٹا کے پیچھے رہنے کا مسئلہ حکمت عملی کی ترقی کے پورے عمل میں ایک مسئلہ ہے۔سب سے زیادہ آسانی سے نظر انداز کیا گیا لیکن سب سے زیادہ اثر کے ساتھنقصانات۔ کم لیکویڈیٹی والی ڈیلیوری کنٹریکٹ مارکیٹس کے لیے:

بنیادی اصول: تاریخی تسلسل کو برقرار رکھنے کے لیے Ticker کا استعمال کریں، اور حقیقی وقت کے مواقع سے فائدہ اٹھانے کے لیے Depth کا استعمال کریں۔

• ٹکر تاریخی ڈیٹا کے تجزیہ (ADF ٹیسٹ، Z-Score کیلکولیشن) کے لیے موزوں ہے۔
• گہرائی حقیقی وقت کے فیصلے اور تجارتی عمل کے لیے موزوں ہے (پوزیشن اوپننگ تصدیق، حد آرڈر کی قیمتوں کا تعین، منافع اور نقصان کا حساب کتاب)۔

یہ مضمون تلاش کے عمل کے دوران درپیش مسائل اور ان کے حل کو ریکارڈ کرتا ہے، اور امید ہے کہ یہ ہر ایک کے لیے کچھ حوالہ فراہم کر سکتا ہے۔دہرانے کے لیے، یہ مضمون صرف تعلیمی اور بحث کے مقاصد کے لیے ہے۔ کوڈ ابھی بھی تیار ہو رہا ہے اور براہ راست براہ راست تجارت میں استعمال نہیں کیا جانا چاہیے۔。

اگر آپ بھی ایسی ہی حکمت عملی استعمال کر رہے ہیں تو بلا جھجھک مجھ سے اس پر بات کریں۔ مارکیٹ پیچیدہ ہے، اور یہ بالکل یہی پیچیدگی ہے جو مقداری تجارت کو بہت مشکل بناتی ہے۔

حکمت عملی کا ماخذ کوڈ: https://www.fmz.com/strategy/519280