Сборка крипто-кредитної картки: чому ламаються ліквідації. Коли користувач витрачає кредитний ліміт, а ціна застави падає — секунди вирішують все. Якщо Chainlink oracle не встиг оновити ціну, ліквідація може пропустити момент, і позиція стане непокритою. На тестових даних при волатильності 5% за хвилину затримка в 30 секунд перетворювала здорову позицію на збиток у $1000. Рішення — комбінація кількох оракулів та fallback-алгоритму на базі TWAP. Ми спеціалізуємося на розробці DeFi продуктів понад 10 років. Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо вимоги та запропонуємо архітектуру.
Як розробити систему крипто-кредитних карток?
Крипто-кредитна картка — це зв'язка DeFi-протоколу (застава в крипті, кредитний ліміт, liquidation engine) з традиційною платіжною інфраструктурою (BIN-спонсор, процесинг, card network). Обидві частини складні самі по собі. У зв'язці — подвійне навантаження на проектування. Ключові компоненти: заставний механізм, інтеграція з платіжною мережею, compliance.
Заставний механізм на смарт-контрактах
Розрахунок кредитного ліміту та 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 check (updatedAt не старше 1 години) та deviation check (ціна не відхиляється більш ніж на 20% від TWAP). Згідно документації Chainlink, stale price має оброблятися примусовою зупинкою нових позик, але дозволом ліквідації (інакше stale price = захист від ліквідації).
Роль health factor
Health factor — індикатор безпеки позиції. Якщо він падає нижче 1.0, позиція ліквідується. Автоматичні margin call при 1.2 запобігають втратам. Це в 3 рази швидше ручного моніторингу, що критично для волатильних ринків.
Ліквідація та margin call
При падінні health factor нижче 1.0 — позиція ліквідовна. Але крипто-кредитна картка має особливість: користувач вже витратив кредит у фіаті. Не можна просто сказати «поверни токени» — вони конвертовані в каву та авіаквитки.
Правильна система: margin call при health factor 1.2 (попередження), примусова ліквідація застави при 1.0. Ліквідатор купує ETH-заставу зі знижкою 5-10%, виручені кошти покривають борг. Залишок повертається користувачеві. Наприклад, при заставі $10,000 та падінні ціни на 15% ліквідація може призвести до втрати $1,500, якщо не спрацює margin call.
Для користувацького досвіду: автоматичне поповнення застави з резервного гаманця користувача або можливість внести додаткову заставу через push-сповіщення до початку примусової ліквідації.
Типові помилки при проектуванні ліквідацій
- Використання одного оракула без fallback — ризик stale price.
- Занадто великий інтервал оновлення oracle — ліквідації не встигають.
- Відсутність перевірки health factor на кожен authorization webhook — можна витратити більше ліміту.
- Неправильний розрахунок discount для ліквідатора — відсутність стимулів.
Інтеграція з платіжною інфраструктурою
Як працює інтеграція з BIN-спонсором?
Visa/Mastercard не працюють напряму з Web3-компаніями. Потрібен BIN-спонсор — ліцензований банк або фінтех з прямим членством у card network, який випускає картки під своїм BIN від вашого імені. Популярні варіанти: Marqeta, Stripe Issuing, Solaris Bank, Railsbank.
Кожен BIN-спонсор надає API для card issuing:
- Створення віртуальних/фізичних карток
- Моніторингу транзакцій у real-time через webhooks
- Управління лімітами та блокуванням картки
Авторизаційний флоу
- Користувач витрачає $50 у магазині
- Merchant -> Card Network -> BIN-спонсор -> ваш authorization webhook (< 2 секунди)
- Ваш сервіс перевіряє наявність достатнього кредитного ліміту.
- Відповідь BIN-спонсору: approve або decline
- Якщо approve — запис транзакції, оновлення використаного ліміту
- Settlement T+1 або T+2 — реальний переказ коштів
Критично: authorization webhook має відповідати за < 2 секунд, інакше автоматичний timeout = decline. Це вимагає синхронного читання стану (кеш Redis, не блокчейн-запит) та високодоступної інфраструктури.
Reconciliation: синхронізація on-chain та off-chain
Кредитний ліміт зберігається on-chain (у смарт-контракті), використаний кредит — і on-chain, і off-chain. Розбіжність можлива при: мережевих збоях, затримках blockchain confirmation, розбіжності settlement між card network та on-chain станом. Наприклад, розбіжність у $50 може бути автоматично скоригована сервісом reconciliation.
Сервіс reconciliation запускається кожні кілька хвилин: порівнює суми використаного кредиту в БД та в контракті, при розбіжності — alert та manual review. Автоматичне вирівнювання тільки в сторону зменшення ліміту (ніколи не збільшувати ліміт автоматично).
Compliance та регуляторні вимоги
Крипто-кредитна картка — фінансовий продукт. У більшості юрисдикцій вимагає:
- KYC/AML для користувачів (Chainalysis, Elliptic для скринінгу on-chain активності)
- Ліцензія кредитора або робота через ліцензованого партнера
- PCI DSS compliance для зберігання даних карток (зазвичай вирішується через BIN-спонсора — дані карток зберігає він)
- GDPR/локальне законодавство для даних користувачів
Регуляторна структура визначається на етапі проектування. Технічні рішення (де зберігати дані, як будувати KYC флоу) залежать від юрисдикції.
Технічний стек
| Шар | Технології |
|---|---|
| Смарт-контракти | Solidity, Foundry, OpenZeppelin |
| Oracle | Chainlink, Pyth |
| Backend | Node.js / Go, PostgreSQL, Redis |
| Card issuing | Marqeta / Stripe Issuing API |
| KYC | Sumsub / Onfido |
| Моніторинг | Tenderly, Datadog |
Процес розробки
Архітектурний дизайн (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.
Що входить у розробку крипто-кредитної картки?
- Архітектурна документація та вибір стеку
- Розробка та тестування смарт-контрактів
- Інтеграція з BIN-спонсором та платіжними системами
- Налаштування моніторингу та алертингу
- Підтримка на етапі запуску та навчання команди
- Гарантія на код за договором
Орієнтири за строками
| Етап | Тривалість |
|---|---|
| Архітектурний дизайн | 1-2 тижні |
| Смарт-контракти | 3-6 тижнів |
| Backend + card integration | 4-8 тижнів |
| Тестування та аудит | 3-4 тижні |
MVP з одним видом застави (USDC, проста структура) та віртуальними картками — 3-4 місяці. Повноцінна платформа з мультиколатералем, фізичними картками та автоматичною ліквідацією — від 6 місяців.
Вартість розраховується після технічної специфікації та вибору регуляторної структури. Замовте проектування вашої крипто-кредитної платформи — ми оцінимо архітектуру та запропонуємо roadmap.







