عندما رأيت «القيود» الخاصة بـ TermMax، كانت أول ردة فعلي هي عدم فهمها، ثم لاحقًا وجدت أنها ذكية جدًا
قبل بضعة أيام كنت أبحث في TermMax، وواجهت تصميمًا غريبًا نوعًا ما.
لا يمكن لـ Vault أن يستخدم مباشرة الأصول التي يودعها المستخدم كضمان للاقتراض.
في الواقع، من أول نظرة شعرت ببعض الحيرة.
بما أن الأموال موجودة داخل Vault، لماذا لا يُسمح له أن يستخدمها مباشرة كضمان؟
أليس هذا أكثر كفاءة؟
بعد أن فكرت في الأمر، شعرت فجأة أن هذا القيد منطقي جدًا.
لأن أكبر فرق بين الحساب الشخصي وVault هو:
الخسارة في الحساب الشخصي تكون من أموالك أنت، بينما Vault يدير أموال الآخرين.
إذا أراد مستخدم عادي أن يرهن ETH للاقتراض من USDC، ثم يقوم بجولة أخرى من الرافعة المالية، فهذا خيارٌ يتخذه بنفسه.
لكن إذا كان Vault يحتوي على أموال المئات من الأشخاص، وكان Curator يمكنه أخذ كامل المسبح المالي بحرية لاقتراضه كضمان، فإن المخاطر تصبح مختلفة تمامًا.
بمجرد أن تتعثر التقديرات الاستراتيجية، أو يتعرض السوق لتقلبات حادة فجأة، لن يتحمل الخسارة شخص واحد فقط، بل مجموعة من المودعين.
لذلك فإن قيود TermMax على Vault، جوهرها هو رسم حدود واضحة للمخاطر.
في التصميم الرسمي، لا تُعد Two-Way Range Order نوعًا يسمح لـ Vault بالاقتراض عبر الرهن المباشر، بل تتحقق هيكلية الاقتراض المطلوبة من خلال توفير Token دين أولًا، ثم الحصول على FT، ثم بيع FT.
المنتج المالي الناضج حقًا ليس بالضرورة أن يكون الأفضل لأنه يضم عددًا أكبر من الوظائف.
أحيانًا تكون عبارة «لا يمكنك فعل شيء ما» أهم من «يمكنك فعل شيء ما».
لأنك عندما تدير أموال الآخرين، لا تكون كفاءة رأس المال الهدف الوحيد.
حدود المخاطر أيضًا جزء من المنتج.
وبطبيعة الحال، هذا لا يعني أن Vault بلا مخاطر. فاستراتيجية التداول، والسيولة، وتقلبات السوق، والتصفية (liquidation) وغيرها من العوامل قد تظل تؤثر على العائد النهائي.
لكن على الأقل هذا التصميم جعلني أرى بوضوح فكرة TermMax:
فهو ليس فقط يسعى إلى دفع الرافعة المالية إلى أقصى حد، بل يفكر في كيفية الحفاظ على مسؤوليات المخاطر واضحة بين المشاركين المختلفين.
من قبل كنت أرى في DeFi أن «وجود قيود» يعني أنها «ليست قوية بما يكفي».
والآن أرى العكس: بعض القيود تُظهر في الحقيقة أن:
هذا البروتوكول يعرف ما الذي لا يمكن فعله بشكل عشوائي.
@TermMax #TermMax
قبل بضعة أيام كنت أبحث في TermMax، وواجهت تصميمًا غريبًا نوعًا ما.
لا يمكن لـ Vault أن يستخدم مباشرة الأصول التي يودعها المستخدم كضمان للاقتراض.
في الواقع، من أول نظرة شعرت ببعض الحيرة.
بما أن الأموال موجودة داخل Vault، لماذا لا يُسمح له أن يستخدمها مباشرة كضمان؟
أليس هذا أكثر كفاءة؟
بعد أن فكرت في الأمر، شعرت فجأة أن هذا القيد منطقي جدًا.
لأن أكبر فرق بين الحساب الشخصي وVault هو:
الخسارة في الحساب الشخصي تكون من أموالك أنت، بينما Vault يدير أموال الآخرين.
إذا أراد مستخدم عادي أن يرهن ETH للاقتراض من USDC، ثم يقوم بجولة أخرى من الرافعة المالية، فهذا خيارٌ يتخذه بنفسه.
لكن إذا كان Vault يحتوي على أموال المئات من الأشخاص، وكان Curator يمكنه أخذ كامل المسبح المالي بحرية لاقتراضه كضمان، فإن المخاطر تصبح مختلفة تمامًا.
بمجرد أن تتعثر التقديرات الاستراتيجية، أو يتعرض السوق لتقلبات حادة فجأة، لن يتحمل الخسارة شخص واحد فقط، بل مجموعة من المودعين.
لذلك فإن قيود TermMax على Vault، جوهرها هو رسم حدود واضحة للمخاطر.
في التصميم الرسمي، لا تُعد Two-Way Range Order نوعًا يسمح لـ Vault بالاقتراض عبر الرهن المباشر، بل تتحقق هيكلية الاقتراض المطلوبة من خلال توفير Token دين أولًا، ثم الحصول على FT، ثم بيع FT.
المنتج المالي الناضج حقًا ليس بالضرورة أن يكون الأفضل لأنه يضم عددًا أكبر من الوظائف.
أحيانًا تكون عبارة «لا يمكنك فعل شيء ما» أهم من «يمكنك فعل شيء ما».
لأنك عندما تدير أموال الآخرين، لا تكون كفاءة رأس المال الهدف الوحيد.
حدود المخاطر أيضًا جزء من المنتج.
وبطبيعة الحال، هذا لا يعني أن Vault بلا مخاطر. فاستراتيجية التداول، والسيولة، وتقلبات السوق، والتصفية (liquidation) وغيرها من العوامل قد تظل تؤثر على العائد النهائي.
لكن على الأقل هذا التصميم جعلني أرى بوضوح فكرة TermMax:
فهو ليس فقط يسعى إلى دفع الرافعة المالية إلى أقصى حد، بل يفكر في كيفية الحفاظ على مسؤوليات المخاطر واضحة بين المشاركين المختلفين.
من قبل كنت أرى في DeFi أن «وجود قيود» يعني أنها «ليست قوية بما يكفي».
والآن أرى العكس: بعض القيود تُظهر في الحقيقة أن:
هذا البروتوكول يعرف ما الذي لا يمكن فعله بشكل عشوائي.
@TermMax #TermMax
