Мультичейн-гаманець (Ethereum, BSC, Polygon, Solana, TON)

Користувач встановлює окремі гаманці для Ethereum, Solana та TON — ключі розкидані, seed-фрази плутаються. Втрата доступу до одного з гаманців призводить до безповоротної втрати активів. Мультичейн-гаманець (Ethereum, BSC, Polygon, Solana, TON) з єдиною seed-фразою за BIP39 та деривацією BIP44 вирішує цю проблему. Ми реалізуємо таке рішення на нативному iOS/Android або Flutter, з підтримкою всіх перерахованих мереж. Наші інженери мають понад 5 років досвіду в розробці криптогаманців, успішно проведено понад 10 проєктів у сторах. Гарантуємо проходження App Store та Google Play Review.

Як деривуються ключі для різних блокчейнів?

Всі підтримувані мережі використовують один BIP39 seed, але різні шляхи деривації BIP44:

Ethereum, BSC та Polygon використовують однаковий coin type 60 та шлях деривації, тому адреса для них спільна. Різниця лише в chainId при підписанні транзакцій та в RPC endpoint. При відправленні важливо явно вказувати мережу, інакше транзакція піде не туди — це виправити вже неможливо. Solana та TON використовують алгоритм ed25519, несумісний з secp256k1. Бібліотека Trust WalletCore підтримує обидва алгоритми через єдиний інтерфейс, що спрощує розробку.

Чому EVM-мережі мають спільну адресу?

Одна й та сама адреса, один і той самий приватний ключ, але різні мережі — різні chainId (Ethereum Mainnet: 1, BSC: 56, Polygon: 137). ChainId обов'язково включається в підпис транзакції (EIP-155) — це захищає від replay-атак між мережами. Для роботи з EVM мережами використовуємо Web3j (Android), web3.swift (iOS) або ethers.js через JavaScriptCore/WebView для крос-платформенності. Для кожної мережі — свій RPC провайдер:

val ethWeb3 = Web3j.build(HttpService("https://mainnet.infura.io/v3/YOUR_KEY"))
val bscWeb3 = Web3j.build(HttpService("https://bsc-dataseed.binance.org/"))
val polygonWeb3 = Web3j.build(HttpService("https://polygon-rpc.com"))

ERC-20 токени, NFT (ERC-721/1155) працюють однаково на всіх трьох мережах — різниця лише в RPC endpoint та адресах контрактів.

Не-EVM блокчейни: Solana та TON

Solana принципово відрізняється від EVM. Немає ERC-20 — є SPL Token Program. Адреси — base58-encoded публічні ключі ed25519. Підключаємося через Solana Mobile Adapter на Android або безпосередньо до ноди. Для роботи з токенами потрібно створити Associated Token Account (ATA) — у кожного токена на гаманці окремий аккаунт, що вимагає rent-exempt lamports.

val connection = RpcClient("https://api.mainnet-beta.solana.com")
val balance = connection.getBalance(publicKey)
val tokenAccounts = connection.getTokenAccountsByOwner(
    owner = publicKey,
    filter = TokenAccountsFilter.byProgramId(TOKEN_PROGRAM_ID)
)

Комісії в Solana фіксовані та крихітні (0.000005 SOL за базову транзакцію) — не потрібно вибирати gas price, що спрощує UX.

TON використовує унікальну архітектуру акторів зі смарт-контрактами на власному стеку. Адреси бувають raw (0:...) та user-friendly (EQ..., UQ...). Jetton — стандарт токенів. Для Kotlin використовуємо ton-kotlin, для iOS — swift-ton або JavaScriptCore з ton.js. Обов'язкова інтеграція TonConnect 2.0 для сумісності з Telegram Mini Apps.

let connector = TonConnect(manifestUrl: URL(string: "https://your-app.com/tonconnect-manifest.json")!)
connector.connect { result in
    // користувач підключився через TonConnect
}

Мультимережевий UI/UX: критичні рішення

Перемикання мереж. Чіткий візуальний індикатор поточної мережі на головному екрані обов'язковий. Помилка «відправив USDT на BSC-адресу замість Ethereum» коштує реальних грошей. Confirmation dialog при відправленні: «Ви відправляєте X USDT в мережі BSC на адресу 0x...». EVM-мережі — одна адреса, але баланси різні: ETH на Ethereum ≠ ETH на BSC. Bridging частий запит — інтеграція через SDK або iframe WebView з попередженням про ризики.

Баланси в нативних токенах малоінформативні без USD-конвертації. CoinGecko API — безкоштовний до ліміту, покриває всі основні токени. DeFiLlama — альтернатива. CoinMarketCap — платний, але надійніший. Кешуємо ціни на сервері з TTL 60 секунд.

Як забезпечити безпеку мультичейн-гаманця

Trust WalletCore знижує кількість помилок підпису в 2–3 рази порівняно з ручною реалізацією криптографії. Seed-фраза зберігається тільки в Keychain/Keystore, ніколи не передається по мережі. Кожна транзакція підписується локально. Основні загрози: address poisoning (атака зі схожими адресами), contract interaction (декодування calldata), нульові апруви ERC-20 після DeFi. Впроваджуємо управління апрувами в інтерфейсі.

Стек та інструменти

• Крос-платформа: Trust WalletCore (C++ bindings для iOS/Android).
• EVM RPC: Web3j, web3.swift, ethers.js.
• Solana: sol4k, solana-swift.
• TON: ton-kotlin, swift-ton.
• WalletConnect: офіційні SDK v2.
• TonConnect: @tonconnect/sdk.
• Flutter: wallet_core, web3dart, solana_dart, ton_dart.

Завдяки використанню Trust WalletCore та готових бібліотек ми скорочуємо час розробки на 30–40% порівняно з написанням кожної мережі з нуля. Це дозволяє заощадити бюджет без втрати якості.

Порівняння нативного та Flutter-підходу

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

1. Аналітика: ваші вимоги, вибір стеку, прототипування UI/UX.
2. Архітектура: схема деривації, інтеграція RPC, налаштування WalletConnect/TonConnect.
3. Реалізація: написання коду, підключення бібліотек, юніт-тести.
4. Тестування: TestFlight/Google Play бета, налагодження транзакцій, перевірка безпеки.
5. Деплой: публікація в App Store та Google Play, моніторинг.

Базова версія (ETH/BSC/Polygon + Solana + TON, баланси, відправлення, історія, WalletConnect та TonConnect) займає 3–4 місяці для нативної розробки iOS+Android. Додавання swap через агрегатори — ще 3–4 тижні. Вартість розраховується індивідуально після аналізу вимог.

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

• Архітектурна документація та схеми деривації ключів.
• Доступи до TestFlight та Google Play Console для тестування.
• Вихідний код з коментарями та налаштований CI/CD.
• Інтеграція WalletConnect v2 та TonConnect 2.0.
• Підтримка протягом 30 днів після публікації.

Замовте розробку мультичейн-гаманця з гарантією проходження App Store та Google Play Review. Отримайте консультацію — зв'яжіться з нами для обговорення вашого проєкту. Ми безкоштовно оцінимо вартість вашого проєкту протягом одного робочого дня.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.