By Heath Muchena · Sources reviewed 13 November 2026 · Original DN analysis and illustrative records
What Matters
A reward forecast is not a receipt. Identify the qualifying event, eligible participant, recipient, unit and payout conditions. Keep earned, claimable and received stages separate, and do not add a token valuation to actual cash as though both were realized proceeds.
An AI agent can summarize offers, estimate token rewards and display an impressive total. The difficult question is what that number represents: an opportunity, a recorded allocation, an available claim, a token receipt or cash already received.
This guide uses current Brave and Zora documentation to show different reward mechanisms. It does not rank income opportunities, establish that automated participation is permitted or estimate typical earnings. “Income” in the headline describes the claim being examined; the tool makes no accounting or tax recognition decision.
The DN thesis
Review one reward rule and one cohort before aggregating a business case. The useful output is a traceable amount at a named stage, with unresolved conditions preserved—not a projected earnings total detached from its terms.
1. Identify the event that actually earns a reward
Begin with a sentence that names the payer, the qualifying event and the asset: “This offer records TOKEN-A when this eligible event occurs.” A view, click, referral, tip, coin allocation and trading-fee share are different events. Their labels should not be merged because they appear in the same app.
Brave’s terms distinguish eligible advertiser ads from house ads and other promotional material, and do not promise a minimum supply of eligible ads. [1] Zora’s protocol describes rewards arising from coin trading, alongside coin allocations with different structures. [4] Neither example establishes that a bot scrolling a feed has generated a payable reward.
Ask an agent to cite the current offer rule before forecasting receipts. Keep a speculative opportunity separate from an amount recorded under that rule. If the underlying event cannot be identified, the income estimate has no clear basis, even when a dashboard displays a large audience or an attractive token price.
2. Check who is eligible, including the delegated activity
A person’s ability to open a page does not establish eligibility for its reward. Identify the relevant account, region, platform, offer period and payout route. Then ask whether the particular delegated action is allowed. A feature that permits an agent to organize records does not automatically permit simulated views, repeated engagement or account farming.
Brave’s current product page requires a connected payout account for earning and describes platform and regional limitations. [3] Its terms make payout conditional and provide for forfeiture in specified situations. [1] An estimated balance should therefore not be treated as an unconditional debt collectible on demand.
The DN record asks for the offer and eligibility evidence separately. “Unknown” is useful: it means the agent should not turn an unresolved permission into a projected revenue line. This article supplies no method for bypassing a restriction, impersonating a participant or manufacturing engagement.
3. Separate attention from the data being disclosed
An attention reward is not necessarily a payment for exporting browsing history. Conversely, a privacy claim about ad matching does not describe every payment identifier or account connection. Map the actual exchange rather than assuming all consumer-data programs have the same design.
Brave’s privacy policy describes ad matching in the browser and says it does not collect browsing history for Rewards. It separately explains Rewards Payment IDs, country information and associations with payout accounts. [2] These are different parts of the service’s data handling, not a reason to claim that no information is processed anywhere.
Before an agent accepts a data offer, record the requested fields, recipient, use and retention statement in a separate consent review. Use aliases here. Do not paste browsing histories, personal identifiers or wallet secrets into a reward worksheet. A higher projected reward is not evidence that an extra disclosure is necessary.
4. Verify the recipient and the rule version
A fee collected by a system is not automatically the amount owed to its creator. A referral reward may belong to a specific recipient, while another part of the fee supports liquidity or the protocol. Record the role that earns the payment and the rule version applying to the particular object.
Zora’s detailed reward guide distinguishes recipient shares and older coin structures. [5] Its developer documentation also distinguishes a platform referral fixed at coin creation from a trade referral set for an individual swap. [6] A general headline about creator earnings is insufficient to identify a particular recipient’s entitlement.
This is especially important when an agent both creates content and routes activity. Keep its creator allocation, creator fee share and referral payment as separate lines until evidence shows how they relate. Do not count a total system fee and each recipient’s share as additional rewards on top of that same total.
5. Reconcile recorded, claimable and received quantities
Use one asset and one defined cohort of rewards at a fixed cutoff. “Recorded earned” is the amount attributed to that cohort. “Received” is the cumulative amount delivered from it. “Claimable” in this tool is the currently unreceived portion reported as available to claim. Those three figures overlap; adding them creates an invented total.
The worksheet first subtracts received units from earned units. It then subtracts the currently claimable subset from that unreceived balance. The remainder is deliberately called unclassified. It could require investigation; the arithmetic does not decide whether it is pending, withheld, expired, forfeited or erroneous.
For example, 120 TOKEN-A recorded, 50 received and 30 still claimable leave 70 unreceived and 40 unclassified. This is an invented record, not a reported provider outcome. If a source uses “claimable” to include already received rewards, normalize the definition before entering it. Preserve the original source record alongside your interpretation.
6. Keep token balances separate from the cash subtotal
A received token quantity and cash available for spending are different records. Do not multiply a balance by a headline price and call the result a realized payout. A conversion may have its own amount, route, charges and evidence.
Brave’s documented self-custody payout route uses bridged BAT on Solana and describes a network-fee requirement for opening the receiving token account. [7] That is a concrete example of why the asset, network and associated cost need their own entries. It does not establish a universal cost for every reward or payout route.
The tool accepts cash actually received and additional cash costs in one currency. It does not price tokens. If conversion fees are already netted from a cash receipt, do not deduct them again. When the cost basis may overlap, the subtraction is withheld. This subtotal is neither a complete business profit calculation nor a tax classification of rewards.
7. Retain the unresolved balance and review the offer again
An agent should be able to hand over a concise record: the offer version, qualifying activity, eligibility evidence, reward asset, cohort, quantities, receipts and outstanding question. A missing payment should stay missing in that record instead of being silently replaced with a forecast.
Keep the evidence date and period in your source references. When terms or payout routes change, start a new record or clearly mark the new boundary. A later successful receipt does not authenticate every earlier estimate. A policy restriction does not erase cash already recorded; the historical fact and the current eligibility question are different.
Choose a human owner for unresolved discrepancies and any proposed disclosure, claim or sale. The instrument makes no transaction. Its purpose is to expose what an agent’s “income” number contains before that number is used in a budget, spending limit or performance report.
DN Attention Reward Claim Record
Use one declared reward cohort and cutoff. Enter aliases and quantities, never personal histories or account secrets. Claimable means unreceived units available to claim; received means cumulative receipts from the same cohort. Cash is calculated separately.
No current calculation. Enter a record or load a labelled example.
This worksheet sends no entered values to a server, connects to no account and stores no input in browser storage. Downloads contain the entries you supplied. Use aliases rather than private data. Other site services remain subject to the site’s privacy policy.
Labelled examples and practical use
In the first fictional case, 120 TOKEN-A are recorded, 50 received and 30 currently claimable. The model returns 70 unreceived and 40 unclassified. Separately, USD12 of recorded cash receipts less USD2 of additional costs gives a USD10 subtotal. It does not infer a token price or assert that the cash came from selling all 50 received units.
The other examples preserve unknown eligibility, flag overlapping quantities, calculate unreceived units when claimable is blank, withhold cash subtraction when fees may overlap and show a negative cash subtotal. None describes a live program or predicts a payout.
Methodology, assumptions and limits
Reward inputs use exact integer arithmetic at the reader’s declared decimal scale from zero to eighteen. With a same-cohort reference and asset, unreceived = earned − received. If claimable is known, unclassified = earned − received − claimable. Receipts exceeding earned, or received plus unreceived-claimable exceeding earned, conflict with this declared partition and suppress quantity differences.
Cash is independent: receipts − additional nonoverlapping costs, using exact decimals up to six places. A possible-overlap declaration withholds that calculation. Missing cash evidence remains visible even where arithmetic is possible. The tool does not fetch a wallet, infer exchange rates, authenticate evidence, claim rewards or classify taxable income.
Primary sources were reviewed on 13 November 2026. Zora’s broad creator messaging and detailed fee tables are not treated as one universal percentage: the article uses the detailed role/version distinction and publishes no forecast rate. Examples are invented; export time records the local calculation, not a new source verification.
Frequently asked questions
Does seeing an ad always earn a token reward?
No. The applicable offer must identify eligible ads, participants and payout conditions. Brave’s terms distinguish eligible ads from other promotional material. [1]
Does a trading fee all belong to the creator?
Not necessarily. Zora’s detailed guide separates creator, referral, protocol and other fee roles, with different structures by coin type and version. [5]
Why are earned, claimable and received not added together?
They are stages of the same declared cohort. In this tool, claimable is an unreceived subset; adding all three double counts amounts.
Is the cash subtotal profit or taxable income?
No. It subtracts only the additional costs entered in one currency. It does not value unsold assets, discover omitted expenses or apply accounting or tax rules.
Primary sources
Reviewed13November2026. A publication or export time does not refresh the evidence.
- Brave Rewards user terms — Eligible ads, payout conditions and forfeiture; not an automation entitlement.
- Brave Browser Privacy Policy — Local ad matching and separately described payment/account data; no blanket no-data claim.
- Brave Rewards product description — Current reward product, platform and connected-payout boundaries.
- Zora Coins Protocol — Different coin types, allocations and fee recipients; no investment return claim.
- Understanding Rewards on Zora — Role-specific fee splits and legacy/current coin structures; no universal creator percentage.
- Zora developer referral rewards — Creation-time versus trade-specific referral recipients for the documented protocol.
- Brave self-custody Solana payouts — Named payout route, bridged asset and setup network-fee requirement; regional limits remain.
Turn the unresolved question into a research brief
For a scoped review of the public documents behind a claim, explore the DN Research Desk. An enquiry is subject to agreed scope and capacity; it does not certify a deployment, establish an entitlement or commit you to a paid service.
Disclosure: this article promotes DN’s own research service. Commercial enquiries do not purchase a favorable conclusion. No external provider is promoted through an affiliate link here.
