Crypto lending receipt tokens record a claim on supplied assets. Some keep the receipt quantity fixed while an exchange rate changes; others show a growing balance in underlying units. Reconcile the quantity, conversion method and cash flows at the same block. A larger accounting claim does not establish how much can be withdrawn immediately, what a market sale pays or whether the underlying's cash value is stable.
Two displays can encode the same claim
A receipt token is a different asset from the underlying token it represents. Start by identifying which unit a wallet or dashboard displays. A quantity of receipt shares, an underlying-equivalent balance and a dollar valuation answer different questions.
Fixed receipt units, changing conversion
In the Compound v2 reference implementation, balanceOf returns the holder's cToken units, while balanceOfUnderlying applies the current exchange rate. A holder can keep the same cToken quantity while its underlying-equivalent balance changes.
For this representation, the useful identity is:
underlying claim = receipt shares × underlying units per share
The exchange rate has units. A rate of 1.30 underlying units per receipt share is different from 1.30 dollars per receipt share. Before applying a raw contract value, check the underlying decimals, receipt decimals and rate scale; a human-readable rate cannot be multiplied directly by an unscaled integer balance.
Growing visible balance, indexed internal units
Aave V3's aToken documentation describes a one-to-one denomination in the corresponding underlying, with accrued supply interest included in the holder's visible balance. The changing quantity carries the accrual rather than requiring a second changing underlying-per-aToken rate.
Its internal units are another layer. The official Aave V3 origin aToken source calculates the visible balance using stored scaled units and the reserve's normalized income index. The scaled-balance base contract separately exposes those stored units. An internal scaled balance and an ordinary balanceOf result should therefore have separate field names in an integration.
These examples concern Compound v2 and Aave V3 EVM contracts. Check the actual deployed version, chain and wrapper before applying either model. A similarly named token can introduce another conversion layer.
The broader rebasing-token accounting guide explains why a balance change need not be a trade. For lending receipts, the additional task is to express that balance in the correct underlying units without counting accrual twice.
Follow one contribution through two ledgers
This hypothetical comparison uses fictitious underlying token U, fixed receipt S and rebasing receipt R. It describes two separate positions with identical economic assumptions, not one position holding both receipts. Each starts with a 1,000 U contribution. All figures are invented; there is no annualized rate or current protocol quote.
The S position receives 800 S at 1.25 U per S. The R position receives 1,000 R, with each visible R denominated as one U of accounting claim. Later, both positions have accrued 40 U. No deposits, transfers, liquidation, incentive tokens or fees occur during that accrual interval.
At that observation, S converts at 1.30 U per share, while the visible R balance is 1,040. For the withdrawal steps, assume each hypothetical pool has 600 U cash available, the account has no debt, and no other restriction or intervening transaction applies. The modeled withdrawal rejects the entire request if cash is insufficient.
| Position state | S held | U per S | Visible R held | Underlying claim in either position | Cumulative U received by redemption |
|---|---|---|---|---|---|
| Contribution completed | 800 | 1.25 | 1,000 | 1,000 | 0 |
| Accrual observed | 800 | 1.30 | 1,040 | 1,040 | 0 |
| Request for 700 U rejected | 800 | 1.30 | 1,040 | 1,040 | 0 |
| Redemption of 260 U completed | 600 | 1.30 | 780 | 780 | 260 |
The rejected request changes neither the receipt holding nor the amount of underlying actually received. Any network cost belongs in a separate transaction-cost record. A submitted amount is not a completed redemption, and this example does not assume an automatic partial fill.
For the successful redemption, the S position burns 260 / 1.30 = 200 S, leaving 600 S. The R position removes 260 visible R, leaving 780 R. Each remaining claim is 780 U. Pool cash falls from 600 to 340 U in either separate model.
The reconciliation is 780 + 260 − 1,000 = 40 U of accrued increase. Looking only at S would show a fall from 800 to 600 shares. Looking only at R would show a fall from 1,000 to 780 units since contribution. Neither decrease measures the economic result without the redemption cash flow. All these amounts are in U; the model does not assign U a dollar price.
An unchanged share count also cannot establish what drove growth. The utilization and lending-rate guide separates a rate snapshot from accrued interest across a period. Here, the 40 U is a stipulated accounting input, not a forecast produced from a displayed APR.
Check the index only once
To illustrate hidden units, let the hypothetical R position begin with 1,000 scaled units and an index of 1.00. An index of 1.04 produces the visible balance of 1,040 R. The 260 U redemption removes 260 / 1.04 = 250 scaled units, leaving 750. Applying the index gives 750 × 1.04 = 780 R.
Multiplying the already indexed 1,040 visible R by 1.04 again would produce 1,081.60 U, overstating the claim by 41.60 U. Store either the authoritative visible balance or the scaled balance with its matching index; if both are stored, use their relationship as a check. This exact arithmetic is a simplified fixture, not a reproduction of a deployment's integer-rounding rules.
If a market distributes a different reward token separately, keep that asset in its own ledger. Its token quantity cannot be added directly to a U-denominated claim. An aggregate valuation would need an explicit price, valuation currency and observation time for each asset.
Make rounding visible before it becomes a mystery balance
Consider a separate hypothetical adapter that quotes 1.30 U per S, accepts a 10.000000 U deposit and issues S only in increments of 0.001. Assume its rule is to round issued shares down. U has six decimals; the unusually coarse three-decimal receipt is chosen to make the effect visible.
The exact division is approximately 7.692307692 S. The adapter issues 7.692 S, or 7,692 receipt base units. At the unchanged illustrative conversion, that quantity represents 9.999600 U. The difference from the 10 U deposit is 0.000400 U, or 400 underlying base units.
Retain both the actual 10 U contribution and the actual 7.692 S mint. Do not silently increase shares to the rounded display estimate or label the difference as a withdrawal fee without evidence. Its treatment depends on the implementation. A real vault can recalculate its rate after a deposit; this fixture holds the conversion constant solely to isolate rounding.
ERC-4626 provides a useful named boundary for vaults that actually implement it: its conversion methods round down and omit operation-specific fees and conditions. That does not establish the rounding behavior of every lending receipt. A cToken adapter, an indexed aToken adapter and an ERC-4626 vault need their own verified calculation paths.
Separate the claim from permission and liquidity
A protocol balance can include assets currently lent to borrowers. In the Compound v2 reference source, the exchange rate uses cash plus borrows minus reserves, divided by receipt supply. Its redemption path separately checks account policy and available cash. This explains how the example's 1,040 U claim can coexist with only 600 U ready for withdrawal.
That source also distinguishes exchangeRateCurrent, which accrues interest, from exchangeRateStored, which does not. A balanceOfUnderlying call also follows the accrual-updating path; it is not a view-only getter. Record the method, its mutability and whether the result came from a read simulation or a confirmed transaction, as well as the block. A stored checkpoint and an updated conversion need not represent the same accrual boundary.
Account restrictions are another independent limit. Aave V3's Pool documentation explains that withdrawing collateral backing debt must preserve the required health factor. Sufficient pool cash alone does not establish that a particular borrower can withdraw its entire visible aToken balance.
For a compliant ERC-4626 vault, distinguish three calls. convertToAssets gives an accounting conversion. previewRedeem includes withdrawal fees but ignores redemption limits. maxRedeem considers global and user limits. These distinctions come from the ERC-4626 specification. A favorable preview alone does not establish that the proposed quantity is presently redeemable.
Selling a receipt introduces a different measurement again: the market's quote for a specified quantity. The liquid staking token discount example illustrates why a conversion benchmark and sale proceeds need separate columns. The same measurement discipline applies here; a lending receipt's accounting rate is not an executable market bid.
If receipts leave an account through liquidation, identify that transfer explicitly. The liquidation bonus and borrower-penalty ledger separates collateral seized from debt repaid. A reduced receipt balance following that event should not be classified as negative lending accrual.
Keep a record another reader can reproduce
Use one observation block for balance and conversion reads. Save the relevant transaction identities for changes between observations. If reads come from different blocks, preserve that fact instead of reporting them as one synchronized balance.
| Record | What to save | Error it helps catch |
|---|---|---|
| Asset identity | Chain, underlying and receipt addresses, decimals, implementation and wrapper | Mistaking a receipt for underlying or applying another version's method |
| Balance basis | Visible receipt quantity; scaled quantity separately where relevant | Multiplying an already indexed balance again |
| Conversion evidence | Block, method, rate or index, direction and integer scale | Combining a fresh balance with a stale or inverted conversion |
| Position flows | Contributions, receipts transferred, redemptions and liquidation transfers | Calling every balance change interest |
| Exit conditions | Available liquidity, account eligibility and applicable limits | Equating an accounting claim with immediate cash |
| Completed exit | Actual receipt burn, underlying received and separate network costs | Recording a request, preview and receipt as three withdrawals |
Recompute the conversion from raw units, then compare it with the contract's own underlying-equivalent calculation where available. Investigate a discrepancy beyond documented rounding. Check a small redemption and a larger cash-constrained request in a controlled simulation of the actual implementation; a successful result at one state cannot establish future liquidity.
Finish each reconciliation with three explicit amounts: the remaining underlying claim, underlying actually received, and contributions or transfers explaining the change. For the worked example those are 780 U remaining, 260 U received and 1,000 U contributed, leaving the stipulated 40 U accrual fully accounted for.