Розробка 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)
Stack варіюється залежно від масштабу — від однієї сторінки dApp для камерного мероприятия до повнофункціонального SaaS з мультиорганізаторським режимом.