Bug de COMP en la Propuesta 62 de Compound

El 30 de septiembre de 2021, Compound Finance ejecutó la Propuesta 62 — un voto de gobernanza destinado a afinar cómo se distribuían las recompensas COMP entre los mercados de préstamo del protocolo. El contrato Comptroller actualizado se envió con un bug crítico que hizo que algunos usuarios recibieran muchísimo más COMP del que las reglas permitían. La exposición teórica máxima: hasta ~$147 millones de COMP a los precios del día, dependiendo de cuán agresivamente reclamaran los usuarios.

Qué ocurrió

El antiguo Comptroller había distribuido las recompensas COMP en un reparto fijo 50:50 entre proveedores de liquidez y prestatarios. La Propuesta 62 introdujo un esquema más flexible que permitía a la gobernanza especificar ratios diferentes por mercado. El contrato de implementación — escrito por Compound Labs y aprobado por gobernanza — contenía un bug en la lógica de seguimiento de recompensas: bajo ciertas secuencias de reclamo, el contrato calculaba el COMP acumulado del usuario basándose en contabilidad obsoleta o duplicada, pagando mucho más de lo que el calendario real de recompensas prescribía.

En cuestión de horas tras la entrada en vigor de la Propuesta 62, los usuarios ya habían reclamado 168.000 COMP ($50M en el momento) a los que no tenían derecho. El análisis del equipo mostró que la exposición teórica en el peor caso — si los usuarios seguían reclamando a través de cada ruta contable accesible — era de alrededor de 280.000 COMP (~$84M) del contrato de distribución inmediato, con exposición adicional de las salidas de reservas más amplias de Compound potencialmente extendiendo la pérdida al rango que Rekt y otros citan como ~$147M.

El error no fue malicioso por parte del equipo — fue un bug de software en una actualización aprobada por gobernanza. Pero los contratos eran no actualizables a nivel de parche, y el bug solo podía abordarse mediante otra propuesta de gobernanza.

Consecuencias

• La gobernanza de Compound aprobó la Propuesta 63 para detener más distribución de COMP mientras se preparaba un parche, y la Propuesta 64 ("Arreglar bug de acumulación de COMP") para enviar el parche.
• Robert Leshner, fundador de Compound, solicitó públicamente que los usuarios que habían recibido COMP en exceso lo devolvieran, señalando que cualquiera que no lo hiciera sería reportado al IRS como receptor de ingresos.
• Una fracción significativa del COMP malapropiado se devolvió voluntariamente en semanas. Algunos usuarios — particularmente quienes habían reclamado e intercambiado inmediatamente por otros activos — no devolvieron fondos.

Por qué importa

El incidente de la Propuesta 62 de Compound es uno de los ejemplos más claros de cómo las actualizaciones aprobadas por gobernanza heredan el mismo riesgo que cualquier cambio de contrato — y a menudo sin el rigor de los ciclos de auditoría pre-despliegue. Votar contra una propuesta defectuosa requiere que los votantes de gobernanza realmente lean los contratos propuestos; en la práctica, la mayoría de los votos pasan con revisión superficial.

La respuesta defensiva que surgió en los años siguientes:

• Timelocks en todas las actualizaciones controladas por gobernanza, dando a los revisores white-hat una ventana para señalar bugs antes de la ejecución.
• OpenZeppelin Defender y herramientas similares para simulación de acciones de gobernanza.
• Auditorías obligatorias de terceros de cualquier propuesta que toque la distribución de recompensas, contabilidad de shares u otras rutas de código críticas para invariantes.

El bug de Compound también es uno de un pequeño número de incidentes donde el "atacante" no es realmente un atacante — es una población de usuarios que resultó estar expuesta a un bug y eligió, individualmente, si quedarse con la ganancia inesperada o devolverla. La cuestión ética on-chain — qué hacer cuando un protocolo te paga más de lo que pretendía — sigue siendo contestada.