Compound v2
Compound v2 pays accrued COMP when a claim transaction meets its funding condition
Compound v2 pays accrued COMP through a claim transaction when the Comptroller holds enough COMP for the holder's accrued balance. An accrued figure records rewards; it does not establish receipt. Completion requires a successful transaction that actually transfers COMP to the address whose rewards are being claimed.
A claim that ends with received COMP
An account with unpaid rewards needs a compatible claim call and evidence of the resulting payment. The holder is the address whose rewards the Comptroller records. Before submitting a transaction, establish that address, the claim contract, and the reward balance that the call will process.
- Confirm that the selected holder matches the account with accrued rewards.
- Use the v2 Comptroller interface at its Unitroller proxy, where the account state resides.
- Simulate the intended claim and inspect both the expected transfer and any remaining accrued balance.
- Submit the transaction only after resolving a wrong target, incompatible call, insufficient COMP funding, or expected execution failure.
- Finish by matching the confirmed COMP transfer to the holder; an unpaid balance requires further investigation.
If the simulation cannot establish a valid call, correct its inputs before proceeding. If funding is insufficient, repeating the same transaction does not supply the missing COMP. A successful execution without the expected transfer leaves the payment task unfinished.
Accrued, allocated, and received COMP
Reward displays can describe different balances, even when each number uses the same COMP unit.
The stored reward balance
The Comptroller records unpaid rewards under
compAccrued
for each holder. Market accounting can add amounts when it updates the holder's reward position. A direct read returns the stored value at the queried block, so it can differ from a calculation that also processes outstanding market updates.
This distinction concerns accounting freshness. It does not establish that a legacy position continues earning new incentives.
An updated calculation
The Compound Lens helper calculates an allocated amount by invoking claim logic, comparing COMP balances, and including rewards that remain accrued. Consequently, its allocated figure can include an unpaid amount when the transfer cannot occur. A display built from that calculation should not automatically label the entire result as received COMP.
Received COMP belongs to the holder's token balance. Keeping that balance separate from the accounting estimate explains why a reward display can show an amount even though the wallet has received nothing.
Claim scope and contract compatibility
The selected
claimComp
method determines which holders and market accounting updates the call processes.
All markets or selected markets
The single-holder method accepts a holder address and processes all markets in the Comptroller's market list. Another method accepts that holder plus selected cToken markets. The expanded method accepts multiple holders and lets the caller select supply-side accounting, borrow-side accounting, or both.
These choices concern reward processing. They do not redeem the cTokens that represent supplied assets or repay outstanding borrowing.
The proxy and its interface
The Unitroller stores protocol state and forwards calls to the Comptroller implementation. Contract access therefore uses the Comptroller's application binary interface, or ABI, at the Unitroller address. The ABI describes the callable methods and their arguments; selecting a matching method matters because
claimComp
has several signatures.
A contract tool that recognizes the method name still needs the correct argument types. A simulation against the actual target can reveal an incompatible call before the sender pays for execution.
Why can a successful claim transfer no COMP?
A successful claim can leave rewards unpaid when the Comptroller lacks enough COMP for the holder's balance. The claim payment function skips the transfer when the holder's accrued amount exceeds the Comptroller's available COMP balance. It retains that unpaid amount in the holder's accrued record.
The payment function does not send the available portion as a partial payout to that holder. Insufficient funding also does not, by itself, force the ordinary claim transaction to revert. Execution can therefore succeed while the holder receives nothing. A zero amount produces no transfer either, which makes the remaining accrued balance useful when distinguishing these outcomes.
Payment requires adequate COMP at execution time. An earlier balance observation cannot reserve those tokens, and the claim call does not promise when additional funding will arrive.
Simulation and transaction execution
A simulated claim calculates an outcome without committing its changes to the blockchain. An
eth_call
request can execute contract logic against a selected block state, including logic that would change balances in a transaction. Its temporary changes disappear after the calculation.
That makes simulation useful for inspecting expected behavior without sending a paid transaction. It also explains why a successful preview leaves the real wallet balance unchanged. A simulation that computes allocated rewards and a transaction that pays them are separate operations, even when both invoke the same claim method.
Execution uses the state that exists when the transaction enters a block. Funding, account balances, or other relevant state can change after a preview. A simulation supports the decision to submit; it cannot guarantee the later outcome.
Receipt details that establish payment
A transaction receipt establishes execution status, while the COMP transfer record identifies the actual payment. The transfer event records the sending address, recipient, and amount. Its emitting contract must be the COMP token contract; a similarly named event from another contract does not establish receipt of COMP.
The holder in the claim arguments should match the recipient in that transfer record. A token balance read provides another view of the resulting holdings. If other transfers affect the account around the same time, the claim transaction's own logs identify its payment more precisely than a broad before-and-after wallet comparison.
A transaction hash alone does not establish inclusion or payment. The receipt and transfer record answer different questions.
Gas costs and the boundary for retrying
The sender pays for transaction execution even when a successful claim produces no reward transfer. Gas cost depends on the computation performed and the effective price per unit of gas. A higher gas allowance cannot repair insufficient COMP funding. Pending execution, a reverted call, and successful execution without payment require different responses: inspect transaction status, diagnose the failure, or examine the unpaid reward and funding balances. Repeating a call without identifying its outcome can add expense while leaving the same condition unresolved.
Compound v2: what people ask
Is there a minimum accrued COMP amount for a direct claim?
The claim payment function requires a positive accrued amount and sufficient COMP to cover it. It does not impose a separate positive minimum reward threshold. Small claims still require transaction execution, so the absence of a minimum does not remove the gas cost.
Can I choose a smaller COMP payout when the contract lacks enough funds?
The standard claim methods do not accept a payout amount chosen by the caller. Selecting markets controls which accounting updates run; it does not set a smaller payment from the holder's stored accrued balance. The payment function evaluates the accrued amount that results from the call.
Does a DistributedSupplierComp event prove that COMP reached my account?
A DistributedSupplierComp event records a supply-side reward accounting update, rather than a COMP token transfer. DistributedBorrowerComp serves the corresponding accounting purpose for borrowing. These events can accompany changes to accrued rewards, so their names alone do not establish that payment occurred.
How can I inspect a claim when the application interface is unavailable?
Contract state and transaction receipts can be read through a compatible blockchain connection without the application interface. An interface outage does not itself show that a claim failed or that rewards disappeared. Inspection still requires the correct contract target, holder address, and transaction identifier where applicable.
Must each COMP reward claim receive governance approval?
An ordinary claim does not require a separate governance vote for the holder. The public claim methods process rewards through the existing contract rules. Governance controls protocol changes, which is different from submitting an individual claim against the accounting and funding already present.