Solid Group’s auditing process goes in-depth and covers a wide range of token code characteristics. The main things the audit checks for are vulnerabilities and imminent risks to the safety and security of the code, Solid Group does an extensive auditing process intending to help their customers increase their code quality while reducing the high level of risk presented by cryptographic tokens and blockchain technology.
Highlights of the process
✅ No mint function
Privileged Functions / Owner Capabilities
SetupAddToWhitelist — The owner can add address to_whiteList whitelist addresses are excluded from transfer fees(The code is deprecated since the trading now is opened for everyone)
TeamReleaseLiquidity - The Owner
1.Allows unlocking 20% of LP tokens when _liquidityUnlockTime has been reached.
2.lock the remaining LP tokens for DefaultLiquidityLockTime (which is set to 1 hour)
TeamRemoveLiquidity - Allows removing 20% of LP tokens which were automatically added by the swapAndLiquify mechanism when _liquidityUnlockTime has been reached.
TeamRemoveRemainingBNB - after 30 days from _liquidityUnlockTime the team can withdraw all the BNB that is in the contract.
TeamSetSellLockTime - The team can set the cooldown period between two successive sells (cannot be greater than two hours)
Issue #1 | Logical Issue| 🔴 High | 🔍 _taxedTransfer | ✅ Acknowledge
_sellLock isn't updated when transferring between two addresses, this means users can bypass the sell cooldown limit by sending to multiple addresses.
It is by design. The holder should be able to transfer to other accounts without Limits and there is currently a 10% tax on transfers to disencourage from transfering to other accounts to bypass the sell lock. The cooldown isn't meant as perfect protection from selling more than the sellLimit, but rather as obstacle.
Issue #2 | Logical Issue| 🟠 Medium | _transfer | ✅ Acknowledge
The if condition
isLiquidityTransfer is logically wrong and will always be false.
bool isLiquidityTransfer = ((sender == _pancakePairAddress && recipient == pancakeRouter)
|| (recipient == _pancakePairAddress && sender == pancakeRouter));
Example for liquidity Addition
both of them use transferFrom which means the sender in _transfer will be the “real” sender and not the router address. Therefore, the condition
recipient == pancakeRouter will always be false and the condition
sender == pancakeRouter will always be false.
There is no way to differentiate between sell transaction and addLiquidity transaction and buy transaction and removeLiquidity transaction from just looking on the sender/recipient.
Issue #3 | Logical Issue| 🟠 Medium | SetupEnableWhitelistTrading | ✅ Acknowledge
The comments don’t match the logic. From the comments, it seems like the liquidity should be locked for 7 days, however,
DefaultLiquidityLockTime is set to 1 hour which means the LP will be locked only for one hour from listing.
If liquidity unlocks holders need to watch carefully that Liquidity lock gets prolonged immidiately after the removal.
Issue #4 | Logical Issue| 🟢 Informational | _taxedTransfer | ✅ Acknowledge
isSell will be applied to liquidity addition transactions as well. Therefore,
sellLimit will be applied to add liquidity transactions as well, as there is no way to differentiate between adding liquidity transactions to sell transactions. Make sure the contract is excluded which will exclude the contract from limitations.
Can be bypassed by the team by excluding account that adds Liquidity.
it's not meant to manually add Liquidity, as contract handles auto Liquidity.
Issue #5 | Logical Issue| 🟢 Informational | _taxedTransfer | ✅ Acknowledge
isBuy will be applied to liquidity removal transactions as well. Therefore,
balanceLimit will be applied to liquidity removal transactions as well, since there is no way to differentiate between removing liquidity transactions to buy transactions.
Can be bypassed by the team by excluding account that removes Liquidity.
Issue #6 | Logical Issue| 🟠 Medium | claimLINK | ✅ Acknowledge
swapExactETHForTokensSupportingFeeOnTransferTokens function, always make sure its error cases are handled gracefully!
Issue #7 | Volatile Code | 🟠 Medium | _transfer | ✅ Acknowledge
_transfer should always work, even if there is a bug in the contract, to ensure that investors’ funds are safe. If the function is critical (such as _transfer) always make sure its error cases are handled gracefully!
_distributeStake which could fail.
Use try-catch when calling external functions.
Issue #8 | Logical Issue| 🟠 Medium | ✅ Acknowledge
The owner cannot remove liquidity without setting balanceLimit to be as high as the number of tokens that are in the liquidity pool. Note that balanceLimit can never be reduced.
The owner can exclude account to make Liquidity removal possible.
Issue #9 | Logical Issue| 🟡 Low | receive |✅ Acknowledge
Anyone can send BNB to the contract.
Our recommendation is to slightly modify the receive() function and to reject any BNB that wasn’t received from the router or other specific addresses in order to prevent a case where investors mistakenly send BNB to the contract.
Issue #10 |Informational | 🟢 Best Practice| ✅ Acknowledge
Lack of events in the contract. Events should be added to all the functions that change important variables and contract functionality.
The team manually lock the LP tokens that were automatically added by calling swapAndLiquify. They mistakenly set the default locking period to 1 hour instead of 1 week on deployment. Therefore, once the tokens are unlocked only 8 hours are needed (in the best case) for all the LP tokens to be fully unlocked. Please make sure the team can provide a transaction for the latest locking transaction. As for now, the tokens are locked for 1 week until the 12th of July.
Earn ChainLink by holding our token eLINK, our token earns you link every time someone buys, sells, or transfers their eLINK token. Claiming can be done by using our dApp.
About Solid Group
Solid Group is a blockchain consulting and auditing service provider, founded by 3 cybersecurity experts with a passion for thinking out of the box, learning, and sharing knowledge. Every project goes through a meticulous process and is viewed by at least two partners, thereby achieving a high level of credibility and professionalism. Our group is partnered with multiple organizations and launchpads that have a combined market cap of over 400 million USD.
SolidGroup reports are not, nor should be considered, an “endorsement” or “disapproval” of any particular project or team. These reports are not, nor should be considered, an indication of the economics or value of any “product” or “asset” created by any team. Solid Group do not cover testing or auditing the integration with external contract or services (such as Unicrypt, Uniswap, PancakeSwap etc’…)
SolidGroup Audits do not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor do they provide any indication of the technologies proprietors. SolidGroup Audits should not be used in any way to make decisions around investment or involvement with any particular project. These reports in no way provide investment advice, nor should be leveraged as investment advice of any sort. SolidGroup Reports represent an extensive auditing process intending to help our customers increase the quality of their code while reducing the high level of risk presented by cryptographic tokens and blockchain technology. Blockchain technology and cryptographic assets present a high level of ongoing risk. SolidGroup’s position is that each company and individual are responsible for their own due diligence and continuous security. SolidGroup in no way claims any guarantee of security or functionality of the technology we agree to analyze.