Compound.finance lets you check Compound III rewards owed before claiming

Claims to the Owner or Another Recipient

The reward destination determines which claim function applies and whether the caller needs account permission.

Payment to the Earning Account

The claim function sends rewards to the account that earned them. Its arguments identify the Comet market, the earning account, and whether to refresh accrual. The transaction sender doesn’t replace the earning account as the recipient. This distinction matters when an application prepares the transaction through a different connected account.

Payment to a Chosen Address

The claimTo function accepts a separate recipient and requires the caller to have permission over the earning account. Ownership satisfies that requirement; an authorized manager can also qualify. Check that permission before signing. Manager authorization extends beyond reward collection and can permit collateral withdrawals or transfers, so granting it solely to redirect one payment introduces broader account access.

Inspect the Outstanding Amount Before Signing

The getRewardOwed function returns a token address and an outstanding amount for the selected market and account. Both fields matter. A quantity without its token identity and decimal scale isn’t enough to describe the payment.

Keep the network, Comet market, rewards contract, and earning account consistent throughout the check. A matching account address alone doesn’t identify the market record.

Although its name sounds like a simple read, the function calls account accrual internally. A simulated call executes that calculation without saving its changes to the blockchain. Tools can perform this through eth_call or an equivalent simulation method. Sending the same function as a transaction changes the execution context and incurs network transaction costs.

The preview neither reserves tokens nor commits a claim. It describes the result at the state that the simulation uses.

Preserve the preview’s block context when comparing it with later results. Further accrual or another completed claim can change the outstanding amount before execution. Compare the same market and account each time, and treat a changed amount as something to explain through transaction history. Repeatedly refreshing an interface without checking those identifiers can conceal a mismatch.

Signed, Submitted, and Pending Transactions

Signing authorizes a claim transaction; broadcasting submits it to the network. A submitted claim can await inclusion, but nodes can also drop or replace it in their transaction pools. A transaction hash identifies the transaction; it doesn’t prove submission or reward payment. Pending transactions have no completed receipt. Once a receipt appears, its execution status distinguishes success from a revert, while subsequent confirmation or finality concerns the durability of that inclusion. Keep the transaction hash available and inspect its status before sending another claim. An interface that continues showing the earlier reward estimate doesn’t establish that submission failed.

Accrual Refresh and the Amount Actually Payable

The shouldAccrue argument controls whether the claim refreshes account accrual before calculating its payment. With true, the contract accounts for rewards through the execution block. With false, it uses the stored accrual record, which may omit progress since the account’s last update. A previous simulated preview doesn’t persist that update.

Comet Rewards calculates the outstanding payment as converted accrued rewards minus the claimed record, with a floor of zero. The raw baseTrackingAccrued value uses the market’s reward accrual scale. The rewards contract converts that value under its configuration before calculating the token amount. Directly treating the raw tracking value as a wallet balance can therefore misstate the reward.

Supply interest, borrowing interest rates, and reward accounting describe different quantities. A refreshed lending balance doesn’t establish that reward tokens reached the wallet.

Match the Receipt to the Reward Transfer

A completed reward payment should agree across the transaction receipt, reward event, and recipient’s token record.

Execution and Event Details

The receipt must belong to the intended network and transaction. A positive successful Comet Rewards payout emits a RewardClaimed event identifying the earning account, recipient, token, and amount. Match those fields to the prepared claim. For a transaction containing several operations, isolate the relevant reward event rather than treating every token movement as part of that payment.

Token Balance and Remaining Rewards

The recipient’s token transfer record provides the payment detail that a wallet’s aggregate balance can obscure. Other incoming or outgoing transfers may affect that balance during the same period. Format the transferred amount using the reward token’s decimals, then inspect the outstanding reward again. A later positive result can reflect additional accrual; it doesn’t automatically mean that the completed transaction underpaid.

Why Can a Successful Claim Transfer Nothing?

A successful claim can transfer nothing when converted accrued rewards don’t exceed the account’s claimed record. The contract then completes without making a reward payment or emitting a positive payout event. This can happen after another claim clears the outstanding amount. Distinguish that outcome from a reverted transaction: successful execution establishes that the call completed, while the event and token records establish whether it paid anything. A fresh owed check helps explain the empty payment result.

Transaction Costs Before a Retry

Claim costs come from executing the transaction on the selected network, so a reward estimate isn’t a fee quote. Inspect the transaction’s gas estimate and fee settings separately. The sender also needs the network’s transaction-fee asset; an expected incoming reward doesn’t establish that the sender can fund execution.

A reverted transaction can still consume gas. Preserve its failure information before preparing another attempt. An authorization failure requires a permission or caller change, while an unsupported-market error requires checking the market and rewards-contract pairing. A reward-token transfer failure concerns payment execution. Repeating the same request without resolving its cause can spend more transaction fees without producing a transfer.

Finish With the Payment Record Intact

Reward reconciliation ends when the intended transfer and the remaining owed amount have an explanation. Retain the transaction hash, market identity, earning account, recipient, and token amount together. That record distinguishes the account that earned the reward from the address that received it. It also prevents a later wallet balance change from replacing the original payment evidence.

View full-size image

Finishing a claim doesn’t establish that a lending position has closed or that collateral has left the market. Those balances require their own operations and checks. If account management was enabled for a broader workflow, reviewing or revoking that permission is also separate from collecting rewards. The concrete record of the reward payout remains the transaction’s RewardClaimed event.