Intenté precisar un detalle específico del diseño de los Trustless Bitcoin Vaults y acabé obteniendo dos respuestas diferentes de dos informes distintos del mismo Temp Check. Una cuenta describe el paso posterior a la liquidación como abierto a liquidadores sin permisos, que pueden intercambiar un vault incautado por WBTC con una prima pequeña para saldar la deuda del prestatario. Otra cuenta de la propuesta idéntica describe un conjunto con permisos de arbitrajistas que compran esos vaults en escrow en su lugar. Mismo mecanismo, misma presentación del 25 de mayo, dos palabras distintas para quién puede participar.
Importa porque “sin permisos” y “con permisos” no son sinónimos meramente estilísticos en DeFi: describen quién necesita aprobación para obtener el spread de liquidación. Si es sin permisos, cualquiera con capital puede competir para liquidar, más cerca de cómo Aave ya funciona hoy. Si es con permisos, algún grupo permitlist se interpone entre un vault en default y su resolución, lo cual reintroduce exactamente el tipo de guardián que todo el planteamiento pretende evitar.
Me inclino por que el diseño pretendido es sin permisos, ya que los propios materiales de Babylon describen la capa de vault como eliminando consorcios de signatarios y el control discrecional en todas partes del sistema. Pero la intención no es lo mismo que una especificación publicada, y el diseño del oráculo además de los supuestos de confianza completos se empujaron explícitamente a una etapa ARFC posterior, en vez de darse por resuelto ahora.
Entonces, ¿qué es: qué tan “trustless” puedo llamar a un sistema cuando el reporte externo sobre su propia presentación de gobernanza ni siquiera puede ponerse de acuerdo sobre quién está autorizado para tocar el último paso?
El diseño de liquidación de Babylon probablemente es sin permisos en espíritu, pero aún no es inequívoco en el registro público; esa brecha entre la intención y la documentación merece observarse antes de que la etapa ARFC lo fije definitivamente.
@BabylonLabs_io $BABY #baby $BANK
Importa porque “sin permisos” y “con permisos” no son sinónimos meramente estilísticos en DeFi: describen quién necesita aprobación para obtener el spread de liquidación. Si es sin permisos, cualquiera con capital puede competir para liquidar, más cerca de cómo Aave ya funciona hoy. Si es con permisos, algún grupo permitlist se interpone entre un vault en default y su resolución, lo cual reintroduce exactamente el tipo de guardián que todo el planteamiento pretende evitar.
Me inclino por que el diseño pretendido es sin permisos, ya que los propios materiales de Babylon describen la capa de vault como eliminando consorcios de signatarios y el control discrecional en todas partes del sistema. Pero la intención no es lo mismo que una especificación publicada, y el diseño del oráculo además de los supuestos de confianza completos se empujaron explícitamente a una etapa ARFC posterior, en vez de darse por resuelto ahora.
Entonces, ¿qué es: qué tan “trustless” puedo llamar a un sistema cuando el reporte externo sobre su propia presentación de gobernanza ni siquiera puede ponerse de acuerdo sobre quién está autorizado para tocar el último paso?
El diseño de liquidación de Babylon probablemente es sin permisos en espíritu, pero aún no es inequívoco en el registro público; esa brecha entre la intención y la documentación merece observarse antes de que la etapa ARFC lo fije definitivamente.
@BabylonLabs_io $BABY #baby $BANK