Guides
How to Run an On-Chain Quest Campaign
A reliable on-chain quest starts with one answerable eligibility question—not a vague instruction to 'be active on-chain.' In Loyalty Stacker, supported EVM quests read current NFT or token holdings or a compatible public contract function, compare the result with your rule, and grant points, a badge or access inside the program. The check is read-only. It does not authorize a wallet transaction or make an automatic token payout.
Choose proof the chain can actually expose
The safest campaign uses current state: an ERC-20 balance, ERC-721 or ERC-1155 ownership, or a public view function returning a boolean or number for the claimant's wallet. Examples include balanceOf(wallet), isWhitelisted(wallet) or stakedBalance(wallet). The return units must be understood and the call must not change state.
Historical claims such as 'bridged last month' or 'lifetime volume above X' may require Alchemy's Transfers API, a subgraph, indexer or protocol API. Loyalty Stacker's native smart-contract quest does not replay a wallet's entire transaction history. If the contract exposes an aggregate such as totalDeposited(wallet), read it; otherwise treat the rule as an API integration project.
| Quest idea | Reliable source | Implementation verdict |
|---|---|---|
| Hold at least one NFT from a collection | Current ERC-721/1155 ownership via Alchemy-backed EVM data | Good native holding quest |
| Hold at least 1,000 ERC-20 tokens | Current token balance, with decimals handled correctly | Good native balance quest |
| Stake at least 500 tokens | Public read-only per-wallet staking balance | Good smart-contract quest if the function is compatible |
| Be on an allowlist | Public boolean function for the wallet | Good smart-contract quest |
| Have voted at least once | Public vote count or status for the wallet | Native only if the contract exposes the value; otherwise use an API/indexer |
| Complete a historical bridge or swap | Defined event-history source, Transfers API or protocol indexer | Custom implementation; do not promise as a generic contract read |
| Reach lifetime trading volume above X | Protocol aggregate function, API or subgraph | Use a readable aggregate or API quest; do not infer from an unspecified history scan |
| Qualify with a TON wallet | Loyalty Stacker's separate TON integration | Document separately; do not attribute TON data to Alchemy |
On-chain quest specification and launch process
- 1Write the eligibility sentence
Use a testable form: 'On Base, the connected wallet currently holds at least one NFT from contract 0x…' Include chain, contract and threshold.
- 2Choose current state or history
If current state answers the question, use a holding or contract-read quest. If the requirement is historical, identify the exact API, event or indexer before campaign copy is approved.
- 3Connect the member wallet
Loyalty Stacker uses Dynamic for wallet connection. Show the required wallet type and let users complete off-chain steps first.
- 4Configure and test the data rule
Select the network and function or holding condition, set the threshold, and test passing and failing wallets. Check decimals and ERC-1155 token IDs.
- 5Set an in-program reward
Choose points, a badge or an unlock. Describe any later NFT or SBT claim as a separate member-authorized action.
- 6Publish with failure guidance
Tell members which chain and wallet are being checked, what the threshold is, and what to do if they connected the wrong wallet or have not yet met the condition.
Worked example: an Arbitrum power-user quest
A DeFi protocol wants to recognize current committed users. Instead of claiming it can scan every swap, it selects a public read-only function on its staking contract: stakedBalance(wallet). The campaign rule is 'connected Arbitrum wallet currently has a staked balance of at least 1,000 units.' The team verifies the contract interface, confirms token decimals, and tests a passing wallet, a wallet below the threshold and a wallet on the wrong network.
A qualifying member receives 300 program points and a Power User badge inside Loyalty Stacker. The badge unlocks a fee-rebate application or partner reward in the shop; the operator handles any external benefit under its own terms. A second off-chain task asks the member to join Discord and verify the relevant role. The campaign now recognizes current protocol commitment and gives the team a channel for continued participation without implying that Loyalty Stacker transferred tokens.
Fraud, freshness and QA controls
Run current-state checks when the member claims and, for valuable gated benefits, again at redemption. A wallet can sell an NFT, unstake or move tokens after an earlier completion. Decide whether completion remains campaign history or each gated action requires current eligibility.
Set completion rules and reward caps. Use one wallet condition per quest so failures are understandable. Never accept a screenshot as a substitute for a supported read. For historical API quests, define the event, contract, chain, time window and duplicate handling. Retest known pass and fail wallets after a contract or provider change.
Read-only means read-only: the quest checks eligibility. It does not request token approvals, sign a transaction, custody assets or send an automatic payout. Program rewards are recorded inside Loyalty Stacker. Any later mint or transfer needs its own explicit flow and authorization.
Use this campaign brief before launch
Record: goal, segment, chain, contract, asset or function, units, threshold, current or historical source, pass and fail wallets, reward, caps, failure message and review owner. This brief keeps marketing, product and community teams aligned.
For a current EVM balance or compatible contract value, use Alchemy verification. For product data or indexed history, scope an API quest. Contact Loyalty Stacker with the brief before assigning a public reward budget.
Quests, referrals, points and wallet cards across Web2 and Web3.
Frequently asked questions
What is the simplest on-chain quest to launch?+
A current holding rule: a connected wallet holds at least one NFT from a specified collection or at least a defined ERC-20 balance on a supported EVM chain.
Can Loyalty Stacker verify any smart-contract action?+
No. A native contract quest needs a compatible public read-only function or current holding condition. Historical events may require a separate API, subgraph or indexer.
Can I reward a past swap or bridge?+
Potentially, but only after defining and testing the historical data source, event, chain and time window. Do not configure it as a generic current-state contract read.
Does the quest send tokens automatically?+
No. It reads eligibility and grants the configured reward inside the program. Any token transfer or mint is a separate, explicit transaction flow.
How should I test an on-chain quest?+
Use a known passing wallet, a known failing wallet and, where relevant, a wallet on the wrong network. Confirm contract address, token decimals, token ID, threshold and member-facing error state.
Keep exploring
Sources
- Alchemy Token API overview (accessed July 12, 2026)
- Alchemy NFT API overview (accessed July 12, 2026)
- Alchemy Transfers API overview (accessed July 12, 2026)
- Alchemy Chain APIs overview (accessed July 12, 2026)
- Dynamic authentication overview (accessed July 12, 2026)
- ERC-721 Non-Fungible Token Standard (accessed July 12, 2026)
Loyalty Stacker is a Gizmolab product. Pricing and competitor details are sourced from public pages on the dates shown and can change. See our editorial & corrections policy.