- thd
- tokenomics
- team
- mechanics
The team unlocks on market cap, not on a calendar
Two percent of supply, released in ten equal steps, one for every ten million dollars of valuation the market has held. There is no clock in the contract at all — and a spike does nothing, because the measure is the lowest sample across the whole window rather than an average.
The team allocation is the part of a token nobody trusts, and the usual answer is a cliff and a linear vest. Twelve months, then twenty-four more, unlocking every block regardless of whether the product did anything. It sounds conservative and it is not: it pays for elapsed time, which arrives whether or not anybody built anything with it, and the unlock lands on the market at a date chosen before anyone knew what the market would look like.
The team share here is 2% of supply — 20,000,000 THD — and it has no clock in it. Not a long one. None. The contract holding it cannot tell you what day it is.
Built, not yet live
This contract is written and is deployed nowhere. No step has been confirmed, nothing has been claimed, and the token is not trading. What follows is the mechanism.
Ten steps, ten million dollars apart
| Valuation held | Unlocked at that step | Cumulative share of supply |
|---|---|---|
| below $10M | nothing | 0% |
| $10M | 2,000,000 THD | 0.2% |
| $20M | 2,000,000 THD | 0.4% |
| $50M | 2,000,000 THD | 1.0% |
| $100M | 2,000,000 THD | 2.0% — all of it |
Nothing unlocks unless the market values the token at ten million dollars or more, and no amount of waiting substitutes for it. A team that ships nothing holds nothing, for ever, and "for ever" here is the literal contract behaviour rather than a promise.
A threshold is not a rung to be climbed one at a time, either. A first confirmation at $55M confirms five steps, because a window minimum of $55M is evidence that every threshold from $10M up to $50M was held across that same window. Refusing to credit the lower ones would punish the token for performing better than the last reading.
The measure is a minimum, and that is the entire design
The valuation is read as the lowest sample across a trailing window, and only when that window is fully covered. It is not a spot price, not a time-weighted average, and not a figure anybody attests to.
The difference between a minimum and an average is not a detail — against an unlock gate it is the whole thing:
| A time-weighted average | A window minimum | |
|---|---|---|
| The statistic | The average across the window | The lowest sample in it |
| To push it above a bar | Hold a high price for part of the window | The price must be above the bar at every single sample |
| What a spike does | Lifts it, in proportion to how long it lasted | Nothing |
Take a three-day window with the bar at 1.0 and the true price at 0.9. Manipulate to 4.0 for twelve of the seventy-two hours and the average comes out at 1.42 — clearing a bar it had no business clearing, for twelve hours of holding. The minimum is 0.9, and it fails. To pass a minimum the price has to be held up for the entire window, against arbitrage the whole time: every minute the price is above its true level is a minute somebody is selling into it.
On the production settings the pool is sampled at most every five minutes across a three-day window. Moving one step means holding above the bar for on the order of eight hundred consecutive samples, with not one of them below. One sample below the bar and the minimum is that sample.
A three-day hold
The measuring contract judges one record of samples over two spans: seven days for listing a token as a prediction-market currency, and three days for a milestone confirmation. The team's unlock reads the three-day span.
The three cheap attacks on a minimum, and what closes them
A minimum is only as good as the evidence it is a minimum of. All three of the obvious ways to poison that evidence are closed before this contract sees a number:
| Attack | What closes it |
|---|---|
| Cherry-pick the samples — only record at the peaks, so the "minimum" is a peak | Coverage is a density test, not a count. The record has to be continuous across the window, so clustered samples do not make one |
| Start sampling today and claim a week of history | An anchor at or before the window's start is required. A record that does not reach back is not covered |
| Read the valuation while the price feed is down and call it zero | A sample taken with no usable ETH/USD feed carries no dollar figure, and a window containing one is not covered |
And when the window cannot be described at all — nobody sampled long enough, somebody stopped, the feed was out — the measurement comes back as zero with a "not covered" flag. Zero reads perfectly well as "the valuation is nothing", which would confirm no steps and look like a normal quiet day.
So the contract never reads it. It reverts, naming the sample count, the last sample time, the window length and whether the price feed is usable right now, so whoever called learns which of the four problems they have. There is no cached last-known valuation anywhere in it, so "whatever it was last time" is not a state this contract can be in.
Confirming and claiming are two separate calls
| Confirm | Claim | |
|---|---|---|
| Reads the valuation oracle | Yes — it is the only thing that does | No |
| Who may call it | Anyone | Anyone |
| Where value goes | Nowhere | A destination held in storage, always |
Combining them was considered and rejected, because it would couple a payout the contract already owes to the health of a price oracle. Split as they are, a stopped sampler or a dead feed can delay the next step and can never withhold one already earned.
Both calls are permissionless, and the claim always pays the same stored destination — whoever submits the transaction appears nowhere in the transfer, so the beneficiary never needs to hold gas to be paid.
A confirmed step is permanent, and a burn makes the next one harder
A step, once confirmed, does not un-reach. A later fall in valuation does not re-lock it, and the reason is worth stating because the alternative fails invisibly. If a fall could lower the ladder, two people with identical entitlements would be paid differently according to how fast they pressed a button: whoever claimed while the price was up keeps their tokens — they have left the contract and nothing brings them back — and whoever waited is re-locked. The schedule would reward speed at the button rather than the performance it exists to reward.
Meanwhile each sample values the token at the pool's price against THD's live total supply, and the step reads the lowest of those samples. Every burn elsewhere in this system lowers that supply, which lowers the valuation at any given price, which makes each remaining step slightly harder to reach.
That direction is chosen rather than accidental. A constant supply would overstate the valuation by everything ever burned, and it would do so in exactly the direction that grants a team unlock nobody earned — which is the one direction the measuring contract refuses to err in anywhere.
The team can finish before the public curve, and that was decided on purpose
The public allocations vest linearly over ninety days. This schedule has no clock, so a strong market can complete it sooner. A floor at the public curve was proposed and refused: the schedule is performance-based, and adding a time floor would turn it back into a time vest with a market-cap gate bolted on.
Steps that are never reached are destroyed, not swept
If the valuation never holds above ten million dollars, every token in this contract is unclaimable for ever — 2% of supply that no address can spend, while every explorer and market cap goes on counting it. That is a permanent lie in the supply figure.
So the unreached portion can be burned: burn(), with the total supply re-read, lowering it for
real. A sweep to a treasury was rejected outright — it cannot lower supply, and it would turn the
team's unearned allocation into a transfer the platform makes to itself.
The residual is recorded rather than argued away: that burn is owner-only and has no deadline. The key can destroy the unreached portion at any time. It cannot redirect it, cannot accelerate a step, cannot pay anybody, and cannot reach tokens a confirmed step has already unlocked.
Reading it yourself
STEP_COUNTandSTEP_FDV_USD— ten, and ten million dollars at eighteen decimals. Both constants; no transaction changes either.highestStepConfirmed— how far the ladder has actually got. This is the number that matters, and it only ever ratchets up.claimable()andclaimed— what is owed now and what has already gone.poolMetrics— the valuation source, and it is immutable. A settable oracle on the contract that unlocks the team's own tokens would be the platform attesting the number that pays the platform, reached by a different route.burned— what was destroyed for never having been earned.
What a quiet day does to the supply covers the other half of this: the rewards pot that destroys its shortfall rather than releasing it on a clock. The fees and payouts page covers where the revenue underneath all of it comes from.