Audit Report for ThunderBolt Project
Overview
Network: on-chain Binance Smart Chain
Website: https://thunderboltfinance.io/
Telegram Group: https://t.me/ThunderBoltBurn
Twitter: https://twitter.com/ThunderBoltBurn
About Thunder Bult
ThunderBolt is a deflationary token with a positive rebase. Total of 156 cycles, each cycle has a TAX amount on buy/sell and send TXs. The tax starts at 5% and scales to 12% per cycle. The fee gradually increases as 1.275M tokens are burnt per cycle. The cycle concludes when it reaches a total of 1.275M tokens burnt. Upon that 50% of the total burnt is minted back to $BOLT holders. The cycle starts again at 5% tax.
Files In Scope
Vulnerability Summary
UML
BEP’s 20’s Conformance
This test checks for BEP-20’s conformance.
• All the functions are present
• All the events are present
• Functions return the correct type
• Functions that must be view are view
• Events’ parameters are correctly indexed • The functions emit the events
• Derived contracts do not break the conformance
Check Events:
✅ Transfer Event
✅ Approve Event
Issue #1
Description
The state variables transferredTokens, tokenBatchCount, MAX_SUPPLY, _gonsPerFragment, and _gonBalances, are never used in the contract.
Recommendation
Remove unused variables to save on storage.
Issue #2
Description
There are many magic numbers in the code.
Recommendation
Magic numbers should be refactored with constant variables. It improves the readability of the code, and easier to maintain.
Issue #3
Description
A function that affects the status of sensitive variables should emit an event. The function _setFeeStage sets the _BURN_FEE a variable which determines the amount of % that is burned in every transaction.
Recommendation
Our recommendation is to add events in critical parts of the contract, such as when the burn rate is changed, when the fee is collected, and the number of tokens that were burned in a transaction. Events are great for integrating with DApps in the future. We recommend considering emitting events when the state is changed.
Issue #4
Description
Lack of events in the contract.
Events are important for the integration with blockchain explorers which are commonly used by non-technical investors(for example BSCSCAN). However, when a burn occurs, the amount of tokens the investor actually gets differs from the number of tokens that are shown in the explorers.
Recommendation
Our recommendation is to emit appropriate Transfer events when burning tokens and collecting fees. For example:
This fix should be applied to all _transfer* functions.
Issue #5
Description
uint256 variables always greater than zero. burnFee type is uint256, burnFee >=0 will be always True.
Example:
Recommendation
Fix the incorrect comparison by changing the value type or the comparison. possible fix:
Contact for audits on Telegram: t.me/solid_1
Contact for audits on Twitter: https://twitter.com/solid_group_1
