Al oír: “Las monedas en el staking aún se pueden usar como garantía para obtener préstamos”, mi primera reacción fue: ¿esta cuenta puede cerrarse sin problemas?
Por un lado está el staking: las monedas quedan bloqueadas en un script y generan rendimiento; por el otro está la garantía para préstamos: las monedas se entregan a la posición de préstamo como aval. Con la misma moneda haciendo dos cosas, siempre me da la sensación de que en la misma parcela se siembran dos cosechas distintas y que la cosecha terminará peleándose.
Después de revisar el diseño del whitepaper @BabylonLabs_io , entendí cómo se calcula la contabilidad: la tesorería establece tres condiciones de salida — redención, liquidación y slashing por doble firma. El rendimiento del staking y la garantía del préstamo no “se usan simultáneamente con estas monedas”, sino que “los tres destinos de estas monedas quedan fijados de antemano por el script”. Mientras el precio no caiga por debajo del umbral, puedes reembolsar y redimir; si el precio cae por debajo del umbral, el liquidador tiene derecho a disponer de los fondos; y si se actúa con mala intención haciendo doble firma, se activa el slashing. Las tres condiciones no interfieren entre sí: cada una tiene su propia lógica de activación.
Lo verdaderamente contraintuitivo de este diseño está en esto: en los préstamos tradicionales, si el colateral queda bloqueado no se puede mover; con TBV, el colateral participa simultáneamente en el staking, y la clave es que se escribe de forma anticipada la regla de “quién puede gastar estas monedas”. Las tres condiciones corresponden a tres rutas, que no se cruzan: la que se activa primero determina cuál se ejecuta. No es “juntar dos parcelas y sembrarlas juntas”, es “dividir la propiedad de la tierra en tres partes y dejar que el script lo ejecute”, sin que la gente haga de árbitro. La cuenta no se “ahorra”: se “separa”. Cada rol obtiene cuánto y cuándo, y el script ya lo tiene colocado.
Pero, para ser honestos: este es el plano del diseño del whitepaper; todavía no se ha validado completamente en la red de pruebas. He mirado varias veces la documentación y no he encontrado el registro de “staked tesorería: validación exitosa”. Las tres condiciones están descritas con mucha claridad, pero el estado de verificación aún está vacío. Así que en mi cuaderno lo anoto así: el diseño funciona según el planteamiento; el estado de validación falta por completar.
La eficiencia de capital que se busca va en la dirección correcta, pero “que el diseño sea correcto” y “que se haya ejecutado” son dos cuentas distintas. $BABY Sobre los proyectos relacionados: al estudiar la nueva mecánica, aclaremos primero esto: ¿es un diseño dibujado en papel o ya está corriendo en la cadena? Si distingues bien estas cuentas, no te dejarás llevar por el relato. #baby
Por un lado está el staking: las monedas quedan bloqueadas en un script y generan rendimiento; por el otro está la garantía para préstamos: las monedas se entregan a la posición de préstamo como aval. Con la misma moneda haciendo dos cosas, siempre me da la sensación de que en la misma parcela se siembran dos cosechas distintas y que la cosecha terminará peleándose.
Después de revisar el diseño del whitepaper @BabylonLabs_io , entendí cómo se calcula la contabilidad: la tesorería establece tres condiciones de salida — redención, liquidación y slashing por doble firma. El rendimiento del staking y la garantía del préstamo no “se usan simultáneamente con estas monedas”, sino que “los tres destinos de estas monedas quedan fijados de antemano por el script”. Mientras el precio no caiga por debajo del umbral, puedes reembolsar y redimir; si el precio cae por debajo del umbral, el liquidador tiene derecho a disponer de los fondos; y si se actúa con mala intención haciendo doble firma, se activa el slashing. Las tres condiciones no interfieren entre sí: cada una tiene su propia lógica de activación.
Lo verdaderamente contraintuitivo de este diseño está en esto: en los préstamos tradicionales, si el colateral queda bloqueado no se puede mover; con TBV, el colateral participa simultáneamente en el staking, y la clave es que se escribe de forma anticipada la regla de “quién puede gastar estas monedas”. Las tres condiciones corresponden a tres rutas, que no se cruzan: la que se activa primero determina cuál se ejecuta. No es “juntar dos parcelas y sembrarlas juntas”, es “dividir la propiedad de la tierra en tres partes y dejar que el script lo ejecute”, sin que la gente haga de árbitro. La cuenta no se “ahorra”: se “separa”. Cada rol obtiene cuánto y cuándo, y el script ya lo tiene colocado.
Pero, para ser honestos: este es el plano del diseño del whitepaper; todavía no se ha validado completamente en la red de pruebas. He mirado varias veces la documentación y no he encontrado el registro de “staked tesorería: validación exitosa”. Las tres condiciones están descritas con mucha claridad, pero el estado de verificación aún está vacío. Así que en mi cuaderno lo anoto así: el diseño funciona según el planteamiento; el estado de validación falta por completar.
La eficiencia de capital que se busca va en la dirección correcta, pero “que el diseño sea correcto” y “que se haya ejecutado” son dos cuentas distintas. $BABY Sobre los proyectos relacionados: al estudiar la nueva mecánica, aclaremos primero esto: ¿es un diseño dibujado en papel o ya está corriendo en la cadena? Si distingues bien estas cuentas, no te dejarás llevar por el relato. #baby