Earn to Play: A Technical Guide to Blockchain Game Economies and Reward Verification

Scope and the direct answer

Earn-to-play games pay players in on-chain assets: a fungible game token, an NFT, or both. The payment is a transaction, and like any transaction it can be inspected, timed, and priced. That makes earn-to-play evaluation an infrastructure problem as much as a gaming one.

The direct answer to "do earn-to-play games actually pay?" is: some do, but the amount you keep is gross reward minus gas, marketplace fees, and the time cost of the activity, and it is denominated in an asset whose price moves. A game that pays 100 tokens worth little at claim time may look generous in a dashboard and disappointing in a wallet.

This article covers how to verify a reward end to end using standard JSON-RPC calls, how to build a measurement table you can rerun, and which failure modes to expect. It does not recommend specific games; game discovery belongs in directories, while the verification method below is game-agnostic.

• Assumption: you have an RPC endpoint for the game's chain and a wallet address that received a reward.
• Assumption: you can read the game's public contract or documentation for the reward token address.
• Out of scope: legal or tax treatment of game rewards, which varies by jurisdiction.

How earn-to-play rewards are issued on-chain

Most earn-to-play economies follow one of three patterns. In a mint-on-claim model, the player calls a claim function and the game contract mints new tokens to the player, subject to cooldowns or caps. In a treasury transfer model, the contract holds a pre-funded balance and transfers tokens on claim. In an off-chain ledger with periodic settlement model, the game tracks points in a database and batches payouts, so the on-chain transaction arrives later and may cover many players.

Each pattern changes what you can verify. Mint-on-claim and treasury transfers are visible immediately as a transaction from or to the game contract. Batched settlement means your individual reward may appear as one transfer inside a larger transaction, so you need to inspect logs rather than just the top-level transfer.

NFT rewards add a second layer: the token ID, metadata URI, and royalty configuration determine whether the asset is liquid and what it costs to sell. A reward NFT with a high creator royalty and thin marketplace liquidity can be worth far less than its listing price suggests.

Prerequisites for a reproducible reward check

Before measuring anything, collect four pieces of information: the chain ID, the game's reward contract address, the reward token address (or NFT contract), and the transaction hash of a payout you received or observed. With those, every check below is deterministic.

You also need an RPC endpoint. Public endpoints often rate-limit or prune logs, which breaks historical queries; a dedicated endpoint avoids that. OnFinality's multi-chain RPC endpoints cover many game chains, and you can compare plans on the RPC pricing page. If you are running your own indexer for a game economy, a dedicated node gives you stable throughput for repeated log scans.

Store the endpoint in an environment variable so the same scripts work across chains:

• Chain ID of the game's network (confirm it matches the RPC you use).
• Reward token or NFT contract address from official documentation.
• A payout transaction hash, either yours or one from a public explorer.
• The block number range you intend to scan, kept small to avoid timeouts.

export RPC_URL="https://your-endpoint.example"
export GAME_CONTRACT="0xGameContractAddress"
export REWARD_TX="0xPayoutTransactionHash"

Step 1: confirm the payout transaction and its status

Start with the transaction receipt. A status of 0x1 means the transaction succeeded; 0x0 means it reverted and no reward moved, regardless of what a game UI displayed. The receipt also gives you the logs, gas used, and effective gas price, which you will need for the cost calculation.

Run this against your endpoint:

• Check status first; a reverted claim is the most common false positive.
• Record gasUsed and effectiveGasPrice for the net-earnings calculation.
• Note the blockNumber so later log queries use the same block.

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getTransactionReceipt",
    "params": ["'"$REWARD_TX"'"]
  }'

Step 2: decode the transfer logs to find the actual amount

The top-level transaction may be a claim call, a batch settlement, or a proxy invocation. The amount you received lives in the ERC-20 Transfer event or the ERC-721 Transfer event. Filter logs by the reward token address and your wallet address to isolate your payout.

The ERC-20 Transfer topic hash is 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef. The to field is your address, left-padded to 32 bytes. This Python snippet uses only the standard library:

• Divide the raw amount by 10^decimals from the token contract's decimals() call.
• If no matching log appears, the reward may have been batched to a different address or paid in a different token.
• For NFT rewards, the third topic is the token ID rather than an amount.

import json, os, urllib.request

rpc = os.environ["RPC_URL"]
tx = os.environ["REWARD_TX"]
wallet = os.environ["WALLET"].lower().replace("0x", "")

