Por Canuto  

BNB Chain prepara el testnet Jenner para probar CAS20, una familia de tokens nativos que separa la activación de la red de los permisos de emisores y administradores. El diseño reserva a la gobernanza un interruptor clave para habilitar nuevas emisiones, mientras deja otras decisiones, como las listas de elegibilidad y las facultades sobre saldos, sujetas a controles distintos.
***

  • La versión v1.8.1 programa Jenner para el testnet Chapel el 29 de octubre a las 02:30 UTC; la guía previa apunta a una llegada a la red principal a finales de noviembre, sin hora confirmada.
  • El borrador BEP-702 propone que la gobernanza nombre al administrador que activa o desactiva funciones de creación CAS20 y de escritura en el registro de políticas.
  • Las restricciones de transferencia, la incautación y la quema dependen de permisos y políticas distintos; cerrar la puerta de creación no modifica por sí solo los saldos de tokens existentes.

BNB Chain prepara Jenner y reserva a la gobernanza el interruptor de CAS20

BNB Chain se acerca a una prueba de Jenner, una actualización que prepara el terreno para una familia de activos nativos llamada CAS20. El diseño busca que la lógica común de esos tokens forme parte de la cadena, pero separa la disponibilidad técnica de una función de los permisos que cada emisor configura para su activo.

La versión v1.8.1, publicada el 16 de octubre, programa el testnet Jenner en Chapel, la red de pruebas de BNB Smart Chain, para el 29 de octubre a las 02:30 UTC. Un anuncio anterior ofrece como orientación una llegada a la red principal hacia finales de noviembre, aunque todavía no establece una hora exacta, según CryptoSlate.

Jenner separa el código de la autorización para emitir

CAS20 forma parte de la propuesta BEP-702, que sigue identificada como borrador, y abarcaría variantes de activos y stablecoins. La documentación de Jenner de BNB Chain describe CAS20 como un estándar de tokens fungibles nativo para activos regulados, incluidas stablecoins y activos del mundo real tokenizados. Los tokens BEP-20 que ya existen no cambiarían por esta propuesta, una distinción importante para quienes usan hoy la red y podrían interpretar Jenner como una actualización automática de todos sus activos.

La arquitectura distribuye el control en varias capas: la red determina si una función está disponible, los administradores del token ejercen facultades específicas y las políticas definen qué cuentas pueden verse afectadas por ciertas operaciones. Así, el despliegue de infraestructura no equivale a otorgar de inmediato todos los poderes a un emisor ni a permitir que cualquier cuenta opere sobre cualquier saldo.

El comportamiento compartido de CAS20 se implementaría mediante precompilados con estado, es decir, componentes nativos de la cadena que pueden ejecutar reglas comunes para distintos tokens. Ese enfoque podría reducir la necesidad de que cada emisor reproduzca por su cuenta la misma lógica, aunque también concentra parte del funcionamiento en el software de la red.

La propuesta advierte que un defecto en el cliente nativo podría afectar a varios tokens CAS20 a la vez y que una corrección podría requerir otro hard fork. Por eso, la decisión de adoptar esa infraestructura no solo trata de simplificar la creación de activos: también implica valorar el alcance compartido de un posible error frente a la lógica individual de cada proyecto.

La gobernanza conserva la llave de activación

El borrador establece que la gobernanza de la cadena designa al administrador de activación mediante GovHub, el contrato de reenvío de gobernanza de BNB Smart Chain. Después, ese administrador realiza llamadas separadas para encender o apagar funciones; solo GovHub puede cambiar quién ocupa el cargo, y únicamente el administrador registrado, si su dirección no es cero, puede manejar los interruptores.

La implementación prevista incluye controles independientes para permitir la creación de tokens de variante Asset, la creación de tokens de variante Stablecoin y las escrituras en el registro de políticas compartidas. Esta separación significa que habilitar una clase de emisión no abre automáticamente todas las demás funciones, y que el registro de políticas tiene su propio control de disponibilidad. La página de CAS20 de BNB Chain también presenta las variantes Asset y Stablecoin.

Una vez activada una variante, la ruta de creación de la fábrica no incluye una lista de aprobación individual para cada emisor. Quien crea el token proporciona el administrador inicial y las instrucciones de inicialización, de modo que el interruptor de red habilita la vía técnica, mientras las decisiones posteriores sobre ese activo dependen de los permisos que se le asignen.

La página de CAS20 de BNB Chain busca emisores con acceso anticipado, pero esa invitación no demuestra que el código exija una licencia individual a cada proyecto. Para un emisor, por tanto, instalar el soporte de Jenner y lograr que la gobernanza active la variante elegida son hitos distintos; ninguno sustituye la configuración administrativa del token.

Apagar la creación no congela los tokens existentes

Si la red desactiva una función de creación, la consecuencia directa sería impedir que se creen nuevos tokens CAS20 de esa variante. El cambio no detendría automáticamente la emisión de unidades adicionales por parte de un token ya creado cuando sus autorizaciones lo permiten, ni impediría transferencias o la administración de sus roles.

