Hablando de Babylon’s BTCVault, esas tres palabras de “auto-custodia” suenan sin duda más contundentes que ese tipo de custodia estilo wBTC. El BTC queda bloqueado en toda su duración en el script Taproot de la red principal de Bitcoin: no hay puente, no hay encapsulado y no se entrega la custodia a terceros. Suena como una solución definitiva para el problema de “en manos de quién está la moneda”.
Pero después de leer la documentación oficial, me di cuenta de que “poder recuperarlo por tu cuenta” tiene un requisito muy real: la recuperación autosuficiente no depende solo de la frase mnemónica.
¿Suena muy libre, cierto? Pero el precio es que hay más cosas que debes gestionar. Perder la frase mnemónica del monedero es obviamente un problema, pero perder también el archivo WOTS y los artifacts del claimer es igual de grave. La documentación oficial lo dice con claridad: si pierdes, de forma simultánea, el archivo WOTS o los artifacts (pero no ambos a la vez), la reclamación autosuficiente dejará de ser posible; si los pierdes los dos y, además, el Vault Provider no responde, solo queda contactar al equipo para que inicie el proceso de recuperación del Security Council. En la fase de testnet, el Security Council cuenta con cinco claves y un umbral de firma múltiple (tres firmas): no puede transferir tu BTC, pero sí puede bloquear pagos en escenarios de emergencia. No es “ceder el control” a otros, pero sí añade una capa en la que necesitas coordinación.
Hay además un problema de tiempo que es fácil de pasar por alto. Desde la presentación para crear el vault hasta su activación transcurren aproximadamente 2 horas; la ventana de activación es de unas 48 horas. Si se excede el tiempo, pasa a estado Expired y el reembolso queda bloqueado por aproximadamente 3 días. Que el proceso funcione en testnet es una cosa; que una gran cantidad de usuarios en mainnet pueda recuperarse sin problemas bajo fallos, es otra muy distinta.
Por eso no voy a interpretar el BTCVault de Babylon de forma simple como “sin riesgo de custodia”. Más precisamente: convierte el riesgo de custodia en riesgos de gestión de claves, riesgos de copias de seguridad de archivos y riesgos por operación del usuario. La auto-custodia no es que no tenga riesgos; lo que ocurre es que los riesgos se reubican: de “confiar en otros” a “administrar bien tus propias cosas”. Y, gestionar bien tus propias cosas, resulta mucho más complejo de lo que uno imagina.
A continuación esperaré a que salgan los datos de las prácticas públicas de recuperación, la tasa de fallos y el tiempo promedio de redención, para decidir realmente qué tan útil es este canal de autoservicio.
#baby $BABY @BabylonLabs_io
Pero después de leer la documentación oficial, me di cuenta de que “poder recuperarlo por tu cuenta” tiene un requisito muy real: la recuperación autosuficiente no depende solo de la frase mnemónica.
¿Suena muy libre, cierto? Pero el precio es que hay más cosas que debes gestionar. Perder la frase mnemónica del monedero es obviamente un problema, pero perder también el archivo WOTS y los artifacts del claimer es igual de grave. La documentación oficial lo dice con claridad: si pierdes, de forma simultánea, el archivo WOTS o los artifacts (pero no ambos a la vez), la reclamación autosuficiente dejará de ser posible; si los pierdes los dos y, además, el Vault Provider no responde, solo queda contactar al equipo para que inicie el proceso de recuperación del Security Council. En la fase de testnet, el Security Council cuenta con cinco claves y un umbral de firma múltiple (tres firmas): no puede transferir tu BTC, pero sí puede bloquear pagos en escenarios de emergencia. No es “ceder el control” a otros, pero sí añade una capa en la que necesitas coordinación.
Hay además un problema de tiempo que es fácil de pasar por alto. Desde la presentación para crear el vault hasta su activación transcurren aproximadamente 2 horas; la ventana de activación es de unas 48 horas. Si se excede el tiempo, pasa a estado Expired y el reembolso queda bloqueado por aproximadamente 3 días. Que el proceso funcione en testnet es una cosa; que una gran cantidad de usuarios en mainnet pueda recuperarse sin problemas bajo fallos, es otra muy distinta.
Por eso no voy a interpretar el BTCVault de Babylon de forma simple como “sin riesgo de custodia”. Más precisamente: convierte el riesgo de custodia en riesgos de gestión de claves, riesgos de copias de seguridad de archivos y riesgos por operación del usuario. La auto-custodia no es que no tenga riesgos; lo que ocurre es que los riesgos se reubican: de “confiar en otros” a “administrar bien tus propias cosas”. Y, gestionar bien tus propias cosas, resulta mucho más complejo de lo que uno imagina.
A continuación esperaré a que salgan los datos de las prácticas públicas de recuperación, la tasa de fallos y el tiempo promedio de redención, para decidir realmente qué tan útil es este canal de autoservicio.
#baby $BABY @BabylonLabs_io
