El mes pasado escribí sobre cómo verificar por cuenta propia el «respaldo 1:1» de BRL1.p. En aquella ocasión solo se trataba de una instantánea del 17 de octubre. Después también deposité dinero en la tesorería, y no dejaba de preguntarme: ¿quién vigila cada día después de la instantánea? Esta semana automatizé la comprobación para que se ejecute cada 6 horas. De paso, revisé una por una todas las transferencias entre cadenas desde el lanzamiento, y encontré dos cosas más de las que esperaba.
La respuesta breve: no basta. Una sola instantánea solo demuestra que las cifras de ambos lados eran iguales en ese momento. Para tener tranquilidad de forma continua, hay que hacer al menos tres cosas: cotejar cada transferencia entre cadenas en ambas cadenas mediante su identificador de mensaje; ordenar en una línea temporal cada cambio de saldo en ambas cadenas y comprobar si en algún momento la cantidad emitida superó la de la tesorería; y volver a comprobar periódicamente quién firma y autoriza las operaciones.
He hecho estas tres comprobaciones en BRL1.p. Desde su puesta en marcha, las 18 transacciones entre cadenas coinciden y, en los 36 cambios de saldo, la cantidad en circulación nunca superó la de la bóveda. Sin embargo, hay dos cosas que la instantánea anterior no podía revelar: uno de los tres verificadores obligados a firmar cambió sus claves de firma el primer día de funcionamiento de BRL1.p, y después su nombre en el registro de LayerZero cambió de Nethermind a Twinstake; además, una misma cuenta envió a la cadena las 54 verificaciones de los tres verificadores.
Lo que no reveló una instantánea
BRL1.p es la versión de la stablecoin BRL1, vinculada al real brasileño, que se transfiere a la cadena pública Rayls. Los usuarios depositan BRL1 en Polygon en un contrato de bóveda; LayerZero transmite el mensaje a Rayls, donde se acuña la misma cantidad de BRL1.p. En sentido inverso, primero se quema y luego se desbloquea.
En la instantánea del 17 de octubre, el saldo de la bóveda y la cantidad de BRL1.p en circulación eran exactamente iguales: 250,013.482911. Pero la instantánea por sí sola no puede decirnos qué ocurrió entre ambas instantáneas. En esa ocasión emparejé los bloqueos y las acuñaciones por importe, dirección y orden temporal; no usé los identificadores de mensaje de LayerZero, así que no habría podido detectar un emparejamiento incorrecto. En cuanto a los «tres verificadores», la instantánea solo mostraba las tres direcciones configuradas; no decía quién estaba detrás de ellas ni qué claves usaban para firmar.
El código de este análisis, los registros de cada transacción y los registros de cada ejecución están en la carpeta 2026-11-brl1p-monitor del repositorio público hansonhan0520-lang/rayls-verify. GitHub Actions lo ejecuta automáticamente cada 6 horas y envía los resultados al repositorio. Las cifras de este artículo proceden de varias ejecuciones realizadas entre las 03:25 y las 03:56 (UTC) del 6 de noviembre de 2026.
Primero: conciliar cada transacción con su identificador de mensaje
LayerZero asigna a cada mensaje entre cadenas un identificador único, GUID. Al enviarse, queda registrado en el evento OFTSent de la cadena de origen; al recibirse, en el evento OFTReceived de la cadena de destino. Solo si los identificadores coinciden se trata de la misma transacción.
El resultado: 18 transacciones; 16 de Polygon a Rayls y 2 de Rayls a Polygon. En cada una, el GUID coincidía en ambos lados, la cantidad bloqueada equivalía a la cantidad acuñada, y los hashes de las transacciones de ambos extremos que muestra el explorador de mensajes de LayerZero, LayerZero Scan, también coincidían con los de la cadena. LayerZero numera secuencialmente los mensajes de cada canal: las 16 transacciones tenían los números del 1 al 16 y las del sentido inverso, el 1 y el 2; no faltaba ningún número, así que no se omitió ningún mensaje en la tabla. También hice la comprobación inversa: cada cambio en el saldo de la bóveda y en la cantidad de BRL1.p en circulación tenía un mensaje entre cadenas correspondiente; no hubo ninguna emisión ni transferencia «de la nada».
Tiempo de llegada: de Polygon a Rayls, entre 248 y 293 segundos, con una mediana de 267 segundos; en sentido inverso, 57 y 63 segundos. El intervalo de las 13 transacciones anteriores era de 248 a 274 segundos. Una transacción añadida el 28 de octubre tardó 293 segundos y elevó el máximo.
Segundo: poner ambas cadenas en una sola línea temporal
Un puente de bloqueo y acuñación que funcione correctamente cumple una condición invariable: la cantidad de BRL1 en la bóveda nunca es inferior a la cantidad de BRL1.p en circulación. Como primero se bloquean los fondos y luego se acuñan los tokens, y primero se queman y luego se desbloquean, durante los cuatro o cinco minutos que dura la transferencia entre cadenas, la bóveda contiene de más la cantidad que está en tránsito.
Ordené por hora de bloque los 36 cambios de saldo de ambas cadenas y calculé la diferencia entre ellas en cada paso. Después de cada cambio, la diferencia fue siempre igual o mayor que 0; el mínimo fue exactamente 0, es decir, en ningún momento la cantidad en circulación superó la de la bóveda. En Polygon no me basé únicamente en los eventos para calcularla: en los bloques de los 18 cambios de saldo, consulté directamente el balanceOf de la bóveda en dos nodos de archivo independientes (drpc y Tenderly), y todas las lecturas coincidieron con el cálculo, sin excepciones.
También volví a revisar los permisos de administración. Desde el 14 de octubre hasta el 6 de noviembre, consulté cada día a las 00:00 (UTC) el propietario de la bóveda de Polygon, el contrato del otro extremo, el delegado de LayerZero y la configuración de los verificadores; los 24 días fueron idénticos. Los 18 eventos de administración y configuración que se encuentran en ambas cadenas ocurrieron durante el despliegue, entre las 18:05 y las 18:10 del 13 de octubre; desde entonces no se ha modificado nada. La situación que señalé anteriormente tampoco ha cambiado: los permisos de acuñación y quema están únicamente en manos del adaptador entre cadenas, mientras que los permisos de administrador, pausa y actualización, así como la propiedad de los contratos en ambas cadenas, siguen en una misma dirección de una billetera común.
Tercero: quién firma realmente para autorizar las transacciones
Este año hubo un incidente grave en este ámbito. En abril, robaron aproximadamente 292 millones de dólares del puente entre cadenas de KelpDAO. En su informe del incidente de mayo, LayerZero atribuyó la causa a la manipulación de nodos RPC, junto con una configuración de la aplicación que dependía de un solo verificador. En LayerZero, los verificadores se llaman DVN: observan los mensajes en la cadena de origen y, una vez alcanzado el número requerido de confirmaciones, firman en la cadena de destino para autorizarlos. En ambos sentidos, BRL1.p exige la firma de los tres DVN: LayerZero Labs, Canary y un DVN con el ID nethermind.
Primero, veamos si realmente firmaron. Antes de que llegue cada mensaje, en la cadena de destino queda un registro PayloadVerified por cada DVN. Las 16 transacciones de Polygon a Rayls tienen tres registros cada una en Rayls, para un total de 48; las 2 del sentido inverso tienen tres cada una en Polygon, para un total de 6. En todos los registros, el número de confirmaciones indicado coincide exactamente con el requerido: 120 bloques en Polygon y 10 en Rayls. Las verificaciones en Rayls se registraron entre 232 y 253 segundos después del bloqueo en Polygon. La mayor parte de los poco más de cuatro minutos de la transferencia entre cadenas se dedicó a esperar los 120 bloques de Polygon.
Ahora veamos quién firmó. El contrato DVN exige que cada verificación incluya las firmas de un número mínimo de firmantes; estas firmas están en los datos de entrada de la transacción de verificación, por lo que es posible recuperar las direcciones de los firmantes. Recuperé una por una las firmas de las 54 verificaciones: el umbral de LayerZero Labs es de 2 firmas de 3 firmantes y las 16 transacciones se firmaron con las mismas dos claves; el umbral de Canary es de 1 firma de 1 firmante y las 16 transacciones se firmaron con la misma clave.
El cambio se produjo en el tercero. Las primeras 4 transacciones (14 de octubre) las firmó la clave 0xbbd4; a partir de la quinta (15 de octubre), se usó la 0x86f0, salvo una transacción firmada con 0x598c. Los registros en cadena muestran que, entre las 19:55 del 14 de octubre y las 00:30 del 15 de octubre (UTC), este DVN añadió dos firmantes y eliminó al anterior, tanto en Polygon como en Rayls. Esto ocurrió justo entre la cuarta y la quinta transacción de BRL1.p.
También cambió el nombre. En el registro de ejecución del 17 de octubre, el registro público de DVN de LayerZero identificaba esta dirección como Nethermind; al consultarlo de nuevo el 6 de noviembre, aparecía como Twinstake, aunque el ID seguía siendo nethermind. Nethermind anunció el 19 de agosto que había dejado de operar como DVN de LayerZero y que pasaría a operar nodos de Chainlink. La explicación más probable que conecta estos hechos es que Nethermind cedió la operación de este DVN a Twinstake y que también se cambiaron las claves de firma. Esto último es una inferencia mía: en la cadena solo se ve que las claves cambiaron el 14 de octubre, no quién las tenía; el registro es una etiqueta fuera de la cadena mantenida por LayerZero, y solo he consultado sus versiones de dos fechas, así que desconozco cuándo se cambió el nombre exactamente.
Hay otro factor común. Las 54 transacciones de verificación, sin importar el DVN ni la cadena, fueron enviadas por la misma cuenta: 0xb8ff…47cb. Esta cuenta y otra, 0xb52f…f0b6, tienen roles de administrador en los seis contratos DVN (tres en cada cadena). En Polygon, esa cuenta ya ha enviado más de 8.88 millones de transacciones. Según el código y la documentación de los contratos de LayerZero, los administradores son responsables de enviar las verificaciones, pero cada envío debe incluir las firmas suficientes de los firmantes; un administrador no puede falsificar una verificación por sí solo. Por eso lo entiendo así: en materia de seguridad, las tres cerraduras siguen siendo tres conjuntos distintos de claves; para falsificar un mensaje habría que obtener al menos 4 claves de firma (2 + 1 + 1). En cuanto a la disponibilidad, el canal de envío está concentrado en una sola cuenta; si deja de funcionar, las transferencias entre cadenas en ambos sentidos se quedarán esperando. Esta última afirmación es una inferencia basada en el código; no he observado ninguna interrupción.
Un obstáculo para reproducir el análisis: los nodos oficiales no permiten reconstruir el historial
Para que otras personas puedan reproducir el análisis, hay que explicar de dónde proceden los datos. El nodo público oficial de Rayls no sirve de mucho para este caso: cualquier consulta sobre el estado histórico devuelve «podado»; ni siquiera permite consultar el bloque del 17 de octubre. Al buscar registros de BRL1.p y del adaptador, devuelve 0 resultados para un rango de 1,5 millones de bloques; tampoco se puede obtener el recibo de ninguna de las 18 transacciones de Rayls. Sin embargo, es posible consultar las transacciones en sí: los datos de entrada de las 16 transacciones de llegada incluyen el GUID correspondiente, la dirección del destinatario y el importe; las 2 transacciones de envío también incluyen la dirección del destinatario y el importe.
Por eso, el historial de eventos del lado de Rayls solo puede obtenerse del explorador de bloques de Rayls. Lo contrasté con tres elementos: los registros de LayerZero Scan, los datos de entrada de las transacciones que devuelve el nodo oficial y la cantidad actual en circulación, 255,291.961901, que consulté en el nodo oficial. Esta última coincide exactamente con la cifra reconstruida a partir de los eventos del explorador. En el lado de Polygon, usé dos nodos, PublicNode y Tenderly, para obtener los registros; ambos coincidieron línea por línea.
Reservas: el informe sigue siendo el mismo
El puente entre cadenas solo se encarga de mantener una relación de uno a uno entre BRL1.p y BRL1. Para saber si BRL1 está respaldado por reales, hay que consultar la prueba de reservas del emisor. El último informe que pude descargar de brl1.io el 6 de noviembre seguía siendo el del 1 de octubre: reservas de 19,354,372 reales, correspondientes a 17,381,384.54 BRL1, una proporción del 111.35%. El informe indica que fue elaborado internamente y que aún no ha sido auditado por una entidad independiente. Sin embargo, el texto del enlace del sitio web dice «Última prueba de reservas auditada». El enlace marcado como «más reciente» en la página «Cómo funciona» lleva a un informe del 14 de abril de 2025, también elaborado internamente; para ver otro enlace hay que iniciar sesión en Google, y la página de reservas de Fact Finance enlazada en el sitio devuelve un error 404.
En ambos informes consultables, comprobé la cantidad de tokens según los números de bloque indicados; las lecturas de los dos nodos de archivo coincidieron con los informes. Esto demuestra que la parte de «pasivos» del informe coincide con la cadena; la parte de «activos» sigue basándose únicamente en lo que afirma el propio emisor. El 6 de noviembre, ya había 17,882,561.54 BRL1 en Polygon, 501,177 más que el 1 de octubre. No hay ningún informe público de reservas que cubra el respaldo correspondiente a esa cantidad adicional.
Como referencia de lo que puede ser una garantía independiente, se puede consultar la ley GENIUS de Estados Unidos: los emisores publican mensualmente la composición de sus reservas, certificada con las firmas del CEO y el CFO y verificada por una firma contable externa. BRL1 es una stablecoin brasileña y esta ley no se le aplica; aquí se menciona solo como referencia. Cuando BRL1 publique un informe independiente, lo primero será comprobar si lo firma una firma contable independiente y si el informe especifica el tipo de verificación realizada y las normas aplicadas. Para comprobar si la cantidad de tokens indicada en el informe puede leerse en el bloque que este señala, basta con ejecutar por_check.py del repositorio.
Lo que aún no se ha logrado
El historial de eventos del lado de Rayls depende del explorador de bloques; el nodo oficial solo permite contrastarlo, no reconstruirlo de forma independiente. Las lecturas diarias de Polygon se realizan una sola vez, a las 00:00, pero cada cambio de saldo también se verificó por separado según su bloque. La cadena no revela quién posee las claves de firma ni quién opera la cuenta 0xb8ff. Las comprobaciones automatizadas comenzaron el 6 de noviembre y solo cubren el periodo posterior; la parte anterior se reconstruyó a partir del historial.
Mi conclusión
La conciliación transacción por transacción muestra que el puente entre cadenas funciona sin problemas: las 18 transacciones coinciden y la cantidad en circulación nunca superó la de la bóveda. La capa de firmas es más compleja de lo que sugiere la expresión «tres verificadores»: en términos de seguridad, sí hay tres grupos distintos de claves, pero uno de ellos cambió el primer día de funcionamiento, y solo hay una cuenta que envía las transacciones. La parte más débil sigue siendo la del emisor: la prueba de reservas más reciente aún es un informe interno sin auditar.
El criterio para comprobarlo es sencillo. Cualquiera puede ejecutar el flujo de trabajo brl1p-monitor en el repositorio rayls-verify o consultar directamente los resultados que se envían cada 6 horas. Si se produce un nuevo evento de administración o configuración, un verificador cambia de firmantes, la cantidad en circulación supera aunque sea una vez la de la bóveda o BRL1 publica un informe de reservas con verificación independiente, quedará constancia en la siguiente ejecución.
Fuentes de referencia:
Código del artículo, registros de cada transacción y registros de ejecución (envío del 6 de noviembre de 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/4e37e76f7541fbea2cba1c0b8967c46afa905677/2026-11-brl1p-monitor
Registros de ejecución de la instantánea anterior (17 de octubre de 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/main/2026-10-brl1p-backing
Documentación del contrato DVN de LayerZero: https://docs.layerzero.network/v2/workers/off-chain/dvn-technical-reference
Registro público de DVN de LayerZero: https://metadata.layerzero-api.com/v1/metadata/dvns
Informe del incidente de KelpDAO de LayerZero (18 de mayo de 2026): https://layerzero.network/publications/kelpdao-incident-report.pdf
crypto.news, Nethermind deja su función como verificador de LayerZero (19 de agosto de 2026): https://crypto.news/nethermind-leaves-layerzero-verifier-role-chainlink/
Sitio oficial de BRL1 y documentos de prueba de reservas (consultados el 6 de noviembre de 2026): https://brl1.io/en
Centro para la Calidad de las Auditorías de Estados Unidos, requisitos de la ley GENIUS para los contadores (27 de octubre de 2025): https://www.thecaq.org/audit-in-action-what-does-the-genius-act-require-of-accountants
#Rayls $RLS #Stablecoins