Para los tenedores actuales, esa diferencia acota el alcance del interruptor de red: no es por sí mismo una herramienta para trasladar saldos ni congelar cuentas. Los poderes que afectan a una operación concreta permanecen en otras capas, por lo que resulta necesario distinguir entre la disponibilidad de una función para crear activos y las reglas que gobiernan cada token existente.

El registro de políticas compartidas introduce una segunda dependencia. Un administrador de token selecciona qué políticas se aplican a determinadas operaciones, mientras que cada política cuenta con su propio administrador, responsable de gestionar quién pertenece a la lista; el diseño limita las escrituras en ese registro mediante el control de activación de funciones.

Si se deshabilitan esas escrituras, una lista existente puede seguir consultándose aunque ya no admita cambios de membresía ni transferencias de administración. En ese escenario, una cuenta bloqueada por una política de transferencias podría continuar restringida mientras la puerta de escritura permanezca cerrada, aun cuando la red no haya congelado el token ni alterado sus saldos.

El administrador predeterminado del token todavía podría vincular otra política existente si conserva los permisos necesarios, porque ese enlace a nivel de token queda fuera del interruptor que controla las escrituras del registro. Vincular una lista disponible no es lo mismo que modificar la membresía de una lista compartida que no acepta actualizaciones.

Reutilizar una política entre varios activos puede facilitar la administración, pero también amplía el efecto de una decisión de membresía: la misma cuenta podría quedar sujeta a esa regla en diferentes tokens y operaciones. Cambiar al administrador de activación de la red devolvería el control del interruptor, pero no corregiría por sí solo una entrada; reabrir las escrituras y actualizar la lista serían pasos separados.

Los permisos del token determinan transferencias e incautación

Dentro de cada token, los poderes administrativos y la selección de políticas también se distribuyen por separado. La propuesta contempla funciones diferenciadas para acuñar, realizar autoquemas, incautar, pausar y reanudar operaciones; las facultades pueden recaer en distintas direcciones o concentrarse, según la configuración elegida por el emisor.

La autoridad que activa funciones en la red, la asignación de roles de un token y la administración de las listas compartidas son permisos distintos, incluso si una misma organización controla más de uno. Esa separación importa porque tener una facultad en un nivel no concede automáticamente las demás ni elimina las condiciones que el contrato aplica a cada operación.

En una transferencia ordinaria, la implementación comprueba las políticas correspondientes al remitente y al receptor, además de revisar al ejecutor delegado cuando alguien mueve fondos en nombre de otra cuenta. La acuñación emplea una política separada para el destinatario, por lo que estar autorizado para recibir unidades recién creadas no resuelve automáticamente si una cuenta puede enviar tokens o actuar por otro tenedor.

La incautación permitiría a un operador autorizado reasignar saldos elegibles sin el consentimiento del tenedor, pero el diseño la deshabilita como facultad general por defecto mediante una protección adicional. El código administrativo de v1.8.1 denomina esa regla SEIZE_EXEMPT_POLICY: una cuenta autorizada bajo esa política queda exenta de incautación, y asignar un rol de incautación no basta para volver elegibles sus fondos.

En llamadas ordinarias posteriores a la creación, una reasignación exige que el tenedor no supere la comprobación de exención, además de un rol de incautación, una función de incautación no pausada, saldo suficiente y un destino válido según la política de recepción de incautación. Cuando se cumplen esas condiciones, seizeWithMemo omite las comprobaciones de las políticas ordinarias de transferencia y mantiene intacto el suministro total.

La quema opera de otra manera: destruye suministro y, en las llamadas ordinarias de CAS20, utiliza los tokens propios de quien la ejecuta bajo un rol separado. Por eso, no deben confundirse las restricciones de transferencia con la elegibilidad para incautación, ni suponerse que pausar las transferencias también detiene la incautación, que tiene su propia configuración de pausa y salvaguardas.

El testnet será el próximo hito operativo

El calendario inmediato apunta al testnet Chapel del 29 de octubre a las 02:30 UTC, tras la publicación de v1.8.1 el 16 de octubre. La orientación previa sitúa la red principal hacia finales de noviembre, pero sin hora exacta confirmada; en cualquier caso, una fecha de despliegue no indicaría por sí sola qué administrador controla las funciones ni cuáles interruptores se han activado.

Los emisores que evalúen CAS20 deberán considerar tanto la disponibilidad de la variante que quieren crear como los controles que mantendrán después del lanzamiento. La lógica nativa puede evitar que cada proyecto implemente por separado comportamientos comunes, aunque esa ventaja viene acompañada por el riesgo de que un fallo del cliente afecte a varios activos y exija una intervención de la cadena.

En adelante, la creación dependerá de que la gobernanza habilite las funciones pertinentes, mientras el mantenimiento de las listas compartidas estará sujeto a que el registro permita escrituras. La exposición de los tenedores a restricciones o reasignaciones, por su parte, dependerá de los roles y políticas efectivamente configurados por cada emisor, no solo del calendario de Jenner.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados