北洛KT

$KII también puede considerarse pan para hoy, hambre para mañana: el primero en salir corriendo fue rápido y vendí por 42U.
La perspectiva no es que sea gran cosa, porque los tirones de mercado por parte de quien los impulsa son, al final, eventos de baja probabilidad; no vale la pena esperar.

¡El 16 de enero ocurrió el incidente y recién el 10 de marzo publicaron el informe de post-mortem! Entre medio, ¿qué demonios estuvo haciendo oficialmente durante esos 53 días? ¡Esa era mi gran duda antes de ver el Post-Mortem!

Copio los puntos de tiempo del post-mortem en mi libreta: el ataque ocurrió el 16 de enero; más tarde esa misma noche se suspendió el servicio de puentes (bridge). A finales de enero se completó la consolidación de fondos y la verificación de las direcciones afectadas. Y el 10 de marzo se publicó el post-mortem completo. Antes de copiar el texto de $DUSK , revisé también las marcas de tiempo de actualización en la página de publicación para confirmar que no se hubiera retirado ninguna versión intermedia. Me detuve en el tercer punto: en esos 53 días, la entidad oficial solo actualizó el estado dos veces: una el día del incidente y otra el día en que publicaron el post-mortem.

Abrí el calendario y lo conté: del 16 de enero al 10 de marzo hay 53 días, con 2 actualizaciones. En promedio, se movieron cada 26,5 días. Esa ronda de finales de enero —la consolidación de fondos y la verificación de direcciones— todo quedó escrito después en el post-mortem; en ese momento, hacia afuera no había ni una sola palabra. Yo dividí esos 53 días en cuatro bloques: la congelación a nivel de horas, la verificación a nivel de días, la causa raíz a nivel de semanas, y el post-mortem más auditoría interna ocupando más de un mes. Los tres primeros bloques quedaron vacíos; solo en el último se pronunciaron. Esa es la cuenta de tiempo que saqué, y también fue exactamente lo que al principio me parecía raro.

Pero si desglosamos esos cuatro bloques, el silencio no equivale a negligencia. @Dusk , que la congelación sea de nivel horas, significa que el mismo día del incidente cortaron la expansión del riesgo; que la verificación sea a nivel días, significa que no se retrasaron conciliaciones una por una; y que la causa raíz sea de nivel semanas, significa que las conclusiones pueden verificarse, no son “a ojo”. Cada tramo tiene acciones claras, solo que no se actualizaron al exterior. También comparé cómo se gestionaron los eventos recientes de puentes: algunos proyectos borran el tuit al día siguiente del incidente; otros arrastran seis meses y publican una declaración sin muchos detalles; y otros simplemente no responden. Después de comparar, aún más claro: el proceso de gestión es el material base de la confianza, y este post-mortem es de las pocas veces en que realmente desglosan por completo la línea de tiempo, la causa raíz y las medidas.

Así que ahora voy a vigilar una cosa: la próxima vez que ocurra algo, desde el momento del incidente hasta la publicación del post-mortem, ¿habrá actualizaciones de proceso en el medio? La frecuencia de actualización es la medida de la transparencia. Por mucho que se diga con la boca, no hay nada que valga más que la honestidad de las marcas de tiempo. #dusk

Muchas personas creen que una blockchain pública de privacidad es completamente anónima en toda la cadena, pero el primer punto que menciona el capítulo 4 del libro blanco de Dusk es precisamente romper esa impresión.

El análisis se divide en tres pasos. Primero: el libro contable tiene dos tipos. Moonlight funciona con cuentas: es público y transparente; se puede consultar el saldo y el estado de cada dirección, y el nonce evita la repetición. Esto está preparado para escenarios donde se necesita publicar información. Las bolsas requieren conciliación, los reguladores deben comprobar el flujo de fondos: el libro contable público da la respuesta directamente; esta es una necesidad urgente para el cumplimiento. Segundo: Phoenix funciona con notas: transferencias confidenciales, en las que el receptor solo puede descifrar con la view key. La nota contiene 6 campos: tipo, compromiso (commitment), cifrado y la dirección; tanto el monto como el receptor quedan ocultos dentro del compromiso. Esto está preparado para escenarios donde se necesita privacidad. Tercero: las dos versiones del libro contable comparten el mismo consenso y el mismo sistema de liquidación. Qué ruta sigue una transacción depende de la naturaleza de la transacción en sí, no de la cadena. Lo público va por Moonlight; lo confidencial va por Phoenix; nadie tiene que adaptarse al otro.

