Розробка системи рарити (редкості) NFT
Rarity score — те, що превращає однотипні токени колекції в ієрархію з різною ринковою вартістю. Без продуманої системи рарити колекція з 10 000 токенів торгується як однорідна маса, де ціна визначається тільки floor price. З правильною системою — топ-1% колекції коштує в 10–50 разів дорожче floor. Це прямо впливає на ліквідність та інтерес трейдерів. Технічно задача складається з двох частин: off-chain генерація й ранжування, та on-chain верифікація через Merkle tree або зберігання в метаданих.
Алгоритми розрахунку 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)
Атрибут з частотою 0.1% (1 з 1000) дає IC = log2(1000) ≈ 10 bits. Атрибут з частотою 50% дає IC = 1 bit. Итоговий score = сума IC всіх атрибутів. Це більш справедлива метрика, яка не штрафує за кількість атрибутів.
Нормалізований score для single-attribute rarities
Якщо в колекції є trait типу "background" з 20 варіантами та trait "special" з 2 варіантами (один з яких зустрічається в 1 токені), нормалізація дозволяє порівнювати вклад різних trait types на єдиній шкалі:
normalized_score(trait) = rarity_score(trait) / max_rarity_score(trait_type)
Вибір алгоритму залежить від структури колекції та маркетингової стратегії. Для колекцій з "Legendary" tier — статистичний підхід з trait type weighting працює краще.
Технічний стек реалізації
Генерація та розрахунок (off-chain)
Python-скрипт з трьома етапами:
- Trait analysis — парсинг всіх JSON метаданих, побудова частотної таблиці по кожному trait_type/trait_value
- Score calculation — вибраний алгоритм, нормалізація, ранжування
-
Output — оновлені JSON файли з доданими полями
rarity_score,rarity_rank
Ключовий момент: метаданні оновлюються до завантаження на IPFS. Після pin на IPFS CID фіксований — змінити rarity score без зміни CID неможливо. Прозорість та неізмінність — обов'язкові умови довіри до проекту.
Merkle-based on-chain верифікація
Для проектів, які хочуть on-chain верифікацію rarity (наприклад, для видачі бонусів топ-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);
}
Root генерується з повного дерева {tokenId: rank} й фіксується в контракті після reveal. Користувач доказує свій rank без зберігання 10 000 значень on-chain.
API для агрегаторів
Rarity Tool, Rarity Sniper, OpenSea — все вони читають метаданні з 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 системи
Trait count не урахований. Токени з різним числом атрибутів (у деяких NFT може не бути певних trait_type) отримують несправедливий score. Рішення: None як окремий лайт з частотою появи.
Score рассчитан до фінальної генерації. Якщо художник додав нові варіанти після розрахунку score — вся таблиця невалідна. Rarity розраховується одноразово по фінальній колекції, до будь-яких змін.
Відсутність тай-брейкера. Токени з одинаковим score отримують одинаковий rank. Стандартний підхід — тай-брейк по tokenId (менший ID = більш високий rank при рівних score).
Процес роботи
Аналітика trait structure (0.5–1 день). Аналізуємо набір атрибутів, частоти, вибираємо алгоритм. Якщо у проекту вже є часткова генерація — перевіряємо коректність trait distribution (немає ли випадкових дублів, пропусків).
Розробка скрипту (1–2 дні). Python pipeline: trait analysis → score calculation → metadata update → IPFS upload. Выходні дані: JSON з rarity_score та rarity_rank для кожного токену, CSV для команди проекту, оновлені файли метаданих.
On-chain компонент (1 день якщо потрібен). Merkle tree генерація, деплой верифікатора, тест доказів.
Інтеграція з маркетплейсами (0.5 дня). Верифікація коректного відображення на OpenSea, Blur, LooksRare.
Сроки: 2–3 дні для колекції до 10 000 токенів. Для більш крупних колекцій або нестандартних алгоритмів — до 5 днів. Вартість розраховується після аналізу структури колекції.