Разработка DAO-инструментов

Разработка DAO-инструментов

DAO — это не только Governor контракт и голосование. Зрелая децентрализованная организация нуждается в наборе специализированных инструментов: управление treasury, делегирование с incentives, off-chain координация, исполнение мультишаговых предложений, мониторинг здоровья governance. Большинство проектов собирают этот стек постепенно из готовых примитивов и кастомных решений.

Treasury Management

Gnosis Safe как основа

Большинство DAO держат treasury в Gnosis Safe (Safe{Core}). Это multisig с гибкой настройкой порога подписей. Для DAO с on-chain governance Safe обычно используется как sub-treasury или как executor для Timelock контракта.

SafeSnap / Reality.eth интеграция: позволяет исполнять Snapshot голосования on-chain через Safe без полноценного on-chain Governor. Snapshot предложение → Reality.eth оракул проверяет результат → Safe автоматически исполняет транзакцию. Это популярный паттерн для DAO, которые не хотят накладных расходов полного on-chain governance.

Zodiac модули

Zodiac — фреймворк от Gnosis Guild для расширения Safe через модули. Ключевые модули:

Reality Module: SafeSnap, описанный выше.

Roles Module: гранулярные разрешения — например, отдельный multisig для мелких операций (до $50K), полный DAO vote для крупных. Это паттерн «оперативный treasury» vs «стратегический treasury».

Delay Module: все транзакции из Safe проходят через задержку. Аналог Timelock, но гибче.

Exit Module: механизм rage quit — участник может сжечь токены DAO и забрать пропорциональную долю treasury даже без поддержки majority. Защита от tyranny of majority.

// Пример настройки Roles Module для операционной команды
IRoles rolesModule = IRoles(rolesModuleAddress);

// Разрешить конкретному адресу вызывать определённые функции
rolesModule.assignRoles(
    operationsMultisig,
    [OPERATIONS_ROLE],
    [true]
);

// Настройка разрешения: можно переводить USDC до $50K
rolesModule.scopeFunction(
    OPERATIONS_ROLE,
    usdcAddress,
    IERC20.transfer.selector,
    [true, false],           // check first param (to), не проверять second (amount)
    [TYPE_STATIC, TYPE_STATIC],
    [abi.encode(allowedRecipients), abi.encode(maxAmount)]
);

Diversification стратегия

Многие DAO держат 90%+ treasury в native токене — это катастрофический риск концентрации. DAO-инструменты для диверсификации:

OTC sales: контракт для продажи токенов крупным покупателям по согласованной цене без проскальзывания на DEX. Gnosis Auction или кастомный Dutch Auction.

DCA через DEX: автоматическая продажа токенов небольшими частями на протяжении длительного периода. TWAMM (FraxSwap) идеален для этого.

Yield на стейблах: idle treasury в USDC → Aave/Compound → yield. Требует governance предложения для первоначального одобрения стратегии, потом автоматически.

Delegation Infrastructure

Delegate registry

Tally, Agora и другие платформы имеют собственные delegate profiles. Полезно также иметь on-chain или off-chain registry делегатов с метаданными: специализация, история голосований, декларации о конфликтах интересов.

Aragon создал ERC-1484 для identity. Более практичный подход для большинства DAO — просто хранить metadata на IPFS с on-chain binding через EAS (Ethereum Attestation Service).

Incentivized delegation

Проблема: большинство token holders не делегируют голоса, governance participation < 5%. Решение — incentivize delegation:

contract DelegationIncentives {
    // Snapshot балансов и делегирования
    mapping(address => mapping(uint256 => uint256)) public delegatedAtEpoch;

    // Reward за поддержание делегирования в течение эпохи
    function claimDelegationReward(uint256 epoch) external {
        uint256 delegated = delegatedAtEpoch[msg.sender][epoch];
        require(delegated > 0, "Not delegated this epoch");

        uint256 reward = (delegated * epochRewardRate) / totalDelegatedThisEpoch[epoch];
        rewardToken.transfer(msg.sender, reward);
    }
}

Compound's COMP, Uniswap's UNI, Gitcoin's GTC — все рассматривали или реализовывали delegation incentives.

Proposal Templates и Safeguards

Proposal builder

Формирование on-chain proposal — технически сложная операция: нужно правильно закодировать calldata для каждого действия. Ошибка в calldata = предложение принято, но функция вызывается с неверными параметрами.

Proposal builder — UI или SDK, который позволяет описать действие на высоком уровне («перевести 100,000 USDC на адрес X») и автоматически генерирует правильный encoded calldata.

// Пример proposal builder SDK
interface ProposalAction {
    target: string;      // адрес контракта
    value: bigint;       // ETH
    description: string; // для UI
    functionName: string;
    args: unknown[];
}

function encodeProposalActions(actions: ProposalAction[]): {
    targets: string[];
    values: bigint[];
    calldatas: string[];
    description: string;
} {
    return {
        targets: actions.map(a => a.target),
        values: actions.map(a => a.value),
        calldatas: actions.map(a => {
            const iface = new ethers.Interface([`function ${a.functionName}`]);
            return iface.encodeFunctionData(a.functionName, a.args);
        }),
        description: actions.map(a => a.description).join('\n'),
    };
}

Simulation перед голосованием

Перед постингом предложения on-chain — симуляция исполнения через tenderly_simulateTransaction или eth_call с state override. Это ловит ошибки до того, как community потратит голоса на невалидное предложение.

Tenderly предоставляет API для симуляции транзакций с читаемыми трейсами. Интеграция в proposal review flow снижает количество failed proposals.

Veto механизм

Для критических предложений (изменение параметров протокола, крупные treasury движения) — дополнительный слой защиты: Guardian или Security Council с правом veto в течение timelock периода.

// Timelock с veto функцией
contract GuardedTimelock is TimelockController {
    address public securityCouncil;

    function vetoTransaction(bytes32 id) external {
        require(msg.sender == securityCouncil, "Not council");
        _cancel(id);
        emit TransactionVetoed(id);
    }
}

Optimism Foundation, Arbitrum Security Council — реальные примеры этой схемы. Это компромисс между decentralization и security в ранней фазе протокола.

Off-chain координация

On-chain governance — дорогой финальный шаг. Большая часть обсуждений и согласований происходит off-chain:

Snapshot: off-chain голосование с подписями кошельков. Бесплатно, используется для temperature check перед дорогостоящим on-chain голосованием.

Forum integration: Discourse или Commonwealth — форум обсуждений. Связь между forum thread и on-chain proposal (через IPFS hash в description) создаёт прозрачный audit trail.

Discord bots: автоматические уведомления о новых предложениях, напоминания о deadlines, результаты голосований. DAO Discord bot — несложная, но очень полезная вещь.

Мониторинг governance health

Participation rate: процент голосующих токенов от circulating supply. Норма для здорового DAO — 10-30% для routine proposals, выше для критических.

Delegation concentration: если топ-5 делегатов имеют >50% голосов — centralization risk. Мониторинг через on-chain событий делегирования.

Proposal velocity: сколько предложений в месяц, какой процент принимается/отклоняется. Слишком много предложений = governance fatigue.

Quorum failure rate: если >30% предложений не достигают кворума — параметры кворума слишком высокие или participation слишком низкая.

Dashboard с этими метриками (The Graph subgraph + Dune Analytics) даёт команде операционную видимость в реальном времени.

Стек и сроки

Полный DAO toolset с нуля: 3-4 месяца. Типичный подход — поэтапная разработка, начиная с Governor + Safe, постепенно добавляя остальные компоненты по мере роста DAO.