La frase original de la documentación oficial es "privacy where needed, transparency where useful": donde se necesita privacidad, se mantiene en secreto; donde se necesita transparencia, se hace público. Si se compara la versión en inglés y en chino, el peso está en where, no en si se quiere privacidad o no, sino en dónde se necesita privacidad. La cadena no decide por los usuarios; en cambio, traslada el poder de elección a cada transacción. Ese diseño es poco común en blockchains de privacidad. La mayoría de las cadenas de privacidad usan un único modelo global: o todo es anónimo o todo es transparente. Dusk coloca ambos libros contables uno al lado del otro para que el escenario determine la visibilidad. $DUSK

@Dusk Antes creía que el valor de una blockchain de privacidad era que “se oculta profundo”, pero al desarmarlo se ve claro: el valor real es “ocultar con precisión”. Para una auditoría, se necesita un punto de entrada; para los clientes, privacidad. Con un solo libro contable solo puedes elegir una de dos cosas; con dos libros contables, se reciben ambas a la vez. Al bajar el poder de elección a cada transacción, este diseño determina si puede o no sostener operaciones de nivel institucional.

En activos tokenizados bajo regulación, lo que más se teme es que la auditoría no tenga punto de entrada y que el cliente no tenga privacidad. Como ambas rutas comparten el mismo consenso, nadie tiene que sacrificar al otro; esa es la base para que el ecosistema pueda hablar tanto con instituciones como con usuarios minoristas. Dos libros contables no son una concesión técnica: son un reflejo de la realidad regulatoria. #dusk

TI15, la ventaja de localía de Shanghái: en el primer día, todo un barrido… hasta que les afeitaron la cabeza.
Solo se puede decir que CN Dota ya no es el mejor Dota; ahora es simplemente un 'cantan, tú' de Dota.
¡Lamenta su desgracia y enójate por su falta de voluntad!
Las predicciones de Predict, llévalas como pago por la nostalgia.

$DOS Esta vez se les dio a Binance y a los de al lado también con dinero.

Binance, al menos, está “en lo correcto” y en línea: simplemente lo repartió a los usuarios de Alpha; en cambio, los de al lado solo lo usaron para el concurso de trading. Los usuarios que compartieron datos no vieron ni un centavo.

Si dan poco, todavía pueden decir que la capacidad de negociación de la plataforma no es suficiente; pero el proyecto claramente lo dio, y la plataforma eligió no repartirlo. Entonces no es un problema de capacidad, sino de actitud.

Dicho sin rodeos: es tratar a los usuarios como tontos.

DOS estos dos días está muy de moda. Soy de la gente que tuvo mala suerte: no pillé alpha y tampoco hubo airdrop; así que me puse de manera muy seria a estudiar el producto. Siento que después conviene ver la oportunidad y recoger ganancias.

El $DOS , el supuesto “Web3 AI operating system” con récord de speedrun por todas las rondas, en realidad es un producto llamado xBubble: una pequeña herramienta para enviar OPC. Ingreso anual de 6,8 millones de dólares vs. FDV de 400 millones. Esa cifra es un poco rara. Polychain está haciendo de “tendero” del asunto, hay colaboración entre múltiples plataformas; el lanzamiento y ¡sube 300%! Toda la atención está en el tablero, no en el producto.

No es un proyecto de largo plazo; el producto difícilmente coincide con su valoración. La historia suena bien, pero no seas la última persona a la que le toca “hacer de comprador del último”. Ve la ganancia, recoge y vete; la gente lúcida gana con mentalidad lúcida.

Vuelvo a ver a alguien decir que el estado del monedero es solo una barra de progreso: “avanzas hasta donde llegue”. Pero en realidad no es así. Lo entendí al revisar la documentación: el estado por etapas es un punto de traspaso de responsabilidades. Cada paso tiene los pendientes de una persona responsable; el estado es un comprobante, no un progreso. Quien ve el comprobante como si fuera progreso, cuando se queda atascado solo se queda esperando.
Pending, Verified y Active, tres estados gestionan porciones distintas. Pending: espera 12 confirmaciones del lado de Bitcoin; eso corresponde a la red. Nadie puede acelerarlo; solo cuando se confirman los bloques en la zona Signet se pasa al siguiente paso. Verified: solo indica que los participantes están listos para completar; no significa que el usuario ya haya revelado/activado el secret. Este paso corresponde a la colaboración. Active: el usuario mismo debe revelar y activar el secreto; corresponde a la propia persona. Un paso, un responsable: responsabilidades claras, y los cuellos de botella se pueden encontrar. Cada paso es el acta de aceptación del eslabón anterior; si no se aprueba esa aceptación, el estado no avanza.
Al comparar el autómata de estados, @BabylonLabs_io muestra que la definición de estados está escrita en el documento: 12 confirmaciones, distintas ventanas de 24 a 48 horas y activación del secret; cada punto corresponde a un sujeto que está esperando. La espera no ocurre al azar: el mecanismo divide la responsabilidad en tramos, y cada tramo tiene un dueño. Cuanto más fino el corte, más fácil es ubicar el atasco.
Hay 3 tipos de esperas: esperar que la red consulte los bloques; esperar que la colaboración consulte la ventana; y esperar que uno mismo consulte la clave. $BABY En el ecosistema, la mayoría de los atascos no se deben a que “el sistema esté roto”, sino a que un pendiente de una de las etapas no se completó. El estado se enciende en qué paso: la responsabilidad está en esa etapa. El propósito de que exista el autómata de estados es que cada paso tenga respaldo verificable; si ocurre un desvío, puedes ubicar el eslabón específico, en lugar de quedarte mirando un estado genérico.
Cuando mires el monedero, pregunta primero qué demuestra este paso. Si entiendes eso, aunque te quedes atascado no te asustas. El pánico viene de tratar el comprobante como el destino. Quien trata el comprobante como el destino siempre espera el siguiente estado; “esperar” es la postura más pasiva. La persona pasiva ni siquiera sabe en qué paso se atascó. La respuesta está escrita en la definición de estados: el estado es un comprobante, no un progreso. El valor del comprobante es que es verificable; el valor del progreso es que es esperable. No los mezcles. #baby

