Мы разрабатываем системы токен-гейтинга контента под ключ. В отличие от традиционных подписок (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 стейкинг — самый простой вариант, но он замораживает ликвидность пользователя.
| Модель | Тип подписки | Перепродажа | Газ при mint | Роялти |
|---|---|---|---|---|
| ERC-721 | Пожизненная / ограниченная | Да | Высокий | ERC-2981 |
| ERC-1155 | Временная (по периодам) | Нет | Средний (batch - низкий) | Нет |
| 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: сравнение
| Модель | Доход | Сложность реализации | Пример использования |
|---|---|---|---|
| Flat (фиксированная) | Предсказуемый | Низкая | Новостные рассылки |
| Tiered access | Максимальный при сегментации | Средняя | Образовательные платформы |
| Pay-per-content | Низкий порог входа | Высокая | Премиум-статьи |
| NFT membership | Роялти при перепродаже | Средняя | Закрытые сообщества |
Выбор модели зависит от аудитории. Например, для закрытого сообщества с высокой лояльностью подходит NFT membership, а для массового контента — tiered access.
Что входит в нашу работу
- Анализ модели монетизации и выбор оптимального стандарта токенов.
- Разработка и аудит смарт-контрактов (Solidity, Foundry) с покрытием тестами, включая fuzzing через Echidna.
- Интеграция децентрализованного шифрования (Lit Protocol / Threshold).
- Настройка IPFS-шлюза и системы раздачи ключей.
- Создание пользовательского интерфейса (React + wagmi/viem, RainbowKit).
- Подключение автопродления через Chainlink Automation.
- Развертывание в выбранной сети (Ethereum, Polygon, Arbitrum, Base).
- Техническая документация и обучение команды.
- Поддержка после запуска.
Опыт и гарантии
Мы реализовали 15+ проектов в области DeFi, NFT и токенизации контента. Используем собственные библиотеки проверенных смарт-контрактов, что сокращает риски и время разработки. Гарантируем стабильность работы благодаря fuzzing-тестированию (Echidna) и мониторингу on-chain. По статистике, наши клиенты экономят до 30% на газе за счёт оптимизации batch-операций — при объёме в $10 000 ежемесячных транзакций это $3 000 экономии.
Сроки разработки
Базовая система подписок с одним тиром, интеграцией Lit Protocol и простым фронтендом — от 4 до 6 недель. Полноценная платформа с tiered access, NFT membership, auto-renewal и аналитикой для creator'а — от 10 до 14 недель. Точные сроки зависят от сложности интеграций и объёма функционала.
Свяжитесь с нами для получения консультации и оценки вашего проекта. Мы поможем спроектировать и внедрить систему подписок под ваш кейс. Закажите анализ вашей модели монетизации — это займёт не больше часа. Подробнее о стандартах можно прочитать в Wikipedia об ERC-1155.