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: of every daily allocation in the groups below, 75% goes into the earner’s own claim and 25% into their quest budget.

That quest pool is larger than any platform bucket, and none of it is the platform’s to spend: the earners who receive it direct it, and the platform has no function that could choose a recipient. The split is not on chain anywhere — it is applied before an allocation reaches a user, and the vault’s creditBatch only moves the result. These allocations are excluded from the split, 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 task menu#

A sponsor builds a campaign from a fixed menu of tasks, and chooses what each one pays. The menu is ordered by what faking a completion would cost the faker, because payout weight is meant to track that and nothing else: a task that costs real money on chain is the strongest signal available, and a task that is free to fake at scale pays at once only while the campaign’s free-step allowance lasts, and after that only once the completer has done a capital or gas task in the same campaign.

How a task is checked is a security property, not a detail. A task read from the chain cannot be asserted into existence by anybody, including the platform. An off-chain check against the X API can be: anybody who can write one database row can manufacture one, which is exactly why those tasks are gated behind a paid one.

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.

Payout batches#

Completions are paid in payout batches. Once a day the quests keeper commits every verified completion since the last batch as one Merkle root — an epoch — with publishRoot, and debits each campaign’s budget, per token, by what its leaves pay. One transaction per day, however many completions it carries. Each leaf names the account it pays, the campaign that funds it and the token it pays in.

Every batch runs on its own clock. Publishing stamps its deadline as publishedAt + CLAIM_WINDOW — 1 day — and that deadline is never inferred from the next batch. A reward is claimed with claim or claimMany inside that window; missing one batch does not roll its rewards into the next. What nobody claims in time returns to the sponsor whose campaign funded it, through reclaimExpired (anyone may send it) or the expiry leg of the next publishRoot. Because the leaf names its campaign and token, nobody chooses which sponsor gets it back.

Claiming THD moves nothing out of the vault: the THD becomes the account’s and waits there. The vault’s only THD exit is settleAccepted, which moves claimed 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. A reward in another token is paid straight to the completer or credited to the 90-day QuestTokenVest, as the campaign chose when it was signed.

Windows and durations#

So a quest runs between 1 hour and 90 days, plus 3 days of settlement grace, and every reward it pays is claimable for 1 day from its batch.

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.