Ayer por la noche revisé de arriba a abajo la página de direcciones del contrato oficial. Detrás de cada contrato venía su número de versión; la planificación para la red de prueba Sepolia y la red principal estaba separada en 2 líneas. La página era corta, pero el contenido no era poco. La propia dirección también es una prueba: los activos de prueba y los activos reales, desde la entrada, se separan.
Tres componentes —Vault Registry, ProtocolParams y adaptadores—, cada uno colgado de tres grupos de identificadores: la versión de Vault Core, la versión de los parámetros fuera de cadena y la versión del conjunto de participantes. Al principio no presté atención a esos números; pensé que los números de versión eran cosa de los desarrolladores. @BabylonLabs_io
Luego leí las descripciones de las dos configuraciones una frente a la otra y entendí qué es lo que realmente bloquean: durante el registro de la bóveda, se sigue una regla de vinculación por versión. Una bóveda, desde el momento de su creación, queda atada a esa tanda de parámetros; las actualizaciones posteriores no pueden cambiarla silenciosamente. Después del número de versión, normalmente también vienen la fecha y el registro de despliegue. Antes y después de una actualización se pueden comparar las diferencias una por una. Los parámetros de despliegue de las 2 configuraciones —red de prueba y red principal— tienen valores propios. Esa es la razón por la que el campo de versión debe registrarse por separado. La fijación de versiones trae un problema práctico: el proceso que la red de prueba verificó, al cambiar a una dirección de la red principal no se copia tal cual; hay que recorrer de nuevo el despliegue y la verificación. Que el sitio oficial liste por separado las dos configuraciones es, en sí mismo, una advertencia: en el entorno de activos, cada despliegue tiene su propio límite de confianza independiente. Lo que se valida con los contratos en la red de prueba solo puede probar lo que ocurre en la red de prueba. $BABY
Antes yo creía que si la red de prueba ya corría, entonces bastaba con pasar directamente a la red principal. Leyéndolo con calma, vi claro que el valor de las etiquetas de entorno y los números de versión en la página de direcciones no es menor que el de los documentos funcionales. En realidad, la conclusión es: para leer los materiales de TBV, primero confirma qué entorno está describiendo; luego mira el número de versión; y finalmente recién entonces revisa la descripción de la función. Entre las direcciones de la red de prueba y la de la red principal —en el caso que figura ahí— lo que hay de por medio es todo el ciclo de despliegue y verificación, no es algo de un clic. En el ecosistema, el aislamiento entre entornos es una decisión de diseño, no una omisión.
Volviendo a esa página de direcciones de anoche: dos líneas de direcciones son dos mundos. Las etiquetas de entorno y los números de versión, más que la descripción de funciones, merecen ser lo primero que se lea. #baby

En la época en que alpha estaba en su punto más alto, el booster también era un verdadero dios. Especialmente esos dos proyectos, $BAS y $PIEVERSE : cada proyecto con no menos de 8 entregas; qué durabilidad tan fuerte, qué nivel de participación tan alto, y qué rentabilidad de primera.
En aquel entonces, $BNB también subió con la marea; el precio fue escalando hasta más de 1300. Ahora ni siquiera es que se haya dividido a la mitad: lo han cortado hasta el muslo.
Cada vez que lo añoro, solo hay una decepción llena de decepciones.

