Informe del incidente de activación del Botón de Pánico.
El 16 de abril de 2026, el protocolo Money On Chain activó su Botón de Pánico después de validar una falla crítica en la infraestructura de OMoC-Decentralized-Oracle. El propósito de este informe es explicar por qué se activó el Botón de Pánico, por qué esa decisión era necesaria y cómo este mecanismo protegió al protocolo durante un período de riesgo inmediato.
Los fondos están seguros. La falla identificada no fue explotada.
La pausa solo afectó al minteo y la redención de DOC y BPRO a través del protocolo. Las transferencias de DOC, BPRO y MOC continuaron funcionando con normalidad, y la posibilidad de operar esos activos en exchanges descentralizados como Uniswap siguió disponible. Una vez levantada la pausa, la operación del protocolo vuelve a la normalidad.
Qué ocurrió.
La minteo y el redención de DOC y BPRO en Money On Chain fueron pausados al descubrirse una falla en la infraestructura de oráculos que ponía en riesgo inmediato los fondos del protocolo. El problema fue notificado al equipo de mimLABS e investigado por este. La pausa fue ejecutada por los operadores del mecanismo del Botón de Pánico, que es un contrato multifirma controlado por la gobernanza descentralizada del protocolo, y cuya operación ha sido delegada por la gobernanza a los firmantes actuales.
El problema fue comunicado por primera vez la mañana del jueves 16 de abril de 2026, a través de un proceso que comenzó con un equipo trabajando desde Immunefi mientras auditaba Tropykus. Después de investigar intensivamente, unas 2 horas después, concluimos que un atacante podía registrarse como oráculo y publicar inmediatamente precios arbitrarios de BTC/USD en la blockchain. Controlar el precio de BTC/USD sin consenso permitiría a un atacante drenar los fondos del protocolo, y también afectaría a otros protocolos e integraciones que dependen del precio de BTC/USD, así como del precio de BPRO/USD derivado de este.
Por lo tanto, se trató de un incidente relacionado con un riesgo inmediato para el protocolo y con la activación del mecanismo de protección diseñado exactamente para este tipo de emergencia. No ocurrió ningún exploit, y los fondos siguen seguros.
Sobre los oráculos OMoC y la falla identificada que generó el riesgo.
La red de oráculos OMoC es la infraestructura que publica en la blockchain el precio de BTC/USD utilizado por Money On Chain, y de la cual también dependen otros protocolos del ecosistema Rootstock. El sistema proporciona un precio especialmente preciso y actualizado, por lo que es favorecido por protocolos DeFi y difícil de reemplazar por otros proveedores de oráculos.
El conjunto de oráculos es descentralizado y está compuesto por hasta diez operadores. Para participar, un operador debe bloquear suficientes tokens MOC como stake para ocupar uno de los 10 lugares disponibles. Cuanto más MOC bloquea un operador, mayor es su participación en la publicación de precios y en la asignación de recompensas. Estos operadores proveen colectivamente, y sólo tras haber consensuado, el precio que el protocolo utiliza directamente, y que otros sistemas también consumen, ya sea de forma directa o mediante valores derivados como BPRO/USD.
Cada operador de oráculo administra dos direcciones. Una es la dirección propietaria, que es la identidad de largo plazo del oráculo, la dirección que bloquea MOC como stake y la dirección que recibe las recompensas del oráculo. Se espera que esta dirección se mantenga bajo fuerte protección, típicamente en una hardware wallet o en un contrato seguro. La otra es la dirección operativa, que es la hot wallet utilizada por la infraestructura en funcionamiento del operador para firmar los mensajes involucrados en el proceso de publicación de precios. Como esta clave operativa vive en infraestructura activa, el protocolo permite rotarla.
Estos contratos existen desde el inicio del protocolo y, a lo largo de su vida útil, fueron revisados por múltiples equipos humanos de auditoría, tanto internos como externos, y también formaron parte del programa de recompensas por bugs de Money On Chain a través de Immunefi. Aun así, dos bugs que existían desde el comienzo del protocolo fueron identificados recién ahora. Creemos que la creciente efectividad y disponibilidad de herramientas de revisión asistidas por IA probablemente sea una razón por la cual estos problemas finalmente fueron descubiertos.
El riesgo identificado surgió de la interacción de dos bugs. El primer bug afectaba la rotación de claves operativas. El segundo bug afectaba la validación de las firmas utilizadas para publicar precios. Juntos, hacían posible que un único operador de oráculo evadiera el proceso de consenso previsto y publicara un precio arbitrario.
Primer bug: mapeos obsoletos de direcciones operativas después de la rotación de claves.
Cuando un operador de oráculo rotaba su clave operativa, la antigua dirección operativa no se eliminaba de la tabla de consulta on chain que mapea direcciones operativas con sus direcciones propietarias. Eso significaba que la antigua dirección operativa seguía siendo reconocida por el protocolo como perteneciente al propietario del oráculo incluso después de la rotación.
Esto fue un error. Cuando se rota material criptográfico, todas las referencias criptográficas que sigan siendo relevantes para la seguridad deben ser eliminadas. En este caso, la antigua dirección operativa ya no tenía ninguna función legítima una vez completada la rotación. Mantener esa entrada obsoleta en la tabla de consulta era innecesario desde la perspectiva del gas, incorrecto desde la perspectiva del diseño del protocolo y peligroso desde la perspectiva de seguridad.
Este bug por sí solo ya significaba que la rotación de claves no revocaba completamente la clave operativa anterior. Si un atacante lograba obtener antiguas claves operativas de múltiples operadores de oráculo, incluso operadores que habían intentado rotar correctamente podían seguir expuestos. Ese camino requería tiempo, preparación y probablemente cierto grado de ingeniería social, por lo que era preocupante, pero no constituía por sí mismo la amenaza más inmediata.
Segundo bug: la validación de firmas contaba direcciones operativas sin exigir unicidad de propietarios.
Para publicar un precio, un oráculo debe presentar firmas de más de la mitad del conjunto de oráculos seleccionados. La rutina de validación recuperaba las direcciones firmantes, mapeaba cada firmante a un propietario de oráculo y verificaba que el propietario recuperado perteneciera a la ronda activa. El código asumía que cada propietario solo podía tener una dirección operativa válida, por lo que no verificaba que las direcciones firmantes presentadas correspondieran a propietarios de oráculo distintos.
Como las direcciones operativas obsoletas permanecían en la tabla de consulta después de la rotación, un único propietario de oráculo que hubiera rotado varias veces podía tener varias direcciones operativas aún reconocidas como firmantes válidos. Eso significaba que un operador de oráculo podía firmar el mismo mensaje de publicación varias veces usando distintas direcciones operativas, todas mapeadas al mismo propietario, y aun así satisfacer el umbral aparente de firmas. En términos prácticos, esto permitía que un único operador de oráculo evadiera el consenso y publicara un precio arbitrario de BTC/USD.
Este segundo bug transformó el problema de limpieza de entradas obsoletas en una amenaza inmediata para los fondos del protocolo.
Por qué el riesgo era inmediato.
El protocolo de oráculos es descentralizado. No hay una whitelist para ingresar, y no hay un período de espera antes de que un nuevo operador pueda sumarse. Un atacante solo necesitaba comprar suficiente MOC, bloquearlo como stake, registrarse como oráculo y ejecutar el ataque. Bajo las condiciones existentes al momento del incidente, eso podía haber ocurrido en cuestión de minutos.
Había varios factores agravantes que hacían que esto fuera particularmente fácil en ese momento. Cuatro lugares de oráculo estaban vacantes. El ingreso en un lugar vacante era inmediato. El umbral mínimo de entrada para un lugar abierto era de 250,000 MOC. El precio de mercado de MOC hacía que ese monto fuera inusualmente barato en relación con la escala de la superficie de ataque que habilitaba. Esto significaba que un actor malicioso no necesitaba comprometer a un operador de oráculo existente para explotar la falla. Bastaba con convertirse directamente en oráculo, de forma rápida y a bajo costo.
La combinación de severidad técnica y explotabilidad inmediata fue la razón por la cual el Botón de Pánico se activó tan pronto como la investigación confirmó el riesgo.
Alcance de la pausa.
El protocolo nunca había sido pausado antes. La decisión de activar el Botón de Pánico fue excepcional y no se tomó a la ligera.
El Botón de Pánico pausó el minteo y el redención de DOC y BPRO a través del protocolo. No pausó la transferencia de DOC, BPRO ni MOC entre usuarios. No pausó la operación de esos activos en exchanges descentralizados como Uniswap. Tampoco otorgó ningún poder para congelar saldos específicos de usuarios ni para interferir con la custodia de los usuarios.
Esta distinción es importante, ya que el Botón de Pánico existe para brindar protección inmediata a nivel de protocolo mientras preserva el control de los usuarios sobre sus activos. Los fondos están seguros, no se perdió ningún fondo y, una vez levantada la pausa, todas las operaciones del protocolo vuelven a la normalidad.
Impacto en el ecosistema.
La red OMoC-Decentralized-Oracle no es utilizada únicamente por Money On Chain. También es utilizada por protocolos de terceros como Tropykus y Sovryn, y por integraciones adicionales on chain y off chain en todo el ecosistema Rootstock. La red de oráculos provee en la blockchain un precio de BTC/USD preciso y frecuentemente actualizado, que es un servicio valioso del que dependen muchas integraciones. Como BPRO/USD se deriva del estado del protocolo y depende de BTC/USD, un precio manipulado de BTC/USD también propagaría riesgo a los sistemas que dependen de BPRO/USD.
Coordinamos estrechamente con protocolos usuarios conocidos para que pudieran evaluar su propia exposición y tomar sus propias decisiones de gobernanza. Al mismo tiempo, dado que el servicio de oráculos es ampliamente consumido y no había una forma realista de identificar y coordinar con todas las partes que dependían de estos precios, algunos detalles que habilitaban la explotación fueron retenidos intencionalmente mientras el problema seguía activo. Esa decisión se tomó como un intento de reducir el riesgo en todo el ecosistema durante la ventana de votación del arreglo, aunque las herramientas actuales de IA reducen la efectividad de este enfoque de “seguridad por oscuridad” en contratos inteligentes.
Cronología.
En la mañana del jueves 16 de abril de 2026, el equipo de mimLABS recibió el primer contacto sobre el problema a través de Tropykus, al ser detectado por una auditoría de seguridad desde la plataforma Immunefi. La investigación interna comenzó de inmediato.
Unas 2 horas más tarde, el problema fue validado como real y crítico. En ese momento concluimos que un atacante podía convertirse en oráculo, publicar precios arbitrarios de BTC/USD sin consenso y usar ese poder para amenazar los fondos del protocolo. Esa misma capacidad de manipulación de precios también pondría en riesgo a protocolos usuarios por su dependencia directa de BTC/USD e indirecta de BPRO/USD. Como el ataque era inmediatamente ejecutable, el Botón de Pánico fue activado ese día. En paralelo, comenzamos a revisar la actividad histórica on chain de los oráculos para determinar si la falla había sido utilizada alguna vez.
Para el viernes 17 de abril de 2026, se había completado una corrección probada, y una propuesta de gobernanza para aplicarla fue preparada y presentada mediante el proceso de gobernanza existente de MoC. Las propuestas requieren veinticuatro horas para alcanzar quórum, seguidas por un período de votación de siete días. Durante ese tiempo, la infraestructura de oráculos permaneció bajo monitoreo cercano, se aplicaron medidas de mitigación interinas y la vulnerabilidad siguió sin ser explotada.
Revisión histórica y mitigaciones interinas.
Después del descubrimiento del problema, exploramos la actividad histórica on chain del sistema de oráculos para determinar si el camino de rotación de claves había sido explotado anteriormente de esta manera. No encontramos evidencia de que hubiera ocurrido.
Mientras la corrección avanzaba a través de la gobernanza, también trabajamos para hacer que el ataque fuera menos ejecutable en la práctica:
Coordinamos respuestas con participantes del ecosistema expuestos a BTC/USD y BPRO/USD.
Limitamos la publicación de detalles que habilitaran el exploit mientras el problema seguía activo.
Instamos a los holders de MOC a retirar liquidez de los mercados para que adquirir los tokens de staking necesarios para un ataque rápido de ingreso como oráculo fuera más difícil.
Promovimos el staking en los lugares vacantes de oráculos para elevar la barrera efectiva de entrada.
Ninguna de estas medidas eliminó el bug subyacente, pero redujeron la practicidad inmediata del ataque mientras la gobernanza completaba la corrección.
La corrección.
La remediación abordó ambos modos de falla. Las direcciones operativas rotadas deben invalidarse completamente, incluyendo cualquier entrada de consulta que de otro modo permitiría que una antigua clave operativa siguiera siendo reconocida. La validación de firmas también debe exigir unicidad a nivel de propietario de oráculo, en lugar de hacerlo únicamente a nivel de dirección operativa. En conjunto, estos cambios restauran las garantías de consenso previstas en el proceso de publicación de precios del oráculo.
Por qué actuamos rápidamente.
Este incidente también reforzó un cambio más amplio en el entorno de seguridad de los contratos inteligentes. Estamos viendo un volumen creciente de descubrimiento automatizado de vulnerabilidades asistido por IA. Estas herramientas reducen el costo de encontrar fallas sutiles a un nivel que ningún equipo humano podría igualar de manera consistente, incluso con mucho tiempo y presupuesto. Eso cambia el valor de la seguridad por oscuridad para bugs zero-day en contratos inteligentes.
Una vez que una falla ha sido encontrada, debemos asumir que otras partes capaces también podrían encontrarla rápidamente e intentar explotarla. Esa suposición guió nuestra respuesta. Después de la validación, tratamos este problema como una amenaza inmediata y activa, y actuamos en consecuencia.
Lecciones y próximos pasos.
El bug está corregido, pero este incidente cambió nuestra forma de pensar sobre la importancia estratégica de la red de oráculos. El sistema OMoC-Decentralized-Oracle es infraestructura crítica para Money On Chain y para otros protocolos de Rootstock, y fortalecerlo debe ir más allá de corregir esta falla específica.
Una prioridad importante es mejorar los incentivos de los operadores de oráculo. Los diez lugares disponibles deberían permanecer ocupados en todo momento, y la participación debería ser lo suficientemente atractiva como para que exista una cola para ingresar. El límite actual de diez lugares está relacionado con el costo de verificación de firmas en Rootstock. Si la verificación nativa de Schnorr estuviera disponible en el futuro, esa restricción podría cambiar y permitir que el conjunto de oráculos escale más.
Otra lección es que los protocolos que dependen de este servicio de oráculos deberían estar más directamente alineados con el costo y la responsabilidad de operarlo. Hasta ahora, la red de oráculos ha brindado un servicio valioso al ecosistema sin cargo para cualquier protocolo distinto de Money On Chain. La gobernanza de MoC debería considerar cobrar a los consumidores de estos precios. Eso mejoraría la sostenibilidad, fortalecería los incentivos y crearía razones para que los protocolos usuarios participen directamente como operadores de oráculo.
Este incidente también destacó la importancia de los circuit breakers bien gobernados. El discurso público suele tratar la descentralización y los poderes de emergencia delegados como si fueran incompatibles, pero este incidente mostró por qué esa visión es demasiado simplista. Una gobernanza descentralizada puede delegar poderes de protección limitados y revocables a un conjunto restringido de firmantes sin otorgarles la capacidad permanente de congelar fondos de usuarios. El mecanismo del Botón de Pánico no otorga a sus operadores la capacidad de incautar saldos ni censurar transferencias normales; solo les da una capacidad estrecha de respuesta de emergencia que puede proteger el protocolo mientras preserva la custodia de los usuarios.
Cierre.
El Botón de Pánico fue activado para proteger a usuarios, integradores y fondos del protocolo durante un período de riesgo real e inmediato. Funcionó como estaba previsto.
Los fondos están seguros. No se perdió ningún fondo. Una vez levantada la pausa, todas las operaciones del protocolo vuelven a la normalidad.
Este post mortem fue escrito por el equipo de mimLABS. Como desarrolladores y custodios técnicos del protocolo, lamentamos profundamente el impacto de estos bugs, y trabajaremos más duro para que esto no vuelva a ocurrir.
Como parte de la comunidad de Money on Chain, queremos expresar nuestra aprobación del Botón de Pánico. Aunque a veces es caracterizado públicamente por detractores como un punto de centralización, este incidente mostró su verdadero valor al proteger el protocolo frente a vulnerabilidades críticas mientras mantiene una gobernanza descentralizada y la propiedad de los usuarios sobre sus activos.
“Para una tecnología exitosa, la realidad debe tener prioridad sobre las relaciones públicas, porque la naturaleza no puede ser engañada.” —Richard Feynman
Descargo de responsabilidad
Este informe se proporciona únicamente con fines de transparencia e información. No constituye asesoramiento financiero, de inversión, legal ni de ningún otro tipo. La interacción con protocolos descentralizados implica riesgos inherentes, incluidos, entre otros, vulnerabilidades en contratos inteligentes, volatilidad del mercado y posible pérdida de fondos.
Aunque se considera que la información presentada aquí es precisa al momento de su publicación, puede estar sujeta a actualizaciones o revisiones sin previo aviso. Los usuarios son los únicos responsables de evaluar los riesgos asociados al uso del protocolo Money On Chain y de tomar sus propias decisiones de manera independiente.
Nada de lo contenido en este informe debe interpretarse como una garantía de rendimiento futuro, seguridad o disponibilidad del protocolo. El rendimiento pasado y los resultados de incidentes anteriores, incluida la ausencia de pérdidas en este caso, no garantizan resultados similares en el futuro.