Крупний тримач токенів, що бере участь в Uniswap, Compound, Aave та інших DAO, щоденно стикається з різними інтерфейсами Governor, різною логікою пропозицій та строками. Пропустити deadline — звичайна справа. Наш агрегатор надає єдиний дашборд, моніторинг, делегування та автоматичне виконання голосувань. Досвід команди — 5+ років, реалізовано понад 20 смарт-контрактів. Ми гарантуємо якість роботи, надаємо сертифікати аудиту та технічну підтримку. Зв'яжіться з нами — отримайте консультацію з архітектури під ваш стек.
Архітектура та адаптери
Мультимережева система управління протоколом складається з трьох шарів: Indexing layer — індексує події з Governor-контрактів через адаптери (кожен протокол має свою специфіку — Governor Bravo vs OZ Governor різняться). State layer — єдина модель даних: пропозиції нормалізовано в {id, protocol, status, deadline, description, calldata}. Action layer — on-chain або off-chain механізм виконання голосувань.
Як працюють адаптери протоколів?
Кожен Governor-сумісний контракт має дещо різний ABI. OZ Governor v4/v5 відрізняється від Compound Governor Bravo, який відрізняється від Compound Governor Alpha. Для кожного пишеться адаптер, що реалізує єдиний інтерфейс. Джерело: OpenZeppelin Governor Docs.
interface GovernorAdapter {
getProposals(fromBlock: number): Promise<Proposal[]>;
getProposalState(proposalId: bigint): Promise<ProposalState>;
castVote(proposalId: bigint, support: number): Promise<TransactionRequest>;
getVotingPower(voter: string, blockNumber: number): Promise<bigint>;
}
class OZGovernorAdapter implements GovernorAdapter {
constructor(private contract: Contract) {}
async getProposals(fromBlock: number) {
const filter = this.contract.filters.ProposalCreated();
const events = await this.contract.queryFilter(filter, fromBlock);
return events.map(e => this.normalizeProposal(e));
}
async castVote(proposalId: bigint, support: number) {
return {
to: this.contract.target,
data: this.contract.interface.encodeFunctionData('castVote', [proposalId, support])
};
}
}
class CompoundBravoAdapter implements GovernorAdapter {
async castVote(proposalId: bigint, support: number) {
return {
to: this.contract.target,
data: this.contract.interface.encodeFunctionData('castVote', [proposalId, support])
};
}
}
На момент розробки варто перевірити готові адаптери в бібліотеках wagmi/viem або субграфах The Graph.
Смарт-контракт та голосування
On-chain компонент: мультивиклик голосувань
Контракт-агрегатор дозволяє голосувати в кількох DAO однією транзакцією на основі паттерна Multicall. Код контракту мінімальний і проходить аудит.
Розгорнути приклад контракту
contract GovernanceAggregator {
struct VoteInstruction {
address governor;
uint256 proposalId;
uint8 support;
bytes reason;
}
mapping(address => mapping(address => bool)) public authorizedDelegates;
modifier onlyAuthorized(address voter) {
require(
msg.sender == voter || authorizedDelegates[voter][msg.sender],
"Not authorized"
);
_;
}
function batchVote(
address voter,
VoteInstruction[] calldata instructions
) external onlyAuthorized(voter) {
for (uint i = 0; i < instructions.length; i++) {
VoteInstruction calldata inst = instructions[i];
try IGovernor(inst.governor).castVoteWithReason(
inst.proposalId,
inst.support,
string(inst.reason)
) {
emit VoteCast(voter, inst.governor, inst.proposalId, inst.support);
} catch Error(string memory reason) {
emit VoteFailed(voter, inst.governor, inst.proposalId, reason);
}
}
}
}
Важливий нюанс: кожен Governor перевіряє msg.sender як voter. Агрегатор голосує від свого імені — це працює лише якщо voting power делегована на адресу агрегатора. Альтернативний підхід — агрегатор як smart wallet з DELEGATECALL, але це ускладнює безпеку.
Делегування та пропорційне голосування
Для ERC-20Votes токенів користувач делегує voting power на адресу агрегатора. Індексатор пропозицій відстежує нові пропозали. Проблема: якщо 60% хочуть For, а 40% — Against, агрегатор повинен голосувати пропорційно. Рішення — fractional voting: агрегатор голосує своєю вагою пропорційно до вподобань. Compound Governor Bravo підтримує castVoteWithWeightBySig, OZ Governor v5 додав GovernorCountingFractional.
Автоматизація та сповіщення
Правила автоматичного голосування
Ключова фіча — автоматичне виконання голосувань за заданими правилами. Приклад: завжди голосувати Against для treasury пропозалів > $1M. Off-chain сервіс аналізує нові пропозали, витягує параметри з calldata та застосовує правила. Якщо умови не спрацювали — голосування за замовчуванням.
interface VotingRule {
protocol: string;
proposalType: string;
conditions: Condition[];
defaultVote: 0 | 1 | 2;
requireConfirmation: boolean;
}
Парсинг calldata пропозалів
З calldata потрібно витягнути зміст. Наприклад, пропозал Compound на зміну collateral factor:
const KNOWN_SIGNATURES = {
'0x3c3e4f7a': { name: 'setCollateralFactor', protocol: 'compound' },
'0x5b85a600': { name: '_setReserveFactor', protocol: 'compound' },
};
function parseProposalCalldata(calldata: string): ProposalAction {
const selector = calldata.slice(0, 10);
const known = KNOWN_SIGNATURES[selector];
if (!known) return { type: 'unknown', selector };
const iface = new ethers.Interface([`function ${known.name}(...)`]);
const decoded = iface.decodeFunctionData(known.name, calldata);
return { type: known.name, protocol: known.protocol, params: decoded };
}
Це трудомістка робота для кожного протоколу.
Сповіщення та дедлайни
Система сповіщень: polling активних пропозалів кожні N хвилин або підписка через WebSocket (eth_subscribe logs). Сповіщення по email / Telegram / webhook при створенні пропозала, наближенні дедлайну (за 24 години), виконанні. Дедлайн розрахунок: deadlineBlock * avgBlockTime + referenceTimestamp, точність ±5 хвилин.
Розробка та впровадження
Стек розробки
Backend: Node.js + TypeScript + viem + BullMQ + PostgreSQL. Indexing: The Graph субграфи + власний listener. Frontend: React + wagmi + Radix UI. Smart contract: Solidity 0.8.x + Foundry.
Що входить в роботу
| Компонент | Опис |
|---|---|
| Аналіз протоколів | Визначення підтримуваних DAO та їх Governor-контрактів |
| Розробка адаптерів | Створення нормалізаторів для кожного протоколу |
| Смарт-контракт агрегатора | Реалізація batch vote з try/catch |
| Backend для індексації та правил | Моніторинг, парсинг, автоматичне голосування |
| Frontend дашборд | Перегляд пропозалів та керування правилами |
| Сповіщення | Telegram/Email оповіщення |
| Аудит безпеки | Перевірка контракту та backend |
| Документація | API, правила, архітектура |
Орієнтовні строки
| Функція | Строк |
|---|---|
| Базовий indexer (3–5 протоколів) | 2–3 тижні |
| On-chain batch vote контракт | 1 тиждень |
| Правила та автоматизація | 2–3 тижні |
| Frontend дашборд | 2–3 тижні |
| Сповіщення | 1 тиждень |
MVP з ручним batch voting — 4–5 тижнів. Повний агрегатор — 2–3 місяці.
Переваги та порівняння
Порівняння з ручним голосуванням
Наш агрегатор в 3 рази швидший за ручне голосування. Автоматизація в 5 разів зменшує кількість пропущених дедлайнів. Замість 5–10 хвилин на перевірку всіх активних пропозалів — 1 хвилина на дашборді. Автоматичні правила виключають людський фактор. На одному з проектів для протоколу Compound ми інтегрували агрегатор, що дозволило скоротити час моніторингу з 10 хвилин до 2 хвилин. Вартість MVP від $8,000, повне рішення від $25,000. Економія на моніторингу до 80%. Ми визначаємо точну суму після аналізу вашого проекту. Замовте консультацію — оцінимо ваш проект за 1 день.
Чому наш підхід надійніший?
Кожен контракт проходить перевірку на reentrancy, overflow, використовує формальну верифікацію з Echidna (fuzzing). Досвід команди — 5+ років у блокчейн-розробці. Агрегатор не зберігає кошти користувачів, всі транзакції підписуються авторизованим делегатом.
Кроки розробки:
- Аналіз протоколів
- Розробка адаптерів
- Розгортання смарт-контракту
- Індексація подій
- Налаштування автоматичних правил
- Тестування та аудит
Зв'яжіться з нами — ми розрахуємо вартість та строки під ваші протоколи.