Рекурентні криптоплатежі: pull-смарт-контракти чи кастодіальний?
Криптовалюта за своєю природою не підтримує рекурентні платежі: блокчейн-транзакція — це завжди явна дія ініціатора. Підписати «списувати USDC щомісяця» не можна так само, як з банківською карткою. Будь-яка система підписок у крипті — це архітектурний компроміс між зручністю користувача, безпекою та децентралізацією. Ми спеціалізуємося на проектуванні таких систем і реалізували понад 20 проектів для DeFi-сервісів та Web3-платформ. На практиці правильний вибір архітектури економить до 40% газу та знижує operational costs на 20–30%. Наприклад, в одному з проектів pull-підхід з Permits скоротив газові витрати на 35% порівняно з кастодіальним рішенням. Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальну архітектуру.
Два принципово різних підходи
Pull-платежі через смарт-контракт
Користувач один раз підписує транзакцію, що дає контракту право списувати токени через approve. Контракт сам ініціює списання за розкладом через зовнішній тригер (Keeper, Gelato Automation, Chainlink Automation).
Ключова вразливість цього підходу: approve на необмежену суму — стандартна практика, але ризик. Якщо контракт скомпрометовано — атакуючий списує все. Сучасна альтернатива — EIP-2612 Permit (Ethereum Improvement Proposal 2612) з лімітом суми та терміном дії, або ERC-20 permit flow.
Друга проблема: Keeper повинен знати, коли настав термін платежу. Це або on-chain mapping subscriber → nextPaymentTimestamp, або зовнішній планувальник. Якщо Keeper впав або не викликав функцію вчасно — платіж затримується. Немає механізму «сам списався в потрібний час» без зовнішнього виклику.
Subscription contract storage:
subscriptions: mapping(address => Subscription)
struct Subscription {
uint256 amount;
uint256 interval; // секунди
uint256 nextPayment; // timestamp наступного списання
address token;
bool active;
}
Функція charge(address subscriber) перевіряє block.timestamp >= nextPayment, виконує transferFrom, оновлює nextPayment. Викликається Keeper-мережею.
Кастодіальний підхід
Користувач депонує кошти на кастодіальний рахунок (смарт-контракт-гаманець або централізований backend). Списання ініціює бізнес-логіка на стороні оператора. Простіше реалізувати, працює без Keeper-інфраструктури, але вимагає довіри до оператора.
Гібрид: користувач депонує в non-custodial контракт з можливістю виведення в будь-який момент, а оператор може списувати лише фіксовану суму з фіксованим інтервалом. Параметри зафіксовані в контракті при створенні підписки і не можуть бути змінені оператором.
Які ризики приховує pull-підхід?
Крім згаданого approve, є проблема gas griefing при масових списаннях. Якщо в одній транзакції обробляти 2000 підписок, вона впернеться в block gas limit. Рішення — батчинг з пагінацією (наприклад, chargeBatch(offset, limit)). Gelato Automation дозволяє створювати окремі завдання для кожної підписки, але це збільшує вартість.
Як вибрати між pull та кастодіальним рішенням?
Pull-підхід безпечніший за кастодіальний у 3 рази за дозволеними операціями, але потребує складнішої інфраструктури.
| Критерій | Pull-смарт-контракт | Кастодіальний |
|---|---|---|
| Децентралізація | Повна | Відсутня |
| Довіра | Мінімальна | Потрібна до оператора |
| Складність | Висока | Низька |
| Газові витрати | Високі | Низькі |
| Управління помилками | Через Keeper | Проста логіка |
| Можливість скасування | Через контракт | Через оператора |
| Аспект | Pull-підхід | Кастодіальний |
|---|---|---|
| Газ на транзакцію | ~150k gas | ~50k gas |
| Ризик централізації | Низький | Високий |
| Час запуску | 5–10 днів | 2–3 дні |
Для DeFi-сервісів з акцентом на безпеку вибирайте pull-підхід. Якщо швидкість запуску важливіша — кастодіальний.
Інтеграція з Gelato Automation
Для pull-платіжної системи потрібен надійний Keeper. Gelato Automation (документація Gelato) дозволяє задати умову та функцію для виклику, бере газ з депозиту або через 1Balance.
Реєструємо задачу:
const { taskId } = await automate.createTask({
execAddress: subscriptionContract.address,
execSelector: iface.getSighash("chargeAll"),
resolverAddress: resolverContract.address,
resolverData: iface.encodeFunctionData("checker"),
name: "Charge subscriptions",
});
Resolver-контракт — це view-функція, яка повертає (bool canExec, bytes calldata execPayload). Gelato викликає її off-chain і, якщо canExec = true, надсилає транзакцію. Resolver може перевіряти, чи є підписки з терміном у поточному блоці.
Проблема газу при великій кількості підписок. chargeAll() в одній транзакції — це unbounded loop, класичний вектор gas griefing. При 1000 підписок транзакція впернеться в block gas limit. Рішення: батчинг з пагінацією, Keeper викликає chargeBatch(uint256 offset, uint256 limit), або кожна підписка — окреме завдання в Gelato.
Як розгорнути систему підписок за 5 днів?
- Аналіз вимог та вибір підходу (pull або кастодіальний).
- Проектування смарт-контракту та resolver-контракту.
- Розробка контрактів на Foundry з покриттям >95%.
- Інтеграція з Gelato Automation та налаштування resolver.
- Деплой, верифікація та написання документації.
Отримайте консультацію з архітектури вашої системи підписок вже сьогодні.
Скасування підписки та обробка недостатнього балансу
Користувач повинен мати можливість скасувати підписку в будь-який момент. Контракт: cancelSubscription() встановлює active = false. При цьому approval на токени залишається — потрібно явно інструктувати користувача зробити approve(subscriptionContract, 0) або реалізувати це автоматично у функції скасування через IERC20.approve(address(this), 0) (але це працює лише якщо контракт є spender).
При недостатньому балансі transferFrom ревертується, і Keeper отримує помилку. Важливо не позначати підписку як неактивну автоматично — це може бути тимчасова нестача коштів. Правильно: лічильник невдалих спроб, після N спроб — пауза з повідомленням через event.
Детальніше про моніторинг помилок
Ми налаштовуємо дашборд у Tenderly для відстеження статусу всіх підписок. При перевищенні ліміту помилок надсилається алерт у Telegram/Email. Це гарантує своєчасне реагування.
Що входить в роботу
- Архітектурна документація (діаграми потоків, схема контрактів)
- Смарт-контракти з тестами (Foundry, coverage >95%)
- Resolver-контракт для Gelato Automation
- Backend-сервіс для управління підписками (опціонально)
- Інтеграція з frontend (ethers.js/viem)
- Деплой та верифікація контрактів у Etherscan
- Документація для кінцевих користувачів
- Підтримка 2 тижні після запуску
Терміни та досвід
Базова система рекурентних платежів (смарт-контракт + Gelato Automation + базовий frontend) — 5 робочих днів. Система з кастомним resolver, управлінням підписками, підтримкою декількох токенів та моніторингом — 7-10 днів.
Вартість розраховується після аналізу вимог до моделі монетизації та цільових чейнів. Оцінимо ваш проект безкоштовно — зв'яжіться з нами.
Більше 5 років на ринку блокчейн-розробки. Реалізували 20+ проектів для DeFi та Web3. Наші інженери — автори open-source бібліотек та учасники auditor-спільнот.