PFP NFT Rules
Collect, Trade, and Forge Your Heroes
Public Sale Draw Rules
Public sale phases from Phase 4 onward use a signature registration and public seed draw. Signing registers intent only; payment opens only for winning wallets after the draw. Phases 1-3 were completed under the legacy direct-payment flow and remain auditable by their on-chain TXIDs and trait hashes.
Phase 1-3 Compatibility
Public Sale Phases 1-3 do not require retroactive signatures. Their historical purchase records, payment TXIDs, and trait-hash verification remain the source of truth.
Sign Once
Each wallet address can hold one registration per sale round. Duplicate signatures for the same wallet and round do not create extra chances.
Public Audit Trail
The public list shows queue position, masked wallet, registration id, message hash, signature hash, and draw result. Full signatures are retained in the admin audit record.
Eligibility at Draw Time
Guild membership and confirmed balance are checked only when the draw runs. Wallets outside an active guild or below the round minimum balance are marked ineligible.
Threshold Settlement Block
Each round publishes its signature target and block offset. When the target signature is accepted, the server records the current chain height H and locks H + offset as the settlement seed block.
Ranking Formula
Eligible registrations are sorted by the lowest score first:sha256(seedBlockHash + ":" + walletAddress + ":" + registrationId)
Winner Payment
The first ranked wallets up to the available inventory become winners. Remaining eligible wallets enter the waitlist. Only winners can submit payment during the payment window.
Seven Factions
The system features seven distinct factions: Knight, Mithia, Adventurer, Wizard, Grum, The Plagued, and Nightspawn. Each faction has 1,500 PFP NFTs for a total supply of 10,500.
Character Composition
Standard PFPs consist of eight trait layers: Background, Emblem, Body, Face, Head Wear, Clothing, Hand, and Weapon. Together, these layers combine to form a unique character profile.
Bonus Part System
All seven factions follow the standard 8 trait layers system. Certain factions have exclusive bonus partsawarded when the Trait Hash contains special hex patterns. Bonus traits do not consume standard production capacity. See the detailed breakdown below.
Supply Structure
The ecosystem contains 10,500 PFP NFTs distributed equally across all seven factions, and 84,000 trait NFTs (8 traits per character).
Per-Faction Breakdown
Trait Generation Mechanics
Minting Process
Users obtain traits by sending a fixed Bitcoin amount (initially 0.0011 BTC) to an official address. The system adopts the Dual-Factor Trait Hash Scheme: combining the Block Hash (determined by miners, unpredictable) with the TXID (tied to the transaction) via SHA-256 to produce a Trait Hash. Like two-factor authentication, one factor comes from the user (TXID) and the other from on-chain randomness (Block Hash) — making the outcome impossible to manipulate.
Compute Trait Hash
After the transaction is confirmed on-chain, the system hashes the TXID with the zero-based Trait Index, then hashes that seed with the Block Hash to produce a 64-character Trait Hash.
txidSeed = SHA256(txid + indexHex)
traitHash = SHA256(blockHash + txidSeed)Faction Class
The last hex character of the Trait Hash is converted to decimal (0-15), then modulo 7 plus 1 determines the faction (1 = Knight, 2 = Mithia, 3 = Adventurer, 4 = Wizard, 5 = Grum, 6 = The Plagued, 7 = Nightspawn).
faction = parseInt(traitHash[-1], 16) % 7 + 1Part Category
The second-to-last hex character of the Trait Hash, converted to decimal then modulo 8 plus 1, determines which of the eight trait layers is assigned (1 = Background, 2 = Emblem, 3 = Body, 4 = Face, 5 = Head Wear, 6 = Clothing, 7 = Hand, 8 = Weapon).
partType = parseInt(traitHash[-2], 16) % 8 + 1Design Variant
Take the hex characters at positions -4 and -3 of the Trait Hash. Multiply position -4 by 16 and add position -3 to form a combined value (range 0-255). Then take the remainder of dividing by the number of design variants (maxVariants) for that (faction, partType) combination, and add 1. Each combination has a different maxVariants based on the available art assets (e.g., Knight Clothing = 65, Nightspawn Head Wear = 8).
variant = (traitHash[-4] × 16 + traitHash[-3]) % maxVariants + 1Dual-Factor Trait Hash Scheme — Why is this tamper-proof?
| Factor | Source | Predictable? | Controllable? |
|---|---|---|---|
| TXID | Buyer | Yes (known after broadcast) | Yes |
| Block Hash | Miner | No (unknown until confirmed) | No |
| Trait Hash | SHA-256 of both | No | No |
Anyone can verify the result: open Purchase History for the assigned Block Hash, TXID, and Trait Index, then use the Verification Tool below to confirm the computed Trait Hash and rarity. Purchase History remains the final cap-aware assignment record when production caps or variant reservation rules apply.
How Verification Works
What is a Block Hash?
The hash of the Bitcoin block that confirmed your transaction. You can find this on any block explorer by looking up your transaction. The Block Hash is determined by miners and is unpredictable before the block is mined, which provides the randomness factor in trait assignment.
What is a TXID?
Your transaction ID (also called txid or transaction hash). This is the unique identifier for your purchase transaction. Every Bitcoin transaction has a unique TXID that is a 64-character hexadecimal string. You can find it in your wallet history or on a block explorer.
How Verification Works
The system first computes txidSeed = SHA-256(txid + indexHex), then computes traitHash = SHA-256(blockHash + txidSeed). This hash deterministically determines your trait's rarity and natural faction/part/variant mapping. Anyone can independently verify this by entering the same Block Hash, TXID, and Trait Index below.
Trait Index is zero-based within a purchase: the first trait is 0, the second is 1. The first byte of the traitHash determines the rarity; the last hex character determines the faction (mod 7), the second-to-last determines the part type (mod 8), and positions -3 and -4 determine the design variant within that combination.
This browser calculator does not read live production counts. If production-cap overflow or variant reservation applies, the final cap-aware assignment is the assignment shown in Purchase History and the server-side verification response.
Interactive Trait Hash Calculator
Enter a Block Hash, TXID, and zero-based Trait Index to compute the Trait Hash and see the resulting rarity and natural faction, part type, and design variant. Or load a sample pair.
First trait = 0, second = 1. Purchase History shows this index for confirmed traits.
Production Rules
The system enforces strict production limits and fairness guarantees to ensure balanced distribution across all factions, part types, and design variants.
Rarity Display Rule
Rarity is derived from the first byte of the Trait Hash and is shown consistently across Purchase History, Treasure Room, Trait Details, and the Verification Tool. This display does not change ownership, Trait Hash, faction, part type, design variant, or assignment time.
If an earlier screenshot shows a different rarity label, it came from a front-end display inconsistency. The underlying assignment data was not rerolled; the current site uses the same launch-era rarity table everywhere.
Common 0-101 | Uncommon 102-178 | Rare 179-224 | Epic 225-247 | Legendary 248-255Production Cap: 1,500 per Combination
Each (faction, partType) combination has a maximum production cap of 1,500 parts, derived from the total supply: 84,000 / 7 factions / 8 part types = 1,500. Once a combination reaches its cap, no more parts of that type can be produced for that faction.
capacity = 84,000 / 7 / 8 = 1,500 per (faction, partType)Deterministic Overflow
When the Trait Hash naturally maps to a (faction, partType) combination that has already reached its 1,500 cap, the system uses deterministic overflow: additional bytes from the Trait Hash (positions 28-31) are used to select an available combination that still has capacity remaining.
The overflow scans all 56 combinations(7 factions × 8 part types) for remaining capacity. This means if an entire faction has reached its cap across all 8 part types (8 × 1,500 = 12,000 parts), the overflow automatically redirects to combinations from other factions that still have room.
This process is fully deterministic — given the same Trait Hash, the overflow always produces the same result, preserving verifiability.
overflowIndex = parseInt(traitHash[28..31], 16) % availableCombos.lengthVariant Reservation Guarantee
Every design variant within a (faction, partType) combination is guaranteed to appear at least once before the cap is reached. The system reserves capacity slots for unseen variants:
effectiveCapacity = 1,500 - unseenVariantsFor example, if Knight Clothing has 65 variants and 50 unique variants have appeared so far, then 15 slots are reserved for the remaining 15. The effective capacity becomes 1,500 - 15 = 1485. Once the produced count reaches this effective cap, the system forces production of missing variants — deterministically selecting from the unseen variants using the Trait Hash.
This ensures complete variant coverage: no design variant is ever left with zero production, creating a balanced and collectible ecosystem.
Design Variant Counts per Faction
Each faction has a unique set of design variants per part type, derived from the actual art assets:
| Faction | Background | Emblem | Body | Face | Head Wear | Clothing | Hand | Weapon | Total |
|---|---|---|---|---|---|---|---|---|---|
| Knight | 8 | 20 | 9 | 33 | 64 | 65 | 22 | 46 | 267 |
| Mithia | 8 | 20 | 16 | 10 | 43 | 80 | 22 | 46 | 245 |
| Adventurer | 8 | 20 | 9 | 33 | 68 | 39 | 22 | 46 | 245 |
| Wizard | 8 | 20 | 10 | 11 | 36 | 31 | 48 | 18 | 182 |
| Grum | 8 | 20 | 11 | 10 | 14 | 105 | 22 | 46 | 236 |
| The Plagued | 8 | 20 | 15 | 21 | 32 | 102 | 22 | 46 | 266 |
| Nightspawn | 8 | 20 | 15 | 11 | 8 | 106 | 22 | 46 | 236 |
Dynamic Scarcity Framework
Design Scarcity is calculated dynamicallybased on actual production data, not pre-defined percentages. As more parts are minted, each variant's scarcity updates in real time.
Note: Design Scarcity measures how rare a visual design is based on production numbers. This is different from Trait Rarity (Common/Uncommon/Rare/Epic/Legendary), which is fixed by the first byte of the Trait Hash.
Scarcity Calculation
For each design variant, scarcity is the ratio of that variant's production count to the total production of its (faction, partType) combination:
scarcity = variantCount / totalProduced(faction, partType)A variant with fewer mints relative to the total has a lower percentage and thus higher scarcity. This metric is fully transparent and verifiable from on-chain data.
Scarcity Tiers
Variants are classified into five tiers based on their dynamic scarcity percentage:
Extremely rare design — minimal production out of 1,500 cap
Highly scarce design — very limited supply
Uncommon design that stands out in collections
Moderately available design variant
Widely produced design variant
Ancient Stele & Mythic Designs
Mythictier designs (scarcity < 2%) feature iconography drawn from the mythical Ancient Stele— ancient stone tablets inscribed with primordial power. These traits include faction leader characteristics, unique visual effects, and historically significant design elements.
Mythic scarcity emerges naturally from the production algorithm. With dozens of variants per combination, some variants will organically receive fewer mints, achieving mythic status. The Variant Reservation Guarantee ensures that even the rarest variants appear at least once.
Bonus Part — TXID Patterns
When certain hexadecimal patterns appear in a Trait Hash, a rare Bonus Part is awarded alongside the regular trait. These patterns arise naturally from Bitcoin transaction hashes.
aceKnight exclusive. Bonus cloak trait — "Oath of the Vanguard": below 30% HP, heal team 15% HP + taunt all 1 turn.
e1fMithia exclusive. Bonus accessories trait — "Grace of Eternity": battle start, shield allies 30% of max HP.
c0deAdventurer exclusive. Bonus accessories trait — "Fortune's Edge": first attack ignores evasion + 50% DEF penetration.
a5ceWizard exclusive. Bonus arcane trait — "Arcane Singularity": spells 15% chance to cast twice.
b100dGrum exclusive. Bonus accessory trait — "Undying Rage": survive lethal hit (1 HP) + ATK ×2 for 1 turn.
deadThe Plagued exclusive. Bonus mutation trait — "Pandemic Protocol": kill spreads all debuffs to nearby enemies.
fadeNightspawn exclusive. Bonus tentacle trait — "Void Anchor": teleport to lowest-HP enemy, ignore DEF 1 hit.
666Universal. Triggers a bonus trait for ANY faction.
777Universal. Triggers a bonus trait for ANY faction.
000Universal. Triggers a bonus trait for ANY faction. Extremely rare.
d1ceUniversal. A roll of fate — triggers a bonus trait for ANY faction.
cafeUniversal. A rare rest stop — triggers a bonus trait for ANY faction.
View real-time production counts and scarcity distribution for all 56 faction × part type combinations.
Scarcity is computed dynamically from real production data and viewable in real time via the Treasure Room. The system is fully transparent and verifiable from on-chain transactions.
Trading & Fusion
Trading
Trait trading occurs on Bitcoin OP_CAT Layer compatible platforms.
Fusion Process
Collect All 8 Traits
Gather all eight matching-faction trait NFTs: Background, Emblem, Body, Face, Head Wear, Clothing, Hand, and Weapon.
Send to Reforging Forge
Transfer all 8 trait NFTs from a single wallet to the official Reforging Forge address. All traits must belong to the same faction.
Burn & Receive PFP
All 8 trait NFTs are permanently burned. In return, a complete PFP character NFT is generated and sent to your wallet.
Creates a scarcity-driven economy that rewards strategic collection.
Cross-Faction Fusion is NOT Allowed
All eight trait NFTs submitted for fusion must belong to the same faction. Mixing traits from different factions (e.g., a Knight weapon with a Wizard body) will cause the fusion transaction to fail. Plan your collection strategy carefully to ensure all traits match a single faction.
