Short answer: Pay for a transaction and you will get transactions. The variable that predicts whether on-chain volume is real is not the chain, the asset or the verification vendor — it is whether the platform paid people per unit of the thing it was counting. Design the reward so the metric cannot be manufactured, then cap how much reward any one wallet can capture.
Disclosure: Zealy publishes this and Zealy sells a quest platform that projects use to drive on-chain activity. That makes the next paragraph the most important one on the page.
What Zealy does not do: Zealy does not verify that on-chain activity is authentic. Zealy's Token and NFT tasks read a wallet balance. Zealy's task called "onChain" does not read a chain at all — on publish Zealy rewrites it into an API task that calls an endpoint the project supplies, and trusts the answer. And Zealy's sybil handling stops at identifier reuse: an anti-cheat score links accounts that share an email, a connected social account or a verified wallet and restricts the ones that pile up, and nothing beyond that separates two genuine identities. All three statements were checked against Zealy's own codebase and public documentation on 14 August 2026; the third was corrected on 17 August 2026, because the first version of this post said Zealy had no such system at all — the search looked for "sybil", and the system is called anti-cheat.
Last verified: 14 August 2026, with the anti-cheat, rate-limiter, captcha and volume-cap claims rechecked against Zealy's source on 17 August 2026 and corrected where they were wrong.
Why paying per transaction produces exactly the volume you paid for
The 2022 Ethereum NFT market came close to a controlled experiment on this question. Analyst hildobby, writing on Dune's blog in December 2022, found that 58% of that year's Ethereum NFT volume carried wash-trading signatures. The split by marketplace is the finding: LooksRare 98%, X2Y2 87%, and OpenSea 2.4%.
Same chain, same assets, largely the same population of wallets. The difference is that LooksRare and X2Y2 paid traders in their own token for trading, and OpenSea did not.
That is the whole argument of this post, and it generalises past NFTs. A quest campaign that pays per transaction is structurally the same instrument as a trade-to-earn token: it attaches a reward to a countable on-chain event, and then counts the events. If the reward per event exceeds the cost of producing the event, someone will produce events. Not because your community is dishonest, but because you asked.
Share of 2022 Ethereum NFT volume carrying wash-trading signatures, by marketplace. Data: hildobby on Dune, 16 December 2022. LooksRare and X2Y2 paid traders in their own token; OpenSea had no trade-to-earn token.
Now the correction, because a post that overstates this problem is as useless as one that hides it.
Wash trading is not most of on-chain volume. Chainalysis reported in January 2025 up to $2.57 billion of suspected wash trading across Ethereum, BNB Smart Chain and Base in 2024. The share is the part worth reading: for November 2024, the same report puts its two detection heuristics at 0.035% and 0.046% of decentralised exchange volume. Chainalysis is also explicit that its method tracks patterns of behaviour and not intent. So: a real, measurable, prosecutable phenomenon, and a small share of the total.
The Dune study makes the same point in a different shape. Wash trading accounted for almost 45% of all-time Ethereum NFT volume by value, but only 1.5% of all trades. A tiny number of addresses cycling large sums distorts a value-weighted metric while leaving a count-weighted one nearly untouched. Which metric you report decides how fooled you get.
Two more pieces of context. The academic work is about a different venue: the NBER working paper published in Management Science in 2023 found wash trading averaging over 70% of reported volume on unregulated exchanges — but the paper studies 29 cryptocurrency exchanges, anonymised behind codes, through statistical forensics on the volume they report about themselves. Nothing in it measures a decentralised exchange, and anyone quoting it as a finding about on-chain volume is quoting it wrong.
And this carries legal risk, not just embarrassment. In March 2021 the CFTC ordered Coinbase to pay a $6.5 million civil monetary penalty, in part over an employee intentionally placing matching buy and sell orders as wash trades. One incident, one company, one regulator — but it establishes that "we were just bootstrapping liquidity" is not a category the law recognises.
One wallet is not one person
Wash trading inflates the value of on-chain activity; sybil farming inflates the count of participants behind it. They are different failures with different fixes, and a campaign can suffer both at once while every individual transaction on the chain remains perfectly genuine and every wallet in the dashboard is real. Counting wallets is not counting people.
The airdrop record is where this is best documented, because airdrops force someone to publish the count. LayerZero disclosed in May 2024 that almost 6 million unique wallet addresses had interacted with LayerZero, and ran a self-reporting window offering sybils 15% of their intended allocation to identify themselves. Cointelegraph reported that 803,093 addresses were ultimately identified as potential sybil addresses, refined down from an initial pool of over two million.
The mechanics scale better than most teams assume. DL News documented an Arbitrum case in June 2023 where one attacker used a wallet to fund over 1,000 accounts, which between them qualified for more than 428,000 airdropped ARB tokens. That is one operator, one funding wallet, and a four-figure participant count in your dashboard.
None of those wallets did anything invalid on-chain — they bridged, swapped and held, and every transaction confirms. The activity is genuine while the population behind it is a fiction.
A wallet connection is a weaker signal still. Zealy's Relative case study reports over 7,500 wallets connected in a month — a count of connections, not of transactions, and quoted here as nothing more than that.
What each verification method actually proves
Every verification method proves one narrow thing and then gets read as proving something much wider. A Zealy campaign can draw on eight, each set out here with what it establishes, what it leaves open, and whose judgment the result rests on. Read the "does not prove" column first, because that is where the surprises are.
| Method | What it proves | What it does not prove | Where the rigor sits |
|---|---|---|---|
| Token task | A connected wallet holds at least a minimum balance of a given token on a given network, optionally for a minimum holding period | How the tokens were acquired, whether they were borrowed for the claim, or who controls the wallet | Zealy reads the balance |
| NFT task | A connected wallet holds at least N NFTs from a collection, optionally for a minimum period | Provenance, purchase price, or that the holder is a distinct person from the other N holders | Zealy reads the balance |
| "onChain" task | Only that an HTTPS endpoint chosen by the project returned a pass. On publish Zealy converts the task into an API task, so this row and the next are one mechanism | Nothing about the chain by itself. Zealy does not query the network | The project's own server |
| API task / Zealy Connect | That the project's endpoint accepted a user's Zealy and linked-account identifiers and returned success | Whatever the project's endpoint did not check | The project's own server |
| Trading-competition volume | Volume the integrated exchange reported for that trader, ranked live | That the counterparties were unrelated, or that the volume was economically motivated | The exchange's reporting |
| Manual review | A human looked at the submission and formed a judgment, with the user's star and flag history visible | Anything the human could not see in the submission | Your reviewers |
| AI Review | A model checked the submission against your written criteria and gave a pass or fail with a reason | Documented gaps: low-resolution or blurry images, handwritten text, exotic fonts, content that needs scrolling or an external link, and tweet threads, which it cannot fetch | Your prompt |
| Proof of Humanity | A member's connected X account looks human rather than automated: it checks for an avatar, rejects accounts following fewer than 50 or followed by fewer than 10, and runs a model over the account | Anything on-chain. It reads no chain data and no Zealy activity | Zealy's heuristic |
The third row deserves prose, because the name is doing real damage.
Zealy's on-chain task is a webhook wearing a blockchain's name. A project configures it with an HTTPS endpoint and a network. When the quest is published, Zealy converts the task into an API task carrying the member's wallet, and at claim time it POSTs to that endpoint and the project's own server returns pass or fail. Zealy never queries a node, never inspects a transaction, and never forms an opinion about what happened on-chain. The task type has no validator of its own in Zealy's backend; the API task it becomes is what does the work.
A webhook is the right architecture. The project knows what "used the protocol" means for its protocol and Zealy does not. But it means the phrase "verified on-chain" on a Zealy campaign describes the project's rigor, not Zealy's. If the endpoint returns 200 for any wallet that ever touched the contract, that is what got verified. The name promises a chain read that nothing in the system performs.
What Zealy does not verify, in plain words
Zealy does not establish that on-chain activity is authentic, that a wallet's holdings were earned rather than borrowed, or that the wallets in a campaign belong to different people. Seven specific limits follow. None are secret, all were checked against Zealy's code and public documentation on 14 August 2026, and none appear in the marketing.
1. Holding is not transacting, and transacting is not being a person. Token and NFT tasks read a balance at claim time. A wallet funded an hour ago passes identically to one that has held for a year, unless you set a minimum holding period — and even then, holding is not evidence of use.
2. The on-chain task is a webhook. Covered above. Any on-chain rigor is yours.
3. Zealy catches identifier reuse, not sybil networks — and this section said something stronger until 17 August 2026. It said Zealy had no sybil detection at all. That was wrong, and the mistake is worth naming: the search that produced it looked for the word "sybil", and the system is called anti-cheat. What packages/api/src/domains/anticheat does: it links your account to every other Zealy account that shares your canonical email (Gmail dots and + aliases stripped), a linked X, Discord or Telegram identifier, or a verified wallet address; counts the linked accounts that have claimed; warns you past one threshold and temporarily restricts the account past the next. A restricted account cannot claim. The thresholds, the restriction length and the window the scoring covers are not printed here — they are the line an attacker would tune against, and Zealy publishes none of them. Two things it is not. It is not per-community — no admin configures it, and it runs across all of Zealy. And it is not wallet clustering: it catches one person recycling identifiers, not one person operating genuinely separate identities with separate wallets, which is the case an on-chain campaign actually has to price. The reviewer-facing duplicate alert, which shows the other members who submitted the same text on the same task, sits behind a per-community review-alerts flag. The community security settings are the complete surface a project can configure: visibility, a minimum XP requirement, invite consumption, and a set of required member details — a connected wallet, Discord, X, X Premium and Telegram, plus a pasted wallet address on communities whose blockchain has no supported wallet connection. Email belongs on that list too: the toggle is gone from the page, but a community that has it set still blocks claims until the member has a verified email, and the setting is still reachable through the community settings API. Note that the two wallet options are not the same: one connects a wallet, the other takes an address the member types in, and Zealy's own interface says "the authenticity of the address can't be verified". There is no sybil toggle, no blocklist and no IP field on that page: the one control that does correlate accounts is the anti-cheat score above, and no community configures it.
And we corrected ourselves on this one. Zealy's own site metadata used to list sybil filtering among the product's capabilities. What the codebase implements is the identifier-reuse score described above, not the filtering that line implied, so it overstated what Zealy does and was rewritten in the same change that published this post. It is named here rather than quietly fixed, because a post about what a platform does not verify has no business hiding an instance of its own publisher doing exactly that.
Galxe does this better than Zealy. Galxe publishes a documented bot-identification system that monitors user activity for patterns differing from typical human behaviour and reads on-chain data for suspicious wallet activity — unusual transaction patterns, rapid address generation, participation in multiple campaigns from seemingly unrelated addresses — and sells an Advanced Sybil Prevention tier to Business+ subscribers on top of it. Zealy has no equivalent capability. If sybil resistance is the deciding factor in your platform choice, that is a reason to choose Galxe, and the rest of the comparison is in Zealy vs Galxe. We would rather you read that sentence here than discover it after a campaign.
For the rest of the category, the information is not published. Searching for and fetching Layer3's and QuestN's documentation on 14 August 2026 surfaced no page describing how either handles sybils — Layer3's blog refused the request outright and QuestN's documentation has no such section — so no claim here is attributed to either.
4. Volume caps bound the prize, not the behaviour. The next section covers this in full.
5. The bot controls that do exist are narrower than they sound, and several are off by default. The captcha on claims containing an X task runs only on the communities where it is switched on, and it does not gate every claim even there. The claim rate limiter counts claims per community over a short window rather than per person — so many accounts each staying under the line are invisible to it. The exact thresholds stay out of this post on purpose: printing the line an attacker has to stay under is a favour to the attacker, and the shape of the control is what changes your campaign design anyway. Automatic rejection of duplicate submissions is a per-task setting on X reply and quote-tweet tasks, defaults to off, and catches duplicate text rather than duplicate people; the reviewer-facing duplicate alert is a separate control gated on a per-community flag.
6. AI Review and Proof of Humanity are content and social-account heuristics. Proof of Humanity reads a member's Zealy profile and connected X account: it wants an avatar, a name and an email on the Zealy side, and on the X side rejects accounts following fewer than 50 or followed by fewer than 10 before a model passes over the account. It does not read the member's quest activity, and neither check touches a chain. Zealy's documentation now says the same: "No Zealy activity is read — not claims, quests, XP, timing or velocity." It described the task as analysing Zealy activity patterns until that page was corrected.
7. IP is seen but not used against you, and one thing is simply not established. A claim's IP address is passed to Cloudflare as part of the captcha check, and the API applies a general per-IP request rate limit, but no IP-based fraud check gates a claim and no IP is stored against one. Separately — and this sentence used to say the opposite — there is a cross-community identity link. The anti-cheat score joins accounts platform-wide on canonical email, shared linked-account identifiers and verified wallet addresses. It reads identifiers rather than behaviour: no device fingerprint, no submission timing, no IP.
Volume caps: the anti-farming control with real teeth
Zealy's trading competitions cap how much volume counts toward the leaderboard per user, per hour and per day. The defaults live in Zealy's API rather than in your hands, and the figures are not printed here. Volume above the cap still happens on the exchange — it simply stops earning rank. The mechanism caps reward capture rather than the trading itself, which is narrower than it sounds and still the strongest control here.
Two conditions worth checking before you rely on it. The caps apply to competitions that run on a daily cycle, and they can be switched off for an individual competition.
Those defaults can be overridden per competition, though not by you. The values live in the competition record, and no public Zealy endpoint creates or updates that record, so changing them is a request to the Zealy team like the rest of the setup.
A cap does not detect self-dealing. A trader wash-trading against themselves inside the cap is invisible to it. What the cap does is change the economics: past the daily limit, every additional dollar of self-wash costs fees and earns zero rank. It makes the attack capital-inefficient rather than impossible, and capital-inefficient is a real defence when the prize pool is fixed.
Zealy also discloses this in its own marketing. The RIZE case study lists, under fair play, "Volume caps enforced per hour and per user to limit abuse", alongside $3.4M in total trading volume over 20 days, an average of $170K daily against a $100K/day KPI, and 300+ unique traders.
One more Zealy competition is published with full figures: a MEXC campaign reporting $9.5M in total volume from $9,800 USDT in rewards over 28 days against a $4.8M target, with roughly 200 daily active traders and a stated reward-to-volume efficiency of 0.103%.
Read both with the caveat attached: these are exchange-reported centralised-exchange volumes, not independently observed on-chain activity. Zealy integrates with the exchange and ranks what the exchange reports. That is a different evidentiary standard from a chain indexer, and the honest thing is to say so rather than let "volume" imply more than it does.
And note where the caps live. Trading competitions are not self-serve: the Zealy team sets each one up against a specific exchange. No equivalent cap exists on ordinary quest claims, so outside a competition this control is not available to you.
How to reward on-chain activity without buying wash volume
No verification method can tell you whether a transaction was economically real, so the reward design has to do that work instead. Five decisions carry most of it: what you pay for, how much you pay, what one wallet can capture, what your endpoint checks, and which number you report. All five are yours, not your platform's.
Reward the outcome, not the transaction. If you pay per swap, you buy swaps. Pay for the state you actually want — a position held through a period, liquidity still present at the end of the window, an account that came back in week three. The 2022 marketplace split exists because trade-to-earn paid the event; OpenSea paid nothing and its wash-trading share was 2.4%.
Make the reward smaller than the cost of faking it. This is the arithmetic that decides everything else. Gas, spread, exchange fees and time are the attacker's cost base. If your per-action reward clears that base, farming is a rational business and someone will run it as one. Price it below, and the economics do the enforcement your verification layer cannot.
Cap what any one wallet can earn. Zealy's trading competitions do this per user, hourly and daily. Outside a trading competition you have to build the equivalent yourself: a first-come-first-served reward with a hard participant limit, a raffle instead of a per-action payout, or an XP-only stage before anything with monetary value.
Decide what your webhook actually checks, then write it down. If you use the on-chain task, you are the verification layer. Minimum transaction size, minimum age of the wallet, funding-source checks, a holding period, a cooldown between qualifying actions — every one of those is a line of code on your side and none of them exist by default. Publish the criteria with the campaign. A public rule is also a deterrent.
Report a metric that farming cannot flatter. Unique wallets is the easiest number to inflate and the one most decks lead with. Prefer wallets still active 30 days after the rewards stopped, median rather than mean position size, or the share of participants who did a second unincentivised action. Those cost more to fake than they pay.
None of this replaces knowing who your first real users are, which is a separate problem covered in how to get your first 1,000 users for a crypto app, or the sequencing question of what a community does in the weeks after a campaign ends, which is in how to grow a crypto community from zero.
The uncomfortable conclusion is that no quest platform can hand you authenticity. Zealy can plumb a verification you define, cap what a leaderboard pays out, and flag accounts that behave like bots off-chain. Whether a transaction meant anything is a question about your reward design, and it stays yours.