Разработка мобильного приложения для крипто-кредитования (Lending)
Мы часто сталкиваемся с запросами на создание мобильных продуктов для крипто-кредитования. Это сложная техническая задача: приложение должно в реальном времени отображать залоговые позиции, считать Health Factor, отправлять уведомления о риске ликвидации и взаимодействовать с DeFi-протоколами. Ошибка в расчётах или задержка данных может стоить пользователю денег. Обратитесь к нам, чтобы избежать типовых ошибок на старте.
Почему крипто-кредитование требует тщательной разработки?
Health Factor и ликвидация
Health Factor = (Collateral × Liquidation Threshold) / Borrowed Amount. Если HF падает ниже 1 — позиция ликвидируется. Это нужно показывать пользователю в реальном времени с визуальным индикатором — не просто числом, а шкалой с зонами: безопасно (зелёный, HF > 1.5), риск (жёлтый, 1.1–1.5), критично (красный, < 1.1).
Цена залогового актива меняется каждые несколько секунд. Значит, HF надо пересчитывать на клиенте при каждом обновлении цены — через Chainlink Price Feeds или CEX WebSocket. Важно не нагружать сервер polling'ом каждые 2 секунды со стороны тысяч клиентов; разумно подписаться на WebSocket от Binance (wss://stream.binance.com:9443/ws/ethusdt@ticker) и считать HF локально.
// Расчёт Health Factor на клиенте struct LendingPosition { let collateralUSD: Decimal // стоимость залога в USD let liquidationThreshold: Decimal // например, 0.82 для ETH let borrowedUSD: Decimal // сумма долга в USD var healthFactor: Decimal { guard borrowedUSD > 0 else { return Decimal.greatestFiniteMagnitude } return (collateralUSD * liquidationThreshold) / borrowedUSD } var riskLevel: RiskLevel { switch healthFactor { case ..<1.1: return .critical case 1.1..<1.5: return .warning default: return .safe } } } Push-уведомление при HF < 1.2 — обязательная функция. Без неё пользователь не узнает о ликвидации. Реализуем через воркер на сервере, который мониторит позиции через смарт-контракт события (LiquidationCall event в ABI протокола) или через протокольный API (если Aave, Compound), и рассылает push через FCM/APNs при достижении порогов.
Как подключиться к DeFi-протоколу?
Если строим на основе существующего DeFi-протокола — Aave V3, Compound V3, Morpho — используем их SDK: Aave V3 (пакеты @aave/contract-helpers и @aave/math-utils через JavaScript bridge или бэкенд), Compound (compound-js или прямые вызовы через web3j / web3.swift).
Для нативных iOS/Android приложений без React Native удобнее держать всю Web3 логику на бэкенде и экспонировать её через REST API: клиент не знает об ABI, он просто делает POST /positions/deposit или GET /positions/{id}.
| Протокол | SDK/Инструменты | Особенности |
|---|---|---|
| Aave V3 | @aave/contract-helpers + math-utils | L2-оптимизация, порталы, eMode |
| Compound V3 | compound-js, web3j | Кастомизируемые пулы, базовая ставка |
| Morpho | собственная библиотека | Peer-to-peer matching, низкие комиссии |
// Android: отображение позиции через Jetpack Compose @Composable fun PositionCard(position: LendingPosition, currentPrice: BigDecimal) { val updatedPosition = position.copy( collateralUSD = position.collateralAmount * currentPrice ) Card( colors = CardDefaults.cardColors( containerColor = when (updatedPosition.riskLevel) { RiskLevel.CRITICAL -> MaterialTheme.colorScheme.errorContainer RiskLevel.WARNING -> Color(0xFFFFF3E0) RiskLevel.SAFE -> MaterialTheme.colorScheme.surfaceVariant } ) ) { Column(modifier = Modifier.padding(16.dp)) { Text("Залог: ${updatedPosition.collateralUSD.formatUSD()}") Text("Долг: ${updatedPosition.borrowedUSD.formatUSD()}") HealthFactorBar(hf = updatedPosition.healthFactor) } } } Как рассчитываются процентные ставки и APY?
Ставки в протоколах DeFi динамические — меняются в зависимости от utilization rate пула. Нужно обновлять их в UI каждые несколько минут. Для кастодиальных платформ (Nexo, BlockFi-подобные) ставки задаются административно и меняются реже.
APY vs APR — показываем оба. Пользователи путаются: APR 8% ≠ APY 8%. APY с учётом компаундинга выше. Формула: APY = (1 + APR/n)^n - 1, где n — количество периодов начисления в год. Мы гарантируем точность расчётов с верификацией на тестнете.
Транзакции и газ
При взаимодействии с EVM-смарт-контрактами каждое действие — это on-chain транзакция. Deposit, borrow, repay, withdraw — каждая стоит газ. Перед отправкой показываем пользователю оценку газа через eth_estimateGas и текущую цену из eth_gasPrice или EIP-1559 eth_maxFeePerGas. Наш опыт показывает, что использование L2 (Arbitrum, Optimism, Base) снижает затраты на газ до 40-60%, что критично для частых операций. Экономия на газе при использовании L2 может достигать 60%, что для активного пользователя означает сотни долларов в месяц — в некоторых случаях до $300–$500 ежемесячно.
Верификация и compliance
KYC через SumSub или Veriff для регулируемых платформ. Ограничения по юрисдикциям — пользователи из США не могут использовать большинство DeFi-платформ без регистрации в SEC. Геофильтрация по IP на сервере, дополнительно — проверка при регистрации. Мы оказываем поддержку по настройке compliance-модуля.
Что входит в работу
- Документация по API и архитектуре
- Исходные коды приложений iOS/Android
- Настройка CI/CD и деплой в магазины приложений
- Доступы к бэкенд-админке и мониторингу
- Обучение команды заказчика (2 сессии)
Сроки и стоимость
| Этап | Срок |
|---|---|
| Архитектура: DeFi-протокол или кастодиальная схема | 3–5 дней |
| Смарт-контракты или интеграция с протоколом | 1–3 недели |
| Серверная часть (позиции, цены, уведомления) | 2 недели |
| Мобильный клиент iOS + Android | 3–4 недели |
| Тестирование на testnet | 1 неделя |
Итого: 8–12 недель. Стоимость такого проекта варьируется в зависимости от сложности интеграций и количества поддерживаемых сетей. Мы оценим ваш проект после анализа требований — закажите консультацию, и мы предложим оптимальную архитектуру.
Пошаговый процесс разработки
- Анализ и выбор протокола (Aave, Compound, Morpho)
- Проектирование API и архитектуры приложения
- Разработка смарт-контрактов (если нужно) или интеграция SDK
- Создание мобильного клиента для iOS и Android
- Тестирование на testnet и аудит безопасности
- Деплой и мониторинг
Типичные проблемы при интеграции — неверная подпись транзакций из-за несовместимости WalletConnect, устаревшие ABI после обновления протокола, задержки при получении данных с WebSocket, проблемы с геофильтрацией на стороне клиента. Наш опыт позволяет избежать этих ошибок на этапе проектирования.
Свяжитесь с нами, чтобы получить консультацию по вашему проекту. Мы гарантируем безопасность и соблюдение всех требований App Store Review Guidelines (Section 4.2/5.1) и Google Play Console. Получите консультацию — мы поможем выбрать подходящий стек и избежать типовых ошибок.