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

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

Крипто-кредитная карта — это не просто дебетовая карта с конвертацией. Это связка 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 check (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, не блокчейн-запрос) и высоко-доступной инфраструктуры.

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 месяцев.

Стоимость рассчитывается после технической спецификации и выбора регуляторной структуры.