👀 Anatomía de una DAO: Construyendo el Club Argentino de Tecnología

"Si querés entender cómo funciona algo, construilo." Esta es la historia de cómo diseñamos la DAO del CAT.

Nada mejor que un Domingo por la mañana, para entrar programar contratos inteligentes y crear una nueva Organización Autónoma Descentralizada al éter. Así que cargá el mate y acompañame a entrar en la Matrix y explorar el mundo de la web3.

Con algunos años de experiencia siguiendo las criptomonedas y la tecnología blockchain, aprendiendo de manera autodidacta y experimentando con contratos inteligentes en Solidity, me propuse un nuevo desafío: desarrollar la base mínima viable de una DAO para el CAT.

🤔 ¿Pero, qué es realmente una DAO?

Una DAO (Organización Autónoma Descentralizada) es una organización digital donde los miembros toman decisiones de forma transparente y democrática a través de votos, y todas las reglas están programadas y son visibles para todos.

Antes de sumergirnos en el código y las decisiones técnicas, es importante entender qué hace que una DAO sea verdaderamente una DAO.

Imagina que estás armando un país en miniatura. Necesitarías tres elementos fundamentales:

Smart Contracts: El Corazón de la DAO

Los smart contracts (contratos inteligentes) son como las leyes fundamentales de nuestra organización, pero con una diferencia crucial: en lugar de estar escritas en papel, están programadas en código. Y aquí viene lo interesante: una vez que los deployás (es decir, los subís a la blockchain), estas reglas quedan grabadas de forma permanente. Es como tallar las reglas en piedra: inmutables y transparentes para todos.

Para el CAT, necesitamos al menos dos contratos fundamentales: El del token de gobernanza y el de cómo se gobierna.

🚨 Alerta, estas a punto de ver código de programación, esto es para que se vea como es un smart contract y es literalmente el que subimos a la blockchain.

Contrato para el Token CAT (ERC20)

// contracts/CATToken.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";

contract CATToken is ERC20, ERC20Permit, ERC20Votes {
    constructor() 
        ERC20("Club Argentino de Tecnologia", "CAT") 
        ERC20Permit("Club Argentino de Tecnologia") 
    {
        // Mint inicial: 1M tokens
        _mint(msg.sender, 1000000 * 10**decimals());
    }

    // The following functions are overrides required by Solidity
    function _update(address from, address to, uint256 value)
        internal
        override(ERC20, ERC20Votes)
    {
        super._update(from, to, value);
    }

    function nonces(address owner)
        public
        view
        override(ERC20Permit, Nonces)
        returns (uint256)
    {
        return super.nonces(owner);
    }
}

Este contrato va más allá de ser una simple moneda digital: es el sistema que define las reglas de votación y participación en nuestra DAO. Elegimos el estándar ERC20 con extensiones de votación porque, al igual que el LEGO, nos permite construir con piezas probadas y seguras. En el espíritu del código libre que caracteriza a la web3, nos inspiramos en contratos existentes y los adaptamos a nuestras necesidades, tal como los constituyentes argentinos se inspiraron en otras constituciones para crear la nuestra.

El Contrato de Gobernanza

// contracts/CATGovernor.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/governance/Governor.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";
import "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";

contract CATGovernor is Governor, GovernorCountingSimple, GovernorVotes {
    uint256 public constant VOTING_DELAY = 1;
    uint256 public constant VOTING_PERIOD = 50400;
    uint256 public constant PROPOSAL_THRESHOLD = 0;
    uint256 public constant QUORUM_PERCENTAGE = 20;

    constructor(IVotes _token)
        Governor("CAT Governor")
        GovernorVotes(_token)
    {}

    function votingDelay() public pure override returns (uint256) {
        return VOTING_DELAY;
    }

    function votingPeriod() public pure override returns (uint256) {
        return VOTING_PERIOD;
    }

    function proposalThreshold() public pure override returns (uint256) {
        return PROPOSAL_THRESHOLD;
    }

    function quorum(uint256 blockNumber) 
        public 
        pure 
        override 
        returns (uint256) 
    {
        return QUORUM_PERCENTAGE;
    }
}

Este es el cerebro de la operación. Define cómo se proponen, votan y ejecutan las decisiones. Es como el reglamento del club, pero automatizado y transparente.

Mas allá del código,

Una DAO necesita un lugar donde registrar sus decisiones y transacciones de manera transparente e inmutable. Ahí es donde entra la blockchain: una base de datos pública y descentralizada donde nuestras reglas, propuestas y votaciones quedan registradas a la vista de todos.

La Primera Decisión: La Infraestructura

¿Deberíamos crear nuestra propia blockchain? Esta pregunta surgió naturalmente en el Discord del CAT.

Después de analizar las opciones, quedó claro que montar una blockchain propia sería como construir una autopista para probar un auto. Polygon ofrecía todo lo que necesitábamos: bajos costos de transacción, compatibilidad con Ethereum y una red estable. La soberanía tecnológica no significa reinventar la rueda, sino entender y controlar las tecnologías que usamos.

El Dilema de los Tokens

La siguiente pregunta fue más compleja: ¿cuántos tokens crear y cómo distribuirlos? Este es el tipo de decisión que te mantiene despierto por la noche. Después de varios borradores y discusiones, llegamos a 1M de tokens por dos razones:

La distribución inicial es un punto importante, el cual vamos a definir en función de la participación y aporte de los miembros del CAT.

La Gobernanza: Un Experimento en Democracia Digital

El sistema de votación fue donde más iteraciones hicimos. El primer intento fue un desastre: necesitábamos 51% de participación para cada votación. Suena democrático, ¿no? El problema es que ni siquiera las democracias tradicionales logran esa participación consistentemente.

Después de varios intentos, llegamos a un sistema más pragmático:

Algunos Desafíos

Los verdaderos desafíos aparecieron en los detalles. Cada error me enseñó algo valioso:

El aprendizaje más memorable fue descubrir que necesitábamos verificar el contrato en Polygonscan para que Tally lo reconociera. Es el tipo de detalle que no aparece en ningún tutorial.

Lo Que Funcionó (Y Lo Que No)

Los aciertos:

Las lecciones:

La Prueba final

El verdadero momento de revelación llegó con la primera propuesta votada exitosamente. Ver los tokens delegados, los votos registrados y el quorum alcanzado fue como ver un motor arrancar por primera vez. Ahí cerro el primer circuito de pruebas. Esta es la esencia de construir una DAO: no se trata solo de escribir contratos inteligentes, sino de diseñar sistemas que permitan a las personas colaborar de nuevas maneras. Cada decisión técnica es, en realidad, una decisión sobre cómo queremos que funcione nuestra comunidad.

Conclusión

Crear una DAO es como fundar una mini-república digital. Los contratos son importantes, pero son solo herramientas. Lo que realmente importa es la comunidad que las usa y cómo las usa.

El código está en GitHub, las propuestas están esperando votos, y el futuro del CAT está en manos de sus miembros. ¿Qué vamos a construir juntos?

🙌 Gracias por leer,

@andycufari

Notas Técnicas: