Що таке onchain-підписка (subscription)

Onchain-підписка — це автоматизований рекурентний платіж, умови якого зафіксовані в смарт-контракті на блокчейні. На відміну від традиційної моделі, де компанія-посередник самостійно списує кошти з картки клієнта за власним розкладом, тут розписка на списання зберігається на ланцюжку, а виконання забезпечується програмним кодом без залучення третьої сторони як ініціатора транзакції.

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

У контексті stablecoin-платежів на Solana onchain-підписки дозволяють приймати рекурентну оплату в стейблкоїнах (наприклад, USDC) без конвертації у фіат на кожному циклі. Це зменшує фрикцію для міжнародних клієнтів і усуває валютний ризик для постачальника послуги, оскільки сума підписки номінована в стабільному активі.

Механіка: рекурентні платежі через смарт-контракти

Solana не має вбудованого планувальника завдань (cron), тому рекурентні списання реалізуються через комбінацію кількох механізмів. Нижче — два основні підходи, які використовуються на практиці.

Авторизація та затвердження

Перший етап — клієнт дає смарт-контракту дозвіл на певний обсяг списань. У екосистемі Solana це зазвичай працює через делегування: користувач затверджує (approve) певну суму токенів на спеціальному акаунті, який контролюється програмою. Цей акаунт часто є PDA (Program Derived Address — похідна адреса програми, яка не має приватного ключа в людському розумінні, але може виконувати інструкції від імені контракту).

Ключовий нюанс: клієнт не передає токени безпосередньо постачальнику. Він делегує право на їх переміщення програмі, причому з обмеженнями — за сумою, за періодом або за загальним лімітом. Це принципово відрізняється від довірчого управління: смарт-контракт не може забрати більше, ніж дозволено.

Автоматичне списання за розкладом

Оскільки Solana виконує транзакції лише тоді, коли хтось їх ініціює, потрібен тригер. Існує два робочі варіанти:

  • Off-chain-релей. Сервер постачальника послуги періодично відправляє транзакцію до мережі, яка викликає смарт-контракт. Контракт перевіряє, чи минув потрібний інтервал, і якщо так — виконує переказ через CPI (Cross-Program Invocation — механізм виклику однією програмою іншої). У цьому випадку постачальник платить комісію за транзакцію (fee), але не контролює логіку списання — вона зафіксована в контракті.
  • Модель потокового розподілу (streaming). Клієнт блокує суму на певний термін (наприклад, на три місяці), а смарт-контракт щосекунди нараховує постачальнику доступну частку. Постачальник може забрати нараховане в будь-який момент. Тут взагалі не потрібен зовнішній тригер — розрахунок відбувається на рівні читання стану контракту.

Обидва підходи мають різні компроміси між централізацією, вартістю транзакцій та досвідом користувача. Вибір залежить від моделі бізнесу: для SaaS-підписок з місячним циклом частіше використовують перший варіант, для зарплатних потоків або послуг з гнучким тарифуванням — другий.

Передумови для впровадження

Перш ніж проектувати onchain-підписку, переконайтеся, що наступні умови виконані:

  • Юридична структура підписки. Токенізація платежу не створює автоматично юридичних зобов'язань. Потрібно чітко визначити, що саме купує клієнт, як діють умови відмови (refund), і як це співвідноситься з чинним законодавством у юрисдикціях, де ви працюєте. Цей момент вимагає перевірки з боку юридичного фахівця.
  • Вибір стабільного активу. Підписка має бути номінована в стейблкоїні з достатньою ліквідністю на Solana та зрозумілою моделлю забезпечення. Перевірте актуальну інформацію про резервний актив обраного стейблкоїна за первинними джерелами емітента.
  • Інфраструктура гаманця клієнта. Користувач повинен мати гаманець, що підтримує делегування токенів (SPL Token Approve). Не всі мобільні гаманці реалізують цю функцію зручним для масового користувача чином.
  • Механізм скасування. Смарт-контракт обов'язково має передбачати можливість для клієнта відкликати делегацію в будь-який момент до наступного списання. Інакше це не підписка, а довічне зобов'язання — і з юридичного, і з репутаційного погляду це неприйнятно.
  • Обробка невдалих транзакцій. На гаманці клієнта має залишатися достатньо SOL для оплати комісій мережі (якщо він ініціює скасування), а на акаунті делегації — достатньо стейблкоїнів для наступного циклу.

Очікуваний результат та як його перевірити

Після розгортання та налаштування onchain-підписки ви маєте отримати такий результат:

  • Клієнт підписав умови (off-chain або onchain) і делегував смарт-контракту ліміт у стейблкоїнах.
  • За кожен розрахунковий період контракт автоматично переміщує фіксовану суму на акаунт постачальника.
  • Клієнт може в будь-який момент переглянути стан делегації та відкликати її через інтерфейс.
  • Постачальник бачить повну історію списань на ланцюжку без залежності від виписок платіжного процесора.

