EarnADA x Solid Group: Audit Results
Auditing Process
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.
Contract
Highlights of the process
✅BEP-20’s Conformance
✅ No mint function
Privileged Functions / Owner Capabilities
SetupAddToWhitelist — The owner can add address to_whiteList whitelist addresses are able to trade a small amount before regular trading unlocks(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.
TeamExcludeFromStaking
TeamExcludeFromStaking
TeamSetSellLockTime - The team can set the cooldown period between two successive sells (cannot be greater than two hours)
TeamExcludeAccountFromFees
TeamIncludeAccountToFees
TeamExcludeAccountFromSellLock
TeamIncludeAccountToSellLockFindings
Issue #1 | Logical Issue| 🔴 High | 🔍 _taxedTransfer | ✅ Acknowledge
Description
_sellLock isn't updated when transferring between two addresses, this means users can bypass the sell cooldown limit by sending to multiple addresses.
Team
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
Description
The if condition isLiquidityTransfer is logically wrong and will always be false.
bool isLiquidityTransfer = ((sender == _pancakePairAddress && recipient == pancakeRouter)
|| (recipient == _pancakePairAddress && sender == pancakeRouter));and addLiquifityETH
Example for liquidity Addition
Binance Transaction Hash (Txhash) Details | BscScan
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
Description
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.
Team
If liquidity unlocks holders need to watch carefully that Liquidity lock gets prolonged immidiately after the removal.
Issue #4 | Logical Issue| 🟢 Informational | _taxedTransfer | ✅ Acknowledge
Description
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.
Team
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
Description
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.
require(recipientBalance+amount<=balanceLimit,”whale protection”);Team
Can be bypassed by the team by excluding account that removes Liquidity.
Issue #6 | Logical Issue| 🟠 Medium | claimADA | ✅ Acknowledge
Description
The function claimADA calls swapExactETHForTokensSupportingFeeOnTransferTokens function. claimADA should always work always make sure critical functions error cases are handled gracefully!
Recommendation
Use try-catch.
Issue #7 | Volatile Code | 🟠 Medium | _transfer | ✅ Acknowledge
Description
_transfer should always work, even if there is a bug in the contract, to ensure that the toekn will always be tradeable and investors’ funds are safe. If the function is critical (such as _transfer) always make sure its error cases are handled gracefully!
_transfer calls _swapTokenForBNB, _addLiquidity, _distributeStake which could fail.
Recommendation
Use try-catch when calling external functions.
Issue #8 | Logical Issue| 🟢 Informational| ✅ Acknowledge
Description
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.
require(recipientBalance+amount<=balanceLimit,”whale protection”);Team
The owner can exclude account to make Liquidity removal possible.
Issue #9 | Logical Issue| 🟡 Low | receive |✅ Acknowledge
Description
Anyone can send BNB to the contract.
Recommendation
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 | Best Practice | 🟢Informational |✅ Acknowledge
Description
Lack of events in the contract. Events should be added to all the functions that change important variables and contract functionality.
TeamReleaseLiquidityTeamUnlockLiquidityInSecondsTeamlimitLiquidityReleaseTo20PercentSetupRemoveFromWhitelistSetupAddArrayToWhitelistSetupLiquidityTokenAddressSetupAddToWhitelistSetupEnableWhitelistTradingSetupEnableTradingTeamRemoveLiquidityTeamRemoveRemainingBNB
Summary
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 until the 20th of September approximately.
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.
📣 Telegram| 🗣Telegram discussion group |🐦 Twitter |🛡 Contact for audit
About EarnADA
EarnAda is a passive yield token that rewards holders with ADA just for holding. Different from another token, you can claim your rewards at any time. EarnADA combines a unique Auto staking mechanism with a unique whale and dump protection. EarnADA has a variable Tax rate capped at max. 20% to generate ADA-Rewards, generate Liquidity and Burn Token, to make EarnADA a deflationary currency. Sells are limited to max. 0.25% of the initial supply and after each sells you are locked from selling for 30 minutes.
📣 Telegram group | 🐦 Twitter | 🌍 Website
Disclaimer
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.
