The problem I needed to solve
A coin reward can appear as animation before reaching the header. I needed to distinguish a successful request from the moment the balance actually changes.
Implementation in this snapshot
RewardDistributionService.GiveCoins can invoke CoinRewardPresentationRequested and retain a PendingCoinGrant. CompletePendingCoinGrant removes that request and then credits CurrencyService.
The design decision and its cost
Without a handler, crediting is immediate. GiveReward dispatches between Coins and StaticItem; rewarded advertising is identified by RewardSource, with a separate provider contract.
Current boundaries
Pending grants live in memory rather than persistent storage. Closing during presentation means a Success result alone does not prove crediting occurred; durability is a real boundary to investigate.
Review scenarios and contract meaning
The rewarded-ad title can draw attention to the advertising network, but this stage concerns when coins are delivered. A provider can report successful viewing and distribution can request a coin animation; neither is inherently the final balance change. A request identifier makes the gap traceable. CompletePendingCoinGrant removes the request before adding coins, so repeating that identifier is not an ordinary second grant. CancelPendingCoinGrant also removes a request and should not be confused with successful delivery.
The hardest scenario is process termination while coins are flying. The pending request lives in an in-memory Dictionary and the current contract does not save it for the next run. Meanwhile, a claiming service may already have recorded success. That combination calls for an explicit decision about durable recording, compensation or acknowledgement timing; I do not claim any of those solutions has been implemented here. The immediate path when no presentation handler accepts the request is another behavior to review separately. My central boundary is that appealing presentation must not obscure accounting, and a request event must remain distinct from final delivery.
Coins and StaticItem show that not every reward needs a coin animation. Item ownership follows another path where identifier and category validity matter. A generic reward view should explain that contract’s result instead of inferring delivery type from artwork. This separation supports new rewards while leaving each definition’s validity open to review.
What this stage taught me
For me, the coin effect should not obscure accounting. A request ID lets presentation completion connect to one grant, while recovery from process interruption needs its own explicit solution.