原生BTC借贷，说穿了就是给小白开的后门，一份新手大礼包。
我一开始也不信这话。借贷、抵押、清算，听着全是金融老手的词，怎么就成了小白福利？直到我把 @BabylonLabs_io 白皮书里三个数字抄下来算了一遍，才觉得这说法不夸张。
三个数字摆一起：WBTC和cbBTC合计TVL不到Aave上ETH代币的三分之一；加起来不足BTC总市值1%；Aave当时TVL约570亿。
算一下：比特币总市值约1.2万亿美元，1%就是120亿，和以太坊那边570亿的池子一比，整个比特币"进DeFi"的量只有个零头。差距不是百分之几十，是数量级。
但真正让我觉得像"新手大礼包"的，不是差距有多大，是它为什么存在。过去比特币持有者想用DeFi，得先过两道门槛：要么把币换成包装币，信任发行方；要么走跨链桥，信任委员会。这两道门槛对老玩家不算什么，对普通人基本是劝退：不是不想让币生息，是不想把币交给不认识的人。
原生BTC借贷把这两道门槛拆了：币留在比特币主网，抵押、清算照常执行，但任何一方都没法临时改目的地。对小白来说，这是第一个不要求你先学会信任别人的DeFi产品——你只需要继续拿着自己的币。官方把这套机制叫trustless execution：不是没人管，而是把"管"交给了脚本和密码学。
所以我说它是新手大礼包，不是调侃，是描述：它把门槛从"学会信任别人"降到了"拿着自己的币就行"。白皮书敢把三个数字写出来，等于先把差距摆在你面前——围绕$BABY 的讨论里判断任何BTC DeFi方案，先问它给谁开的门：是给老玩家的新玩具，还是给普通持币人的后门。#baby

Una sola semilla solo puede florecer una vez; al sembrarla, hay que pensarlo bien. Guardar las semillas solo depende de ti.

Esto es lo que me di cuenta en el jardín. La clave WOTS de @BabylonLabs_io es precisamente ese tipo de semilla: uso único. Los materiales de clave usados quedan invalidados; el nuevo flujo debe usar claves nuevas. El protocolo lo fija como de un solo uso, y la responsabilidad de las copias de seguridad recae en el usuario.

Hagamos un experimento mental. Si la clave pudiera reutilizarse, ¿qué ocurriría? La reutilización de materiales de firma equivale a dejarle a un atacante una ventana para aprovechar de nuevo. Si ocurre una filtración, entonces las desgracias se repiten. Yo pensaba que el diseño de uso único era una molestia; al terminar de leerlo, entendí que coloca el riesgo en la primera línea: la clave se usa y se desecha; la ventana de filtración se cierra directamente. En el jardín, una semilla que solo florece una vez es, en realidad, la mejor forma de combatir las plagas: los insectos se la comen una vez, y la siguiente ya no hay flores que comer.

Entonces, ¿qué debe hacer el usuario? Las copias de seguridad. Como la semilla se acaba, antes de sembrar hay que dejar lista la siguiente tanda. El inventario de respaldo debe llevar el registro de la relación con el “bóveda” correspondiente: registrar el estado de uso de las claves de un solo uso, y la ubicación donde se guardan los materiales. Si se omite algo, equivale a perder una temporada de cosecha.

¿En concreto qué debe registrarse en el inventario de respaldo? La relación con la bóveda, el estado de uso de la clave de un solo uso y la ubicación de almacenamiento de los materiales: las tres cosas son indispensables. Solo recordar la ubicación pero no el estado significa que no se sabe si la “semilla” sigue ahí o no. Solo recordar el estado pero no la relación significa que no queda claro a quién corresponde la cosecha. Las reglas del jardín: si marcas todo con claridad, al año siguiente habrá cosecha. En el ecosistema de $BABY , todo lo que diga “solo se puede usar una vez” merece tener dos copias de seguridad.

Para cerrar con una idea: lo “de un solo uso” no es para fastidiar, sino para adelantar el costo de seguridad al día de la creación. El usuario puede ver el costo adelantado; el usuario no ve el riesgo que queda para después. El costo visible es fácil de gestionar; lo invisible es lo que asusta. Quien cultiva flores lo sabe: una buena cosecha empieza por elegir las semillas. Esta lección de las copias de seguridad hay que hacerla antes de sembrar. Los materiales se guardan en tres lugares: en local, en un disco sin conexión (offline) y en papel; en la cadena (on-chain) deja un índice. Si pierdes una copia, aún tendrás dos.

Lee despacio este diseño y notarás que cada vez encaja más: el uso único es el límite de seguridad del protocolo, y las copias de seguridad son el límite de responsabilidad del usuario; cada uno se encarga de lo suyo. Babylon separa el límite y la responsabilidad de forma clara y el usuario solo debe seguirlo. #baby

