Compound v2 tied COMP rewards to supply and borrow activity

Existing balances determine the available actions

Existing suppliers, borrowers, and holders of accrued COMP have different actions available when managing a legacy position. A supplier holds cTokens representing an underlying asset balance. A borrower also owes debt, which may restrict collateral withdrawals. Someone with an accrued reward balance may have COMP to claim even after ending their lending activity. These balances belong to specific account addresses, so account queries and claims must identify the holder. Another address can submit a COMP claim for that holder.

Governance executed Proposal 512 to pause new minting and borrowing across v2 markets. The change also redirected newly accrued borrower interest to protocol reserves. It did not erase outstanding loans or redeem supplied assets automatically. Repayment and redemption therefore remain relevant to existing positions, subject to the contracts' normal restrictions. A historical description of supplying or borrowing explains how a balance arose; it does not establish an available entry path today.

Reward eligibility was separate from collateral membership

COMP eligibility depended on a recorded supply or borrow balance and the applicable market reward settings. Connecting a wallet, approving a token allowance, or enabling collateral did not by itself create reward earnings. Supply participation arose through holding the market's cTokens. Borrow participation depended on the account's recorded debt. Each side had its own accounting, allowing its reward allocation to differ from the other side.

Collateral membership served another purpose: it identified assets included in the account's borrowing-capacity calculation. Entering a market did not guarantee rewards, and receiving supplier rewards did not require borrowing against the supplied assets. This distinction matters when interpreting an old account. A collateral flag describes how the protocol treats a balance for risk calculations, rather than proving that COMP accrued during a particular period.

Market settings governed the pace of COMP accrual

The reward system allocated COMP through cumulative market indexes, which tracked distribution relative to participating balances. The Comptroller maintains separate supply-side and borrow-side COMP distribution speeds for each market. Supplier calculations used cToken balances and the supply index. Borrower calculations used debt normalized by the market's borrowing index. This normalization separated reward allocation from the interest already incorporated into borrowing balances.

A distribution speed was a configurable allocation per block, not a permanent yield percentage. The reward attributable to an account also depended on its share of participating balances. Changes in other accounts' participation could therefore change an individual allocation even without a governance change. A zero speed stopped additional distribution for that side while it applied; it did not by itself cancel rewards already accrued.

The presence of these accounting functions does not establish an active incentive program.

Supply interest and reward tokens followed different accounting

Supply interest was reflected in the relationship between cTokens and their underlying assets, while COMP rewards accumulated separately. A cToken balance did not need to increase for its represented underlying balance to grow. The exchange rate connected the two quantities. That relationship explains why a wallet's token count and an interface's supplied-asset value could change differently without indicating a missing payment.

Borrower interest supported supplier returns after the market's reserve allocation. The deprecation change redirected new interest into reserves, so historical supplier yields do not describe that configuration. Existing debt can still accrue interest even when a supplier receives no corresponding interest allocation. A reserve factor also has no automatic effect on an account's recorded COMP balance: lending interest and reward distribution use different settings.

View full-size image

Stored reward balances and updated calculations can differ

Reward accounting records progress when relevant contract interactions update market and account indexes. It does not write a fresh account balance automatically after every block. An account's stored accrued COMP can therefore exclude amounts that an index update would recognize. The distinction concerns when the calculation is recorded, rather than whether a dashboard has refreshed its display.

The accrued reward field is also separate from the COMP already held in the wallet. Claimed tokens appear in the token balance, while unpaid accrual remains in the Comptroller's accounting. In a CompoundLens claim simulation, the allocated value combines the simulated payout with remaining accrual. Adding it to the simulated post-claim wallet balance would count the payout twice.

A simulated contract call can calculate an updated result without publishing a transaction.

That simulation is useful for reading account state, but it does not transfer tokens on the blockchain. An actual payout requires an executed transaction and a corresponding token transfer. When comparing displays, the account address, selected markets, and calculation block must describe the same position. A difference between stored and simulated values alone does not prove that rewards disappeared.

Claiming accrued COMP requires an actual token transfer

The Comptroller's claim function processes reward accounting for the requested holder and markets, then attempts to transfer accrued COMP. Its variants allow all markets or a selected market list, with options for supply and borrow accounting. Processing fewer relevant markets can avoid unrelated work, although the transaction's actual execution determines its gas consumption.

The claim implementation retains unpaid accrual when the Comptroller lacks enough COMP to transfer the account's full accrued amount. A successful transaction therefore does not necessarily mean that a positive reward payment occurred. The receiving account's COMP transfer and resulting balance establish payment. An accounting update without a transfer establishes only that the reward calculation was processed.

Claiming COMP does not repay debt or redeem cTokens. The reward amount and the underlying lending position must be interpreted separately. Likewise, an unchanged wallet balance can reflect zero entitlement, unpaid accrual, or a calculation that covered different markets. Repeating the same claim does not resolve a funding shortfall.

Collateral restrictions continue to affect outstanding loans

Outstanding borrowing remains constrained by collateral value, market collateral factors, and the prices supplied to the protocol's risk calculations. The Comptroller combines eligible collateral values after applying their factors, then compares that capacity with debt. Falling collateral prices, growing interest, or changed risk parameters can reduce the available margin. A reward entitlement does not automatically offset that debt.

A collateral redemption is rejected when the Comptroller calculates that it would create an account shortfall. This restriction applies across the account's relevant markets, so the asset being withdrawn may secure borrowing elsewhere. Liquidation can repay part of an eligible debt and seize collateral under the applicable rules. Deprecation did not remove the need to account for those obligations.

Repayment, redemption, and reward claims have different limits

Repayment, redemption, and claiming address different balances, so their availability depends on different contract conditions. Repayment reduces borrowed underlying assets owed. Redemption exchanges cTokens for underlying assets. A reward claim attempts to move accrued COMP into the holder's wallet. None of these operations substitutes automatically for either of the others.

A market can have insufficient redeemable cash even when an account has enough collateral capacity. Repaying debt may remove a collateral restriction, but it does not guarantee liquidity in another market. Similarly, receiving COMP does not establish that the lending position has closed. Each operation has its own resulting balance.

COMP ownership also supports governance participation

COMP has a governance role beyond its historical use as a lending incentive. Token holders can delegate voting power, including to their own address. Delegation concerns governance votes and does not transfer ownership of the tokens. It also does not enable paused lending operations or create supplier and borrower rewards.

Accrued but unpaid COMP is not yet part of the holder's wallet token balance. Once transferred, it follows the token's ordinary ownership and delegation rules. Governance can change protocol parameters through its proposal process, but an announced proposal and an executed change are different events. A proposal's text alone does not establish the settings that a contract enforces.

Access to legacy positions depends on account and contract state

Legacy position management depends on the correct account, the v2 contracts, and access to their blockchain state. A missing dashboard balance does not erase a cToken holding, debt record, or reward entitlement. Interface availability and contract availability are separate dependencies. Account data can be read from the blockchain even when a particular display or data service is unavailable.

For outstanding positions, the useful records are concrete: the cToken balance, updated debt, collateral membership, accrued COMP, and completed asset transfers. These records answer different questions and should not be collapsed into a single earnings figure. Withdrawal remains limited by collateral rules and market cash, while a reward payment remains limited by entitlement and available COMP. An interface refresh cannot remove either restriction.