ShieldNetwork
Locker.sol
Issue 1 - Informational Severity - makeUnlockTokensRequest(), acceptUnlockTokensRequest() | ✔️ Resolved
Description
Lack of events in these functions.a
Recommendation
Consider adding event
Question: Consider checking that an unlock request was made in acceptUnlockTokensRequest()
Presale.sol
Issue 1 - Logical Issue - Low Severity - Line 73 | ✔️ Resolved
Description
Line 73 enforces that busdLimits[0] is strictly smaller than busdLimits[1]. Some presales may wish to provide only a single contribution amount, which isn't possible with this condition.
Recommendation
Consider changing the condition to "<="
Issue 02 - Volatile Code - High Severity - join function | ✔️Resolved
Description
In join(), if tokenToHold is set to address(0), line 107 will raise an exception, rendering the contract useless.
Recommendation:
Check if tokenToHold == address(0) in the require.
Issue 03 - Logical Issue - High Severity -
join, withdrawRaisedFunds function | ✔️Resolved
Description
If a malicious user sends busd to the contract, he can make tokenAmount greater than the available tokenX balance, which will make the withdrawal fail.
This issue can also arise if there is no hardcap and the presale contract raised more funds than the owner has tokenX to cover.
Recommendation
Calculate tokenAmount based on raised funds, not busd balance, and make sure the owner has enough tokens to cover all amounts of raised funds. Note that in these cases, users will not be able to get refunds until the presale is manually canceled.
Same issue as above on closePresale()
Issue 04 - Gas Optimization - Informational Severity - onlyFactory() | ✔️ Resolved
Description
onlyFactory() modifier is not used.
Issue 05 - Logicial Issue - Medium Severity - withdrawRaisedFunds() | ✔️ Resolved
Description
withdrawRaisedFunds() requires that
without check if hardcap was already reached.
Recommendation
If hardcap was reached before presaleCloseAt, allow withdrawRaisedFunds to continue as the presale has ended de-facto.
Issue 06 - Best Practice - Low Severity - getRefund | ⚠️ Consider Note
Descrption
If presale was successful (softcap was reached) users' funds are locked until either the presale is canceled or the team calls withdrawRaisedFunds.
Recommendation:
Consider taking a more decentralized approach - if presale wasn't canceled or withdrawRaisedFunds after a set amount of time, users can automatically call getRefund
Note
After hard cap is reached, investors are still able to withdraw their funds as long as the presale wasn't finalized by calling withdrawRaisedFunds. Please note, that this can create a scenario where presale bounce between filled and not filled, because as mentioned users can get a refund even after hardcap was reached.
Issue 07 - Logical Issue - Medium Severity - join function | ✔️ Resolved
Description
Contract can buy shield-network token to participate in presale, call join function and sell shield network token immediately. By doing that, they can bypass the minimum amount of tokens required to participate.
Recommendation
require tx.origin is msg.sender in order to prevent contracts from participating in presale
Issue 08 - Best Practice - Informational Severity - join function | ✔️ Resolved
Description
busd name is not indicative, since the presale can raise funds in any token and not restricted to be busd.
Issue 09 - Best Practice - Medium Severity - join function | ✔️ Resolved
Description
The join function checks the amount of raised busd using busd.balanceOf. This means if users erroneously send busd directly to the contract they will not receive tokens, but the project creator will receive their funds.
Recommendation
In withdrawRaisedFunds transfer all excess busd to shield network, and in the join function perform the check using raisedFunds instead of busd balanceOf(address(this)).
Issue 10 - Logical Issue - High Severity - withdrawRaisedFunds |✔️ Resolved
Description
if tokenX has fees then when the presale owner transfer tokenX to the contract for distribution in withdrawRaisedFunds, the contract will receive less tokens than expected which will guarantee that some presale participants won't be able to receive their tokens.
Recommendation
Add a sanity check that makes sure that after the tokenX transfer, the tokenX balance of the presale contract is at least the expected tokenXAmount.
⚠️ Please note that in this scenario, presale does not support tokens with fees on transfer. This should be communicated to clients.
PresaleFactory.sol:
Question: belongsToThisFactory is not used. Is this verification necessary?
Informational: getSelectedItems is not used
Issue 01 - Gas Optimization - Informational Severity - getSelecetedItems | ✔️ Resolved
Description
getSelecetedItems function is not used.
Recommendation
Consider removing unused code.
Issue 02 - Best Practice - Low Severity - Factory | X Not Resolved
Description
busd address is controlled by shield team. However, projects may want to raise their funds in WBNB or any other token.
Recommendation
Let the project choose the funding token from a list of whitelisted tokens (for example, tokens with rfi-like fees shouldn't be supported with the current code).
LockerFactory.sol
Issue 01 - Informational - setLocketImplementation
Description
Typo
General Note
Last updated