Eloin 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 Address
Network: Binance Smart Chain
Highlights of the process
✅BEP-20’s Conformance
✅ No mint function
Contract
Owner Capabilities
Findings
Issue #1 | Owner Capabilities | 🔴 High | 🔍 setTaxFeePercent, setLiquidityFeePercent, setMaxTxPercent, setExtraTaxFeePercent | Status: Fixed ✅
Description
The owner of the contract can make the tokens untradable. By calling setMaxTxPercent(0) or by setting _taxFee variable or _liquidityFee or _extraTaxFee, variables to a significant %. (Pancakeswap behavior is unexpected if the total slippage exceeded 39%)
Recommendation
For the first issue, our recommendation is to limit the sum of _taxFee , _liquidityFee, and _extraTaxFee to a reasonable number.
For the second issue, our recommendation is to add a require statement that would limit setting _maxTxAmount to 0.
Issue #2 | Volatile Code| 🔴 High | 🔍 _transfer | ✅ Fixed
Description
_transfer function should always work, even if a bug was found in the contract.
In order to ensure that investors’ funds are safe & secured.
If a function is mandatory (such as _transfer) our state of mind is to always make sure its error cases are handled gracefully!
_transfer calls swapTokensForEth and addLiquidity which could fail when calling swapExactTokensForETHSupportingFeeOnTransferTokens and addLiquidityETH.
Recommendation
Use try-catch statements when calling external functions such as swapExactTokensForETHSupportingFeeOnTransferTokens & addLiquidityETH.
Issue #3 |Owner Capabilities| 🟠 Medium |🔍 lock, unlock | ✅ Fixed
Description
The contract uses a modified version of Ownable contract. These modifications have a significant flaw — a malicious owner can get his owner capabilities even after calling renounceOwnership!
Here’s a list of the required steps:
1️⃣ The owner of the contract can call lock() to lock the contract (the lock function saves the previous owner into a variable)
2️⃣ After the locking period has passed the owner of the contract can call unlock() and regain the ownership.
3️⃣ The owner of the contract can then call the renounceOwnership function. Now, the contract allegedly has no owner (users can verify it by looking for the renounceOwnership transaction and making sure that the owner is set to the zero address).
4️⃣ The owner of the contract can call the unlock function again, and get the ownership back.
Recommendation
Remove lock and unlock functions.
Issue #4 |Best Practice| 🟠 Medium |🔍 swapAndLiquify | ❌ Not Fixed
Description
swapAndLiquify function converts half of the contract’s tokens to BNB. The other half of the tokens are used for liquidity addition. The price of the token drops after executing the first conversion, having said that the other half of tokens require less than the converted BNB to be paired with it when adding liquidity.
Recommendation
Our recommendation is to use the leftover BNBs for buyback. The team could add a simple buyback function that will use the leftover bnbs for buyback.
Issue #5 |Best Practice| 🟠 Medium |🔍 receive| ❌ Not Fixed
Description
In order to prevent the contract from receiving ETH from investors, which will be resulted in a loss of funds, our recommendation is to have “whitelisted” addresses which can send ETH to the contract (for example the router address should be whitelisted).
When an investor sends ETH by mistake, the transaction will be reverted by the contract.
receive() external payable {}
Issue #6 |Logical Issue| 🟠 Medium |🔍 includeInReward| ✅ Fixed
Description
The code is vulnerable to the SafeMoon bug — excluding an address from the fee and then later including it back will cause the address to receive all RFI rewards for the time it was excluded (at the expense of other holders).
In includeInReward _rOwned is not updated. _rOwned should be updated and be calculated according to the current rate.
Recommendation
Properly calculate _rOwned of the included address in includeInReward based on its _tOwned amount
Issue #7 |Owner Capabilities| 🟠 Medium |🔍 addLiquidity| ✅ Fixed
Description
The recipient of the newly created LP tokens is the owner of the contract. The newly created LP tokens are unlocked.
uniswapV2Router.addLiquidityETH{value: ethAmount}(
address(this),
tokenAmount,
0, // slippage is unavoidable
0, // slippage is unavoidable
owner(),
block.timestamp
);
Recommendation
Our recommendation is to change the recipient of the newly created LP tokens to the contract in order to ensure that the LP tokens are locked or to simply locked the tokens in the contract for a certain period.
Issue #8 |Logical Issue| 🟠 Medium |🔍 _isBuy, _isSell| ✅ Acknowledge
Description
There is no way to differentiate between sell transaction and addLiquidity transaction and buy transaction and removeLiquidity transaction by just looking at the sender/recipient.
Therefore, _isBuy will also return True for removeLiquidity transaction, and _isSell will also return true for addLiquidity transactions.
Issue #9 | Best Practice| 🟢 Informational| 🔍 setTaxFeePercent, setLiquidityFeePercent, setMaxTxPercent, setExtraTaxFeePercent, setSwapAndLiquifyEnabled, changeTaxFeeWallet |❌ Not Fixed
Description
Lack of events in the contract.
Recommendation
Our recommendation is to emit events when changing the state variables of the contract.
Issue #10 |Owner Capabilities | 🟠 Medium |🔍 addToBlacklist| ❌ Not Fixed
Issue
The owner of the contract can blacklist any address, even the pair address. If the team blacklist the pair address the token will be untradable.
Recommendation
Limit the timeframe the owner can blacklist addresses.
Issue #11 |Owner Capabilities | 🟠 Medium |🔍 addToBlacklist| ❌ Not Fixed
The owner has the ability to call updateSellLimit function which could adjust the number of tokens being sold in a transaction. If the sell limit will be low , the token would become unsellable due to the fact that gas consumption price could be higher than the value of the transaction itself thus making the transaction not worthwhile.
Recommendation
Limit the minimum value that can be set by updateSellLimit.
Summary
We would like to congratulate Eloin for peaking at x10 shortly after listing using our Bot Protection tool which allowed them to ensure a clean listing & a bot-free environment. We welcome everyone to read more about our exceptional tools and to reach out for future cooperation.
About Eloin
A meme-themed token empowering the creators. Eloin provides the spotlight/platform for unspotted talents.
A deflationary and non-mintable true meme coin that provides meme content creators to create value out of their innovative memes.
Three simple functions occur during each trade: Reflection, LP Acquisition, and Burn. A sort of community-driven project followed by charity, bout, merch, and few more upcoming features.
🗣 Telegram group |🐦 Twitter
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
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.
