Разработка платформы NFT для билетов на мероприятия
Классический рынок продажи билетов страдает от двух системных проблем: скальперы скупают квоты через ботов и перепродают с наценкой 300–500%, а организатор после первичной продажи теряет контроль над вторичным оборотом полностью. NFT-тикеты решают обе проблемы архитектурно — через on-chain логику, а не через попытки закрутить гайки в CRM.
Архитектура смарт-контракта тикетов
Контракт строится на базе ERC-721 с расширениями, которые перекрывают стандартный transferFrom. Ключевые механики:
Роялти на вторичных продажах реализуются через ERC-2981 (royaltyInfo). Организатор получает процент от каждой перепродажи автоматически — без посредников. Стандарт поддерживается OpenSea, Blur, LooksRare и большинством агрегаторов.
Whitelist и лимиты покупки — через Merkle Tree для газ-эффективной верификации. Вместо хранения списка адресов on-chain держим только root-хэш. Пользователь предоставляет proof, контракт верифицирует за O(log n) за несколько тысяч gas.
Soulbound-режим — при необходимости билет делается non-transferable после валидации входа. Реализуется через override _beforeTokenTransfer с проверкой флага isUsed. Это убивает вторичный рынок для конкретных категорий (например, VIP с персонализацией).
Динамический URI — метаданные меняются в зависимости от состояния: до события, после валидации, после использования. Через tokenURI с проверкой block.timestamp против eventDate и isUsed. Удобно для коллекционного "послематчевого" состояния билета.
function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId,
uint256 batchSize
) internal override {
require(!usedTickets[tokenId], "Ticket already validated");
if (transferRestricted[tokenId]) {
require(from == address(0) || to == address(0), "Non-transferable");
}
super._beforeTokenTransfer(from, to, tokenId, batchSize);
}
Процесс валидации на входе
Это технически самая ответственная часть. Два варианта:
On-chain валидация — организатор вызывает validateTicket(tokenId) через мобильное приложение с подключённым кошельком. Транзакция записывает isUsed = true, повторный вход невозможен. Минус — latency и gas cost на каждый вход. На Polygon/Arbitrum это приемлемо (~$0.01), на Ethereum mainnet — нет.
Off-chain с подписью — стандартный паттерн для высокой пропускной способности. Владелец билета подписывает сообщение {tokenId, eventId, timestamp} своим кошельком (EIP-712 typed data). Валидатор на входе проверяет подпись через ecrecover и сверяет ownerOf(tokenId) через read-only RPC call. Если подпись валидна и токен принадлежит подписанту — пропускаем. Задание "использован" фиксируется off-chain в базе организатора; on-chain write — опционально, батчем после события.
Для фестивалей с тысячами одновременных входов используем второй вариант с локальным кэшем состояний токенов, который синхронизируется каждые 30 секунд через WebSocket подписку на Transfer-события.
Frontend и пользовательский поток
Пользователь покупает через стандартный dApp:
- Подключение кошелька (wagmi + ConnectKit / RainbowKit)
- Выбор категории и количества билетов
- Если presale — whitelist проверка через Merkle proof
- Оплата в ETH/MATIC/USDC через
mint() - Билет появляется в кошельке как NFT, отображается в интерфейсе с QR-кодом (подписанное сообщение EIP-712)
Для организаторов — отдельная панель управления: настройка мероприятий, выгрузка аналитики on-chain продаж, управление квотами и whitelist'ами.
Интеграция с вторичными маркетплейсами
Стандартная интеграция с OpenSea через правильно заполненный contractURI (collection-level metadata) и tokenURI (per-token metadata). Поддержка оператора через setApprovalForAll — стандартная. Если нужно ограничить площадки, реализуем operator filter (паттерн Operator Filter Registry от OpenSea, хотя его enforcement уже ослаб).
Для собственного вторичного рынка — мини-маркетплейс на базе Seaport (open-source протокол от OpenSea): листинг через fulfillBasicOrder, атомарный swap токена и оплаты в одной транзакции, роялти через ERC-2981.
Что входит в разработку
- Смарт-контракт ERC-721 с расширениями (роялти, whitelist, soulbound-режим, динамические метаданные)
- Деплой в testnet + mainnet (Ethereum, Polygon или другая EVM-цепь по выбору)
- Frontend dApp для покупателей (React + wagmi)
- Панель управления для организаторов
- Мобильное приложение или веб-сканер для валидации на входе
- Интеграция с IPFS (Pinata/NFT.Storage) для метаданных и изображений
- Аудит контракта (Slither + ручной review)
Стек варьируется в зависимости от масштаба — от одностраничного dApp для камерного мероприятия до полноценного SaaS с мультиорганизаторским режимом.