validateSupply
Last updated
Last updated
cache
,updateState
, updateInterestRates
were explained in the common functions section.
In validateSupply
, two key checks are being executed:
check asset status: ensure ACTIVE & ensure NOT FROZEN & NOT PAUSED
check supply cap: ensure it is not exceeded by this new supply action
Function takes ReserveConfigurationMap
struct as parameter. ReserveConfigurationMap
contains data
, which is a bitmap, and the various status flags range from bit 56 to 60.
For in-depth explanation: see getFlags
Execution reverts if any of the following conditions are TRUE:
asset is not ACTIVE
asset is PAUSED
asset is FROZED
The long require statement simply means:
if supplyCap == 0, require statement clears (unlimited supply allowed)
if newSupply <= supplyCap, require statement clears
The easier (less-gas intensive) check is placed first, to allow early reversion thereby saving gas on wasted calculations.
Only bits 116 - 151 are set to 0
in the mask; these bits will be set to 1
after the ~
operation.
data & ~SUPPLY_CAP_MASK
will return a hexadecimal number in which all the characters are set to 0,
except potentially the bits representing the supply cap.
These bits will return the hex value of the supply cap.
If supply cap is indeed 0
, then 0x000...000
would be returned.
Numbers in Solidity are left-padded. Therefore to convert our resulting hexadecimal number to the appropriate number representation so that it can be cast as a uint256
, right shifting by 116 bits is required.
this will remove all the 0s on the right, from the least significant bit to the value
left-padding will be done accordingly, to ensure 32 byte representation
See a more in-depth walkthrough of this process at getReserveFactor.
amount
is the incoming injection of deposits
AToken.scaledTotalSupply
represents supply held only by suppliers
Need to account for treasury portion separately as Treasury's ATokens are not minted, just numerically tracked as we saw in .updateState