Розробка внутрішньоігрового NFT-маркетплейсу під ключ

Ігровий NFT-маркетплейс — не просто вітрина JPEG. Якщо не продумати архітектуру смарт-контрактів та індексацію атрибутів, гравці зіткнуться із затримками транзакцій, неочікуваними комісіями та неможливістю торгувати предметами з унікальними характеристиками. На відміну від готових рішень, кастомна розробка дозволяє інтегрувати внутрішньоігрову валюту, оренду предметів та складні аукціони. Це знижує операційні витрати та утримує економіку всередині гри. Ми — Web3-розробники з 5+ річним досвідом — будуємо маркетплейси, які витримують навантаження сотень тисяч предметів з глибиною атрибутів (рівень, модифікатори, сумісність за класами). Отримайте консультацію, щоб обговорити ваш проєкт.

Які проблеми вирішує кастомний NFT-маркетплейс?

Готові рішення на кшталт Seaport (OpenSea protocol) покривають базові сценарії, але не враховують ігрову специфіку. Типові проблеми, які ми вирішуємо:

• Gas-оптимізація. У грі можуть здійснюватися сотні мікротранзакцій на день. Кастомний контракт дозволяє використовувати пакетні трансфери ERC-1155 та агрегувати роялті в одну операцію. Ми використовуємо batchTransferFrom та multiCall для зниження газу на 40-60%. Така економія складає від $0.01 до $0.05 за операцію, що при масовому використанні дає значний виграш.
• Reentrancy. Ігровий маркетплейс — часта мішень для атак повторного входу. Ми блокуємо їх за допомогою ReentrancyGuard від OpenZeppelin та перевіряємо за допомогою Echidna-фазінгу.
• Складна логіка торгів. Bundle-продажі (персонаж + інвентар), аукціони з кількома валютами, лістинги з умовами (мінімальний рівень, класи). Seaport не підтримує таке без переписування.

Як вибрати стандарт токена та модель торгів?

Починаємо з вибору стандарту токена. Для ігор найкраще підходить ERC-1155 — один контракт на всі типи предметів, ERC-721 — для унікальних персонажів. Між ними варто обирати виходячи з очікуваної кількості типів предметів та частоти торгівлі. Також для оренди NFT використовуємо ERC-4907.

Потім визначаємо модель торгівлі:

• In-game currency vs ETH/USDC: Найкращий варіант — гібрид. Лістинги в ігровому токені, але кнопка «Купити за USDC» автоматично робить swap через DEX. Це утримує економіку в грі та приваблює зовнішню ліквідність.
• Роялті: розподіл між розробниками, творцями та стейкхолдерами. Реалізуємо через роздільний відсоток або стандарт ERC-2981.
• Оренда NFT: для дорогих предметів використовуємо ERC-4907, де ownership та right to use розділені.

