Mendifinance used cToken exchange rates to value legacy lending balances.

Reading a legacy supplied balance

A legacy supply balance translated into an underlying asset quantity through the exchange rate for that particular market. The account's cToken balance counted lending tokens representing its supplied position. Those tokens and the underlying asset had different units, so their displayed quantities did not necessarily match. Multiplication by the correctly scaled exchange rate established the underlying quantity represented by the holding. The market applied the same exchange-rate calculation to its holders; each account's token balance determined its share.

The converted amount described gross supplied assets. Outstanding borrowing remained a separate obligation, with its own balance and interest accounting. Subtracting a loan required compatible asset valuations; the supply conversion alone did not describe a net account position.

The market accounting behind the exchange rate

With nonzero cToken supply, the contract divided cash plus recorded borrowing minus reserves by total cToken supply. In raw contract units, the scaled relationship was R = floor((C + L - V) × 10^18 / S) . Here, C represented market cash, L total recorded borrowing, V reserves, and S total cToken supply.

Market cash counted the underlying assets the contract held. Recorded borrowing counted assets borrowers owed the market, including interest already added to accounting. Together, these amounts described the asset backing before the reserve deduction.

Reserves formed a separate accounting allocation. The exchange-rate calculation deducted them before assigning underlying value to cToken supply. Including all cash and borrowing without that deduction would overstate the conversion numerator. Reserve accounting therefore affected supplied-asset valuation even when the account's cToken quantity remained unchanged.

The reserve factor directed a fraction of newly accrued borrowing interest into reserves. That reserve increase reduced the interest contribution to the exchange-rate numerator. The factor belonged to market configuration, so a conversion estimate could not substitute a universal reserve percentage.

A zero-supply market followed a different branch: the contract returned its configured initial exchange rate. That initial parameter applied to the zero-supply branch; it did not establish a common conversion value across every legacy market.

Raw units and token decimal precision

Raw cToken and underlying balances used integers, and each token's decimal precision determined its readable quantity. The conversion needed those units before any display formatting.

Contract-unit calculation

The underlying conversion used the raw cToken balance B and the scaled exchange-rate integer R. Its relationship was U = floor(B × R / 10^18) , where U represented raw underlying units. The fixed-point divisor removed the rate's arithmetic scale. Applying that expression directly to a balance already formatted as readable cTokens would mix units. The contract's calculation operated on integers before a display added decimal places.

Readable token quantities

The underlying asset's decimal precision converted U into a readable asset amount. The cToken's precision separately controlled how its own integer balance appeared. These precisions need not match. A rate between readable token quantities therefore needed the decimal relationship as well as the fixed-point scale. A large raw rate integer alone conveyed neither a large investment return nor a large asset balance.

When did a stored exchange rate omit interest?

A stored rate omitted borrowing interest the market had not yet added to its recorded balances. Elapsed time and completed accrual updates therefore described different accounting states.

Stored reads

The legacy exchangeRateStored method calculated the conversion without accruing interest first. It used recorded borrowing and reserves alongside the contract's cash calculation. A stored read did not freeze the rate at an earlier displayed number. Cash formed an input to the calculation, while pending interest remained outside the recorded borrowing and reserve amounts.

Accrual before calculation

The exchangeRateCurrent method called accrueInterest before returning the calculated rate. Accrual updated total borrowing, reserves, and the borrow index. The balanceOfUnderlying method used that current-rate path to calculate an account's underlying balance. Stored and current calculations could agree when no additional interest accrued; the different method names did not guarantee different values.

View full-size image

Elapsed time in the legacy interest model

The legacy base implementation measured elapsed time through timestamps, despite several identifiers containing the word block. Its getBlockNumber function returned block.timestamp . Interest accrual used the difference between that value and the previous accrual checkpoint. Reading borrowRatePerBlock as a rate per produced blockchain block would therefore misinterpret this base implementation. Annualizing a rate required the actual time basis and the applicable interest model. A method name alone did not supply those assumptions or a permanent annual return.

Two redemption inputs and one conversion relationship

The legacy ERC-20 market implementation exposed redemption by cToken quantity and redemption by underlying quantity. These entry points used the exchange rate in opposite calculation directions. Their parameter units determined what the caller specified, while the market's redemption checks governed whether either operation could proceed.

A cToken quantity

The redeem entry point accepted the number of cTokens to exchange. The calculation multiplied that quantity by the exchange rate to determine underlying output. An amount expressed in readable underlying tokens did not belong in this cToken-unit parameter. The internal redemption path accrued interest before calculating the conversion and checking the requested redemption.

An underlying quantity

The redeemUnderlying entry point accepted the requested underlying amount. Division by the exchange rate determined the corresponding cToken quantity. This path also accrued interest before conversion. An earlier stored-rate estimate could therefore differ from the arithmetic at execution. Both entry points retained collateral and market-cash constraints; changing the input unit did not remove those conditions.

Account snapshots and collateral valuation

An account snapshot combined a cToken balance, a stored borrowing balance, and a stored exchange rate. The controller used those values when assessing collateral requirements. Its calculation converted supplied cTokens into underlying exposure, then applied the market's collateral factor and oracle price. Borrowing contributed separately through the borrowed asset's price. This produced a collateral-adjusted account assessment, with a different meaning from an underlying supply balance. A price movement or collateral-factor change could alter that assessment without changing the wallet's cToken count.

The hypothetical account-liquidity calculation modeled a proposed redemption or additional borrowing using stored market snapshots. It did not itself accrue fresh interest across those markets. The calculation returned excess collateral capacity or a shortfall after the proposed effect. A zero oracle price produced a price error in this controller calculation. Accurate token conversion alone therefore did not establish the value the controller could use for collateral assessment.

Conversion value and available cash

A computed underlying entitlement could exceed the assets a market held as immediately transferable cash. Recorded loans contributed to the exchange-rate numerator, while redemption required enough underlying cash for the requested output. The redemption implementation rejected an output exceeding its available cash. The controller also checked the proposed effect on collateral for accounts entered into that market.

Integer rounding at the conversion boundary

Integer division discarded fractional raw units in the conversion arithmetic. Multiplying cTokens by the scaled rate produced an underlying integer, while dividing an underlying amount by the rate produced a cToken integer. Display software could then apply its own rounding to readable quantities. These operations occurred at different boundaries, so reversing a displayed conversion did not necessarily reproduce the original integer balance.

The relevant precision depended on the market's token units and the requested direction. The redemption verification hook also rejected a positive underlying amount paired with zero redeemed cTokens. A tiny requested amount therefore needed more than a visually nonzero display value; the contract arithmetic determined the corresponding token quantity.

Historical balance comparisons after sunset

A historical balance comparison needed the cToken holding and market rate from the same accounting state. Combining an earlier balance with a later rate assigned later market accounting to an earlier holding. Changes in the account's token quantity could also affect its supplied-asset amount. The market rate alone therefore could not explain the account's entire balance change if its cToken quantity also changed. Meaningful comparisons preserved the relevant market, units, and time context.

The sunset notice specified a limited withdrawal-interface period without giving a calendar cutoff. Smart-contract access was the specified continuation after that window. Legacy balance valuation still concerned the underlying assets represented by a position. Its practical limit remained the distinction between that accounting quantity and assets available for an actual redemption.