Vuelvo a revisar los parámetros de la red de pruebas TBV de @BabylonLabs_io y descubrí que el nombre vaultBTC es muy fácil de malinterpretar: aunque se registra 1 vaultBTC por 1 BTC y se conservan 8 decimales, no se puede transferir libremente; solo puede quedarse como unidad contable interna dentro del adaptador de Aave v4.
Es como un comprobante de vale de recogida electrónica emitido por un almacén, pero ese comprobante no se puede usar en la calle para circular: solo puede contabilizarse en el mostrador designado como garantía.
El usuario bloquea el BTC nativo en el Vault de Bitcoin. Tras activarlo, el sistema acuña el vaultBTC correspondiente y lo suministra automáticamente del lado de Aave. En la red de pruebas pública, el factor de colateral es del 78%, o sea, en términos contables 1 BTC no se calcula como capacidad de préstamo al 100%. Ese descuento no significa que “les falte BTC” después, sino que deja margen para la volatilidad de precios, la conciliación entre sistemas y el tiempo de liquidación.
No olvides que estos aún son parámetros de red de pruebas: un solo “puesto” máximo 0.4 BTC, y el límite total de la aplicación en Aave es de 10 BTC. El tope se observa dentro de flujos pequeños: no es suficiente para demostrar que, cuando aparezcan simultáneamente grandes posiciones en la red principal, congestión y caídas bruscas de precios, todo se mantenga igual de fluido.
Reconozco el valor de estas restricciones. Si el comprobante no puede transferirse por ahí, se elimina una vía para la desanclaje en el mercado secundario, el doble colateral o que otros protocolos lo confundan y lo usen mal. El sistema mantiene vaultBTC encerrado dentro del adaptador; en otras palabras, te está diciendo: se encarga de demostrar que “hay mercancía en el cajón”, no de recrear un nuevo BTC que puedas intercambiar y especular por todas partes.
Pero el problema también está precisamente en “el mostrador designado”. La no transferibilidad reduce el riesgo de la combinación, pero también ata la usabilidad a la integración con Aave, al contrato del adaptador y a la gobernanza de parámetros. El cajón está en Bitcoin, el libro de préstamos está en Ethereum y el comprobante queda en medio; si cualquier capa no está sincronizada con la otra, lo que el usuario ve puede no ser el simple cuento de “1 moneda por 1 moneda”.
Así que el $BABY aquí no obtiene valor automáticamente solo por el nombre. Lo que hay que mirar es si el uso de Vault genera comisiones, qué parámetros caen bajo la gobernanza y si la actividad económica puede volver a satisfacer la demanda de BABY. Tratar el suministro de vaultBTC directamente como ingresos de BABY, o tomar el total de vales de almacén del centro comercial como si fuera ganancia patrimonial, es igual de absurdo. #baby
Mi opinión: restringir la transferibilidad es un límite de seguridad, no un defecto del producto; pero cuanto más estrecho sea ese límite de seguridad, más se concentra la dependencia del protocolo. ¿Prefieres tener un comprobante de seguridad que solo se puede usar en el mostrador designado, o quieres un activo transferible para combinar libremente, pero con riesgo que se desborda? Hablad en los comentarios.
$BTC $UBER
Es como un comprobante de vale de recogida electrónica emitido por un almacén, pero ese comprobante no se puede usar en la calle para circular: solo puede contabilizarse en el mostrador designado como garantía.
El usuario bloquea el BTC nativo en el Vault de Bitcoin. Tras activarlo, el sistema acuña el vaultBTC correspondiente y lo suministra automáticamente del lado de Aave. En la red de pruebas pública, el factor de colateral es del 78%, o sea, en términos contables 1 BTC no se calcula como capacidad de préstamo al 100%. Ese descuento no significa que “les falte BTC” después, sino que deja margen para la volatilidad de precios, la conciliación entre sistemas y el tiempo de liquidación.
No olvides que estos aún son parámetros de red de pruebas: un solo “puesto” máximo 0.4 BTC, y el límite total de la aplicación en Aave es de 10 BTC. El tope se observa dentro de flujos pequeños: no es suficiente para demostrar que, cuando aparezcan simultáneamente grandes posiciones en la red principal, congestión y caídas bruscas de precios, todo se mantenga igual de fluido.
Reconozco el valor de estas restricciones. Si el comprobante no puede transferirse por ahí, se elimina una vía para la desanclaje en el mercado secundario, el doble colateral o que otros protocolos lo confundan y lo usen mal. El sistema mantiene vaultBTC encerrado dentro del adaptador; en otras palabras, te está diciendo: se encarga de demostrar que “hay mercancía en el cajón”, no de recrear un nuevo BTC que puedas intercambiar y especular por todas partes.
Pero el problema también está precisamente en “el mostrador designado”. La no transferibilidad reduce el riesgo de la combinación, pero también ata la usabilidad a la integración con Aave, al contrato del adaptador y a la gobernanza de parámetros. El cajón está en Bitcoin, el libro de préstamos está en Ethereum y el comprobante queda en medio; si cualquier capa no está sincronizada con la otra, lo que el usuario ve puede no ser el simple cuento de “1 moneda por 1 moneda”.
Así que el $BABY aquí no obtiene valor automáticamente solo por el nombre. Lo que hay que mirar es si el uso de Vault genera comisiones, qué parámetros caen bajo la gobernanza y si la actividad económica puede volver a satisfacer la demanda de BABY. Tratar el suministro de vaultBTC directamente como ingresos de BABY, o tomar el total de vales de almacén del centro comercial como si fuera ganancia patrimonial, es igual de absurdo. #baby
Mi opinión: restringir la transferibilidad es un límite de seguridad, no un defecto del producto; pero cuanto más estrecho sea ese límite de seguridad, más se concentra la dependencia del protocolo. ¿Prefieres tener un comprobante de seguridad que solo se puede usar en el mostrador designado, o quieres un activo transferible para combinar libremente, pero con riesgo que se desborda? Hablad en los comentarios.
$BTC $UBER
