StonkBuilder
EN

Editorial / guide

On-Chain Rewards Guide: Evidence and Coverage

By StonkBuilderUpdated 29 Oct 20261 min read

An incoming token transfer is not automatically a verified reward. A careful analysis checks the exact wallet, mint, transaction, instruction path, amount, source, finality, and any available project allocation evidence. Purchases, liquidity movements, ordinary transfers, and ambiguous records should not be silently counted as earnings.

A four-step evidence chain for checking a possible on-chain reward

Check a possible reward step by step

  1. Identify the account and asset. Confirm the network and exact wallet and mint addresses. A symbol, token logo, or explorer label is not a unique asset identifier.
  2. Inspect the transaction. Record the signature, timestamp, result, amount, token account, and instruction path. The Solana history RPC method returns signatures within a node's available history, and transaction details provide the transaction record to inspect. A transfer is still only a transfer until its context supports a reward classification.
  3. Corroborate the source. Check whether the project published an allocation, campaign rule, distributor, or payment record that connects the transaction to a reward. A matching amount or timing can be a clue; it does not prove the source by itself.
  4. State the conclusion and limits. Separate verified records, unresolved candidates, and excluded transfers. Include the date range, retrieval date, provider, missing periods, matching rules, and any price source.

Worked example: an incoming transfer is only a candidate

Suppose an explorer shows a finalized incoming token transfer to a wallet. That observation supports a narrow statement: the wallet received the identified mint in that transaction. Before calling it a project reward, match the transaction to the project's published campaign rule or distributor evidence. If the source cannot be corroborated, label the row unresolved incoming transfer and keep it out of reward totals. A similar timestamp, token name, or amount is not enough to establish the reason for the transfer.

Keep coverage and valuation honest

When a provider returns only partial history, show the coverage state and the periods you could not inspect. A missing record is not proof that a payment never occurred. When an asset has no reliable price for the relevant time, keep the token quantity visible and omit a dollar value rather than inventing one. When two providers represent the same canonical receipt, reconcile them before adding totals.

An account's balance does not explain why tokens arrived. A transfer can reflect a purchase, a liquidity operation, a refund, a gift, a migration, or a project distribution. Do not label uncertain activity as income or claim that an on-chain observation settles legal, tax, program, or eligibility questions.

Continue with how to read an on-chain rewards report and why on-chain data can be incomplete. An evidence-aware, read-only report is not financial advice or a guarantee of future rewards.

For current staking history questions, the JUP Staker Scanner checks public staking records for a chosen period. Its result does not determine eligibility for a third-party reward or program.

The scanner measures JUP held in the supported governance escrow. During a full unstake, escrow custody and voting power can differ; check the official Jupiter Vote portal for current governance and withdrawal rules.

Sources

Reviewed by StonkBuilder Editorial · Last reviewed 22 Oct 2026

Sources