Як перевірити:

  1. Створіть тестову підписку на тестовій мережі (devnet) або з мінімальною сумою на mainnet.
  2. Делегуйте контрактну програмі невелику суму стейблкоїнів.
  3. Дочекайтеся одного повного циклу списання (або імітуйте його через off-chain-релей, якщо використовуєте цю модель).
  4. Перевірте баланси: акаунт делегації має зменшитися на суму підписки, акаунт постачальника — збільшитися.
  5. Ініціюйте скасування підписки та переконайтеся, що делегація відкликана, а наступне списання не відбулося.
  6. Перевірте історію транзакцій у блокчейн-експлорері — кожне списання має бути окремою транзакцією з посиланням на контрактну програму.

Типові помилки при налаштуванні

  • Надмірна делегація. Деякі реалізації просять клієнта делегувати всю суму на весь термін підписки одразу. Це створює ризик концентрації коштів на контрактному акаунті та знижує довіру. Безпечніша практика — делегувати по одному циклу або встановлювати жорсткий ліміт.
  • Відсутність механізму поновлення делегації. Якщо клієнт делегував суму на три цикли, а на четвертий делегація закінчилася — підписка просто зупиняється без сповіщення. Контракт або інтерфейс мають явно сигналізувати про необхідність поновлення.
  • Ігнорування комісій мережі. Якщо списання ініціює постачальник через релей, він платить fee за кожну транзакцію. При великій кількості підписників з малими сумами це може зробити модель економічно нежиттєздатною. Рахуйте економіку до розгортання.
  • Жорстке прив'язування до одного стейблкоїна. Якщо контракт працює лише з одним активом, міграція на інший стейблкоїн (у разі проблем із поточним) вимагатиме повного перерозгортання. Продумайте архітектуру так, щоб підтримка нового токена була можливою без зміни контракту.
  • Нечіткий статус підписки в інтерфейсі. Клієнт має бачити: активна підписка, призупинена через нестачу коштів, скасована, завершена. Якщо інтерфейс не відображає стан делегації, підтримка стане основним каналом комунікації — що не масштабується.

Ризики: відмова платежу, волатильність підлеглого активу

Відмова платежу (payment failure). У традиційних системах відмова означає недостатність коштів на рахунку або блокування з боку банку. В onchain-моделі відмова виникає, коли на акаунті делегації недостатньо токенів у момент списання. Смарт-контракт не може «спробувати пізніше» самостійно — потрібен новий зовнішній виклик. Це означає, що бізнес повинен реалізувати логіку повторних спроб (retry) на рівні off-chain-релея або чітко визначити, що один пропущений цикл автоматично скасовує підписку.

Волатильність підлеглого активу. Хоча стаття розглядає stablecoin-платежі, важливо розуміти: жоден стейблкоїн не є абсолютно стабільним за визначенням. Девіація навіть на 1–2% може бути критичною для підписок з великими оборотами. Крім того, можливі технічні інциденти з боку емітента (пауза контракту, заморожування резервів). Мінімізація цього ризику — у виборі стейблкоїнів з прозорою та регулярно аудитованою структурою забезпечення, а також у можливості швидкої міграції на інший актив.

Регуляторний ризик. Автоматизовані рекурентні платежі в криптоактивах перебувають у сірій зоні в багатьох юрисдикціях. Залежно від того, що саме ви надаєте в обмін на підписку (доступ до сервісу, фінансовий інструмент, токен-гovernance), це може підпадати під різні регуляторні режими. Цей аспект вимагає індивідуальної юридичної оцінки під вашу конкретну модель бізнесу та юрисдикції присутності.

Наступний крок: вибір платформи

Після розуміння механіки onchain-підписок наступне логічне рішення — обрати інструментарій для реалізації. Є три напрямки:

  • Готові протоколи підписок на Solana. Відкриті смарт-контракти, які вже реалізують делегування, розклади та скасування. Ви інтегруєтеся через їхнє API або SDK. Переваги — швидкий запуск, перевірена безпека. Обмеження — залежність від стороннього протоколу, менша гнучкість у бізнес-логіці.
  • Власний контракт на Anchor. Розробка з нуля дає повний контроль над логікою, комісіями, умовами скасування та інтеграцією з вашою системою. Підходить, якщо підписка — ключова частина продукту з нестандартними правилами (градуйовані тарифи, usage-based моделі, динамічні знижки).
  • Гібридна модель. Використання готового контракту для базової делегації та списання, але з власним off-chain-сервісом для білінгу, сповіщень та аналітики.

Критерії вибору залежать від обсягу транзакцій, необхідної кастомізації, наявності розробницьких ресурсів та готовності нести відповідальність за аудит власного контракту. Якщо ви ще не визначилися, чи взагалі потрібна вашому бізнесу інтеграція з Solana на цьому етапі, перейдіть до наступного матеріалу: Коли бізнесу потрібна інтеграція Solana.

Джерела