⛓️ Blockchain Learning Path
GitHub

11 · DAO y gobernanza

Nivel: Avanzado · ⏱️ Duración estimada: 150 min · Fuente: OpenZeppelin Governor y Compound Governance ⬅️ Currículo · 📚 Bibliografía 🧭 ⬅️ Anterior: 10 · Oráculos, almacenamiento e indexación · 📚 Índice · ➡️ Siguiente: 12 · Escalabilidad y capas 2 📖 Glosario de términos · 🌱 ¿Nuevo en esto? Empieza aquí

🎯 Objetivos

📚 Resultados de aprendizaje

Al finalizar, el estudiante podrá:

  1. Explicar cómo un snapshot de poder de voto impide comprar votos justo antes de la votación.
  2. Configurar un Governor de OpenZeppelin con quorum, periodo de votación y TimelockController.
  3. Justificar el uso de un timelock como demora entre la aprobación y la ejecución.
  4. Analizar un ataque de flash-loan governance y las defensas que lo neutralizan.
  5. Diseñar un mecanismo de emergencia acotado, transparente y con límites explícitos.
  6. Distinguir el voto on-chain del off-chain según coste, participación y verificabilidad.

🗺️ Temas

# Tema Por qué importa
1 Propuestas y ciclo de vida Estructuran cómo la comunidad decide y ejecuta cambios.
2 Delegación de voto Permite a titulares delegar su poder sin transferir tokens.
3 Snapshots de poder Fijan el poder en un bloque pasado para evitar compra de última hora.
4 Quorum y participación Sin participación mínima, una minoría decide por todos.
5 Timelock y ejecución La demora da tiempo a reaccionar ante una propuesta maliciosa.
6 On-chain vs. off-chain Snapshot abarata el voto pero traslada la confianza fuera de la cadena.
7 Tesorería multisig Un Safe con múltiples firmantes protege los fondos de la DAO.
8 Amenazas de gobernanza Flash loans, captura y baja participación erosionan la legitimidad.

🧠 Modelo mental

Una DAO bien diseñada se parece a un parlamento con reglas de procedimiento: no basta con que una mayoría levante la mano una vez. Hay un registro de quién tiene derecho a voto en cierto momento (el snapshot), un debate con quorum, y un periodo obligatorio entre la aprobación y la entrada en vigor de la ley. Ese retraso no es burocracia inútil: es la ventana en la que la comunidad puede leer la letra pequeña y, si detecta un abuso, retirar sus fondos o reaccionar antes de que el cambio se aplique.

El límite de la analogía: en un parlamento tradicional el poder de voto no se puede alquilar por diez segundos, pero en cadena sí. Un atacante puede pedir prestado un capital enorme vía flash loan, votar y devolverlo en la misma transacción. Por eso el snapshot de poder en un bloque anterior y el timelock no son adornos, sino defensas centrales: separan el momento en que se mide el poder del momento en que se vota, y el momento en que se decide del momento en que se ejecuta.

🧩 Esquema visual

El ciclo de vida de una propuesta en un Governor de OpenZeppelin impone etapas obligatorias entre la creación y la ejecución.

stateDiagram-v2
    [*] --> Pending
    Pending --> Active: abre el periodo de voto
    Pending --> Canceled: el proponente la retira
    Active --> Succeeded: logra quorum y apoyo suficiente
    Active --> Defeated: sin quorum o con rechazo
    Succeeded --> Queued: entra en cola del timelock
    Queued --> Executed: cumple la demora y se ejecuta
    Queued --> Canceled: se detecta un abuso y se cancela
    Executed --> [*]
    Defeated --> [*]
    Canceled --> [*]

La arquitectura separa quién mide el poder de voto, quién decide y quién ejecuta: solo el timelock es dueño de los contratos administrados.

flowchart LR
    T["Token con ERC-20Votes"] --> D["Delegación y checkpoints"]
    D --> G["Contrato Governor"]
    G --> TL["TimelockController"]
    TL --> TS["Tesorería de la DAO"]
    TL --> PC["Parámetros del protocolo"]
    TL --> UP["Actualizaciones de contratos"]

📖 Conceptos y definiciones

🔬 Profundización

Anatomía de un ataque de gobernanza: Beanstalk (2022)

