#termmax في اليومين الماضيين أجريتُ بنفسي اختبارًا مقارنًا لتكلفة الاقتراض، وأردتُ التأكد مما إذا كان الـAPR المعروض على الصفحة @TermMax هو نفسه الرقم الذي تنتهي عليه التكلفة الفعلية بعد إتمام الصفقة. والخلاصة هي: في معظم الحالات لا يكونان متطابقين، لأن المقترض يتحمل في الحقيقة متوسطًا مرجحًا لمعدل الفائدة عبر نطاق معيّن، وليس قيمة البداية التي يراها في الواجهة الأولى.
والسبب في ذلك أن جانب الاقتراض هنا في جوهره يلتهم أوامر العرض الموضوعة على Lending Range Order. هذه الأوامر ليست بسعر موحّد، بل تُقسَّم إلى عدة مقاطع، ولكل مقطع معدل فائدة وعمق خاص به. قد يستهلك الاقتراض الصغير المقطع الأول فقط، فتكون التكلفة قريبة من أفضل عرض؛ لكن بمجرد أن يتجاوز حجم الاقتراض عمق المقطع الأول، يبدأ الأمر بالاختراق صعودًا على طول المنحنى، وتُحتسب المقاطع التالية ذات الفائدة الأعلى ضمن سعر التنفيذ. $SNDKB
ولنأخذ مثالًا يمكن حسابه مباشرة. لنفترض أن المقطع الأول في جانب الإقراض لأحد الاستحقاقات Maturity هو 8% بعمق 300 ألف USDC، والمقطع الثاني 9.5% بعمق 400 ألف، والثالث 11% بعمق 500 ألف. إذا أردتُ اقتراض 600 ألف، فبنية التنفيذ الفعلية ستكون 300 ألف عند 8% و300 ألف عند 9.5%، وبالحساب المرجّح تكون النتيجة 8.75%. وهذا أعلى بـ75 نقطة أساس من 8% البداية المعروضة على الصفحة، وإذا وضعناه على دورة مدتها 180 يومًا، فإن فرق التكلفة المطلقة ليس صغيرًا.
وأكثر ما يخطئ فيه الناس هنا هو فكرة تجزئة الصفقة لتقليل التكلفة. يظن البعض أن تقسيم 600 ألف إلى ثلاث طلبات كل منها 200 ألف وتقديمها بشكل منفصل سيحصل على معدل أقل، لكن إذا تم ذلك في الوقت نفسه وبشكل متتالٍ، فإن ترتيب الالتقاط يبقى نفسه تمامًا، ولن يتغير المتوسط المرجّح بمقدار فلس واحد. والشرط الحقيقي الذي يجعل التجزئة ذات معنى هو التنفيذ عبر الزمن، بحيث تدخل أموال إقراض جديدة إلى الشرائح منخفضة الفائدة في الوسط، ويُعاد ملء قاع المنحنى، وعندها فقط قد تقع الطلبات اللاحقة في موضع أفضل. $SPCXB
لذلك، قبل أن أستدين عبر TermMax الآن، أمضي في ثلاث خطوات: أولًا أتحقق من توزيع العمق المتبقي في كل شريحة فائدة، ثم أحسب يدويًا الـAPR المرجّح وفقًا لحجمي، وأخيرًا أقارن هذه القيمة المرجّحة مع معدل البروتوكول العائم الحالي، بدلًا من مقارنة سعر البداية. وما أودّ التحقق منه لاحقًا أكثر هو: عندما يُوضَع طلب كبير مباشرةً على borrowing range order بانتظار أن يطابقه جانب الإقراض، ما نقطة التوازن بين تكلفة الوقت وميزة سعر الفائدة مقارنةً بالاختراق المباشر للأوامر.
#TermMax @TermMax
والسبب في ذلك أن جانب الاقتراض هنا في جوهره يلتهم أوامر العرض الموضوعة على Lending Range Order. هذه الأوامر ليست بسعر موحّد، بل تُقسَّم إلى عدة مقاطع، ولكل مقطع معدل فائدة وعمق خاص به. قد يستهلك الاقتراض الصغير المقطع الأول فقط، فتكون التكلفة قريبة من أفضل عرض؛ لكن بمجرد أن يتجاوز حجم الاقتراض عمق المقطع الأول، يبدأ الأمر بالاختراق صعودًا على طول المنحنى، وتُحتسب المقاطع التالية ذات الفائدة الأعلى ضمن سعر التنفيذ. $SNDKB
ولنأخذ مثالًا يمكن حسابه مباشرة. لنفترض أن المقطع الأول في جانب الإقراض لأحد الاستحقاقات Maturity هو 8% بعمق 300 ألف USDC، والمقطع الثاني 9.5% بعمق 400 ألف، والثالث 11% بعمق 500 ألف. إذا أردتُ اقتراض 600 ألف، فبنية التنفيذ الفعلية ستكون 300 ألف عند 8% و300 ألف عند 9.5%، وبالحساب المرجّح تكون النتيجة 8.75%. وهذا أعلى بـ75 نقطة أساس من 8% البداية المعروضة على الصفحة، وإذا وضعناه على دورة مدتها 180 يومًا، فإن فرق التكلفة المطلقة ليس صغيرًا.
وأكثر ما يخطئ فيه الناس هنا هو فكرة تجزئة الصفقة لتقليل التكلفة. يظن البعض أن تقسيم 600 ألف إلى ثلاث طلبات كل منها 200 ألف وتقديمها بشكل منفصل سيحصل على معدل أقل، لكن إذا تم ذلك في الوقت نفسه وبشكل متتالٍ، فإن ترتيب الالتقاط يبقى نفسه تمامًا، ولن يتغير المتوسط المرجّح بمقدار فلس واحد. والشرط الحقيقي الذي يجعل التجزئة ذات معنى هو التنفيذ عبر الزمن، بحيث تدخل أموال إقراض جديدة إلى الشرائح منخفضة الفائدة في الوسط، ويُعاد ملء قاع المنحنى، وعندها فقط قد تقع الطلبات اللاحقة في موضع أفضل. $SPCXB
لذلك، قبل أن أستدين عبر TermMax الآن، أمضي في ثلاث خطوات: أولًا أتحقق من توزيع العمق المتبقي في كل شريحة فائدة، ثم أحسب يدويًا الـAPR المرجّح وفقًا لحجمي، وأخيرًا أقارن هذه القيمة المرجّحة مع معدل البروتوكول العائم الحالي، بدلًا من مقارنة سعر البداية. وما أودّ التحقق منه لاحقًا أكثر هو: عندما يُوضَع طلب كبير مباشرةً على borrowing range order بانتظار أن يطابقه جانب الإقراض، ما نقطة التوازن بين تكلفة الوقت وميزة سعر الفائدة مقارنةً بالاختراق المباشر للأوامر.
#TermMax @TermMax
先算加权再借
0%
拆单其实没用
67%
挂单等对手盘
33%
3 الأصوات • تمّ إغلاق التصويت