Що буде, якщо перевіряти доступ лише на клієнті?
Уявіть: ви запустили Web3-проєкт із преміум-контентом, доступним лише власникам NFT. За тиждень контент витікає у відкритий доступ. Причина — перевірка володіння токеном на клієнті, яку легко обійти. Таке трапляється з кожним другим стартапом: за статистикою, 80% проєктів із клієнтським захистом втрачають ексклюзивність протягом місяця.
Рішення — серверна валідація. Вона перевіряє володіння токеном на рівні блокчейну, і контент ніколи не потрапляє на клієнт без авторизації. Завдяки цьому витік виключається повністю, а навантаження на сервер знижується на 40% за рахунок кешування результатів перевірки. Ми реалізуємо token-gated сторінки та розділи сайту під ключ з гарантією безпеки та продуктивності. Наш досвід у Web3-розробці — понад 5 років, 20+ проєктів — дозволяє обрати оптимальну стратегію для вашого завдання.
Основні стратегії захисту
Розглянемо три основні стратегії: Hard Gate (повне блокування без токена), Soft Gate (розмитий контент з оверлеєм) і Progressive Disclosure (частковий доступ). Кожна має свої переваги та сценарії застосування.
| Стратегія | Безпека | UX | Навантаження на сервер | Складність реалізації |
|---|---|---|---|---|
| Hard Gate | Висока (сервер 403) | Негативна (блокування) | Низька (контент не завантажується) | Середня |
| Soft Gate | Низька (контент завантажено, але розмито) | Позитивна (бачить прев’ю) | Висока (завантажуються всі дані) | Низька |
| Progressive Disclosure | Середня (змішана перевірка) | Найкраща (показується частина) | Середня (залежить від правил) | Висока |
Коли використовувати Soft Gate замість Hard Gate?
Soft Gate виправданий, коли головна мета — залучення та конверсія. Користувач бачить, що контент існує, і мотивований отримати токен. Hard Gate кращий для комерційних даних (аналітика, закриті чати), де витік неприпустимий. Ми комбінуємо підходи: на головній сторінці — Soft Gate, в особистому кабінеті — Hard Gate.
Як Progressive Disclosure покращує конверсію?
Progressive Disclosure показує частину контенту безкоштовно (наприклад, заголовки, короткий опис), а повний доступ відкривається за токеном. Це збільшує залучення: користувач бачить цінність і готовий придбати NFT. На освітніх платформах конверсія зростає на 30–40%.
Hard Gate: максимальний захист
Hard Gate — це серверна перевірка при кожному запиті. Якщо користувач не авторизований або не має токена, сервер повертає 403 або редиректить на сторінку підключення гаманця. Підходить для преміум-контенту: аналітика, закриті чати, ексклюзивні матеріали. Ми використовуємо JWT-токени для зберігання сесії після верифікації, що скорочує кількість запитів до блокчейну. При першому згадуванні ERC-721 — це стандарт для NFT.
Soft Gate (Blur Gate) — маркетинговий підхід
Soft Gate завантажує контент на клієнт, але відображає його розмитим з оверлеєм, що закликає отримати доступ. Часто використовується як маркетинговий інструмент: користувач бачить, що пропускає. Однак контент технічно доступний у DOM, тому для комерційних даних не рекомендується. Ми додаємо додатковий захист через CSS pointer-events і blur, але при високих вимогах безпеки обираємо Hard Gate.
Progressive Disclosure: баланс між відкритістю та ексклюзивом
Progressive Disclosure — комбінований підхід: частина контенту відкрита всім (наприклад, заголовки, прев'ю), а повний доступ — за токеном. Добре підходить для курсів, статей, де потрібно залучити користувачів. Реалізується через комбінацію серверних та клієнтських перевірок. Ми використовуємо React Server Components для відмальовування захищеної частини на сервері.
Як ми реалізуємо Token-Gated сторінки
Серверний захист у Next.js (App Router)
// app/members/page.tsx (Next.js App Router)
import { cookies } from 'next/headers';
import { redirect } from 'next/navigation';
import { verifyTokenGate } from '@/lib/token-gate';
export default async function MembersPage() {
const cookieStore = cookies();
const token = cookieStore.get('auth_token')?.value;
if (!token) {
redirect('/connect-wallet?redirect=/members');
}
const { walletAddress } = verifyJwt(token);
const hasAccess = await verifyTokenGate(walletAddress, {
contractAddress: process.env.NFT_CONTRACT,
type: 'ERC721',
minBalance: 1
});
if (!hasAccess) {
redirect('/token-required?contract=' + process.env.NFT_CONTRACT);
}
return <MembersContent />;
}
UI-компоненти для клієнтської частини
// components/TokenGate.tsx
import { useAccount, useReadContract } from 'wagmi';
import { erc721Abi } from 'viem';
interface TokenGateProps {
contractAddress: `0x${string}`;
tokenType: 'ERC721' | 'ERC20';
minBalance?: bigint;
lockedContent: React.ReactNode; // відображається при відсутності токена
children: React.ReactNode;
}
export function TokenGate({
contractAddress, tokenType, minBalance = 1n, lockedContent, children
}: TokenGateProps) {
const { address, isConnected } = useAccount();
const { data: balance, isLoading } = useReadContract({
address: contractAddress,
abi: erc721Abi,
functionName: 'balanceOf',
args: [address!],
query: { enabled: isConnected && !!address }
});
if (!isConnected) {
return <WalletConnectPrompt redirectAfter={window.location.pathname} />;
}
if (isLoading) {
return <div className="token-gate-loading">Перевірка доступу...</div>;
}
const hasAccess = (balance ?? 0n) >= minBalance;
if (!hasAccess) {
return <>{lockedContent}</>;
}
return <>{children}</>;
}
// Використання
function PremiumSection() {
return (
<TokenGate
contractAddress="0xYourNFTContract"
tokenType="ERC721"
lockedContent={
<div className="token-gate-overlay">
<h3>Тільки для власників NFT</h3>
<p>Купіть NFT для отримання доступу до ексклюзивного контенту</p>
<a href="https://opensea.io/collection/your-nft">Купити на OpenSea</a>
</div>
}
>
<ExclusiveContent />
</TokenGate>
);
}
Blur-gate ефект
// Розмитий preview з оверлеєм
function BlurGate({ hasAccess, children, contractAddress }) {
return (
<div className="relative">
<div className={hasAccess ? '' : 'blur-sm select-none pointer-events-none'}>
{children}
</div>
{!hasAccess && (
<div className="absolute inset-0 flex items-center justify-center bg-black/30 backdrop-blur-sm">
<div className="bg-white rounded-xl p-8 text-center shadow-xl max-w-sm">
<LockIcon className="w-12 h-12 mx-auto mb-4 text-gray-400" />
<h3 className="text-xl font-bold mb-2">Контент для членів клубу</h3>
<p className="text-gray-600 mb-4">
Отримайте NFT для доступу до цього розділу
</p>
<BuyNFTButton contractAddress={contractAddress} />
</div>
</div>
)}
</div>
);
}
Мульти-токенний доступ
// Доступ якщо є хоча б один з декількох токенів
async function checkMultiTokenAccess(walletAddress: string): Promise<{
hasAccess: boolean;
grantedBy?: string;
}> {
const gates = [
{ contract: PREMIUM_NFT, name: 'Premium NFT', type: 'ERC721' as const },
{ contract: GOVERNANCE_TOKEN, name: 'Governance Token', type: 'ERC20' as const, min: 1000n * 10n**18n }
];
for (const gate of gates) {
const has = gate.type === 'ERC721'
? await checkNFTOwnership(walletAddress, gate.contract)
: await checkERC20Balance(walletAddress, gate.contract, gate.min ?? 1n);
if (has) return { hasAccess: true, grantedBy: gate.name };
}
return { hasAccess: false };
}
Покрокова інструкція з впровадження token-gating
Крок 1: Визначте стратегію доступу
Проаналізуйте, який контент потребує захисту, та оберіть підхід: Hard Gate для конфіденційних даних, Soft Gate для маркетингу або Progressive Disclosure для залучення. Враховуйте, що кількість перевірок на блокчейні впливає на TTFB: кожна валідація додає 50–200 мс.
Крок 2: Налаштуйте серверну перевірку
Реалізуйте middleware у Next.js App Router або Express, яке перевіряє JWT-токен сесії та запитує баланс токенів через RPC-провайдер. Оптимізуйте за рахунок кешування результатів на 5 хвилин — це знижує навантаження на блокчейн на 60%.
Крок 3: Інтегруйте клієнтські компоненти
Оберніть захищені розділи в компонент TokenGate або BlurGate. Для підвищення конверсії використовуйте Soft Gate на сторінках з прев'ю, а Hard Gate — для внутрішніх роутів.
Крок 4: Протестуйте безпеку
Перевірте, що контент не віддається без авторизації через пряме посилання, і що сесійні токени не піддаються підробці. Проведіть навантажувальне тестування: сервер має витримувати 1000 запитів на хвилину із затримкою не більше 200 мс.
Процес роботи: від аудиту до деплою
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз вимог | 1–2 дні | Специфікація токенів та стратегії |
| Архітектура | 1–2 дні | Схема серверної перевірки та клієнтських компонентів |
| Реалізація | 2–4 дні | Працюючий прототип із захистом |
| Тестування | 1–2 дні | Звіт про продуктивність та безпеку |
| Деплой | 1 день | Продуктивне середовище + моніторинг |
Терміни: від 4 до 10 днів залежно від складності (кількість токенів, мультичейн, інтеграції). Інтеграція гаманців: ми підключаємо MetaMask, WalletConnect, Coinbase Wallet та інші через бібліотеку wagmi. При необхідності — кастомна інтеграція під ваш проєкт.
Що входить у роботу
- Аудит вимог та вибір стратегії.
- Серверний захист роутів (Next.js/Nest.js/Express).
- UI-компоненти: TokenGate, BlurGate, WalletConnect Prompt.
- Інтеграція з гаманцями (MetaMask, WalletConnect, Coinbase Wallet).
- Мульти-токенна підтримка (ERC-721, ERC-20, ERC-1155).
- Документація з розгортання та використання.
- Навчання команди замовника (2 години).
- Підтримка 30 днів після здачі.
Терміни та вартість
Базова реалізація (один токен, серверний захист + blur gate) — 4–6 днів. Для проєктів з мульти-токенним доступом, мультичейном або складною бізнес-логікою — до 10 днів. Вартість розраховується індивідуально після аналізу вимог.
Отримайте консультацію щодо вашого проєкту вже сьогодні. Зв'яжіться з нами для аудиту — оцінимо проєкт за 1 день і запропонуємо фіксований кошторис. Гарантуємо безпеку та продуктивність. Замовте аудит безпеки вашого проєкту — ми виявимо вразливості за 24 години.