Якщо ви хочете обговорити архітектуру вашого ігрового маркетплейсу, зв'яжіться з нами — ми допоможемо вибрати оптимальний стек.

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract GameNFTMarketplace { IERC20 public gameToken; IERC1155 public gameItems; uint256 public marketFeePercent = 250; // 2.5% uint256 public royaltyPercent = 500; // 5% до творців address public treasury; address public developersWallet; struct Listing { address seller; uint256 itemTypeId; uint256 amount; uint256 pricePerUnit; // в gameToken uint256 minimumPurchase; // мінімальна покупка bool acceptsBundle; // чи приймає bundle оферти uint256 expiresAt; ListingType listingType; } enum ListingType { FIXED_PRICE, ENGLISH_AUCTION, DUTCH_AUCTION } struct Auction { address seller; uint256 itemTypeId; uint256 tokenId; uint256 startPrice; uint256 currentBid; address currentBidder; uint256 endTime; uint256 minBidIncrement; } mapping(uint256 => Listing) public listings; mapping(uint256 => Auction) public auctions; // Fixed price purchase function buyItem(uint256 listingId, uint256 amount) external { Listing storage listing = listings[listingId]; require(listing.seller != address(0), "Listing not found"); require(block.timestamp <= listing.expiresAt, "Listing expired"); require(amount >= listing.minimumPurchase, "Below minimum purchase"); uint256 totalPrice = listing.pricePerUnit * amount; uint256 fee = (totalPrice * marketFeePercent) / 10000; uint256 royalty = (totalPrice * royaltyPercent) / 10000; uint256 sellerProceeds = totalPrice - fee - royalty; // Платежі gameToken.transferFrom(msg.sender, listing.seller, sellerProceeds); gameToken.transferFrom(msg.sender, treasury, fee); gameToken.transferFrom(msg.sender, developersWallet, royalty); // Передача предметів listing.amount -= amount; if (listing.amount == 0) delete listings[listingId]; gameItems.safeTransferFrom(listing.seller, msg.sender, listing.itemTypeId, amount, ""); emit ItemSold(listingId, msg.sender, amount, totalPrice); } // English auction function placeBid(uint256 auctionId, uint256 bidAmount) external { Auction storage auction = auctions[auctionId]; require(block.timestamp < auction.endTime, "Auction ended"); require(bidAmount >= auction.currentBid + auction.minBidIncrement, "Bid too low"); // Повернення попередньому bidder if (auction.currentBidder != address(0)) { gameToken.transfer(auction.currentBidder, auction.currentBid); } // Новий bid в escrow gameToken.transferFrom(msg.sender, address(this), bidAmount); auction.currentBid = bidAmount; auction.currentBidder = msg.sender; // Anti-snipe: якщо bid < 5 хвилин до кінця — продовжуємо if (auction.endTime - block.timestamp < 5 minutes) { auction.endTime += 5 minutes; } emit BidPlaced(auctionId, msg.sender, bidAmount); } // Dutch auction: ціна знижується з часом function getDutchPrice(uint256 listingId) public view returns (uint256) { Listing storage listing = listings[listingId]; // ... linearly interpolate price from startPrice to endPrice over duration } } 

Як організувати пошук за атрибутами?

Ігровий маркетплейс вимагає багатого контексту: рівень предмета, модифікатори, сумісність з класом, історія боїв. Ми будуємо інтерфейс, де кожен NFT показується не як JPEG, а як повноцінна картка з характеристиками.

interface GameItemListing { tokenId: number; itemType: { id: number; name: string; rarity: "common" | "rare" | "epic" | "legendary"; category: "weapon" | "armor" | "consumable" | "companion"; imageUrl: string; }; attributes: { level: number; damage?: number; defense?: number; speed?: number; durability: number; upgradeCount: number; enchantments: string[]; }; gameContext: { compatibleClasses: string[]; compatibleGames: string[]; requiredLevel: number; lastUsedInBattle?: Date; totalBattlesUsed: number; }; listing: { price: bigint; currency: "GGD" | "USDC"; seller: string; listedAt: Date; expiresAt: Date; }; priceHistory: Array<{ price: bigint; date: Date }>; floorPrice: bigint; pricePower: number; } 

Для фільтрації за атрибутами використовуємо PostgreSQL з GIN-індексами на JSONB або Elasticsearch. Це дозволяє шукати предмети з конкретними зачаруваннями, рівнем або класом за мілісекунди.

interface MarketplaceFilters { itemCategory?: string[]; rarities?: string[]; minPrice?: bigint; maxPrice?: bigint; minLevel?: number; maxLevel?: number; compatibleClass?: string; hasEnchantment?: string; currency?: "GGD" | "USDC"; sortBy?: "price_asc" | "price_desc" | "recently_listed" | "ending_soon" | "price_power"; } async function searchListings(filters: MarketplaceFilters, page: number) { const query = db("listings") .where("status", "active") .where("expires_at", ">", new Date()); if (filters.itemCategory?.length) { query.whereIn("item_category", filters.itemCategory); } if (filters.minLevel) { query.where("attributes->>'level'", ">=", filters.minLevel.toString()); } if (filters.hasEnchantment) { query.whereRaw("attributes->'enchantments' @> ?", [JSON.stringify([filters.hasEnchantment])]); } return query .orderBy(getSortColumn(filters.sortBy)) .limit(PAGE_SIZE) .offset(page * PAGE_SIZE); } 

Процес роботи

1. Аналітика: розбираємо економіку гри, потік предметів, очікувані сценарії торгівлі.
2. Проєктування: вибір L2 (Polygon, Arbitrum) для дешевих транзакцій, визначення структури контрактів.
3. Реалізація: пишемо смарт-контракти з Foundry, фронтенд — Next.js + wagmi.
4. Тестування: unit-тести, інтеграційні тести, fuzzing в Echidna, тести на gas consumption.
5. Security-аудит: внутрішній Slither + зовнішній аудит за бажанням.
6. Деплой: налаштування моніторингу Tenderly, індексація подій.

Напишіть нам, щоб отримати детальне комерційне пропозицію.

Що входить в роботу

• Смарт-контракти з повним покриттям тестами (95%+)
• Документація (архітектура, функції, події)
• Код фронтенду з кастомізованими картками
• Набір скриптів для деплою та верифікації на Etherscan
• Інтеграція з ігровим бекендом (REST або WebSocket)
• Навчання команди замовника роботі з адмінкою
• Підтримка протягом 1 місяця після запуску

Терміни орієнтовно

Вартість розраховується індивідуально. Оцінимо ваш проєкт — пишіть.

Ми гарантуємо, що маркетплейс пройде аудит та витримає навантаження до 10 000 одночасних користувачів. Досвід — 5+ років та 15+ реалізованих проєктів у DeFi та GameFi. Звертайтеся за консультацією.