Розробка системи підписок на контент за токени з автоподовженням

Ми розробляємо системи токен-гейтингу контенту під ключ. На відміну від традиційних підписок (Patreon, Medium), де управління доступом централізоване і creator платить комісію платформі (до 12%), наше рішення базується на смарт-контрактах. Платежі проходять безпосередньо від підписника до автора, а доступ до контенту верифікується on-chain. Реалізація такої схеми вимагає вирішення кількох технічних викликів: шифрування контенту з доступом лише для підписників, автоматичне продовження підписки та організація tiered access без зайвих газових витрат. Нижче розберемо архітектуру, яку ми використовуємо в продакшені — від вибору стандарту токена до інтеграції децентралізованого шифрування. Наш стек: Solidity 0.8.x, Foundry, Lit Protocol, IPFS, Chainlink Automation. Наводяться конкретні приклади коду та конфігів.

Як обрати оптимальний стандарт токена для підписки?

Кожен стандарт вирішує свою задачу. ERC-1155 став індустріальним стандартом для тимчасових підписок: він використовує batch transfer та динамічну генерацію tokenId на основі періоду, знижуючи газові витрати на 30–50% порівняно з ERC-721 при масових продовженнях. ERC-721 краще підходить для довічних NFT-членств з можливістю перепродажу та роялті за ERC-2981. ERC-20 стейкінг — найпростіший варіант, але він заморожує ліквідність користувача.

Приклад структури контракту підписки:

