Galxe quests differ in required activity and reward allocation

Social activity, blockchain activity, and imported records require different evidence

Compare task types by the activity they require and the record that establishes completion, rather than counting task cards. A short requirement can involve preparation outside the quest.

Social and community tasks

Social tasks can require follows, posts, or community membership. Their verification methods differ: some evaluate a page visit or intent, while others check completed activity. Read the actual requirement before treating similar task names as equivalent.

Holdings and contract activity

Blockchain credentials can check asset holdings or contract interactions. Holding an asset and performing a transaction impose different demands. The specified wallet, network, and activity determine whether the record matches the requirement.

Imported participant records

Imported credentials use organizer-supplied records or connected data services. Their timing depends on that data becoming available to the verifier. Repeating an external action does not itself update an imported record.

Reward types and allocation methods answer different questions

The reward type identifies the benefit, while allocation determines which qualifying participants receive it. Compare both fields together. A displayed token pool, for instance, describes the campaign allocation rather than an amount owed to every participant.

Points, achievement tokens, and custom rewards

Loyalty points record participation within a reward program. On-Chain Achievement Tokens, or OATs, recognize accomplishments, while NFT rewards provide collectibles with campaign-specific properties. A community role grants the permissions attached to that role. None of these descriptions establishes an automatic entitlement to a future token distribution.

Custom rewards require particular attention to delivery conditions because the organizer distributes them outside Galxe. A successful claim and delivery of the promised benefit can therefore be separate events. Compare the stated benefit and fulfillment requirements, rather than assuming every reward arrives through the same mechanism.

First-come allocation and token raffles

First-come, first-served rewards require qualifying and claiming while an allocation remains available. A raffle introduces winner selection. Completing its tasks establishes eligibility for participation; it does not establish that the participant will receive tokens.

A fixed token raffle assigns the same token amount to each winner, while a luck-based token raffle distributes different amounts among winners. The maximum possible reward in a luck-based campaign describes an upper outcome, not the expected payout for every entrant. Compare the pool, winner count, allocation method, and claim conditions without converting the largest displayed amount into a personal reward estimate.

Can identical tasks have different eligibility requirements?

Identical task lists can have different eligibility requirements because organizers configure participation conditions separately from the visible activities. These conditions can involve previous participation, loyalty points, asset holdings, account characteristics, or measures against multiple-account abuse. An account that qualifies for one campaign may therefore fail another campaign with similar tasks. Compare those conditions before estimating the work involved.

Time sensitivity also changes the comparison. An account-age condition requires elapsed time; completing another social action cannot substitute for that history. Likewise, a requirement tied to previous participation concerns an existing record, rather than willingness to perform the new quest. These distinctions help separate immediately available activities from campaigns that require preparation.

Open full-size image

Sponsored claims and transaction costs need separate treatment

Compare costs at the required activity, quest claim, and prize-transfer stages, because sponsorship does not necessarily cover each stage. The Gas Station can fund supported quest claims and raffle participation. For luck-based token raffles, winners still pay the network transfer fee when moving their prize to their wallet. A sponsored entry therefore does not establish a cost-free payout. Read the fee shown for the particular action before authorizing it.

Open full-size image

Choosing a points quest without committing to a payment

Consider a hypothetical comparison between a points quest and a token raffle. Assume both recognize activity already completed by the participant, require no new account binding or transaction, and show successful verification. The participant wants a recorded points award without personal payment and will stop if the claim requests a fee. These assumptions describe this example, not standard campaign terms.

Both candidates pass the same preliminary checks: existing eligibility, verified activity, and no further task requirement. Their rewards differ. The points quest matches the chosen outcome; the raffle offers a chance at tokens. A larger displayed raffle pool does not change that mismatch.

With sponsorship available, the points claim requests no personal payment. The participant authorizes the claim, then checks that the claimed status and points record reflect the award. Verified task indicators alone would establish only readiness to claim.

Open full-size image

If sponsorship runs out before the claim, the interface asks the participant to pay. The participant declines before authorizing payment. The participant receives no points from the declined claim and pays nothing. A later sponsorship top-up could make another attempt suitable. Once a paid transaction has been confirmed, cancelling a later prompt cannot undo that earlier commitment. In this example, the participant can walk away without a new payment, account binding, or transaction because none was required before the claim.

Why can a completed task still fail verification?

A completed activity can fail verification when the checked account, required condition, or available data does not match. Imported records may also need an update before the verifier recognizes completion. Compare the failed requirement with the activity record before repeating work. Repeating a paid action without identifying the mismatch can add cost while leaving the same condition unresolved.

Recurring quests reset credential verifications and claims when each configured cycle ends. An earlier cycle's completion therefore does not establish completion for the next cycle. This creates a different follow-up obligation from a one-time campaign: participation must satisfy the requirements of the relevant cycle. Recurring quests support loyalty points only.

A missing task record, a losing raffle entry, and an unclaimed prize describe different problems. Verification repair addresses the first. It cannot turn a losing entry into a winning one or extend an expired claim window. The next valid action changes with the status that the campaign actually records.