Розробка мобільного додатка для DAO (голосування, пропозиції)

Розробка мобільного додатка для DAO (голосування, пропозиції)

Ми створюємо мобільні додатки для DAO, які перетворюють читання пропозицій та голосування на простий, інтуїтивний процес. Тримачі токенів хочуть швидко дізнатися, які рішення приймаються, проголосувати в пару кліків і не пропустити дедлайн. Наш досвід — 5+ років розробки мобільних Web3-рішень, включаючи інтеграцію з Governor і Snapshot, делегування токенів та аналітику. Це дозволяє скоротити час розробки на 40% і уникнути типових помилок на стику блокчейну та мобільної платформи.

Головна технічна складність — підтримка двох принципово різних стандартів голосування: on-chain (OpenZeppelin Governor) і off-chain (Snapshot). Кожен потребує своєї архітектури запитів, підпису транзакцій та обробки станів. Ми комбінуємо їх так, щоб користувач отримував єдиний інтерфейс без зайвих дій.

Як працюють стандарти голосування: Governor vs Snapshot

On-chain (Governor): Всі транзакції в блокчейні. OpenZeppelin Governor — стандарт де-факто, який використовують Compound, Uniswap, Aave. Голосування коштує газ, але результати криптографічно верифіковані. Підтримує делегування через ERC20Votes.

Off-chain (Snapshot): Підписи EIP-712 без газу. Голосування зберігається в мережі Snapshot, але не виконується автоматично — потрібен multisig або виконавець. Економія на газі до 100%.

Більшість DAO комбінують: Snapshot для попереднього голосування (без газу), Governor для виконання. Додаток повинен працювати з обома через єдиний інтерфейс.

Як реалізувати голосування on-chain та off-chain?

Покроковий процес для інтеграції двох стандартів:

1. Визначте тип голосування залежно від критичності та бюджету: on-chain для відповідальних рішень, Snapshot для швидких опитувань.
2. Для on-chain використовуйте governor.castVote(proposalId, support) з параметрами 0 (Against), 1 (For), 2 (Abstain). Транзакція потребує газу.
3. Для off-chain підпишіть повідомлення EIP-712 та відправте через Snapshot API. Безкоштовно — ключова перевага. Приклад реалізації:

struct SnapshotVotePayload: Codable { let version: String // "0.1.3" let timestamp: Int let space: String // ID простору DAO let type: String // "single-choice", "approval", "quadratic" let payload: VotePayload struct VotePayload: Codable { let proposal: String // IPFS hash пропозиції let choice: Int // 1 = For, 2 = Against let metadata: String // "{}" } } 

Підпис через WalletConnect або вбудований гаманець.

Список пропозицій: дані та стани

Пропозиція проходить через кілька станів (див. таблицю). Дані отримуємо через The Graph (субграф OpenZeppelin Governor) або Tally API — прямий виклик IGovernor.state() для списку неефективний.

Для запиту списку використовуємо GraphQL-запити до Tally API:

struct TallyProposalsQuery: Codable { static let query = """ query Proposals($governorId: ID!, $first: Int!) { proposals(governorId: $governorId, pagination: { first: $first }, sort: { sortBy: id, isDescending: true }) { id title description status voteStats { support votes percent } start { ... on Block { timestamp } } end { ... on Block { timestamp } } } } """ } 

Tally, Boardroom, Messari — готові агрегатори. Для власного DAO розгортаємо субграф The Graph.

Чому екран пропозиції — головна точка онбордингу?

Більшість учасників тільки голосують, не створюють пропозиції. Екран повинен показувати статус, таймер, результати в реальному часі та кнопку голосування (тільки в Active). Приклад структури:

• Заголовок та опис (рендеримо Markdown)
• Статус та часові рамки
• Результати: For / Against / Abstain з прогрес-барами
• Кворум: набрано X з Y голосів
• Кнопки голосування (тільки в Active)
• Історія подій: хто проголосував і коли

data class ProposalVoteStats( val forVotes: BigDecimal, val againstVotes: BigDecimal, val abstainVotes: BigDecimal ) { val totalVotes get() = forVotes + againstVotes + abstainVotes val forPercent get() = if (totalVotes > BigDecimal.ZERO) (forVotes / totalVotes * BigDecimal(100)).toInt() else 0 val quorumReached get() = totalVotes >= quorumThreshold } 

Делегування голосів: що і як перевіряти

Токени ERC20Votes дозволяють делегувати голосуючу силу без передачі токенів. Виклик token.delegate(delegateeAddress) — одна транзакція. Поки не викликана — токени не беруть участі в голосуванні Governor, навіть якщо на балансі.

UX: при першому вході перевіряємо делегування через token.delegates(account). Якщо не делеговано — показуємо банер «Активуйте право голосу». Приклад коду:

func getDelegatee(for address: EthereumAddress) async throws -> EthereumAddress { return try await governanceToken.delegates(account: address) } 

Push-сповіщення для активних учасників

Підписуємо на події через APNs/FCM: нова пропозиція, швидке закриття голосування (за 24 години), кворум набрано, пропозицію виконано. Користувач налаштовує фільтри — не спамимо.

Створення пропозиції: коли це потрібно

Створення пропозиції через Governor потребує вказання targets, values, calldatas та description. Інтерфейс спрощуємо через шаблони або конструктор викликів для технічно грамотних. Перевіряємо мінімальний поріг токенів (proposalThreshold) до відправки.

Що входить в роботу

• Технічна документація по інтеграції з Governor і Snapshot
• Вихідний код модулів голосування та делегування
• Налаштування push-сповіщень та аналітики
• Доступ до репозиторію та CI/CD
• Навчання команди по доробках та підтримка 2 тижні

Строки

MVP (список + голосування + делегування): 3–4 тижні. Повний додаток зі створенням пропозицій, історією, аналітикою: 8–12 тижнів.

Зверніться до нас для детального обговорення вашого DAO-додатка. Отримайте консультацію інженерів з досвідом понад 5 років у мобільній розробці та 30+ реалізованих Web3-проектів. Ми гарантуємо дотримання App Store Review Guidelines та безпеку приватних ключів. Замовте розробку та скоротьте час виходу на ринок на 40%.