Gobernanza on-chain
Este colectivo había llegado a un punto donde las decisiones importantes se tomaban en un grupo de Telegram entre cuatro personas. No porque quisieran concentrar el poder — sino porque no había una forma mejor de hacerlo.
El dolor
Cuando alguien propone algo en un chat y espera que la gente reaccione con emojis, eso no es gobernanza. Es aprobación informal. Sin quórum, sin registro permanente, sin mecanismo para que una decisión sea vinculante. Y la tesorería del colectivo dependía de que las personas responsables actuaran de buena fe, sin ningún control técnico sobre eso.
Querían algo serio: membresía verificable, propuestas formales con plazo de votación, quórum definido, y una tesorería que nadie pudiera mover unilateralmente. Todo en blockchain, todo auditable por cualquier miembro. El problema era que nadie del equipo sabía Solidity ni cómo desplegar contratos de forma segura en producción.
Lo que cambió
Diseñé los contratos de membresía, gobernanza y tesorería de forma modular. Cada pieza puede actualizarse sin afectar las demás. Hardhat para tests y deploy, con scripts que permiten al colectivo hacer upgrades sin depender de mí. El código es auditable — cualquiera puede leerlo en la cadena.
Además de los contratos, construí un SDK en TypeScript para que el frontend pudiera interactuar sin que nadie tuviera que escribir código de contratos, un indexador con Ponder para consultar el historial de propuestas y votos sin depender de RPCs lentos, y una consola de gobernanza donde los miembros crean propuestas, votan y ven el estado de la tesorería. El colectivo hoy toma decisiones en blockchain, no en un chat.
DAO en producción con membresía, gobernanza y tesorería en Solidity. Decisiones vinculantes sin intermediarios.
Arquitectura
El costo de gas fue el constraint de diseño más importante. Cada voto es una transacción en blockchain — si cuesta demasiado en gas, la gente deja de votar. Los contratos usan bitmap para almacenar votos: en lugar de guardar una entrada por voto, almacena los resultados de hasta 256 votos en un solo uint256. Eso reduce el costo de cada voto a una fracción de lo que costaría con almacenamiento naive. No es elegante de leer en el código, pero el ahorro en gas es real.
El patrón UUPS (ERC-1967) para upgradeabilidad: el proxy guarda la dirección del contrato de lógica en un slot de storage específico. Cuando hay que actualizar la lógica, se despliega un nuevo contrato y se actualiza el puntero. Las cuentas de los miembros no cambian, sus balances no cambian. La trampa de los upgrades es que puedes romper el storage layout si agregas variables en el orden incorrecto — los tests de Hardhat verifican explícitamente que el layout sea compatible entre versiones.
Ponder como indexador escucha los events de los contratos — ProposalCreated, VoteCast, MemberAdded — y construye una base de datos relacional que el frontend consulta con queries normales. Sin esto, cargar el historial de 200 propuestas requeriría 200 llamadas RPC individuales al abrir la consola. Con Ponder son milisegundos.
Los tests corren contra un fork de la red en un bloque específico. Esto es crítico para contratos de tesorería: necesitas probar con el comportamiento real de la red, no una simulación local que puede diferir en detalles que importan. El fork hace snapshot de la cadena y corre los tests en ese estado reproducible.
Stack
Qué aprendimos
Los upgrades asustaban al colectivo. Aunque el mecanismo UUPS es seguro si se implementa bien, la idea de que 'alguien puede cambiar los contratos' generaba desconfianza. La solución fue transferir el control del upgrade al propio DAO: solo una propuesta que pase quórum puede iniciar un upgrade. Yo no puedo hacer nada unilateralmente después del deploy inicial. Tomó tiempo explicarlo, pero era la única forma de que el proyecto tuviera sentido filosófico.
La UX de billetera sigue siendo una barrera real. Parte del colectivo nunca había instalado MetaMask. Tuve que crear una guía de onboarding completa y hacer varias sesiones de introducción antes del lanzamiento. Esto no es un problema que el código resuelve — es fricción estructural de blockchain que hay que aceptar y trabajar alrededor.
Decidir en qué red desplegar fue más difícil de lo que parece. Ethereum mainnet: gas caro. Polygon: gas barato pero percibido como menos seguro. La decisión fue Base, una L2 sobre Ethereum: más barato que mainnet, más seguro que sidechains, compatible con las mismas herramientas. Pero es una decisión permanente — migrar contratos entre redes requiere redespliegue completo y que todos los miembros actúen.
Servicios relacionados
¿Tienes un problema parecido?
Cuéntame qué duele en tu operación. Un mensaje directo a Telegram y respondemos en el día.
Abrir Telegram