Compound rewards are governance-Set COMP Incentives That Reshape Yield

Compound rewards are governance-set COMP incentives that accrue to eligible base-asset suppliers and borrowers in a specific Compound III Comet market. They sit beside base interest rather than replacing it, and users claim the accumulated token amount through that market’s Comet Rewards contract. Net yield changes with incentive speed, COMP price, position size, and network gas.

That distinction drives every practical decision on this page: compare the two return streams separately, identify the exact market configuration, and claim only when the accumulated value justifies execution and conversion costs.

Claim Economics Before the Transaction

Zero protocol claim fee means the direct cost of collecting Compound rewards is one network transaction, with gas paid in the chain’s native asset by the caller.

Ethereum charges an EIP-1559 base fee plus a priority fee, both multiplied by gas used. Base, Arbitrum One, and Optimism settle execution charges and add costs tied to posting data to Ethereum. Those inputs move by block, so a gas quote would mislead. The Comet Rewards contract subtracts 0 COMP as a service fee; when a claim succeeds, it transfers the entire amount owed. Converting COMP into USDC or another base asset creates a separate trading fee, price impact, and transaction cost outside Compound III. Wallet interfaces may combine the claim with another action through Bulker, changing gas total without changing the reward calculation.

Claim cadence is therefore an amortization decision. Divide expected gas and conversion costs by the COMP value collected, then compare that percentage with the holding period. Small balances support less frequent claims; a planned governance vote or portfolio rebalance supports earlier collection.

The economic answer changes whenever COMP value, network fees, or the intended holding period changes.

Reward APY and Net Yield in Separate Columns

Three moving inputs - base interest, the COMP incentive, and realization costs - determine net yield, so any combined percentage is only an estimate for a stated decision interval. Base interest accrues in the market’s base asset; rewards accrue in a separate token whose price changes independently.

Keep four numbers separate: supplied or borrowed principal, base-asset interest, COMP accrued, and claim-plus-conversion cost. For a supplier, net return adds base interest and the base-asset value of COMP, then subtracts realization costs. For a borrower, the reward offsets part of the borrow interest rather than turning debt into income automatically. Annualizing either side uses 31,536,000 seconds for a 365-day year, yet the displayed reward rate still changes when total participating principal, governance speed, or COMP price moves. Unclaimed COMP does not reinvest into USDC, WETH, or another Comet base balance.

A clean comparison fixes the same time window and values COMP at one consistent price. The decision changes when the reward is held as COMP instead of converted into the base asset. The related mechanics are detailed in Compound walkthrough.

Supply Incentives and Borrow Incentives Diverge

Two governance-controlled speeds allocate tracking separately to base-asset suppliers and borrowers, and a speed of 0 switches reward growth off for that side within one market. A positive base balance follows the supply index; a negative base balance follows the borrow index.

Collateral is outside this allocation rule. In a USDC Comet market, supplying WETH, WBTC, cbETH, or another approved collateral asset supports a borrow position, yet that collateral amount alone does not receive the base tracking incentive. The account earns supplier rewards only on positive USDC principal, or borrower rewards only while its base principal is negative. This difference prevents users from treating every supplied token as incentive-bearing.

If an account crosses through a 0 base balance, subsequent tracking follows its new side while previously accrued units remain attached to the account.

When Does Reward Accrual Actually Start?

One nonzero baseMinForRewards threshold gates each index: total supplied base must meet it for supply rewards, and total borrowed base must meet it for borrow rewards.

The threshold belongs to the entire Comet market, not to one wallet. A user with a small eligible base position accrues once the relevant market total reaches the configured amount; a large user does not bypass a market total below it. Supply and borrow tests run independently against the same configured number. The contract requires that number to exceed 0 when an implementation is created. Because governance may deploy and point the proxy to a new implementation, readers should inspect baseMinForRewards alongside both tracking speeds for the exact market rather than copy a threshold from another deployment.

Accrual advances with elapsed block time when the market state updates, and getRewardOwed requests an account accrual before returning the unpaid amount. Eligibility changes when either market total crosses the configured threshold.

One Comet Market, One Reward Configuration

Five EVM networks illustrate the boundary clearly: Ethereum, Base, Arbitrum One, Optimism, and Polygon PoS maintain independent Comet state and reward ledgers for every deployed market. Their chain IDs are 1, 8453, 42161, 10, and 137, respectively. A USDC market and a WETH market on the same chain are separate Comet instances, each with its own speeds, threshold, and reward configuration; one Rewards contract may serve several instances. Accrued COMP on one instance is not claimable from another; the route changes when an account uses a different market or network.