En abril de 2022, el protocolo Beanstalk perdió unos 182 M USD en el mayor ataque de gobernanza con préstamo relámpago registrado. El atacante había creado una propuesta maliciosa días antes (disfrazada, con ironía, de donación benéfica) y luego, en una sola transacción, pidió prestados cientos de millones de dólares en stablecoins vía flash loan, los depositó para obtener la supermayoría de poder de voto, ejecutó la propuesta mediante un mecanismo de emergency commit que no exigía demora, transfirió la tesorería a su propia dirección y devolvió el préstamo. Beneficio neto para el atacante: alrededor de 76 M USD.

El ataque funcionó porque fallaron a la vez las tres defensas canónicas:

Ninguna defensa aislada basta: el snapshot sin timelock deja pasar propuestas maliciosas votadas con poder legítimo comprado barato, y el timelock sin snapshot solo retrasa el saqueo.

Parámetros de diseño de un Governor

Parámetro Qué protege Trade-off al subirlo
Voting delay (entre propuesta e inicio de votación) Da tiempo a delegar, informarse y detectar propuestas hostiles Retrasa decisiones urgentes legítimas
Voting period (duración de la votación) Participación real en distintas zonas horarias y contextos Alarga todo el ciclo; más exposición a campañas de compra de votos
Proposal threshold (poder mínimo para proponer) Filtra spam y propuestas triviales de atacantes sin capital Concentra la iniciativa en ballenas y grandes delegados
Quorum (participación mínima) Impide que una minoría diminuta decida por todos Con apatía alta, ningún cambio legítimo alcanza el umbral
Timelock delay (demora antes de ejecutar) Ventana de reacción y salida ante una propuesta aprobada maliciosa Ralentiza correcciones de emergencia; exige un mecanismo de guardián acotado

No existen valores universales: un protocolo con tesorería enorme y comunidad madura tolera ciclos largos; uno joven que necesita iterar rápido suele empezar con parámetros bajos y endurecerlos a medida que crece el valor en juego.

veTokens y delegación líquida

El modelo vote-escrowed (veToken), popularizado por Curve con veCRV, ataca dos males crónicos: el capital mercenario que vota hoy y se va mañana, y la apatía del votante pequeño. El titular bloquea sus tokens por un plazo elegido (hasta 4 años en Curve) y recibe poder de voto proporcional al monto y al tiempo restante de bloqueo, que decae linealmente: quien más se compromete a largo plazo, más pesa. La delegación líquida (el patrón de ERC-20Votes) resuelve el otro flanco: permite ceder el poder de voto a delegados activos sin transferir la propiedad, elevando la participación efectiva.

Las críticas también son serias: el bloqueo prolongado ilíquido concentra el poder en quienes pueden permitirse inmovilizar capital años; alrededor de los veTokens surgieron mercados de sobornos de voto (bribes) y capas como Convex que re-concentran el poder que el diseño quería dispersar; y la delegación líquida tiende a oligarquías de delegados profesionales con baja rendición de cuentas. La lección de diseño: ningún mecanismo de tokenomics sustituye a una comunidad que vigila la concentración de poder — solo cambia dónde hay que mirar.

Un ataque de gobernanza, y por qué cada defensa existe

Las piezas de un Governor (snapshot, quorum, timelock) parecen burocracia hasta que se ve el ataque que cada una impide. Sigamos uno completo.

El objetivo: una DAO con una tesorería de 50 millones y un token de gobernanza que cotiza en mercado.

Sin ninguna defensa, el ataque cuesta una transacción:

1. Flash loan de 20 millones          ← sin colateral, se devuelve al final
2. Comprar tokens de gobernanza
3. Crear la propuesta "transferir la tesorería a esta dirección"
4. Votar a favor con los tokens recién comprados
5. Ejecutar
6. Vender los tokens, devolver el préstamo

Todo en un bloque. Y ahora, dónde se rompe la cadena según qué defensa esté puesta:

Defensa En qué paso muerde Qué impide exactamente
Snapshot en bloque pasado (getPastVotes) 4 Los tokens comprados en el paso 2 tienen cero poder de voto: el peso se leyó de un bloque anterior a la compra. Mata el ataque entero
Retraso de votación 3→4 Entre crear la propuesta y poder votar pasan bloques, así que ninguna operación atómica los abarca
Periodo de votación (días) 4 Sostener un préstamo relámpago durante días es imposible por definición
Quorum 4 Obliga a movilizar una fracción real del suministro, no solo mayoría de los que votaron
Timelock 5 Aunque todo lo anterior fallara, la ejecución se retrasa: da tiempo a ver la propuesta y salir

