Представьте: у вас сайт с премиум-аналитикой, видео-курсами или закрытым сообществом. Вы хотите дать доступ только владельцам вашего NFT-коллекции или определённого количества токенов ERC-20. Но как это сделать надёжно, без утечки данных и с минимальными затратами на RPC? Мы реализуем серверную проверку баланса с кешированием и инвалидацией по блокчейн-событиям — готовое решение за 3–5 дней.
Почему серверная проверка обязательна?
Token-gating — не просто проверка баланса на фронтенде. Клиентская проверка легко обходится через DevTools. Нужна серверная валидация, но каждый RPC-вызов платный (около $0.0001–0.01 на Ethereum Mainnet). Без кеширования при 1000 запросов в день вы потратите ощутимую сумму, а при пиковых нагрузках — сотни долларов. Кроме того, баланс может измениться (пользователь продал NFT), поэтому кеш нужно инвалидировать.
Другая проблема — поддержка разных стандартов и сетей. ERC-20 и ERC-721 требуют разных ABI, а RPC-эндпоинты для Polygon, Arbitrum и других L2 имеют разную стоимость и задержки. Мы используем библиотеку viem — она унифицирует вызовы и поддерживает десятки сетей.
Как работает проверка токенов?
После подключения кошелька (MetaMask, WalletConnect) сервер получает адрес из JWT-токена. Middleware проверяет кеш (Redis), если нет — делает RPC-вызов к контракту. Результат кешируется на 5 минут, а параллельно подписывается на Transfer-события для автоматической инвалидации. Такой подход обеспечивает баланс между безопасностью и стоимостью.
Проверка ERC-20 баланса
import { createPublicClient, http, parseAbi } from 'viem';
import { mainnet } from 'viem/chains';
const client = createPublicClient({
chain: mainnet,
transport: http(process.env.ETHEREUM_RPC_URL)
});
const ERC20_ABI = parseAbi([
'function balanceOf(address owner) view returns (uint256)',
'function decimals() view returns (uint8)'
]);
async function checkERC20Balance(
walletAddress: string,
tokenContractAddress: `0x${string}`,
minBalance: bigint
): Promise<boolean> {
const balance = await client.readContract({
address: tokenContractAddress,
abi: ERC20_ABI,
functionName: 'balanceOf',
args: [walletAddress as `0x${string}`]
});
return balance >= minBalance;
}
// Пример: нужно >= 100 токенов EXAMPLE
const hasAccess = await checkERC20Balance(
userWalletAddress,
'0xYourTokenContract',
100n * 10n ** 18n // 100 токенов с 18 decimals
);
Проверка NFT (ERC-721)
const ERC721_ABI = parseAbi([
'function balanceOf(address owner) view returns (uint256)',
'function ownerOf(uint256 tokenId) view returns (address)'
]);
async function checkNFTOwnership(
walletAddress: string,
nftContract: `0x${string}`,
specificTokenId?: bigint
): Promise<boolean> {
if (specificTokenId !== undefined) {
const owner = await client.readContract({
address: nftContract,
abi: ERC721_ABI,
functionName: 'ownerOf',
args: [specificTokenId]
});
return owner.toLowerCase() === walletAddress.toLowerCase();
}
const balance = await client.readContract({
address: nftContract,
abi: ERC721_ABI,
functionName: 'balanceOf',
args: [walletAddress as `0x${string}`]
});
return balance > 0n;
}
Middleware для защиты роутов
async function tokenGateMiddleware(req, res, next) {
const user = req.user;
if (!user?.walletAddress) {
return res.status(401).json({ error: 'Wallet not connected' });
}
const cacheKey = `token_gate:${user.walletAddress}:${TOKEN_CONTRACT}`;
const cached = await redis.get(cacheKey);
if (cached !== null) {
if (cached === '0') return res.status(403).json({ error: 'Token required' });
return next();
}
const hasToken = await checkNFTOwnership(user.walletAddress, TOKEN_CONTRACT);
await redis.setex(cacheKey, 300, hasToken ? '1' : '0');
if (!hasToken) {
return res.status(403).json({
error: 'Access denied',
requiredToken: TOKEN_CONTRACT,
purchaseUrl: 'https://opensea.io/collection/your-nft'
});
}
next();
}
app.get('/premium/content', authenticate, tokenGateMiddleware, getContent);
app.get('/members-only/*', authenticate, tokenGateMiddleware, handleMemberRoute);
Кейс из практики: ускорение в 24 раза
Для одного NFT-сообщества (10 000 holders) мы изначально сделали прямые RPC-вызовы при каждом запросе — LCP вырос до 4 секунд, TTFB — 1.2 с. После внедрения Redis-кеша с TTL 5 минут TTFB упал до 50 мс для закешированных пользователей. Инвалидация по Transfer-событиям гарантирует, что если владелец продаст NFT, доступ закроется в течение 15 секунд. В итоге стоимость RPC снизилась в 10 раз (экономия около $500 в месяц), а пользователи перестали жаловаться на тормоза.
Как кеширование снижает затраты?
Без кеширования каждый запрос премиум-контента вызывал бы RPC-вызов к блокчейну. Это не только дорого (около $0.01 за вызов на Ethereum Mainnet), но и медленно: ответ от Ethereum может приходить 2–5 секунд. Кеш на Redis с TTL 5 минут решает обе проблемы. А инвалидация по Transfer-событиям гарантирует, что доступ закрывается мгновенно после продажи токена.
Как реализовать инвалидацию кеша?
const ERC721_TRANSFER_ABI = parseAbi([
'event Transfer(address indexed from, address indexed to, uint256 indexed tokenId)'
]);
client.watchContractEvent({
address: TOKEN_CONTRACT,
abi: ERC721_TRANSFER_ABI,
eventName: 'Transfer',
onLogs: async (logs) => {
for (const log of logs) {
await redis.del(`token_gate:${log.args.from}:${TOKEN_CONTRACT}`);
await redis.del(`token_gate:${log.args.to}:${TOKEN_CONTRACT}`);
}
}
});
Сравнение типов токенов и кеширования
| Параметр | ERC-20 | ERC-721 |
|---|---|---|
| Тип токена | Фунгибельный | Нефунгибельный |
| Проверка | balanceOf + min | balanceOf или ownerOf |
| Пример | 100 USDT → доступ | Bored Ape → VIP |
| Тип кеша | Задержка | Стоимость | Инвалидация |
|---|---|---|---|
| Без кеша | 2–5 сек | Высокая (>$100/мес) | N/A |
| Redis + TTL | <50 мс | Низкая | 5 минут |
| Redis + события | <50 мс | Низкая | 15 секунд |
Что входит в работу
- Архитектурная схема кеширования и выбора сети.
- Middleware для Express/NestJS с интеграцией JWT и Redis.
- Подписка на Transfer-события с автоматической инвалидацией.
- Фронтенд-компонент подключения кошелька (MetaMask, WalletConnect).
- Документация API и инструкция по деплою.
- Тестирование под нагрузкой и пост-релизный мониторинг (2 недели).
Как настроить token-gating: пошаговая инструкция
- Подготовить RPC-эндпоинт и контракты токенов.
- Установить Redis и зависимости (viem, ethers).
- Реализовать middleware согласно примерам выше.
- Настроить веб-хуки или listen для Transfer-событий.
- Протестировать сценарии: подключение, смена владельца, ошибки RPC.
- Развернуть на сервере с мониторингом.
Типичные ошибки при реализации
- Проверка только на фронтенде — легко обходится.
- Отсутствие кеша — высокие расходы на RPC и медленная загрузка.
- Игнорирование инвалидации — доступ остаётся после продажи токена.
- Необработанные ошибки RPC (rate limit, timeout) — пользователь видит «доступ запрещён» даже при наличии токена.
Сроки и стоимость
Token Gating с ERC-20/ERC-721 проверкой, кешированием и middleware — 3–5 дней. Если нужен собственный контракт и интеграция с несколькими сетями — до 2 недель. Стоимость рассчитывается индивидуально, наш опыт — 5+ лет в Ethereum и Polygon, реализовано 20+ gating-решений. Получите консультацию по интеграции token-gating в ваш проект.