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

Мы разрабатываем системы токен-гейтинга контента под ключ. В отличие от традиционных подписок (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'a: сравнение

Выбор модели зависит от аудитории. Например, для закрытого сообщества с высокой лояльностью подходит 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.