Lo importante: el snapshot solo por sí mismo ya cierra este ataque. Las demás no son redundancia inútil: cada una cubre un camino distinto (compra progresiva, colusión de delegados, propuesta maliciosa disfrazada). Un diseño con snapshot pero sin timelock es vulnerable a un ataque más lento y más difícil de detectar.

La consecuencia práctica que sorprende: con ERC20Votes, tener tokens no da poder de voto. Hay que delegar explícitamente, aunque sea a uno mismo. Es la causa número uno de participación baja en DAOs recién lanzadas, y no es un bug: es lo que permite que el snapshot funcione.

💡 En una frase: cada pieza de un Governor existe porque alguien ya ejecutó el ataque que impide. El snapshot es la que hace inviable comprar la votación en el último segundo.

🎓 Si ya dominas esto — donde la gobernanza se rompe de verdad
  • El voto ponderado por tokens es plutocracia con pasos extra. Quien más capital tiene, más decide. La votación cuadrática mitiga la concentración pero es vulnerable a Sybil sin identidad, lo que traslada el problema a "cómo pruebas que eres una persona" — que no está resuelto.
  • La apatía es el estado por defecto y es racional. Votar cuesta tiempo y gas; el efecto de un voto pequeño es nulo. Por eso la delegación es la solución de facto, y por eso los delegados profesionales concentran poder de forma silenciosa: revisa la distribución del voto delegado, no solo la del token.
  • La ejecución en varias cadenas rompe la atomicidad de la decisión. Una propuesta aprobada en L1 que debe aplicarse en varias L2 puede quedar a medias si un mensaje falla. Hay que diseñar la reversión antes que la ejecución.
  • El timelock protege y expone a la vez. La ventana que da a los usuarios para salir se la da también a un atacante para preparar la explotación de un cambio que ya conoce. La duración correcta equilibra ambas cosas; copiarla de otro protocolo sin ese análisis es copiar su modelo de amenazas.
  • ERC-6372 permite anclar los checkpoints al tiempo en vez de al número de bloque. Es lo correcto en L2 con tiempos de bloque variables, donde "dentro de 40 320 bloques" puede significar cualquier cosa.

🧪 Laboratorio guiado

🧪 Estas prácticas están catalogadas y resueltas paso a paso en el catálogo de laboratorios.

  1. Abre los contratos de gobernanza y timelock del módulo, ubicados en labs/08-protocols, y revisa cómo se enlaza el Governor con el TimelockController.

  2. Ejecuta la suite de pruebas con trazas para seguir una propuesta desde su creación hasta su ejecución.

forge test -vv

  1. En las trazas, localiza el snapshot de poder de voto y comprueba que corresponde a un bloque anterior al inicio de la votación.

  2. Sigue el paso por el timelock e identifica la demora obligatoria entre la aprobación y la ejecución.

📝 Reto verificable

Diseña e implementa una DAO en la que una propuesta crítica requiera votación con quorum, una demora en TimelockController y una ejecución verificable, más un mecanismo de emergencia acotado y transparente.

Criterio de aceptación: forge test -vv pasa en verde; una prueba demuestra que una propuesta no puede ejecutarse antes de cumplir la demora del timelock; otra prueba demuestra que el poder de voto se mide por snapshot en un bloque pasado; y el mecanismo de emergencia tiene límites explícitos y deja rastro on-chain.

⚠️ Errores frecuentes

Síntoma Causa y cómo comprobarlo
Alguien aprueba una propuesta con tokens prestados Falta de snapshot en bloque pasado; verifica que el poder se lea con getPastVotes.
Una propuesta se ejecuta al instante No hay timelock entre aprobación y ejecución; comprueba la demora en TimelockController.
Casi nadie vota y una minoría decide Quorum demasiado bajo o apatía; revisa el umbral y los incentivos de participación.
El poder de voto no aparece Titular no delegó, ni siquiera a sí mismo; recuerda que ERC-20Votes exige delegación explícita.
Un delegado concentra el control Captura por delegación; monitoriza la distribución del poder delegado.
El "botón de emergencia" hace demasiado Mecanismo sin límites; acótalo, hazlo transparente y auditable.

🛡️ Seguridad y ética

🔗 Referencias

✅ Criterio de dominio

🧭 Navegación

⬅️ Módulo 10 · Oráculos, almacenamiento e indexación · 📚 Índice del currículo · ➡️ Módulo 12 · Escalabilidad y capas 2

🧠 Autoevaluación del módulo

Responde sin volver atrás. Cada opción incorrecta corresponde a un error frecuente documentado en este mismo módulo: si fallas, la explicación te dice qué releer.