def call(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(rpc, body, {"Content-Type": "application/json"})
    return json.load(urllib.request.urlopen(req))["result"]

receipt = call("eth_getTransactionReceipt", [tx])
topic_to = "0x" + wallet.rjust(64, "0")
transfer_topic = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"

for log in receipt["logs"]:
    if log["topics"][0] == transfer_topic and log["topics"][2] == topic_to:
        raw = int(log["data"], 16)
        print("token", log["address"], "raw amount", raw)

Step 3: price the reward and subtract the costs

A reward is only meaningful in a unit you can compare across games. Convert the token amount to a common unit using a price source you trust, then subtract the gas you paid to claim and any marketplace fee you would pay to exit. The result is your net reward for that claim.

Build a table like this for each claim you observe. Leave the value cells blank until you have measured them; do not fill them with estimates from a game's dashboard.

• | Field | Source | Example format |
• | Gross token amount | Transfer log, divided by 10^decimals | 125.0 GAME |
• | Token price at claim time | Your chosen price source, timestamped | $0.04 |
• | Gross value | Amount × price | $5.00 |
• | Claim gas cost | gasUsed × effectiveGasPrice × native price | $0.12 |
• | Exit fee | Marketplace or DEX fee for the token | 2% |
• | Net value | Gross value − gas − exit fee | $4.78 |
• | Time spent | Your own log of active minutes | 45 min |

Step 4: verify the contract's reward rules before trusting a rate

Games often advertise an earning rate that the contract does not guarantee. Read the reward contract's public functions and events to see whether the rate is fixed, governed by an admin key, or dependent on a treasury balance. A treasury-transfer model can pay until the balance runs out; a mint-on-claim model can inflate supply and depress price.

Useful checks include the treasury token balance held by the game contract, the presence of pause or admin-withdraw functions, and whether claim caps are enforced on-chain or only in the game server. If the caps exist only off-chain, your on-chain verification cannot confirm them, and you should treat the advertised rate as a policy rather than a guarantee.

For chains where you need historical state or archive access to inspect old claims, confirm your provider supports it before relying on the result. The network directory lists supported chains and their capabilities.

Expected verification result and how to read it

A successful verification produces four facts: the transaction succeeded, the reward amount matches the token's decimals, the recipient address is yours, and the net value after gas and exit fees is positive for the time you spent. If any of those fails, the claim is not a real earning event for you.

A common surprise is that the gross amount is correct but the net is negative after gas on a congested chain. Another is that the reward arrived in a token with no liquid market, so the exit fee is effectively 100%. Both are legitimate outcomes of the method, not errors in it.

Record the block number and timestamp with every row. Reward rates and token prices change, and a table without timestamps cannot be compared across weeks.

Troubleshooting common verification failures

When a check fails, the cause is usually one of a small set of issues. Work through them in order before concluding that a game did not pay.

• Receipt not found: the transaction may be pending or on a different chain; confirm the chain ID of your RPC matches the game.
• Status 0x0: the claim reverted, often due to a cooldown, cap, or insufficient treasury; the game UI may still show a pending reward.
• No matching Transfer log: the payout may be batched, sent to a custodial address, or denominated in a token you did not expect.
• Log query times out: public endpoints often limit eth_getLogs ranges; narrow the block range or use a dedicated endpoint.
• Amount looks 10x or 1000x off: you skipped the token's decimals(); always read it from the contract.
• Net value negative: gas or exit fees exceeded the reward; this is a real result, not a bug.

Limitations and tradeoffs of on-chain reward measurement

On-chain verification tells you what was paid, not whether the game is fun or the economy is sustainable. A game can pay accurately and still collapse when emissions outpace demand for the token. Conversely, a game with a healthy economy may batch payouts in ways that make individual verification harder.

There is also a cost to measurement itself. Scanning logs and pricing tokens takes time and RPC capacity, and on high-throughput chains the log volume can be large. For a single claim, a public endpoint is usually enough; for a recurring dashboard across many players, you need stable infrastructure and probably an indexer. That is the point at which a dedicated node or a managed RPC plan becomes cheaper than retrying rate-limited requests.

Finally, off-chain components such as matchmaking, anti-cheat, and point ledgers are invisible to RPC. A reward can be fully verified on-chain while the activity that generated it remains unverifiable. Treat the on-chain layer as the settlement layer, not the whole game.

Next steps: build a repeatable earnings check

Turn the steps above into a small script you run after each claim: fetch the receipt, decode the transfer, price the token, and append a row to your table. Keep the RPC URL in an environment variable so you can switch chains without editing code.

If you are building a game or a rewards dashboard rather than playing one, the same method applies at scale: index Transfer events from your reward contract, store them with block timestamps, and join them to a price feed. Start with the RPC endpoint guide for the fundamentals, then choose a provider that supports the log ranges and chains you need. For endpoint selection by chain, the RPC Assistant's multi-chain endpoint guide is a practical companion to this verification workflow.

The habit that matters most is separating documented behavior, your own measurements, and recommendations. A game's documentation tells you what it intends to pay; your table tells you what it actually paid you.