Розробка системи крипто-кредитних карт

Розробка системи крипто-кредитних карт

Крипто-кредитна карта — це не просто дебетова карта з конвертацією. Це зв'язка DeFi-протоколу (залог у крипті, кредитний лімінт, liquidation engine) з традиційною платіжною інфраструктурою (BIN-спонсор, процесинг, card network). Обидві частини складні самі по собі. У зв'язці — подвійне навантаження на проектування.

Nexo, Ledn, Coinbase Card — різні реалізації однієї ідеї: користувач блокує BTC або ETH як залог, отримує кредитну лінію в USDC/USD, тратить через Visa/Mastercard. Деталі реалізації визначають фінансову стійкість та регуляторну сумісність системи.

Залоговий механізм на смарт-контрактах

Розрахунок кредитного лімінту та health factor

Логіка аналогічна Aave: LTV (loan-to-value) визначає максимальний кредит від вартості залогу. ETH з LTV 70% — $10,000 у ETH дають максимальний кредитний лімінт $7,000. Liquidation threshold — рівень, при якому починається ліквідація (зазвичай LTV + 10-15%).

function getHealthFactor(address user) external view returns (uint256) {
    uint256 collateralValueUSD = getCollateralValueUSD(user);
    uint256 borrowedValueUSD = getBorrowedValueUSD(user);
    
    if (borrowedValueUSD == 0) return type(uint256).max;
    
    return (collateralValueUSD * liquidationThreshold * 1e18) 
           / (borrowedValueUSD * 100);
}
// health factor < 1e18 → позиція unhealthy

Ціновий оракул — Chainlink з обов'язковою перевіркою staleness (updatedAt не старіший за 1 годину) та deviation check (ціна не відхиляється більше ніж на 20% від TWAP). При stale price — контракт повинен зупиняти нові займи, але дозволяти ліквідацію (інакше stale price = захист від ліквідації).

Ліквідація та margin call

При падінні health factor нижче 1.0 — позиція ліквідуєма. Але крипто-кредитна карта має особливість: користувач вже витратив кредит у фіаті. Неможливо просто сказати «верни токени» — вони конвертовані в каву та авіабілети.

Правильна система: margin call при health factor 1.2 (попередження), примусова ліквідація залогу при 1.0. Ліквідатор купує ETH-залог зі скидкою 5-10%, вирученні кошти покривають борг. Остаток повертається користувачу.

Для користувальницького досвіду: автоматичне поповнення залогу з резервного гаманця користувача або можливість внести додатковий залог через push-нотифікацію до початку примусової ліквідації.

Інтеграція з платіжною інфраструктурою

BIN-спонсор та card issuing

Visa/Mastercard не працюють напрямку з Web3-компаніями. Потрібен BIN-спонсор — ліцензований банк або фінтех з прямим членством у card network, що виробляє карти під своїм BIN від вашого імені. Популярні варіанти: Marqeta, Stripe Issuing, Solaris Bank, Railsbank.

Кожен BIN-спонсор надає API для:

• Створення віртуальних/фізичних карт
• Мониторингу транзакцій у real-time через webhooks
• Управління лімітами та блокуванням карти

Авторизаційний флоу

1. Користувач тратить $50 у магазині
2. Merchant → Card Network → BIN-спонсор → ваш authorization webhook (< 2 секунди)
3. Ваш сервіс перевіряє: достатньо ліміту кредиту?
4. Відповідь BIN-спонсору: approve або decline
5. Якщо approve — запис транзакції, оновлення використаного лімінту
6. Settlement T+1 або T+2 — реальний переводу коштів

Критично: authorization webhook повинен відповідати за < 2 секунди, інакше автоматичний timeout = decline. Вимагає синхронного читання стану (кеш Redis, не блокчейн-запит) та high-доступної інфраструктури.

Reconciliation: синхронізація on-chain та off-chain

Кредитний лімінт зберігається on-chain (у смарт-контракті), використаний кредит — і on-chain, і off-chain. Розхідження можливе при: сітьових збоях, затримках blockchain confirmation, розходженні settlement між card network та on-chain станом.

Сервіс reconciliation запускається кожні кілька хвилин: порівнює суми використаного кредиту у БД та у контракті, при розходженні — alert та manual review. Автоматичне вирівнювання тільки в сторону зменшення лімінту (ніколи не збільшувати лімінт автоматично).

Compliance та регуляторні вимоги

Крипто-кредитна карта — фінансовий продукт. У більшості юрисдикцій вимагає:

• KYC/AML для користувачів (Chainalysis, Elliptic для скринингу on-chain активності)
• Ліцензія кредитора або робота через ліцензованого партнера
• PCI DSS compliance для зберігання даних карт (зазвичай вирішується через BIN-спонсора — дані карт зберігає він)
• GDPR/локальне законодавство для даних користувачів

Регуляторна структура визначається на етапі проектування. Технічні рішення (де зберігати дані, як будувати KYC флоу) залежать від юрисдикції.

Технічний стек

Процес розробки

Архітектурний дизайн (1-2 тижні). Вибір BIN-спонсора, схема даних, залоговий механізм, compliance-структура. Без цього етапу технічні рішення доведеться переделувати після першого регуляторного консультування.

Смарт-контракти (3-6 тижнів). Collateral vault, credit line manager, liquidation engine, price oracle integration. Foundry-тести з fork mainnet, Echidna property-тести для інваріантів.

Backend та card integration (4-8 тижнів). Authorization webhook, reconciliation, KYC флоу, управління картами через BIN-спонсор API.

Тестування та аудит (3-4 тижні). Зовнішній аудит смарт-контрактів обов'язковий. Нагрузкове тестування webhook під 1000 RPS.

Орієнтири за часом

MVP з одним видом залогу (USDC, проста структура) та віртуальними картами — 3-4 місяці. Повнофункціональна платформа з мультиколлатералем, фізичними картами та автоматичною ліквідацією — від 6 місяців.

Вартість розраховується після технічної специфікації та вибору регуляторної структури.