#baby $BABY Cuando marqué una palabra en la descripción oficial de los préstamos, me di cuenta de que lo “simple” de TBV en sí es una frontera: en Babylon Core Spoke, los registros de colateral solo tienen una forma.
@BabylonLabs_io lo documenta de manera muy concreta: el factor de colateral de la posición actual es fijo, porque la zona de préstamos “core” solo acepta colateral en BTC; si un mercado acepta varios tipos de colateral a la vez, entonces hay que calcularlos con ponderaciones para cada activo. Por eso TBV elimina una capa de comprobaciones de parámetros: la salud que ve el usuario es más fácil de explicar y el protocolo no tiene que gestionar primero el peso de riesgo entre una cesta de activos.
Pero esta sencillez no es gratuita. Un prestatario que solo tiene BTC entiende mejor las reglas; en cambio, quien tenga a la vez stablecoins, ETH u otros activos no puede meterlos juntos en la misma posición para repartir la presión derivada de un único tipo de colateral. Para aumentar el margen de seguridad, lo principal que puede hacer es reducir la deuda o incrementar BTC.
Los escenarios de estrés no requieren un análisis de mercado complejo. El usuario ya tiene un préstamo con colateral en BTC y, después, quiere complementar la garantía con otro activo; pero descubre que ese activo no puede incorporarse al mismo registro de colateral. En ese momento, el problema no es que él no entienda la salud, sino que el producto ni siquiera le ofrece la segunda opción de activo. La eficiencia de capital y el cálculo del riesgo quedan bloqueados del lado de BTC.
Así que mi valoración del diseño actual de TBV es esta: prioriza haber construido un modelo único de colateral legible y controlable, pero eso todavía no demuestra que sea adecuado para un conjunto más amplio de prestatarios. Lo que vale la pena observar tras $BABY no es si la tabla de parámetros se hará más larga, sino si, cuando aparezcan nuevos activos de colateral, el protocolo podrá explicar las reglas de ponderación con la misma claridad que ahora.
@BabylonLabs_io lo documenta de manera muy concreta: el factor de colateral de la posición actual es fijo, porque la zona de préstamos “core” solo acepta colateral en BTC; si un mercado acepta varios tipos de colateral a la vez, entonces hay que calcularlos con ponderaciones para cada activo. Por eso TBV elimina una capa de comprobaciones de parámetros: la salud que ve el usuario es más fácil de explicar y el protocolo no tiene que gestionar primero el peso de riesgo entre una cesta de activos.
Pero esta sencillez no es gratuita. Un prestatario que solo tiene BTC entiende mejor las reglas; en cambio, quien tenga a la vez stablecoins, ETH u otros activos no puede meterlos juntos en la misma posición para repartir la presión derivada de un único tipo de colateral. Para aumentar el margen de seguridad, lo principal que puede hacer es reducir la deuda o incrementar BTC.
Los escenarios de estrés no requieren un análisis de mercado complejo. El usuario ya tiene un préstamo con colateral en BTC y, después, quiere complementar la garantía con otro activo; pero descubre que ese activo no puede incorporarse al mismo registro de colateral. En ese momento, el problema no es que él no entienda la salud, sino que el producto ni siquiera le ofrece la segunda opción de activo. La eficiencia de capital y el cálculo del riesgo quedan bloqueados del lado de BTC.
Así que mi valoración del diseño actual de TBV es esta: prioriza haber construido un modelo único de colateral legible y controlable, pero eso todavía no demuestra que sea adecuado para un conjunto más amplio de prestatarios. Lo que vale la pena observar tras $BABY no es si la tabla de parámetros se hará más larga, sino si, cuando aparezcan nuevos activos de colateral, el protocolo podrá explicar las reglas de ponderación con la misma claridad que ahora.