Docs·Rewards and mechanics
Rewards and mechanics
THD — the eleven allocations and the unlock
The eleven allocations, the fee meter that releases them, the four payout shapes, and the team's FDV milestone ladder.
THD is The Hood’s platform token. Its entire supply — 1,000,000,000, minted once at genesis, with no mint function — is held by one contract and released against the protocol fees the platform actually earns. This section documents the eleven allocations that supply is cut into, the clock that releases them, and the surfaces they are paid through.
What exists, and where#
| Contract | Status |
|---|---|
THD · THDEmissionControl (eleven buckets) · ThdLiquidityManager · ProtocolFeeSplitter | Deployed |
THDMilestoneClaim — the team bucket’s destination | Deployed · wired to the team bucket |
SpoilsVault · SpoilsSplitter · FortuneWheel · Battlepass · BandRegistry · BandRewardsDistributor · SeasonRewardsPool · ItemMall · ItemPricing · QuestVault · ThdVoting · ThdFeeRouter · ThdLpRewards | Deployed |
Insurance backstop’s THDVestedClaim | Not deployed · bucket destination unset |
ThdRewardVest · ClaimGateAttestor | Not deployed |
The platform as a whole is also not open to the public, which is the notice at the top of every page in this section. The two facts are separate: one is about who may use the platform, the other about which contracts exist on a chain at all.
The eleven allocations#
One percent is 10,000,000 THD. The shares are constructor immutables on the emission contract, with no setter, and they come from params/shared.json → thd.bucketBps — a ratio, identical on every environment.
| # | Allocation | bps | THD | Destination |
|---|---|---|---|---|
| 0 | Traders | 2200 | 220,000,000 | Public |
| 1 | Creators | 1500 | 150,000,000 | Public |
| 2 | KOLs / referrers | 1700 | 170,000,000 | Public |
| 3 | Liquidity | 1200 | 120,000,000 | Locked |
| 4 | LP providers | 1000 | 100,000,000 | Public |
| 5 | Spoils | 1100 | 110,000,000 | Public |
| 6 | BD / marketing | 400 | 40,000,000 | Platform |
| 7 | Ecosystem grants | 300 | 30,000,000 | Platform |
| 8 | Insurance backstop | 300 | 30,000,000 | Platform |
| 9 | Team | 200 | 20,000,000 | Platform |
| 10 | Settlers | 100 | 10,000,000 | Public |
| Destination | bps | THD |
|---|---|---|
| Public | 7600 | 760,000,000 |
| Locked | 1200 | 120,000,000 |
| Platform | 1200 | 120,000,000 |
Three of the allocations split again — 75% to the earner’s own claim, 25% into a quest budget they direct. That is 116,250,000 THD, 11.6% of supply, routed through user-directed acquisition. See quests.
The unlock clock#
One rule, applied identically to every allocation. Nothing unlocks on a calendar; it unlocks when the platform earns.
counted = min( that day's protocol fees, maxCountedPerEpoch );
// THDEmissionControl.totalUnlocked()
effective = min( feeSplitter.totalProtocolFeesReceived(), FEES_TO_FULL_EMISSION );
unlocked = effective * 1_000_000_000e18 / FEES_TO_FULL_EMISSION;| Parameter | Where it comes from | Production | Dev and staging |
|---|---|---|---|
FEES_TO_FULL_EMISSION | A constructor immutable, from money.feesToFullEmissionWei. No setter. | 150 ETH | 0.000015 ETH |
maxCountedPerEpoch | A constructor immutable on ProtocolFeeSplitter, from money.protocolFeeMaxCountedPerEpochWei | 2 ETH per UTC day | 2 ETH per UTC day — the same figure |
| Epoch | EPOCH_SECONDS, a fixed window keyed on timestamp / 86_400 | One UTC day | |
| Minimum duration | FEES_TO_FULL_EMISSION / maxCountedPerEpoch | 75 days | Not comparable — the numerator is scaled and the denominator is not |
An unlock percentage without its denominator is not comparable with anything. FEES_TO_FULL_EMISSION is per deployment, so a testnet percentage is a percentage of a different number. Every published unlock figure carries feesToFullEmissionWei beside it. See THD and the fee meter for the meter’s own definitions.
The set has two phases and they fall out of when each pot is funded rather than from a stored schedule. Acquisition — traders, creators, KOLs and settlers, 5,500 bps — runs during the unlock and ends by itself, because every acquisition pot is share × that day’s unlock and there is no pot once the unlock completes. Retention — LP providers and Spoils, 2,100 bps — accrues during the emission and is held: LP providers starts only after full unlock, and Spoils starts once THD is trading. No end date is stored anywhere, so none can drift.
How an allocation is paid#
| Shape | Contract | How it releases |
|---|---|---|
| Merkle | THDMerkleDistributor | Claim opens at TGE + 24 hours and closes claimWindow later — 360 days on production, from time.thdMerkleClaimWindowSeconds. The root is replaceable only while nothing has been claimed and freezes permanently on the first claim. After the deadline, THD still held for projects that never graduated goes to Spoils through sweepUngraduatedToSpoils(); burnUnclaimed() then burns what was credited and never claimed — permissionless, no destination and no amount to choose, and it re-reads totalSupply(). |
| Vested | THDVestedClaim | A 24-hour cliff from TGE, then straight-line over an immutable duration — 365 days for BD/marketing and 90 days for ecosystem grants and the insurance backstop on production. Vested THD stays in the contract until its controller (the owner Safe) directs it: releaseTo(to, amount) pays the named recipient directly and is the only way THD leaves. The controller never receives THD. The allocation is measured as balanceOf(this) + released, never snapshotted. |
| Milestone | THDMilestoneClaim | The team only. Released against measured FDV rather than against time — see below. |
| Safe | — | Liquidity pays its destination directly, with no claim schedule. A bucket whose destination reads as the zero address is a recorded fact — some are deliberately left unset until the Safe that will hold them exists, and those buckets refuse to pay until then. |
The team's FDV milestone ladder#
The team’s 200 bps — 20,000,000 THD — is not on a clock. THDMilestoneClaim contains no time-based vest at all. It releases one tenth of the allocation per $10,000,000 of measured fully-diluted valuation, to a ceiling of $100,000,000.
| Step | FDV threshold | Cumulative THD | Cumulative % of supply |
|---|---|---|---|
| 1 | $10,000,000 | 2,000,000 | 0.2% |
| 2 | $20,000,000 | 4,000,000 | 0.4% |
| 3 | $30,000,000 | 6,000,000 | 0.6% |
| 4 | $40,000,000 | 8,000,000 | 0.8% |
| 5 | $50,000,000 | 10,000,000 | 1.0% |
| 6 | $60,000,000 | 12,000,000 | 1.2% |
| 7 | $70,000,000 | 14,000,000 | 1.4% |
| 8 | $80,000,000 | 16,000,000 | 1.6% |
| 9 | $90,000,000 | 18,000,000 | 1.8% |
| 10 | $100,000,000 | 20,000,000 | 2.0% |
The thresholds are step × STEP_FDV_USD where STEP_FDV_USD = 10_000_000e18 — USD at 18 decimals, which is a deliberate, owner-ruled exception in an otherwise ETH-denominated system. The release is allocation × step / STEP_COUNT, clamped to the whole allocation at step 10, and the allocation is measured as balanceOf(this) + claimed + burned rather than snapshotted — so it is invariant across a claim and across a burn.
A step is a threshold, not a rung climbed one at a time. A first confirmation at $55,000,000 confirms five steps at once.
How the FDV is measured#
| Property | Value |
|---|---|
| Oracle | PoolMetrics, held as an immutable. A settable oracle would be the platform attesting the number that unlocks the platform’s own team tokens. |
| Statistic | minFdvUsd — the lowest valuation sampled across the trailing window. Not a TWAP and not a spot price: a gate asks “did it hold above a bar?”, and the only statistic that answers that is a minimum. |
| Window | PoolMetrics.CONFIRMATION_WINDOW, from time.fdvConfirmationWindowSeconds — 259,200 seconds, 3 days, on production; 900 on dev and staging. The listing gate keeps WINDOW, 7 days. |
| Sampling | At most every MIN_POKE_INTERVAL — 300 seconds on production — with MAX_SAMPLE_GAP at four times that. Covering a 3-day window therefore needs on the order of eight hundred consecutive samples, none of them below the bar. |
minConfirmationWindow | A second, deployment-time floor: the constructor reads PoolMetrics.CONFIRMATION_WINDOW() and refuses a window shorter than it. On production it resolves from the same time.fdvConfirmationWindowSeconds, so 3 days. |
A confirmed step is irreversible. The high-water mark ratchets upward only, and a fall in FDV can never re-lock one. The reasoning is in the source: if a fall could re-lock, two people with identical entitlements would be paid differently according to how quickly they pressed a button — whoever claimed while the price was up keeps their THD and there is no clawback path. The only coherent design is the one where being slow costs nothing.
The property that buys: releaseTo() never reads the oracle. An outage, a stopped keeper or a dead price feed can delay the next step and can never withhold one already earned. confirm() is permissionless and separate from paying out; releaseTo() is controller-only and pays the recipient the owner Safe names — never the Safe itself. confirm() works with no controller set, so a step reached while the controlling Safe is still being deployed is still recorded.
The one thing that can shorten the ladder is burnUnreached(), an owner-only, irreversible call with no deadline. It destroys the THD backing every unreached step, re-reads totalSupply(), and drops the ceiling to the confirmed step in the same transaction so no later confirmation can record an entitlement nothing can pay. It cannot touch a confirmed step or anything a claim already owes.
The sinks, and what is not revenue#
Two contracts destroy THD that a user spent, and both prove the burn by re-reading totalSupply(): the battlepass (premium, and the late-claim penalty) and the item mall (every platform-shop receipt). A third destroys THD nobody earned: Spoils, on a day the platform under-earned. A fourth may: the burn/recycle vote, on the pool’s THD fee leg.
A burn in this system always means burn() with the supply re-read and the call reverted if the supply did not fall by exactly the amount. A transfer to a dead address is not a burn: it leaves every explorer, aggregator and market cap quoting the pre-burn number for ever, which defeats the point of burning at all. No contract in this section writes one.