En los documentos técnicos, al leer ese tipo de calificativos fuertemente restrictivos como “solely controlled”, yo estoy acostumbrado a completar primero el complemento directo. Lo que está controlado de manera individual, ¿cuál es? ¿Y quién lo controla? Leer el documento es como leer un contrato: los sustantivos que van después del calificativo determinan a quién se le imponen las obligaciones.
Peg-in generará un output de tipo “depositor claim” de importe pequeño, que está controlado en exclusiva por la clave de Bitcoin de Depositor. Su cuantía es muy pequeña, pero su función es muy específica: sirve para anclar la entrada de “self-claim”; es la casilla de la que, de verdad, Depositor tiene control dentro de todo el flujo.
Pero tener control de esa casilla no equivale a tener control de toda la bóveda. Ese output ancla la entrada de self-claim, no la salida; para completar realmente el self-claim, se necesitan los eventos correspondientes, el WOTS de esta vault y los artifacts, y luego completar el proceso establecido y el período de desafío. Con la entrada en la mano, cada paso posterior sigue siendo una variable. El anclaje solo ocupa la posición; los materiales, los eventos y el período de desafío siguen siendo variables.#baby
El BTC de la “main vault” es otro asunto. Está sujeto a la restricción del diagrama de transacciones prefirmadas: el camino queda escrito de antemano y no puede ser cambiado fácilmente por la clave de Depositor para desviar fondos, retirarlos antes o saltarse condiciones previstas. El diagrama prefirmado fija toda la ruta de salida, no es un borrador que se pueda modificar en cualquier momento. Es decir, dentro del TBV de @BabylonLabs_io , la key de Depositor controla ese output pequeño, pero no controla la ruta preestablecida de la tesorería principal.
Volviendo a la descripción técnica inicial, “solely controlled” no miente; lo que suele causar problemas es el complemento directo omitido.$BABY En el documento, cada vez que aparezca un calificativo de este tipo, vale la pena completar el complemento directo para verificar: ¿qué controla y qué no controla? Lo que realmente determina el alcance de los permisos no es nunca qué tan fuerte es la palabra “solely”, sino quién es exactamente el objeto al que modifica.
Verificar el complemento directo está más cerca de la realidad que debatir sobre la frase en sí; esta afirmación merece colocarse junto a cada explicación de un acuerdo.

Muchas tarifas incomodan, no necesariamente porque los números sean exagerados, sino porque el descuento llega demasiado tarde. La gente ya ha metido el dinero, ha esperado un tiempo y también se ha acostumbrado a que en la cartera todavía estén esos BTC. Pero cuando llega el momento de salir, ve que la cantidad real que le devuelven es menor de lo esperado. Aunque la tarifa ya esté escrita en las reglas desde el principio, emocionalmente igual primero aparece una frase: ¿por qué justo ahora me cobran?

En el diseño de los Trustless Bitcoin Vaults (TBV) con pruebas públicas actuales en @BabylonLabs_io , la comisión de VP se determina al crear el cofre y también se incorpora al Payout prefirmado. No se va del monedero de inmediato en el momento de la creación; tiene que esperar a que, más adelante, al retirar, se descuente de los pagos que salen en BTC.

Esto se parece a una tarjeta de crédito. En el instante de pasar la tarjeta, el dinero ya está gastado, pero el saldo sigue ahí, en silencio. Justo después de pagar, la gente normalmente recuerda esa compra y se recuerda a sí misma no olvidar la fecha de pago. Pero con el tiempo, al revisar el saldo varias veces, el cerebro sin darse cuenta vuelve a sumar esa parte de dinero dentro de lo que “todavía se puede usar”. Hasta que llegue el día del pago y realmente lo descuenten, es cuando aparece ese dolor muy concreto: ¿cómo se me acabó quitando de golpe tanto?

La comisión de VP también genera esa diferencia en el tiempo. Las tarifas confirmadas al crear el cofre, cuanto más pasa el tiempo, más fácil es que pasen de ser un número claro en la memoria a quedar como una impresión borrosa. Al retirar, recibes menos BTC, pero la sensación es inmediata. Las reglas no cambian de forma temporal, y la brecha en el monedero sigue siendo muy real.

No me atrevo a sacar conclusiones sobre el precio de $BABY en términos de mercado, pero el valor del protocolo no puede juzgarse solo con grandes narrativas. Qué momento se fija la tarifa, y si durante la salida aún hay margen para cambiar el precio de manera temporal: esos pequeños números también hay que contarlos.

El registro ya quedó anotado, pero en la cartera se siente un poco más tarde. Cuando el dinero por fin se descuenta, lo primero que queda es, por lo general, no el acuerdo confirmado, sino ese instante en que el saldo de repente baja. #baby