contract ContentSubscription { struct SubscriptionTier { uint256 pricePerMonth; // в wei або ERC-20 токенах address paymentToken; // address(0) = native ETH uint256 maxSubscribers; // 0 = unlimited string contentCID; // IPFS CID для зашифрованого контенту bytes32 encryptionKeyHash; // хеш ключа шифрування для цього тиру } struct Subscription { uint256 tierId; uint256 expiresAt; uint256 startedAt; bool autoRenew; } mapping(uint256 => SubscriptionTier) public tiers; mapping(address => mapping(uint256 => Subscription)) public subscriptions; address public creator; uint256 public platformFeeBps = 250; // 2.5% modifier onlyCreator() { require(msg.sender == creator, "Not creator"); _; } function subscribe(uint256 tierId, uint256 months, bool autoRenew) external payable { SubscriptionTier memory tier = tiers[tierId]; uint256 totalCost = tier.pricePerMonth * months; if (tier.paymentToken == address(0)) { require(msg.value >= totalCost, "Insufficient ETH"); } else { IERC20(tier.paymentToken).transferFrom(msg.sender, address(this), totalCost); } Subscription storage sub = subscriptions[msg.sender][tierId]; // Продовження існуючої або нова підписка uint256 currentExpiry = sub.expiresAt > block.timestamp ? sub.expiresAt : block.timestamp; sub.expiresAt = currentExpiry + months * 30 days; sub.tierId = tierId; sub.autoRenew = autoRenew; if (sub.startedAt == 0) sub.startedAt = block.timestamp; _distributeRevenue(tier, totalCost); emit Subscribed(msg.sender, tierId, sub.expiresAt); } function isSubscribed(address user, uint256 tierId) external view returns (bool) { return subscriptions[user][tierId].expiresAt > block.timestamp; } function _distributeRevenue(SubscriptionTier memory tier, uint256 amount) internal { uint256 platformFee = amount * platformFeeBps / 10000; uint256 creatorAmount = amount - platformFee; if (tier.paymentToken == address(0)) { payable(creator).transfer(creatorAmount); payable(platform).transfer(platformFee); } else { IERC20(tier.paymentToken).transfer(creator, creatorAmount); IERC20(tier.paymentToken).transfer(platform, platformFee); } } } 

Як захистити контент від неавторизованого доступу?

Зберігати контент on-chain неможливо і безглуздо. Стандартна схема: контент шифрується і завантажується в IPFS, ключ шифрування видається лише верифікованим підписникам. Проблема: хто видає ключ? Якщо централізований сервер — немає сенсу в блокчейні. Рішення — Lit Protocol або Threshold Network: децентралізована мережа нод зберігає ключові шарди і видає доступ лише при виконанні on-chain умови. Реалізація на JavaScript:

import { LitNodeClient, checkAndSignAuthMessage } from '@lit-protocol/lit-node-client'; // Умова доступу: активна підписка на тир 1 const accessControlConditions = [ { contractAddress: SUBSCRIPTION_CONTRACT_ADDRESS, standardContractType: '', chain: 'ethereum', method: 'isSubscribed', parameters: [':userAddress', '1'], // tierId = 1 returnValueTest: { comparator: '=', value: 'true' } } ]; // Шифрування контенту (виконується creator'ом при завантаженні) async function encryptContent(content) { const client = new LitNodeClient(); await client.connect(); const authSig = await checkAndSignAuthMessage({ chain: 'ethereum' }); const { encryptedString, symmetricKey } = await LitJsSdk.encryptString(content); const encryptedSymmetricKey = await client.saveEncryptionKey({ accessControlConditions, symmetricKey, authSig, chain: 'ethereum' }); return { encryptedContent: encryptedString, encryptedKey: encryptedSymmetricKey }; } // Розшифровка (користувач при читанні) async function decryptContent(encryptedContent, encryptedKey) { const client = new LitNodeClient(); await client.connect(); const authSig = await checkAndSignAuthMessage({ chain: 'ethereum' }); const symmetricKey = await client.getEncryptionKey({ accessControlConditions, toDecrypt: encryptedKey, chain: 'ethereum', authSig }); return await LitJsSdk.decryptString(encryptedContent, symmetricKey); } 

Чому Chainlink Automation — стандарт для автоподовження?

Автоподовження підписки вимагає зовнішнього тригера — смарт-контракт не може сам себе викликати за розкладом. Chainlink Automation (колишній Keepers) перевіряє умову checkUpkeep() і викликає performUpkeep() при необхідності:

contract AutoRenewSubscription is AutomationCompatibleInterface { function checkUpkeep(bytes calldata) external view override returns (bool upkeepNeeded, bytes memory performData) { // Знайти підписки, що закінчуються, з autoRenew=true address[] memory toRenew = _findExpiringSubscriptions(); upkeepNeeded = toRenew.length > 0; performData = abi.encode(toRenew); } function performUpkeep(bytes calldata performData) external override { address[] memory toRenew = abi.decode(performData, (address[])); for (uint256 i = 0; i < toRenew.length; i++) { _attemptRenewal(toRenew[i]); } } function _attemptRenewal(address subscriber) internal { // Спроба списати кошти, якщо баланс достатній // При невдачі — подія, сповіщення користувача } } 

Chainlink Automation дешевший і надійніший за ручний виклик — він автоматизує продовження, знижуючи навантаження на користувача. Альтернативи (Gelato) теж працюють, але Chainlink дає більш щільну інтеграцію з екосистемою Ethereum.

Моделі монетизації для creator'а: порівняння

Вибір моделі залежить від аудиторії. Наприклад, для закритої спільноти з високою лояльністю підходить NFT membership, а для масового контенту — tiered access.

Що входить в нашу роботу

• Аналіз моделі монетизації та вибір оптимального стандарту токенів.
• Розробка та аудит смарт-контрактів (Solidity, Foundry) з покриттям тестами, включаючи fuzzing через Echidna.
• Інтеграція децентралізованого шифрування (Lit Protocol / Threshold).
• Налаштування IPFS-шлюзу та системи роздачі ключів.
• Створення користувацького інтерфейсу (React + wagmi/viem, RainbowKit).
• Підключення автоподовження через Chainlink Automation.
• Розгортання в обраній мережі (Ethereum, Polygon, Arbitrum, Base).
• Технічна документація та навчання команди.
• Підтримка після запуску.

Терміни розробки

Базова система підписок з одним тиром, інтеграцією Lit Protocol та простим фронтендом — від 4 до 6 тижнів. Повноцінна платформа з tiered access, NFT membership, auto-renewal та аналітикою для creator'а — від 10 до 14 тижнів. Точні терміни залежать від складності інтеграцій та обсягу функціоналу.

Зв'яжіться з нами для отримання консультації та оцінки вашого проекту. Ми допоможемо спроектувати та впровадити систему підписок під ваш кейс. Замовте аналіз вашої моделі монетизації — це займе не більше години. Докладніше про стандарти можна прочитати у Wikipedia про ERC-1155.