Claiming Through the Comet Rewards Contract

Two Comet Rewards functions cover claiming: claim sends tokens to the source account, while claimTo routes them to a chosen address after Comet verifies manager permission. Both accept a shouldAccrue flag that selects whether the account is updated to the transaction’s block before transfer.

Two Claim Paths

Both claim paths transfer the full positive difference between total accrued and previously claimed amounts. If the difference is 0, the contract records no payout. The claimed ledger advances to total accrued only when an owed amount exists and the token transfer succeeds.

Owner-Address Transfer

The claim function takes 3 arguments: the Comet address, the source account, and shouldAccrue. Any caller may trigger it for another account, but the recipient remains the source account. That design lets a relayer pay gas without gaining the reward. Passing true first calls accrueAccount, incorporating participation through the current block; passing false uses the account’s already stored tracking state. A dashboard quote commonly simulates getRewardOwed, which returns 2 fields - the reward-token address and the unpaid token amount - without requiring the user to broadcast a claim transaction.

Approved-Manager Routing

The claimTo function takes 4 arguments by adding a destination address. The caller must be the source account or a manager authorized through Comet’s account-permission system. Permission is checked before the transfer, so a third party cannot redirect tokens merely by knowing an address. This route suits smart contract wallets, treasury operations, and custody workflows that separate the earning account from the receiving account.

Bulker also exposes 1 reward-claim action for batching with other supported Comet operations. The preferred path changes when the account needs a different recipient or a fresh accrual checkpoint.

Governance Changes the Inputs, Not Past Accounting

Three governance-controlled inputs reshape incentives directly: the supply tracking speed, borrow tracking speed, and baseMinForRewards threshold for the selected Comet market after an executed protocol upgrade.

The Configurator stores proposed parameter changes, while the Comet Factory produces an implementation with those immutable values. After governance approval and Timelock execution, CometProxyAdmin points the market proxy to that implementation. Remote EVM deployments add 2 message-handling components, a Bridge Receiver and a Local Timelock, between Ethereum governance and local execution. The proxy address stays stable while the code and configured speeds change.

The COMP contract fixes total supply at 10,000,000 tokens and represents balances with 18 decimal places. Reward allocations therefore use funded COMP held by the Rewards contract; governance does not create extra COMP by raising a market’s speed.

If that contract lacks enough token balance, the transfer reverts while the tracked accrual and claimed ledger preserve the unpaid difference. Payout availability changes after the Rewards contract is replenished.

Precision, Scaling, and Token Units Under the Hood

Six decimal places define Comet’s reward-accounting precision, even when the reward token itself, such as COMP, exposes 18 decimals to wallets and applications through ERC-20 units.

The Scaling Path

Comet stores baseTrackingAccrued as a 64-bit unsigned integer scaled by 10^6. Comet Rewards reads that value, applies a 64-bit rescale factor upward or downward to match the reward token’s decimals, and then applies a 256-bit multiplier against a 10^18 factor scale. For COMP, the decimal conversion expands the integer representation; it does not add economic precision beyond the six decimal places already tracked. Integer division rounds down, so sub-unit fractions do not appear in the stored reward amount.

The interest system uses a separate 10^15 base-index scale, while Comet permits base assets with at most 18 decimals and requires its protocol price feeds to expose 8 decimals. Those constants explain why raw integers from Comet, Comet Rewards, and ERC-20 balanceOf should never be displayed with one shared divisor. An application must read the returned token address and its decimals before formatting the owed amount.

The visible number changes when a market uses a reward token with different decimals or a non-unit multiplier.

A Decision Checklist for Claim Timing

Five checks turn a reward estimate into a claim decision by testing market identity, eligibility, accrual, contract funding, and total realization cost in order before signing.

Use this decision checklist at the address level, because each Comet deployment keeps its own ledger.

• Match the deployment. Confirm that the wallet network, Comet proxy, and Comet Rewards contract belong to the same market.
• Identify the earning side. Look for positive base supply or a negative base borrow, then confirm its configured speed exceeds 0.
• Test the market threshold. Compare total supply or total borrow with baseMinForRewards for the relevant side.
• Read the payable amount. Check that getRewardOwed names COMP, returns a positive amount, and corresponds to a funded Rewards contract.
• Price the full exit. Include claim gas, any later token-transfer gas, trading fees, and price impact if COMP will be converted.

A claim is economically positive when the COMP value collected exceeds network gas plus any planned conversion cost, without counting an unclaimed dashboard estimate twice. Claim cadence changes when those costs or the destination for COMP changes.

Still have questions?