Розробка мобільного додатка для 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%.

Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

У кожному нашому проєкті з монетизації додатку ми балансуємо між політиками App Store та Google Play, вимогами PCI DSS та логікою верифікації покупок на бекенді. Неправильно зроблена система платежів — це не просто баг, це фінансові втрати та можливий бан додатку. За 7 років ми розібрали понад 50 кейсів інтеграції платіжних SDK — від простої Stripe-форми до розподіленого біллінгу з власними серверними вебхуками.

Як вибрати між In-App Purchase та зовнішнім платіжним шлюзом?

Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.

In-App Purchase: дві платформи, два різних API

StoreKit 2 (iOS 15+)

StoreKit 2 — повна переробка оригінального StoreKit з async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читабельно та передбачувано порівняно з чергою транзакцій через SKPaymentTransactionObserver.

Найважливіша зміна: транзакції в StoreKit 2 підписані JWS (JSON Web Signature) і верифікуються локально без серверного roundtrip. Transaction.verificationResult повертає .verified(Transaction) або .unverified(Transaction, VerificationError). Це не означає, що сервер не потрібен — він потрібен для зберігання статусу підписки, але локальна верифікація прибирає затримку при старті.

StoreKit.AppTransaction — верифікація самого факту завантаження додатку з App Store. Потрібна для додатків з платним завантаженням або безстроковими покупками, не підписками.

Складне місце в StoreKit 2 — обробка renewalState для підписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Стан inGracePeriod означає, що Apple намагається відновити оплату (до 16 днів) — у цей час потрібно продовжувати надавати доступ. Не обробиш — втратиш лояльних користувачів, у яких тимчасово не пройшла картка. За досвідом, близько 5% підписок потрапляють у billing retry, і автоматичне відновлення доступу повертає до 80% з них.

Google Play Billing Library (v6+)

Google Billing — складніший за StoreKit за кількістю сценаріїв. BillingClient з PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обов'язково викликати при кожному старті додатку, не покладатися на PurchasesUpdatedListener як єдине джерело правди.

Підтвердження покупки: acknowledgePurchase() для non-consumables та підписок, consumePurchase() для consumables. Якщо не викликати acknowledge протягом 3 днів — Google автоматично зробить повернення. Це гарантована втрата грошей, якщо забути про acknowledge на бекенді після верифікації.

ProductDetails з SubscriptionOfferDetails — в Billing v5+ структура оферт ускладнилася: один продукт може мати кілька basePlanId та offerId (пробний період, знижка для нових користувачів, retention-офер). BillingFlowParams.SubscriptionUpdateParams для апгрейду/даунгрейду підписки з prorationMode.

Чому серверна верифікація обов'язкова?

Ніколи не довіряйте лише клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.

Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус у БД, віддає відповідь клієнту. RevenueCat робить це за вас — але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.

Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток — додаток не отримає про цю подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус. Ми використовуємо перевірку підпису вхідних запитів через Apple's signedPayload та Google's DeveloperNotification.

Як RevenueCat спрощує інтеграцію?

Підтримувати StoreKit 2 та Google Billing одночасно, з урахуванням промо-кодів, оферт, відновлення покупок та серверної верифікації — це кілька місяців розробки. RevenueCat закриває більшу частину цього шару.

RevenueCat — не просто SDK для платежів. Це:

• Єдиний API для iOS та Android (і Stripe для вебу)
• Серверна верифікація та зберігання статусів підписок
• Webhooks на події (покупка, відновлення, скасування, billing issue)
• Аналітика по когортам, MRR, churn
• A/B тестування оферт через Experiments

Purchases.configure(withAPIKey:) при старті, Purchases.shared.getCustomerInfo() для отримання поточних entitlements — мінімальний інтегрований шар. Purchases.shared.purchase(package:) замість прямого виклику StoreKit/Billing.

У документації RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Обмеження RevenueCat: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.

Stripe в мобільних додатках

Stripe — для оплати фізичних товарів, послуг, B2B-платежів де IAP не вимагається політикою платформи.

Stripe iOS SDK та Android SDK — PaymentSheet для готового UI оплати, PaymentSheetFlowController для кастомного UI зі збереженими картками. Payment Intent створюється на сервері, client secret передається в додаток — карткові дані ніколи не проходять через ваш сервер, лише через Stripe.

Apple Pay та Google Pay через Stripe: PKPaymentRequest (iOS) та GooglePayLauncher (Android) вже інтегровані в Stripe SDK. Конверсія у Apple Pay дає в 1.3–2 рази вищий результат, ніж форми з ручним введенням картки — це цифри, які ми підтвердили на десятці проєктів.

Збережені картки через SetupIntent + Customer API — користувач платить в один тап при повторному візиті. Compliance: PCI DSS SAQ A — найлегший рівень compliance, оскільки Stripe Tokenization прибирає потребу зберігати карткові дані на своїй стороні. Згідно з PCI DSS, передача токенів звільняє від необхідності сертифікації рівня 1.

3DS2 (Strong Customer Authentication) — обов'язковий для платежів у ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно коректно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.

Що входить в роботу (deliverables)

Процес та терміни

Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.

Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.

Як налаштувати тестове середовище для платежів?

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.