Без продуманої системи рідкості колекція з 10 000 токенів торгується як однорідна маса, де ціна визначається тільки floor price. З правильною системою top-1% колекції коштує в 10–50 разів дорожче floor — це прямо впливає на ліквідність та інтерес трейдерів. Завдання складається з двох частин: off-chain генерація та ранжування, і on-chain верифікація через Merkle tree або зберігання в metadata. Ми розробляємо такі системи під ключ: від вибору алгоритму до інтеграції з маркетплейсами. Понад 5 років на ринку, десятки завершених NFT-проєктів — наш досвід гарантує прозорість кожного етапу.
Як вибрати алгоритм rarity score?
Statistical rarity (метод Rarity Tools)
Класичний підхід: для кожного атрибута рахується частота появи в колекції. Score = сума 1 / trait_frequency за всіма атрибутами токена.
# Псевдокод розрахунку for nft in collection: score = 0 for trait_type, trait_value in nft['attributes']: frequency = count(trait_value) / total_supply score += 1 / frequency nft['rarity_score'] = score Проблема statistical rarity: trait count bias. Токен з 10 звичайними атрибутами може отримати вищий score, ніж токен з 5 атрибутами, один з яких унікальний (1/10000). Це counterintuitive для користувачів.
Information content rarity (метод Rarity Sniper)
Використовує information-theoretic підхід: кожен атрибут вносить внесок пропорційно його інформаційному вмісту -log2(probability).
IC(trait) = -log2(count(trait) / total_supply) Information content rarity перевершує statistical rarity у 2–3 рази за справедливістю ранжування — не страждає від trait count bias.
Нормалізований score для single-attribute rarities
Якщо в колекції є trait типу "background" з 20 варіантами і trait "special" з 2 варіантами (один з яких зустрічається в 1 токені), нормалізація дозволяє порівнювати внесок різних trait types на єдиній шкалі:
normalized_score(trait) = rarity_score(trait) / max_rarity_score(trait_type) Чому важлива on-chain верифікація?
Генерація та розрахунок (off-chain)
Python-скрипт з трьома етапами:
- Trait analysis — парсинг всіх JSON metadata, побудова частотної таблиці по кожному trait_type/trait_value
- Score calculation — обраний алгоритм, нормалізація, ранжування
- Output — оновлені JSON файли з доданими полями
rarity_score,rarity_rank
Ключовий момент: metadata оновлюється до завантаження на IPFS. Після pin на IPFS CID фіксований — змінити rarity score без зміни CID неможливо. Прозорість і незмінність — обов'язкові умови довіри до проєкту.
Merkle-based on-chain верифікація
Для проєктів, які хочуть on-chain верифікацію rarity (наприклад, для видачі бонусів top-100 холдерам):
// Merkle proof верифікація rarity rank function verifyRarityRank( uint256 tokenId, uint256 rank, bytes32[] calldata proof ) external view returns (bool) { bytes32 leaf = keccak256(abi.encodePacked(tokenId, rank)); return MerkleProof.verify(proof, rarityMerkleRoot, leaf); } Витрати на газ при on-chain верифікації через Merkle tree становлять менше $10 за апдейт — економія близько 90% порівняно з повним зберіганням.
API для агрегаторів
Rarity Tool, Rarity Sniper, OpenSea — всі вони читають metadata з tokenURI(). Важливо коректно форматувати поле attributes:
{ "attributes": [ {"trait_type": "Background", "value": "Gold"}, {"trait_type": "Eyes", "value": "Laser"}, {"display_type": "number", "trait_type": "Rarity Rank", "value": 42}, {"display_type": "number", "trait_type": "Rarity Score", "value": 847.3} ] } display_type: "number" дозволяє OpenSea та іншим маркетплейсам показувати rarity rank як числове поле з сортуванням.
Порівняння алгоритмів rarity score
| Метод | Переваги | Недоліки | Коли використовувати |
|---|---|---|---|
| Statistical rarity | Простота, широка підтримка | Trait count bias | Колекції з однаковою кількістю атрибутів |
| Information content rarity | Без bias, математично справедливий | Складніший для розуміння | Колекції зі змінною кількістю атрибутів |
| Normalized score | Зручність порівняння | Залежить від max score | Single-attribute rarities |
Етапи та терміни розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз trait structure | 0.5–1 день | Вибір алгоритму, частотна таблиця |
| Розробка скрипта | 1–2 дні | Python pipeline, CSV, JSON з rank |
| On-chain компонент (якщо потрібен) | 1 день | Merkle tree, контракт верифікації |
| Інтеграція з маркетплейсами | 0.5 дня | Перевірка відображення на OpenSea, Blur |
Переглянути код розрахунку (Python-псевдокод)
for nft in collection: score = 0 for trait_type, trait_value in nft['attributes']: frequency = count(trait_value) / total_supply score += 1 / frequency nft['rarity_score'] = score Типові помилки при розробці rarity системи
- Trait count не враховано. Токени з різною кількістю атрибутів (у деяких NFT може не бути певних trait_type) отримують несправедливий score. Рішення:
Noneяк окреме значення з частотою появи. - Score розраховано до фінальної генерації. Якщо художник додав нові варіанти після розрахунку score — вся таблиця невалідна. Рідкість розраховується єдиний раз за фінальною колекцією, до будь-яких змін.
- Відсутність тай-брейкера. Токени з однаковим score отримують однаковий rank. Стандартний підхід — тай-брейк по tokenId (менший ID = вищий rank при рівних score).
Що входить в роботу
- Документація щодо алгоритму та процесу розрахунку
- Оновлені JSON metadata з rarity score та rank
- CSV-експорт рідкісних токенів
- Merkle tree та контракт верифікації (при необхідності)
- Підтримка після впровадження протягом 2 тижнів
Терміни: 2–3 дні для колекції до 10 000 токенів. Для більших колекцій або нестандартних алгоритмів — до 5 днів. Вартість розраховується після аналізу структури колекції. Напишіть нам — оцінимо ваш кейс і запропонуємо оптимальне рішення.