$GRVT Todavía corre bastante rápido; en el primer momento ya se fue con 45U. Aunque la verdad es que se desplomó muchísimo, aun así sí que envió bastante dinero; probablemente sea el número uno de julio. Si contamos creadores, alpha y booster, también son 200 y pico U desde el inicio.
Ponerlo en la actualidad realmente es algo de gran esplendor.
Aguanta un poco; los sueños siempre llegarán.

GRVT30 de julio a las 20:00 en alpha, adivino a ojo una tanda de 240 puntos, la típica partida para ayudar a la gente. Total, esta semana hace demasiado falta bajar saldo. Llevan aguantando sin parar, así que solo están esperando que salga la nueva moneda para calmar la sed.

Cada booster trae 25 monedas por persona; parece que el precio en cadena es de 0,3 U por unidad, así que calculo que serían unas 7-8 U. Este panorama del mercado sigue estando bastante jugoso.

Dicho sea de paso, en cualquier caso: en la situación actual, los que se atreven a listar la nueva moneda son valientes; son gente que viene a repartir dinero. A quien levanta la antorcha para todos no se le puede dejar morir congelado entre la nieve y el viento. Que se abra la mentalidad
$BNB

Quienes pagan a empresas lo saben: lo más difícil de prevenir tal vez no sea la factura falsa. El nombre del proveedor es real, el contrato también es real; solo que la cuenta bancaria para recibir el pago fue sustituida por la de otra persona. Cada campo por separado no tiene fallas, pero al combinarlos se termina enviando el dinero a otro lugar.
Incluso en las cadenas cruzadas existe un peligro de este tipo. No es que todos los datos sean falsos, sino que la clave pública de Bitcoin y la dirección de Ethereum se ensamblan a la fuerza como si pertenecieran a alguien con credenciales.
En las solicitudes de depósito de @BabylonLabs_io para Trustless Bitcoin Vaults (TBV), se incluyen al mismo tiempo la dirección de Ethereum, la clave pública de Bitcoin, la selección del Vault Provider, el compromiso de WOTS y la prueba de control de la clave con BIP-322. No es la cantidad de términos lo que me preocupa, sino quién tiene la autoridad para presionar el botón de confirmación.
Una vez que la solicitud se hace efectiva, los pasos posteriores tratarán las acciones en ambas cadenas como si fueran parte de una misma relación de autorización. Si el iniciador no controla siquiera la clave pública de Bitcoin correspondiente, no es un detalle menor: es alguien abriendo una cuenta en nombre de otro e indicando además a quiénes se contactará después.
Puesto aquí, BIP-322 se parece más a una verificación de elegibilidad antes de abrir una puerta. Primero se demuestra el control real sobre la clave pública de Bitcoin; luego se habla de cómo conectar cuentas y aplicaciones en el lado de Ethereum. No vuelve el mundo más simple; solo impide que un extraño copie una cadena de información pública y así una ambos extremos que no le pertenecen.
Muchos problemas en internet no nacen de que los documentos estén falsificados, sino de que se usurpan las relaciones. El número de teléfono es real, la cuenta bancaria es real, el nombre también es real; al final, lo que está mal es quién tiene derecho a combinarlos para realizar una operación. Si el sistema solo revisa las piezas y no verifica a la persona que establece la relación, cuanto más rápida sea la automatización, más rápido correrán también los errores.
En las discusiones relacionadas con $BABY , este umbral no suena tan llamativo como un BTC nativo, pero se acerca más a la esencia cotidiana de la seguridad. El protocolo primero rechaza a quien no tiene derecho fundamental para iniciar la solicitud; recién después, el resto del flujo tiene sentido.
BIP-322 no es KYC, ni tampoco va a determinar por juicio legal real a quién pertenece el BTC. Lo que protege son las puertas de entrada del protocolo, no la totalidad de la propiedad en la sociedad. El margen es muy estrecho, pero está en el lugar correcto.
Muchos incidentes no ocurren porque las piezas sean falsas, sino porque las piezas reales se conectan con la persona equivocada. #baby

在已有仓位的基础上再加入一座 BTC 金库，最容易产生的误解，是原来的 BTC 也要跟着搬家：先拆开旧金库，再把新旧资产合成一笔更大的抵押。可变化的主要是应用层。旧 BTC 仍待在原来的 Bitcoin 记录里，新 BTC 进入另一座独立金库；两者只是被同一个借贷仓位一起计算。

在 @BabylonLabs_io 的 Trustless Bitcoin Vaults (TBV) 公开测试环境中，每座金库都对应一个独立 UTXO。它是 Bitcoin 上的一笔资产记录，有自己的位置和合法支出边界。增加新金库，不会把旧 UTXO 花掉后重新组合，也不会把几座金库倒进共享 BTC 池。官方设计同样不把金库 BTC 继续拿去再抵押。

