У меня уже давно есть вопрос по поводу фразы «полноценные резервы BTC»: даже если в каком-то адресе действительно лежат BTC, почему же стейблкоин-контракт в другой сети вообще «знает», что эти средства действительно заблокированы, и что их можно использовать для выкупа или ликвидации в соответствии с заранее заданными условиями?
Стаблкоин-архитектура Trustless Bitcoin Vaults (TBV) из белой книги Babylon как раз сначала решает проблему того, «как факт обеспечения становится видимым». Пользователь кладёт нативные BTC в Vault на Bitcoin, после чего смарт-контрактная цепочка с помощью light-клиента Bitcoin проверяет этот депозит и затем, согласно заданной ставке обеспечения, чеканит долларо- привязанные токены. BTC не нужно переносить в смарт-контрактную цепочку и не нужно заранее передавать кастодиану, чтобы он обменял их на обёрнутый актив.
Самое важное тут не просто то, что в ончейне есть одна запись с BTC, а то, что стейблкоиновая система способна проверить: к какому именно Vault относится этот BTC, остаётся ли он по-прежнему заблокирован и каков объём доступной эмиссии под него. TBV стремится сделать доказательство обеспечения непосредственным участником правил чеканки, а не заставлять пользователя просто верить эмитенту, который периодически публикует отчёт о резервах.
Разумеется, это всё ещё направление применения стейблкоинов, предложенное в белой книге, а не уже запущенные стейблкоины Babylon. По-настоящему нужно проверить, смогут ли light-клиент и кроссчейн-верификация всегда корректно и синхронно отражать состояние Vault. Если на Bitcoin произойдёт что-то, что не совпадает с тем, что, по мнению контракта, произошло, то даже самый прозрачный адрес обеспечения не будет иметь смысла. Оставить BTC на исходной цепочке — это лишь первый шаг. Самое сложное и ключевое в этой схеме — чтобы факт обеспечения на другой цепочке постоянно и правильно распознавался.
@BabylonLabs_io #baby $BABY