Уявіть: у вас сайт із преміум-аналітикою, відео-курсами або закритою спільнотою. Ви хочете надати доступ лише власникам вашої 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 у ваш проект.