Ethereum 应用看到的，是这些金库支持一个仓位。新增金库接入后，应用可以把新的抵押状态与原有仓位汇总，用户不需要为了扩大抵押，先迁移旧 BTC 或重做原有金库。#baby 这里关键的区别，是“合在一起使用”和“合成一笔资产”并不是一回事。

这更像几处独立房产共同为一份贷款提供担保。贷款方可以合计价值，但其中一套房不会因为新增另一套，就被拆掉或并成同一本产权。对应到 TBV，应用层汇总抵押能力，Bitcoin 层继续保留每座金库各自的控制边界。

所以我在看 $BABY 相关的原生 BTC 能力时，更在意扩展使用范围是否要求旧资产先交出原来的控制结构。TBV 给出的答案是：可以增加新的独立金库，让应用获得更多抵押状态，但旧 BTC 无需迁移，也不会因为汇总而变成池中份额。

当前仍是 Bitcoin signet 与 Ethereum Sepolia 上的测试机制，不能写成实测结果。多座金库可以服务同一个仓位，每座 BTC 仍沿自己的 Bitcoin 边界存在。应用把能力合起来，没有把资产揉在一起。

La ventana de desafío de tres días no parece corta, pero si ocurre una anomalía de verdad, el tiempo se consume rápidamente con la búsqueda de materiales, la confirmación del estado y la transferencia de responsabilidades. Los usuarios pueden desafiar directamente una solicitud inválida; esto solo indica que las reglas brindan una vía de entrada, no que esa entrada esté siempre disponible.

En la red de pruebas pública de Trustless Bitcoin Vaults (TBV) asociada a @BabylonLabs_io , el desafiador registrado se encarga de monitorear los comprobantes de rescate. Incluso después de que el depositante conserva los materiales necesarios, también puede iniciar un desafío contra el comprobante inválido. El script de Bitcoin no puede comprender directamente eventos de Ethereum, por lo que el desafío aún depende del mecanismo de comprobación establecido y de contar con los materiales correctos. La ventana actual es de 432 bloques de Bitcoin, aproximadamente 3 días. Tras que el solicitante recibe un desafío, aún quedan alrededor de 108 bloques para rebatir; todo esto son parámetros de la red de pruebas.

Lo que realmente afecta la capacidad de respuesta ante emergencias es si la anomalía puede detectarse a tiempo. A quién se le encarga el monitoreo, cómo llega la alerta al usuario, si los materiales corresponden al monedero (vault) correspondiente, y quién es responsable de presentar la acción después de recibir la alerta: si estas responsabilidades no se aterrizan de forma habitual, los derechos en la cadena irán perdiendo gradualmente su significado durante la cuenta regresiva. El usuario no necesariamente tiene que vigilar la cadena todo el día, pero no se puede asumir por defecto que siempre habrá alguien que detecte el problema por uno mismo.

Si el protocolo ofrece un watchtower o una vía de alertas, también debe dejar claro el alcance de cobertura y el límite de ineficacia; las herramientas solo ayudan a responder, no asumen la responsabilidad final. Esta es también una capa que suele pasarse por alto en la narrativa de seguridad de #baby . El derecho de desafío reduce la dependencia total del rol registrado, pero devuelve al usuario parte de la responsabilidad de monitoreo y preparación.

Si el debate de seguridad en torno a $BABY solo cuenta el número de derechos, aún se escapará si las herramientas, los materiales y el proceso de respuesta pueden realmente hacerse cargo de ello. Actualmente no hay registros de operaciones de desafío por parte de usuarios individuales, así que no se puede convertir una ruta en papel en algo ya verificado como maduro. Un criterio más práctico es si, antes de la emergencia, se puede completar la preparación, y si, una vez que aparece la anomalía, se puede convertir el derecho en acción dentro de la ventana. Si los materiales están en la ubicación equivocada, la alerta no es recibida por nadie, por muy bien escrita que esté la regla, no se podrá comprar tiempo para el usuario.

En una discusión de equipo, alguien mencionó que, ante cualquier anomalía, lo primero es cambiar la dirección de cobro: al menos se puede rescatar el patrimonio. Esa afirmación suena sólida, incluso con un toque de responsabilidad. Pero si desglosas la ruta siguiendo la vía de firma previa, en realidad me vuelve más cauteloso esa “buena intención” improvisada.

Quien puede cambiar a una dirección segura, también puede cambiar a un lugar al que no debía. En el debate alrededor del BTC nativo en torno al #baby , Trustless Bitcoin Vaults (TBV) eligió otro camino: al crear la bóveda, se debe construir la ruta legal de gasto de Bitcoin y prefirmarla.

