Quest platforms promise measurable onboarding: set tasks, attach a reward, watch wallets complete them. What they reliably deliver is completions. Whether those completions belong to people who will ever return is decided entirely by design, which is the core of how to run a quest campaign, and most are designed to be farmed.
This is how to run a quest campaign that leaves users behind rather than a completion count.
1. Define the behaviour you want repeated
Write down the single action that would make someone a real user: a first swap, a deposit held for a week, a position opened, a governance vote. That action is the campaign. Everything else is decoration around it.
Campaigns built around following an account and joining a channel measure nothing, because the cost of doing both is a few seconds and the accounts doing it exist for that purpose.
2. Make the tasks cost something a farm will not pay
Automation is cheap for social actions and expensive for anything requiring capital, time or a wallet with history. Tasks that involve an on-chain transaction, a holding period, or a minimum wallet age are the ones that filter.
The filter does not need to be harsh. Requiring that a deposit remain in place until the campaign closes removes most farming, because the strategy depends on completing and withdrawing immediately.
3. Size the reward against the effort, not the market
A reward far above the effort attracts people whose interest is the reward. A reward far below it attracts nobody. The useful range is one where a genuine user considers the task worthwhile and a farm operator does not consider it worth scripting.
Non-financial rewards are underused here. Early access, a role, a place in a queue and recognition all attract people who want the thing rather than the resale value, and none of them can be liquidated on receipt.
4. Set the eligibility rules in advance and publish them
Wallet age, prior activity, a limit of one reward per address cluster, exclusion of addresses funded from the same source. Publish these at the start, not after the campaign, because retroactive disqualification is the fastest way to turn a campaign into a public dispute.
Say plainly that Sybil filtering will be applied and roughly on what basis. Detail invites evasion, silence invites accusations of arbitrariness after the fact.
5. Choose the platform for its filtering, not its reach
Quest platforms differ mainly in how seriously they detect automation and how well they verify on-chain conditions. A platform with a large user base and weak filtering delivers a large number of worthless completions, which is the worst possible outcome because it looks like success.
Ask what their Sybil detection actually does, whether you receive the raw address list, and whether you can exclude addresses before rewards are distributed. If the answer to the last one is no, the campaign cannot be corrected once it starts.
6. Run a short campaign with a fixed end
Two to four weeks with a published end date works better than an open-ended programme. It creates a reason to act now, it caps the exposure, and it gives a clean measurement window.
Continuous quest programmes drift into a fixed population of participants who complete every task and use nothing, which is the pattern that makes teams conclude quests do not work.
7. Distribute rewards on a stated schedule
Say when rewards arrive and then send them then. Delayed or silently changed distributions are the most common source of reputational damage from quest campaigns, and the complaints outlive whatever the campaign achieved.
If Sybil filtering removes a large number of participants, publish the count and the criteria rather than quietly paying fewer people than completed.
8. Measure retention, not completions
The number that matters is how many participating addresses are still active thirty days after rewards were distributed. Completion counts are available immediately and describe nothing.
Across the task campaigns we have run, retention tracks the difficulty and on-chain nature of the tasks far more closely than it tracks reward size. Campaigns with harder tasks and smaller rewards consistently leave more real users behind than the reverse.
Write the brief the platform needs
A quest platform builds what the brief describes, and a vague brief comes back as tasks that verify nothing. Specify each task with the contract address and the chain it runs on, the exact condition that counts as completion, the window in one named timezone, and the reward asset with the wallet it will be paid from.
Put the exclusion list in the same document. Addresses belonging to the team, to testers, to earlier campaigns and to anybody paid by the project should never appear in a reward file, and stripping them out afterwards is a manual job that somebody will get wrong at the end of a long week.
Ask how every condition is verified before signing anything. A task checked by reading the chain is worth running. A task checked by asking the participant to paste a transaction hash is a form, and forms get filled in with somebody else’s hash by people who do this for a living.
Agree funding, fees and deliverables
Settle who holds the reward budget and when it moves. Funding the platform up front means trusting it with the whole amount, while funding at distribution means proving the wallet is ready before results are announced. Either arrangement works, and the failure is deciding halfway through with several thousand participants waiting for an answer.
Write the deliverable into the contract as the raw address list with per-task completion data rather than a summary. Without the addresses there is no retention measurement afterwards and no independent check on the completion count you are being billed against, which makes the invoice the only version of events.
Cover unclaimed rewards too. A share of participants never claim, and whether that budget returns to the project or stays with the platform is an argument worth having before the campaign rather than in the week after it closes, when the position each side takes is already decided by who is holding the tokens.
Track the cohort from day one
Take a snapshot of active addresses before the campaign opens. Without a baseline, activity during the campaign has nothing to be measured against, and any figure published afterwards describes the campaign and the wider market at once with no way to separate them. The snapshot costs one query and cannot be reconstructed later.
Tag every participating address as a cohort and measure it with the definition used to design the campaign. If the target action was a deposit held for a week, the retention question is how many of those addresses still hold a deposit, not how many showed up again for any reason at all.
Keep a second cohort for addresses that completed and were then filtered out. The difference between the two groups is the only honest measure of whether the filtering worked, and it is the first number to look at when designing the campaign after this one rather than repeating the same rules by default.
How to run a quest campaign safely
Safety here is mostly about what gets promised. Publish the rules, the end date and the distribution date, then change none of them. A campaign that adds a condition after launch, however reasonable the condition is, reads as a way of paying fewer people, and that reading is very difficult to argue against in public.
Give a short appeals window once the filtered list is published, with a stated closing time and one place to appeal. Address filtering catches genuine users occasionally, and somebody who can point at their transaction and get a decision within days does not become a complaint that follows the project into the next campaign.
Knowing how to run a quest campaign also means knowing when to stop one early. If the completion pattern shows a farm has found it in the opening days, closing and paying what was genuinely earned costs less than running the full window and disqualifying most of the list at the end of it.
What to do when it breaks
The common failure is verification that stops working, usually because an address was wrong in the brief or an indexer has fallen behind. Pause new completions rather than letting them pile up, say what happened in the channel the same day, and extend the window by the length of the outage instead of quietly ignoring it.
If the reward wallet is short at distribution, publish the delay with a date before anybody has to ask. Silence at the moment rewards were promised is what produces complaints that outlive the campaign entirely, and a stated new date costs almost nothing against that. Meeting the new date matters more than the original one.
If a bug lets people complete a task without doing the work, decide quickly whether to honour those completions. Paying for an error the project made is usually cheaper than the argument that follows, and the correct fix is closing the task rather than disqualifying the people who happened to find the gap.
Mistakes that waste the reward budget
Paying before filtering is the first and the worst. Once tokens are distributed there is no recovery, so filtering has to happen on the list rather than on the complaints afterwards. Anything else pays the farm in full and asks the genuine participants to be patient while the project works out what happened.
Choosing a reward that can be sold within the hour is the next, and it decides the audience before the task design gets a chance to. Rewards that arrive with a holding condition, or that cannot be traded at all, select for people who wanted the thing rather than people who wanted the exit.
The last is running a campaign against a product with no second visit in it. A campaign can bring a wallet to the contract once. Whether it comes back is decided by the product, and no amount of task design compensates for a first visit that had nothing worth returning for.
Handle the rewards distribution cleanly
Distribute in batches and check the first batch landed before sending the rest. A wrong decimal or a wrong asset in a single large transaction is unrecoverable, and the small batch that fails loudly is the cheapest error the campaign can produce. Publish the transaction hashes so participants can verify their own payment without asking.
Expect a number of addresses to fail delivery, whether through a contract that cannot receive the asset or a chain the participant never used. Set a claim deadline, state it with the rules, and hold the residual until it passes rather than leaving the question open for months while people ask about it.
Answer the reward questions in one public place rather than individually. A pinned post with the criteria, the filtered count and the transaction hashes handles most of the volume, and it leaves the community managers free for the cases that are genuinely wrong rather than the ones that are merely unanswered.
Decide what happens after the campaign
Plan the week after distribution before the campaign opens. Participants who did the work are at their most reachable immediately afterwards, and a project with nothing prepared for that week converts a spike into nothing at all. Something as small as a next action with a reason attached changes the shape of the retention curve.
Separate the people who engaged from the addresses that completed. A participant who asked questions, reported a bug or stayed in the channel is a different asset from a wallet that met a condition, and the names are worth keeping in a list that a human being actually reads later.
Write down what the campaign cost per retained address and keep it next to the design. That single figure, compared honestly across campaigns, is what tells you whether the harder tasks were worth the smaller completion count, and it is the only defence against repeating a campaign because the completion number looked impressive.
Walk through every task before launch
Complete the whole campaign yourself from a wallet with no history, on the day before it opens. Reading the task list is not the same as doing it, and the errors that appear are the ordinary ones: a condition that registers late, a task that cannot be completed on a phone, and an instruction that assumes knowledge the participant does not have.
Confirm each completion actually registers on the platform rather than assuming the verification works because it was specified. A task that silently fails to record is indistinguishable from a task nobody attempted until the support messages arrive, and by then the participants who gave up have gone and will not come back for the second attempt.
Check the reward wallet balance, the end time in the timezone you published and the wording of the rules page on the same pass. These are the parts nobody looks at again once the campaign is live, and every one of them has been the cause of a campaign that had to be paused publicly in its first day.
How to run a quest campaign, and what it is not
It is not a substitute for a reason to use the product. If the underlying thing is not worth returning to, the campaign buys a spike and the retention curve returns to where it was, which is the honest description of most published quest results.
It also is not a community. Participants arrive for a task and are not in conversation with anyone. Turning some of them into a community is separate work, covered in how to build a Telegram group from zero.
For campaign design, Sybil filtering and the retention measurement afterwards, that is what our crypto community management page covers.