Powered by SECURI LAB
-
yes
-
-
yes
-
-
-
-
yes → NewContract:DividendDistributor
yes
yes
Vulnerability Findings
ID | Vulnerability Detail | Severity | Category | Status |
SEC-01 | Unchecked tokens transfer (unchecked-transfer) | High | Acknowledge | |
SEC-02 | Centralization Risk | High | Acknowledge | |
SEC-03 | Avoid using block timestamp | Low | Acknowledge | |
SEC-04 | Empty Function Body – Consider commenting why | Low | Acknowledge | |
SEC-05 | Multiple calls in a loop (calls-loop) | Low | Acknowledge | |
SEC-06 | unlocked-compiler-version | Informational | Acknowledge | |
SEC-07 | inconsistent-comments-and-code | Informational | Acknowledge | |
NC-01 | Functions not used internally could be marked external | – | Acknowledge | |
GAS-01 | Use `selfbalance()` instead of `address(this).balance` | – | Acknowledge | |
GAS-02 | Use assembly to check for `address(0)` | – | Acknowledge | |
GAS-03 | Using bools for storage incurs overhead | – | Acknowledge | |
GAS-04 | Use Custom Errors | – | Acknowledge | |
GAS-05 | Use != 0 instead of > 0 for unsigned integer comparison | – | Acknowledge |
SEC-01: Unchecked tokens transfer (unchecked-transfer)
Vulnerability Detail | Severity | Location | Category | Status |
Unchecked tokens transfer (unchecked-transfer) | High | Check on finding | Acknowledge |
Finding:
DividendDistributor.distributeDividend(address) (ETS.sol:354-365) ignores return value by ETH.transfer(shareholder,amount) (ETS.sol#360)
Recommendation:
Use `SafeERC20`, or ensure that the transfer/transferFrom return value is checked.
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unchecked-transfer
Exploit Scenario:
there’s a potential risk associated with the ETH.transfer(shareholder, amount) line. This line transfers Ether without checking for the success of the transfer operation. If the transfer fails, the contract will continue executing, potentially leading to unexpected behavior.
Alleviation:
EthShares team has Acknowledge this issue.
SEC-02: Centralization Risk
Vulnerability Detail | Severity | Location | Category | Status |
Centralization Risk | High | Check on finding | Acknowledge |
Finding:
109: abstract contract Auth {
135: function authorize(address adr) public onlyOwner {
142: function unauthorize(address adr) public onlyOwner {
163: function transferOwnership(address payable adr) public onlyOwner {
398: contract ETS is IBEP20, Auth {
468: ) Auth(msg.sender) {
“`
Scenario:
Centralized risk refers to the potential security risks that arise when a smart contract is controlled by a central entity or a single point of failure. If the contract is controlled by a central authority, then the contract may be vulnerable to attacks that target the centralized entity.
Centralized risk that can lead to rug pulls typically arises from the centralization of control or ownership of a project’s assets, particularly in decentralize d finance (DeFi) projects built on blockchain platforms like Ethereum.
Contract Auth (File: ETS.sol)
In the Auth (File: ETS.sol) contract, Owner can call functions authorize, unauthorize, transferOwnership We’ve found that some functions work in an anti-whale manner and allow the owner to pause trading. Assigning a backlist address and also another function we recommend that for transparency use Timelock to increase the delay for users. Function calls are visible before they are fully executed. Additionally, the implementation of a multi-signature feature adds another layer of security to safeguard the owner’s account.
Contract ETS (File: ETS.sol)
In the ETC (File: ETS.sol) contract can external call, for authorized role can call functions setTradingEnabled, triggerZeusBuyback, clearBuybackMultiplier, setAutoBuybackSettings, setBuybackMultiplierSettings, launch, setTxLimit, setIsDividendExempt, setIsFeeExempt, setIsTxLimitExempt, setFees, setFeeReceivers, setSwapBackSettings, setTargetLiquidity, setDistributionCriteria, setDistributorSettings We’ve found that some functions work in an anti-whale manner and allow the owner to pause trading. Assigning a backlist address and also another function we recommend that for transparency use Timelock to increase the delay for users. Function calls are visible before they are fully executed. Additionally, the implementation of a multi-signature feature adds another layer of security to safeguard the owner’s account.
Recommendation:
In terms of timeframes, there are three categories: short-term, long-term, and permanent.
For short-term solutions, a combination of timelock and multi-signature (2/3 or 3/5) can be used to mitigate risk by delaying sensitive operations and avoiding a single point of failure in key management. This includes implementing a timelock with a reasonable latency, such as 48 hours, for privileged operations; assigning privileged roles to multi-signature wallets to prevent private key compromise; and sharing the timelock contract and multi-signer addresses with the public via a medium/blog link.
For long-term solutions, a combination of timelock and DAO can be used to apply decentralization and transparency to the system. This includes implementing a timelock with a reasonable latency, such as 48 hours, for privileged operations; introducing a DAO/governance/voting module to increase transparency and user involvement; and sharing the timelock contract, multi-signer addresses, and DAO information with the public via a medium/blog link.
Finally, permanent solutions should be implemented to ensure the ongoing security and protection of the system.
Alleviation:
EthShares team has Acknowledge this issue.
SEC-03: Avoid using block timestamp
Vulnerability Detail | Severity | Location | Category | Status |
Avoid using block timestamp | Low | Check on finding | Acknowledge |
Finding:
314: block.timestamp
350: return shareholderClaims[shareholder] + minPeriod < block.timestamp
361: shareholderClaims[shareholder] = block.timestamp;
583: if (launchedAtTimestamp + 1 days > block.timestamp) {
585: } else if (buybackMultiplierTriggeredAt.add(buybackMultiplierLength) > block.timestamp) {
586: uint256 remainingTime = buybackMultiplierTriggeredAt.add(buybackMultiplierLength).sub(block.timestamp);
624: block.timestamp
647: block.timestamp
664: buybackMultiplierTriggeredAt = block.timestamp;
689: block.timestamp
716: launchedAtTimestamp = block.timestamp;
Recommendation:
Using block timestamp in smart contracts can lead to security vulnerabilities and should be avoided.
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#block-timestamp
Exploit Scenario:
–
Alleviation:
EthShares team has Acknowledge this issue.
SEC-04: Empty Function Body – Consider commenting why
Vulnerability Detail | Severity | Location | Category | Status |
Empty Function Body – Consider commenting why | Low | Check on finding | Acknowledge |
Finding:
493: receive() external payable { }
550: if(!isDividendExempt[sender]){ try distributor.setShare(sender, _balances[sender]) {} catch {} }
550: if(!isDividendExempt[sender]){ try distributor.setShare(sender, _balances[sender]) {} catch {} }
551: if(!isDividendExempt[recipient]){ try distributor.setShare(recipient, _balances[recipient]) {} catch {} }
551: if(!isDividendExempt[recipient]){ try distributor.setShare(recipient, _balances[recipient]) {} catch {} }
553: try distributor.process(distributorGas) {} catch {}
553: try distributor.process(distributorGas) {} catch {}
635: try distributor.deposit{value: amountBNBReflection}() {} catch {}
635: try distributor.deposit{value: amountBNBReflection}() {} catch {}
Recommendation:
While this line of code might work correctly in most cases, it is considered potentially unsafe because it assumes the ERC20 token contract implements the transfer function correctly and consistently with the ERC20 standard.
A safer way to interact with ERC20 tokens is to use a widely-adopted and audited library, such as OpenZeppelin’s ERC20 library. This helps you avoid potential issues with non-standard or malicious token implementations.
Alleviation:
EthShares team has Acknowledge this issue.
SEC-05: Multiple calls in a loop (calls-loop)
Vulnerability Detail | Severity | Location | Category | Status |
Multiple calls in a loop (calls-loop) | Low | Check on finding | Acknowledge |
Finding:
354: function distributeDividend(address shareholder) internal {
if(shares[shareholder].amount == 0){ return; }
uint256 amount = getUnpaidEarnings(shareholder);
if(amount > 0){
totalDistributed = totalDistributed.add(amount);
ETH.transfer(shareholder, amount);
shareholderClaims[shareholder] = block.timestamp;
shares[shareholder].totalRealised = shares[shareholder].totalRealised.add(amount);
shares[shareholder].totalExcluded = getCumulativeDividends(shares[shareholder].amount);
}
365: }
Recommendation:
distributeDividend(address shareholder) function, which involves making an external call using ETH.transfer(shareholder, amount). Although the provided code snippet does not contain a loop, the warning suggests that you should favor the “pull over push” strategy for external calls, which can help reduce the risk of reentrancy attacks and make your contract more gas-efficient in certain situations.
Favor [pull over push](https://github.com/ethereum/wiki/wiki/Safety#favor-pull-over-push-for-external-calls) strategy for external calls.
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation/#calls-inside-a-loop
Exploit Scenario:
–
Alleviation:
EthShares team has Acknowledge this issue.
SEC-06: unlocked-compiler-version
Vulnerability Detail | Severity | Location | Category | Status |
unlocked-compiler-version | Informational | Check on finding | Acknowledge |
Finding:
2: pragma solidity ^0.8.0;
Recommendation:
Unlocked pragma disables all source code analysis, making it vulnerable to attacks
Exploit Scenario:
–
Alleviation:
EthShares team has Acknowledge this issue.
SEC-07: inconsistent-comments-and-code
Vulnerability Detail | Severity | Location | Category | Status |
inconsistent-comments-and-code | Informational | Check on finding | Acknowledge |
Finding:
538: //
Recommendation:
Inconsistent comments and code can lead to confusion and misunderstandings when maintaining and auditing a smart contract. It’s crucial to keep comments up-to-date and in sync with the actual code implementation
Exploit Scenario:
–
Alleviation:
EthShares team has Acknowledge this issue.
Powered by SECURI LAB SIPNet+