Alchemy Integration: Read-Only On-Chain Quest Verification

What Alchemy does inside Loyalty Stacker

Alchemy provides structured blockchain data and JSON-RPC access; Loyalty Stacker turns selected reads into campaign conditions. A marketer chooses the network, contract and threshold, while a member connects a wallet. At claim time, the program reads the relevant state and decides whether the member qualifies.

The cleanest native cases are current-state checks: holds at least one NFT from this collection, holds at least this amount of an ERC-20 token, or a public read-only contract function returns the expected boolean or number for this wallet. These checks are evidence, not payments. After a pass, Loyalty Stacker updates the member's in-program state. If the operator separately offers an NFT mint or another on-chain benefit, that needs its own member claim and transaction flow; it must not be described as an automatic Alchemy payout.

Configure a read-only eligibility check

1. 1
   Choose the exact network

   Select the supported EVM network used by the asset or contract. Do not assume the same address represents the same asset on another chain.

2. 2
   Paste and verify the contract

   Confirm the contract address, standard and expected asset metadata. For a custom function, use a verified interface where possible and inspect the return type.

3. 3
   Define a current-state rule

   Choose a minimum balance, NFT count, true/false result or numeric threshold. Write the member-facing rule in the same units the contract returns.

4. 4
   Test pass and fail wallets

   Run the check with at least one wallet that qualifies and one that does not. Confirm decimals, token IDs and edge cases before attaching a valuable reward.

5. 5
   Grant the reward inside the program

   On a pass, issue program points, a badge or an unlock. Keep any separate blockchain transaction explicit and member-authorized.

Example: recognize current holders without a snapshot spreadsheet

An NFT project on Base creates a quest for wallets currently holding at least one token from its ERC-721 collection. The member connects an EVM wallet, Loyalty Stacker asks the Alchemy-backed data layer for current ownership, and the claim passes only when the configured collection condition is met. The member receives 250 program points and a Holder badge. The badge unlocks a merchandise item in the rewards shop.

If the member transfers the NFT later, a future gated check should read current state again rather than relying on the old claim as permanent ownership proof. If the project wants to reward a historical minter who no longer holds the asset, that is a different campaign: it requires a tested event-history or project API source and should not be labeled a current-holder quest. See the on-chain quest guide for the full specification template.

Use the smallest reliable proof

A current balance or a single public contract value is easier to explain, test and audit than a vague instruction such as 'be active on-chain.' Start with the narrow rule that actually predicts customer value, then pair it with Discord membership, an API-backed product action or a referral if the campaign needs richer evidence.

Bring the chain, contract address, desired condition, two test wallets and the in-program reward. Contact Loyalty Stacker to confirm whether the condition fits a native read-only quest or needs a custom API/indexer before the campaign is promised publicly.