Use one shared record for who has claimed, then send each approved reward to the recipient’s chosen chain. Five steps cover setting eligibility, locking claims, delivering payments, and checking costs. This keeps users from claiming the same reward through separate chain pools, while giving you a clear way to retry delayed payments.
One shared claim record prevents duplicate payouts
A shared claim record is the source of truth for each campaign. Give every campaign a unique ID, such as “season-12,” and track each eligible wallet against that ID. A wallet can then receive its reward once, even if it uses several chains.
A common mistake is to publish a separate reward list and claim flag on every chain. Someone eligible on three networks could claim three times before those records catch up. Fix this by using one canonical registry—a single authoritative record—and having every payout check it.
For example, say a campaign distributes 1,000 tokens to 100 wallets. If each wallet gets 10 tokens, its claim record must cover the campaign and wallet together. A Merkle proof, a short piece of data showing that a wallet belongs on the published list, lets the contract check eligibility without storing the whole list on-chain.
Follow five steps from reward list to payout
- Set the campaign rules. Choose the campaign ID, eligible wallets, reward amounts, claim deadline, and payout chains. Publish one eligibility list and its Merkle root, a compact fingerprint of that list, so users can verify the same allocation wherever they claim.
- Choose the claim record and payout route. For rewards that users can collect across networks, omnichain interoperability coordinates eligibility and payout through cross-chain messages. Keep the claim registry canonical, then let a user select the destination chain for payment.
- Mark the claim before sending the message. When a wallet submits its proof, check eligibility and whether its campaign-and-wallet record is already claimed. Set that record before requesting the cross-chain payout; this prevents a second request from winning while the first message is still travelling.
- Make delivery safe to retry. Include the campaign ID, recipient, amount, and destination in the message. The destination contract should reject a repeated message ID, so a delayed delivery or operator retry cannot pay twice. If delivery stalls, resend the same request; do not clear the original claim.
- Reconcile the results. Compare claimed records with successful destination payments. Track pending messages separately from failed ones, and keep enough funds on each destination chain for approved rewards. Close the campaign only after pending deliveries are resolved or clearly reported.
Batch work carefully and price both chains
Cross-chain payout takes at least one source-chain transaction and a destination-chain execution, with message delivery handled between them. Fees change with network demand and the route, so check current estimates for both chains before setting the campaign budget. Batching many recipients can reduce repeated setup work, but a large batch may be slower or harder to retry when one part fails.
Test the full route with a small reward first. Confirm that an invalid proof is rejected, a second claim is blocked, and repeating a delivery message does not pay again. In practice, I’d prioritize a single claim record and safe retries; they prevent costly duplicate payouts without making users repeat steps.
For recurring campaigns, reuse the same flow with a fresh campaign ID and eligibility snapshot each time. That gives users one clear claim per campaign and gives operators a record they can reconcile.