#baby $BABY Когда я обвёл одно слово в официальном описании заимствований, я только тогда осознал, что «простота» TBV сама по себе является границей: в Babylon Core Spoke в залоговой записи существует только один вариант.
Документация @BabylonLabs_io написана очень конкретно: коэффициент залога для текущей позиции фиксирован, потому что в основной зоне кредитования используется только залог в BTC; если один и тот же рынок принимает несколько видов залога, то нужно выполнять взвешенный расчёт по разным активам. Поэтому у TBV не хватает одного уровня параметрической логики: уровень здоровья, который видит пользователь, проще объяснить, а протоколу не нужно заранее разбираться с весами риска между целой корзиной активов.
Но такая лаконичность не даётся бесплатно. Заёмщику, у которого есть только BTC, правила понять легче; однако если в руках есть стейблкоины, ETH или другие активы, их нельзя одновременно разместить в одной и той же позиции, чтобы распределить давление, возникающее из-за одного-единственного типа залога. Чтобы увеличить запас безопасности, ему в основном остаётся либо уменьшать долг, либо увеличивать BTC.
Для сценария давления не нужны сложные рыночные условия. У пользователя уже есть заём под залог BTC, а затем он хочет добавить в качестве обеспечения другой актив, но обнаруживает, что этот актив нельзя включить в ту же залоговую запись. Здесь проблема не в том, что он не понимает уровень здоровья — дело в том, что продукт вообще не даёт ему выбора второй разновидности залога. Эффективность использования капитала и расчёт рисков оказываются «заперты» на стороне BTC.
Поэтому моя оценка текущего дизайна TBV такова: он в первую очередь сделал читаемую и управляемую модель единого залога, но это ещё не доказывает, что он подходит более широкой группе заёмщиков. $BABY — то, за чем стоит следить дальше, это не то, станет ли таблица параметров длиннее, а сможет ли протокол при появлении новых залоговых активов объяснить взвешенные правила так же ясно, как сейчас.
Документация @BabylonLabs_io написана очень конкретно: коэффициент залога для текущей позиции фиксирован, потому что в основной зоне кредитования используется только залог в BTC; если один и тот же рынок принимает несколько видов залога, то нужно выполнять взвешенный расчёт по разным активам. Поэтому у TBV не хватает одного уровня параметрической логики: уровень здоровья, который видит пользователь, проще объяснить, а протоколу не нужно заранее разбираться с весами риска между целой корзиной активов.
Но такая лаконичность не даётся бесплатно. Заёмщику, у которого есть только BTC, правила понять легче; однако если в руках есть стейблкоины, ETH или другие активы, их нельзя одновременно разместить в одной и той же позиции, чтобы распределить давление, возникающее из-за одного-единственного типа залога. Чтобы увеличить запас безопасности, ему в основном остаётся либо уменьшать долг, либо увеличивать BTC.
Для сценария давления не нужны сложные рыночные условия. У пользователя уже есть заём под залог BTC, а затем он хочет добавить в качестве обеспечения другой актив, но обнаруживает, что этот актив нельзя включить в ту же залоговую запись. Здесь проблема не в том, что он не понимает уровень здоровья — дело в том, что продукт вообще не даёт ему выбора второй разновидности залога. Эффективность использования капитала и расчёт рисков оказываются «заперты» на стороне BTC.
Поэтому моя оценка текущего дизайна TBV такова: он в первую очередь сделал читаемую и управляемую модель единого залога, но это ещё не доказывает, что он подходит более широкой группе заёмщиков. $BABY — то, за чем стоит следить дальше, это не то, станет ли таблица параметров длиннее, а сможет ли протокол при появлении новых залоговых активов объяснить взвешенные правила так же ясно, как сейчас.