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

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