Quests

Status#

Quests are the platform’s user-directed acquisition budget. A quarter of every reward-earning user’s daily THD allocation is routed into a budget they spend on attracting other users. The platform never spends it and never chooses who receives it.

The 75/25 split#

The split is applied before the allocation reaches the user: a trader earning 100,000 THD on a day takes 75,000 into their claim and 25,000 into their quest budget.

That is larger than any platform bucket, and none of it is the platform’s to spend. Three allocations are deliberately excluded and the reasons differ:

What a campaign is#

A campaign is a sponsor-published task list, a set of rates and a budget. Completers who do the tasks are paid out of that sponsor’s budget, and — where they are not already tied to a referrer — become the sponsor’s referee.

Every row is self-interested, which is the design: a task list built around what the platform wants is a list nobody chooses from. The platform benefits are side effects — curve volume rises because creators want graduation, activation rises because referrers want referees who actually trade.

The six steps#

The budget is on chain. The completions are not. The settlement is a root. That division is the whole architecture.

Why the budget is genuinely on chain rather than a database number: a sponsor is committing tokens to strangers. If the budget were only our record, the sponsor would be trusting us not to renege and so would every completer. Locked in a vault, the money is provably there before anybody does a task.

A leaf is keccak256(abi.encode(index, account, amount)), and amount is the completer’s whole day, summed across every campaign they completed. That is why acceptance is one call however many sponsors paid them, and why the sponsor-side accounting settles at publication rather than at acceptance.

Accepting moves nothing: the THD stays in the vault and becomes the account’s. The vault’s only exit is settleAccepted, which moves accepted balances to the reward distributor, ThdRewardVest — the only caller it accepts — where they vest to the end of the 90-day window from TGE + 24h. Every exit — including both sweeps — points at that one address, and it is whitelist-gated.

Windows and durations#

A lapsed acceptance returns to the sponsor, either through the keeper’s reclaimExpired or through the expiry leg of the next publishRoot, and the return is bounded twice — by the campaign’s own debit for that epoch, and by the epoch’s unsettled remainder.

There is no manual close (owner ruling 28-09-2026). A sponsor may still revoke a signature that has not yet been relayed — the revocation is keyed on the terms rather than the campaign id, because the id is the EIP-712 digest and only exists once the campaign is open.

What the keeper can and cannot do#

campaignId == EIP-712 digest of
  Campaign(address sponsor, bytes32 termsHash, uint256 budget,
           uint64 duration, uint64 validUntil, uint256 salt)

Only the digest is stored. The terms themselves live off chain behind termsHash, and the signature is checked with a checker that accepts EIP-1271, so a Safe can sponsor a campaign.

The owner’s power is narrower still: it appoints the keeper and repoints the reward distributor, and the second is guarded three ways — non-zero, has code, and listed in TreasuryRegistry, whose address is immutable on this contract. That registry gate is what breaks the five-call owner-compromise walk, and it is why the vault is owned by the owner Safe rather than the guardian. See the trust model.