The contract is designed as a rebasable token, where the total supply changes dynamically. Every 4 days, the supply is halved, and in between, it decreases linearly every 34 minutes.
Potential Issues: This type of contract can be tricky for users because it can result in confusing token balances. Users may see their token count decrease, which could be mistaken for a loss due to a bug or exploit. Also, the frequent changes in supply can lead to various edge cases and bugs if not handled properly.
The contract includes a mechanism where at each rebase, 13.37% of the debased supply is sent to the feesCollector.
Potential Issues: The function updateTotalSupply
checks and potentially sends a portion of the supply to the fees collector address. If the feesCollector
address is not controlled securely, this could result in an unexpected transfer of tokens. Additionally, if the fee collection process is not transparent or clear to users, it could be seen as a hidden fee or a form of centralization.
The contract inherits from Ownable
, meaning there is an owner who has special permissions, such as setting the Uniswap V2 pair address (setUniswapV2Pair
) and the fees collector (setFeesCollector
).
Potential Issues: Having an owner with the ability to change key addresses (like the feesCollector
) and initialize the contract could be used maliciously if these powers are abused or if the owner's private key is compromised.
The contract includes an initialize
function, which sets key addresses like feeCollector
and uniswapV2Pair
.
Potential Issues: If the initialize
function can be called more than once or if it's improperly secured, it could lead to re-initialization attacks where an attacker might reset crucial parameters to values under their control. However, the code does contain checks to prevent this (_initialized
).
The contract uses sync
calls with both the feesCollector
and _uniswapV2Pair
.
Potential Issues: If the contracts for feesCollector
or _uniswapV2Pair
are not properly designed or have their own bugs, calling sync
could lead to unintended side effects.
There is a mechanism to prevent minting beyond a certain point (_maxSharesReached
).
Potential Issues: If this logic is flawed or can be manipulated, it could lead to unexpected token distributions or stop the contract from functioning correctly.
updateTotalSupply()
: Contains the logic for handling the debased supply and sending fees. This function is crucial for the correct operation of the contract and ensuring that debasing and fee collection happen as intended.initialize()
: As mentioned, initializing the contract only once is essential. Any bugs here could lead to vulnerabilities._mintShares()
: Contains logic to handle the maximum number of shares. Any errors here could lead to incorrect minting behavior.Make sure that all imported contracts and libraries, such as OpenZeppelin's ERC20
or SafeERC20
, are reviewed and up-to-date. Using outdated libraries can expose your contract to known vulnerabilities.
Ensure all arithmetic operations are safe from overflow and underflow. Solidity 0.8.0 and above have built-in overflow checks, but if any operations use unchecked arithmetic for gas savings, they should be carefully analyzed.
Events are correctly emitted to ensure transparency of critical actions like setting new addresses and updating supply. This helps in tracking the contract’s operations.
To comprehensively ensure the contract's security:
Given the complexity of the rebase mechanism and the dynamic changes in the supply, extra caution and testing are advised to ensure that the contract behaves as intended under all circumstances.
Link to Github