# Data liquidity and rewards

Testril's data-liquidity model connects paid materialization, titled coverage, subsequent paid reads, and wallet accounting. For agents, the useful questions are: what was bought, what is still covered, what was earned, and what can be claimed?

## Inspect a wallet's accounting

```json
{"tool":"inspect","arguments":{"subject":"nft","wallet":"<WALLET_ADDRESS>"}}
```

The claim-right card includes `purchases` and lifetime totals such as `paid`, `refunded`, `cost`, `earned`, `claimed`, `unclaimed`, and `pnl`. Monetary atom values are decimal strings; preserve exact integer arithmetic. A purchase can appear at payment before data delivery. Inspect the relevant job and coverage separately.

Each purchase records its quote ID, bound-function ID, original requested window, and accounting. The original window may include blocks already covered even though only unpaid holes were bought. Do not equate requested block count with charged block count.

Purchase earnings and read counts follow the blocks actually delivered. When historical attribution cannot be reconstructed, a purchase omits `earned`, `pnl`, and `reads`. Sum known purchase earnings plus wallet `earned_unattributed` to reconcile lifetime `earned`; missing attribution does not forfeit unclaimed rewards.

## Data availability is a different ledger

Expiry and materialized geometry live on `inspect subject:bound_function`. Wallet accounting is not a guarantee that all purchased blocks are currently available. An empty wallet card can have zero totals and no token ID; the token ID is omitted until minted.

When an NFT collection is configured, the card follows the current owner at the chain tip. An ownership lookup failure produces `unavailable`, not fabricated zero totals. The original payer may no longer hold the claim-right.

## Claim existing rewards

```json
{"tool":"claim_rewards","arguments":{"wallet":"<WALLET_ADDRESS>"}}
```

Inspect unclaimed amounts first. Keep the actual claim response and re-inspect accounting afterward. The implementation handles eligible USDC atoms; it does not promise that a newly bought window will earn enough to cover its cost.

The minimum claim is 10,000 atoms ($0.01). Below that minimum, the response reports claimed `"0"`, `reason: "below_minimum"`, and no transfer. Claims follow current claim-right ownership; an unreadable ownership record is a refusal, not proof that no rewards exist.

## Paid reads and shared value

A paid read of titled coverage can contribute to holder accounting according to the implementation's pricing and overlap rules. A quote alone is not earned revenue. Coverage overlap, retention, prices, and the actual completed paid read matter. Use the current card and settlement records as evidence instead of projecting a yield from a marketing tagline.