Al observar la tokenomics de los validadores de Babylon, noté un interesante diseño de alineación de incentivos.
En las cadenas PoS tradicionales, los ingresos de los validadores provienen principalmente de las recompensas por bloque y de las comisiones de transacción. Pero en el marco de Babylon, los validadores tienen una fuente adicional de ingresos: las tarifas de seguridad entre cadenas (cross-chain security fees).
Estas security fees provienen de las cadenas PoS que se conectan a Babylon; deben pagar tokens BABY para alquilar la seguridad de Bitcoin. Estas tarifas se distribuyen a los validadores según la proporción de su stake.
Creo que este modelo de ingresos multi-stream puede mejorar significativamente la resiliencia económica de los validadores. Incluso si la actividad de una cadena downstream disminuye y, con ello, bajan las transaction fees, los validadores aún pueden recibir compensación por otras cadenas.
Pero este diseño también introduce una nueva complejidad: ¿cómo poner un precio de forma justa a los servicios de seguridad? Las necesidades de seguridad de cada cadena PoS son distintas; algunas requieren envíos frecuentes de checkpoints, mientras que otras solo necesitan una garantía de finalidad de baja frecuencia.
La solución actual de Babylon es que cada cadena obtenga security slots mediante un mecanismo de subasta; el precio basado en el mercado, en teoría, permitiría una asignación eficiente.
Sin embargo, me preocupa que en la fase inicial, si hay muy pocas cadenas participantes, la subasta podría no tener suficiente competencia, lo que causaría una distorsión en el pricing.
Otro punto digno de atención es el diseño de la validator bonding curve. Babylon exige que los validadores hagan bond tanto con BABY como con BTC, y la proporción entre ambos determina su poder de voto. Este mecanismo de bonding con dos activos incrementa el requerimiento de capital para los validadores, pero también eleva el costo de un ataque.
Desde la perspectiva de la seguridad, este diseño es razonable: un atacante necesita adquirir ambos activos para lanzar un ataque, lo que aumenta de forma considerable la complejidad del ataque.
$BABY #baby @BabylonLabs_io
En las cadenas PoS tradicionales, los ingresos de los validadores provienen principalmente de las recompensas por bloque y de las comisiones de transacción. Pero en el marco de Babylon, los validadores tienen una fuente adicional de ingresos: las tarifas de seguridad entre cadenas (cross-chain security fees).
Estas security fees provienen de las cadenas PoS que se conectan a Babylon; deben pagar tokens BABY para alquilar la seguridad de Bitcoin. Estas tarifas se distribuyen a los validadores según la proporción de su stake.
Creo que este modelo de ingresos multi-stream puede mejorar significativamente la resiliencia económica de los validadores. Incluso si la actividad de una cadena downstream disminuye y, con ello, bajan las transaction fees, los validadores aún pueden recibir compensación por otras cadenas.
Pero este diseño también introduce una nueva complejidad: ¿cómo poner un precio de forma justa a los servicios de seguridad? Las necesidades de seguridad de cada cadena PoS son distintas; algunas requieren envíos frecuentes de checkpoints, mientras que otras solo necesitan una garantía de finalidad de baja frecuencia.
La solución actual de Babylon es que cada cadena obtenga security slots mediante un mecanismo de subasta; el precio basado en el mercado, en teoría, permitiría una asignación eficiente.
Sin embargo, me preocupa que en la fase inicial, si hay muy pocas cadenas participantes, la subasta podría no tener suficiente competencia, lo que causaría una distorsión en el pricing.
Otro punto digno de atención es el diseño de la validator bonding curve. Babylon exige que los validadores hagan bond tanto con BABY como con BTC, y la proporción entre ambos determina su poder de voto. Este mecanismo de bonding con dos activos incrementa el requerimiento de capital para los validadores, pero también eleva el costo de un ataque.
Desde la perspectiva de la seguridad, este diseño es razonable: un atacante necesita adquirir ambos activos para lanzar un ataque, lo que aumenta de forma considerable la complejidad del ataque.
$BABY #baby @BabylonLabs_io