Después, en la fase operativa, VP, el Security Council u otros participantes no pueden “inventar” una dirección nueva de forma improvisada para desviar el BTC hacia un sitio fuera del plan. Las reglas son como rieles: hacia qué vías puede ir el tren se decide antes de la salida, y la vía debe quedar tendida. Esta restricción rígida es sólida, pero no es un “paquete de seguridad” regalado.

Como más adelante no se puede confiar en cambiar direcciones a última hora para salvar la situación, el diseño de rutas, la configuración de firmas y la definición del destino deben ser mucho más firmes desde la creación.

Los errores no desaparecen: solo se trasladan, en vez de depender de la discreción humana durante la operación, pasan a depender de la calidad de la implementación antes de salir a producción. El tiempo de revisión que se ahorra antes puede convertirse más tarde en puntos ciegos donde ya no hay manera de actuar.

Al observar @BabylonLabs_io desde este ángulo, el valor de la pre-firma no es solo impedir que lo haga “gente malintencionada”; también es rechazar a un administrador todoterreno durante un accidente. No promete que todas las situaciones puedan resolverse con flexibilidad, sino que primero define qué acciones nadie puede realizar.

Por eso la seguridad tiene un poco menos de improvisación en el momento y un poco más de responsabilidad previa. Lo que hoy puede confirmarse es que el destino del gasto legal queda limitado por la ruta prefirmada: no se puede derivar sin más, para un usuario común, hasta un punto en el que pueda verificar técnica y paso a paso todos los detalles en una página. Todavía existen riesgos en la implementación, la auditoría y la configuración de firmas; además, la red de pruebas pública no es una red principal madura.

Antes de crear, trataré la ruta, las firmas y el destino como elementos obligatorios a comprobar. $BABY , en el peso de este diseño, no proviene de un “apagafuegos” universal después de un accidente, sino de comprimir al máximo el espacio para desviar el camino antes de que ocurra. Una vez que las reglas se cierran con llave, la comprobación más tardía también debe ocurrir antes de cerrar la cerradura.

Considerar las cotizaciones flotantes como un precio total a largo plazo es el costo más fácil de subestimar dentro de un préstamo. Los números en la página de apertura parecen muy concretos, e incluso pueden dar la impresión de que el contrato ya está fijado. Pero una vez que el tipo de interés varía con la dinámica del mercado y la utilización, ese número solo describe el momento presente y no puede garantizar las próximas semanas o meses.

Después de que los Trustless Bitcoin Vaults (TBV) con el @BabylonLabs_io conectaran el estado de BTC nativo en garantía a Aave v4, el tipo de interés del préstamo sigue determinado por la utilización del activo correspondiente en Aave Hub. Cuanto más escaso es el capital en el mercado, más puede cambiar la tasa; los intereses también se van registrando en la deuda de forma continua a medida que avanzan los bloques de Ethereum. El BTC nativo ofrece una vía de acceso como garantía, pero no fija el costo del préstamo.

El impacto más directo para los usuarios es que el presupuesto no puede limitarse a copiar la tasa existente en el momento de abrir la posición. El plan de reembolso necesita dejar margen para la variación y también debe recalcularse según el tiempo de préstamo. Cuanto más largo sea el período de préstamo, más importante se vuelve esta reevaluación.

Lo que los usuarios deben vigilar no es solo si hoy pueden pedir prestado, sino también si, una vez que cambie la tasa, aún podrán pagar de acuerdo con el plan original. Yo lo compararía con una tarifa eléctrica que varía según la carga: conectarte a la red significa que puedes usar electricidad, pero no implica que cada kilovatio se calcule a la tarifa de hoy. Al discutir la eficiencia de capital (por ejemplo, #baby ), si solo se dice “naturalmente es barato” con una frase menos, y en su lugar se explica con claridad cómo cambia el costo, se estará más cerca del uso real.

La eficiencia de capital le da a los activos más usos, mientras que los costos dinámicos exigen que quien los utiliza gestione continuamente, en lugar de guardar la calculadora después de abrir la posición. Si en el debate alrededor de $BABY se enfatiza únicamente que el BTC nativo por fin permite pedir prestado, pero no se explica cómo se recalcula el costo, el usuario solo recibe media información. Actualmente, la aplicación registrada solo incluye Aave v4, y el activo prestado es un “mock asset” en la red de pruebas pública, sin valor real.

Aquí lo que se puede confirmar es el mecanismo de tasas, no cuánto pagará finalmente una cuenta real concreta. La innovación en la entrada es importante, pero la disciplina presupuestaria no puede faltar. Mi conclusión es sencilla: la tasa al abrir es el punto de partida, no es una cotización para todo el período de préstamo.