Description: Any address can abort the LGE at any time before it has reached its soft cap.

Risk/Impact: Any SD Token's LGE can be aborted instantly, or after users have deposited to prevent fundraising and deny LGE functionality.

Recommendation: The project team should disallow LGE abortions before its end time is reached.

Resolution: The team has implemented the above recommendation.

Description: The loanAll() function does not properly erase a user's debt from their existing expired loan. Only the first backing token's debt is erased.

for(i = 0; i < l; i++) {
	if (loansToken[user] > 0 && lendData[user] <= timeNow1) {
		loansBaseAll[user][backingAssets[i]] = 0;
	}
	how = loansToken[user];
	if(how > 0) {
		collateral -= how;
		loansToken[user] = 0; 
		lendData[user] = 0;
		SafeTransfer._pushUnderlying(IERC20(mainToken), BURN, how);
	}
}

Risk/Impact: Users will carry over debt from an expired loan when opening a new one. This debt is added to their new loan, requiring them to owe more on it than intended.

Recommendation: The logic in the for loop above should be updated to ensure that all backing token debt is erased when an expired loan is deleted.

Resolution: The team has implemented the above recommendation.

Description: A user's regularLoan status does not change upon opening a new multi-token loan. If a user's single token loan expires and is replaced by a multi-token loan, they will still be marked as holding a single token loan.

Risk/Impact: Users replacing expired single token loans with multi-token loans will be prevented from repaying their loan by the current repayment logic.

Recommendation: A user's regularLoan status should be set to false when a loan is erased in the loanAll() function.

Resolution: The team has implemented the above recommendation.

Description: A user's single token debt is not erased when replaced by a multi-token loan.

Risk/Impact: Certain scenarios could result in a user owing more than intended on a loan. For example, if a user takes a single token loan, replaces it with a multi-token loan, then replaces it once again with a single token loan, they will owe the sum of their current loan's debt and their first loan's debt.

Recommendation: A user's loanBase amount should be set to zero upon replacement by a multi-token loan.

Resolution: The team has implemented the above recommendation.

Description: In an effort to mitigate front running risk, the platform has employed a "tick" system to compare the 4 most recent liquidity pool reserve values. The SDDeployer's FEG:WETH and Backing:WETH ticks are set upon any deposit into an LGE using them, making them susceptible to tampering.

Risk/Impact: A malicious user can manipulate ticks by first executing a large FEG or Backing token buy to significantly change reserve values. The user can then execute four negligible LGE deposits to create 4 ticks that store the new reserve values. If the user can then trigger the LGE to end, the front running check will pass as the 4 ticks that are compared will all be similar. This allows them to successfully front run the LGE's WETH→FEG swap or WETH→Backing swaps executed during its end.

Recommendation: The project team should use a price oracle instead of the current tick logic to calculate expected amounts to receive from swaps. To facilitate this, a backing token whitelist with associated oracle addresses could be introduced. The project team could alternatively allow SD token creators to provide their own oracle, but this would require additional trust in the creators. A third solution would be to only allow the SD token owner to end their LGE, and add minimum Backing token and FEG amount parameters to the endLGE() function.

Resolution: Minimum FEG and Backing amounts to receive on swaps are now specified upon ending an LGE. Additionally, only the LGE owner or a Super Admin of the Reader contract are now permitted to end the LGE, so users should ensure trust in the project teams before contributing.

Description: The SD contract’s setBacking() function can only be called by the associated BackingLogic address, but the BackingLogic contract only calls SDT.setBackingAddress(), which does not exist.

Risk/Impact: The BackingLogic contract's updateBacking() function will always fail, disabling its functionality.

Recommendation: The project team should ensure that the correct function name is called when attempting to update the SD token's backing asset.

Resolution: The team has implemented the above recommendation.

Description: The SD contract’s frontRun() function contains the following line which intends to multiply the user’s latest balance by the specified range to use for comparisons, but instead multiplies the length of the user’s balance array by the range:

uint256 a = (balance[who].length - 1) * range;

Risk/Impact: Front running checks will likely fail due to the comparison of the user's previous balances to a multiple of their balance history length.

Recommendation: The above line should be updated to the following:

uint256 a = (balance[who][balance[who].length - 1]) * range;

Resolution: The team has implemented the above recommendation.

Description: The frontRun() method will now only function properly if an SD token is passed into it due to the following line.

who = tokenBackingPair[who];

Risk/Impact: Front running checks will not be executed on the FEG pool when swapping for FEG in the LGE contract.

Recommendation: The "who" address should not be updated to the tokenBackingPair when called on the FEG address.

Resolution: The Reader contract is now used to fetch the correct address to check ticks on. The team has stated that calls to this contract will now function correctly when FEG front running is checked. The Reader contract was not included in the scope of this audit.

Description: If significant trading occurs through either the FEG:WETH or Backing:WETH near or after the LGE's end time, the reserves in the pool may vary significantly from the most recently recorded "ticks". As ticks track reserve values to protect against front running, out of date ticks could produce false front running flags.

Risk/Impact: Failed front running checks on swaps executed during an LGE's end could prevent the LGE from ending, even if the transaction is not being front run. As users are not permitted to emergency withdraw if an LGE's end time has passed, user deposited funds would be trapped in the contract.

Recommendation: The project team should implement oracles using the recommendation provided in Finding #2. The project team can also consider only allowing the SD token owner to end their LGE and add minimum Backing token and FEG amount parameters to the endLGE() function.

Resolution: Only the SD owner or a Super Admin of the Reader contract can end the LGE, and must specify minimum Backing and FEG amounts to receive from swaps. As a result, the project team can loosen front run limits if necessary to allow for an LGE to end. Users can also now withdraw from a sold out LGE if it has not been ended after a period has passed from its sell out time.

Description: SD Tokens can be transferred to the SD:FEG pair before an LGE is closed. If liquidity is added before an LGE is closed, the LGE's raised funds may not be added to liquidity at the intended rate, resulting in the contract receiving less LP tokens than intended.

Risk/Impact: The owner or a user holding SD tokens could add liquidity at a ratio much different than the rate defined in the LGE in exchange for liquidity tokens. All raised funds will be added to liquidity when the LGE is ended, but the LGE will receive less LP ownership than they should due to the rate mismatch. The original liquidity provider's LP tokens would then be worth more and could be redeemed for a profit at the loss of the LGE providers.

Recommendation: The project team should prohibit SD token transfers to the SD:FEG pair before the LGE has ended.

Resolution: SD Tokens can now only be transferred to the SD:FEG pair by the LGE address.

Description: The following line present in both the convertBacking() and convertLiquidity() functions incorrectly calls the SD Token's frontRun() method to compare the previous SD balances of the SD Token itself instead of comparing previous SD balances of the SD:WETH Pair.

require(!sdep(mainToken).frontRun(mainToken, range), "Front Run");

Risk/Impact: These functions may incorrectly fail if the owner uses the SD token contract's token locking functionality, preventing taxed token transfers from occurring. It also may allow a swap to occur when the SD:WETH liquidity pool's reserves have been manipulated.

Recommendation: The project team should update the frontRun() function call to the following:

require(!sdep(mainToken).frontRun(uniswapV2Pair(), range), "Front Run");

Resolution: The correct frontrun() calls are now executed, and the tick mechanism has improved. The project team must still ensure that proper settings are used when calling frontRun() to mitigate the risk of manipulation. SD Token owners must also ensure to maintain low backing and liquidity thresholds to mitigate the risk of front running on these swaps.

Description: Exchanges are not exempt from reflection rewards. As a result, Pair addresses will earn significant rewards from holding a large portion of the total supply over time.

Risk/Impact: Rewards earned by the Pair address are not added as reserves unless the sync() function is called, so any user can potentially withdraw reflection rewards from the Pair at any time.

Recommendation: The project team should add an owner ability to exclude addresses from rewards.

Update: The project team has implemented the above recommendation.

Description: When entering an LGE with a user-specified token instead of WETH, the LGE's address is used as the token address parameter instead of the intended token.

SafeTransfer.safeTransferFrom(IERC20(address(this)), msg.sender, address(this), amount);

Risk/Impact: Users will not be permitted to enter LGEs with tokens despite intended functionality.

Recommendation: The above code in the enterLGEWithToken() function should be updated to the following:

SafeTransfer.safeTransferFrom(IERC20(token), msg.sender, address(this), amount);

Resolution: The team has implemented the above recommendation.

Description: Various fields and multipliers throughout the platform are currently set shorter than intended, likely for testing purposes. Examples of this include values in the SDLGE's lockLP(), claimShare(), checkShare(), setVesting(), editLGE(), and setInitial() functions, as well as many other values throughout the platform.

Risk/Impact: Functionality throughout the platform will not work as intended.

Recommendation: The project team should update these values to their intended amounts.

Resolution: The team has implemented the above recommendation.

Description: KYC and ticket details are intended to be sensitive information and are access-restricted; however, any variables present on the blockchain are inherently public.

Risk/Impact: Sensitive information, including submitted KYC information, can be accessed by anyone despite intended functionality.

Recommendation: Any sensitive information should be stored off-chain.

Resolution: The team stated that sensitive information is not intended to be directly submitted to the blockchain. Users should ensure that any submitted links are access-restricted.

Description: When submitting KYC in the SDDeployer.submitKYC() function, heldDonation is only incremented by the minimum ticket cost, but is decremented by the entire donated amount when confirmed or recovered. This can lead to underflow if the donated amount is larger than the minimum ticket cost.

Risk/Impact: Ticket and KYC functionality could break for an SD token if a user chooses to donate more than the minimum price for KYC verification.

Recommendation: The heldDonation variable should be incremented by the entire donation amount in the submitKYC() function.

Resolution: Donation amounts for tickets and KYC now must equal exactly the minimum price, preventing underflow.

Description: The following ternary operators in the recoverDonation() and confirmKYC() functions currently execute the inverse of their intended functionality. The heldDonation variable is reset to zero if the recovered or confirmed value is less than the current total heldDonation, and the recovered or confirmed value is subtracted from heldDonation if it is greater.

heldDonation[sd] = d > heldDonation[sd] ? heldDonation[sd] - d : 0;

heldDonation[sd] = don > heldDonation[sd] ? heldDonation[sd] - don : 0;

Risk/Impact: The heldDonation variable will be incorrectly reset and will underflow in many cases, breaking ticket and KYC functionality.

Recommendation: The expressions updating the heldDonation variable should be swapped in both of the above lines.

Resolution: The team has implemented the above recommendation.

Description: The SD Token's front running mechanism is also susceptible to manipulation if taxes are low enough. A malicious user can set their accepted slippage to the maximum of 30%, make multiple large trades to impact SD prices, then several small trades to level out recent tick values.

Risk/Impact: Swaps executed by the BackingLogic contract may not be protected from front running if the SDToken's backing threshold or liquidity threshold is large enough. Users may also be susceptible to front running and could receive less tokens than intended from a buy or sell if they do not provide a maximum slippage to the Router contract.

Recommendation: SD Token owners should ensure to set a low backing and liquidity threshold to mitigate front running risk. Users should exercise caution and avoid relying on the token's built in front running protection by specifying slippage when trading.

Resolution: Additional safety measures have been added to the tick mechanism; however, token owners and users should still follow the recommendation mentioned above. Users should also note that front running will not be checked until the user's specified number of ticks have been set.

Description: The LGE contract does not accurately track the total number of whitelisted users that have deposited. When a whitelisted user deposits into an LGE with a previous deposit amount of zero, the whiteListEntered counter is incremented to count the number of unique whitelisted contributors. If a single user deposits an amount of zero twice, the counter will be incremented twice since their deposited balance has not changed.

Risk/Impact: Once the whiteListEntered counter reaches the contract's whitelist total, the LGE is automatically opened to the public. A malicious user can make repeated deposits to artificially increase the tracked number of depositors and open the LGE to the public early, denying other whitelisted users the opportunity to deposit before the public.

Recommendation: Users should not be permitted to deposit an amount of zero.

Resolution: The team has implemented the above recommendation.

Description: When the owner withdraws SD tokens from the LGE through the saveTokens() function, the supplyForLP is set to 0 but the hard and soft fundraising caps remain the same.

if(token == SD) {
	if(started) {
		require(aborted && raised == 0, "rax");
	}
	a = a - totalTokensVested;
	pre.supplyForLP = 0;
}

Risk/Impact: If SD tokens are withdrawn before the LGE's start time, the LGE will function normally and accept contributions despite having no SD tokens to pair with for liquidity. This may result in WETH and FEG transfers to their respective SD liquidity pools without LP token minting, allowing any user to skim the pools to drain the transferred funds.

Recommendation: The hard and soft caps should be updated accordingly with the new token supply.

Resolution: The team has implemented the above recommendation.

Description: A new LGE cannot be created for an SD token if an existing aborted LGE's funds have not been reclaimed by all users.

Risk/Impact: A malicious or inactive contributor can prevent the creation of a replacement LGE by not reclaiming their contributed funds.

Recommendation: The project team should consider adding an ownership function to reclaim deposits and send them back to their original addresses to enable new LGE creation.

Resolution: A new LGE can be created without requiring reclaimment of all funds. Users can still reclaim their deposit from the old LGE at any time.

Description: When creating an LGE for an SD token, liquidity cannot already exist in the SD:FEG liquidity pool to ensure that liquidity is added correctly. The SDLGECreator.createLGE() function currently only executes this check if the pool does not exist yet.

if(fp == address(0)) {
	require(IERC20(token).balanceOf(fp) == 0, "invalid bal");
	fp = Swap(Swap(UNISWAP_V2_ROUTER()).factory()).createPair(token, FEG());
}

Risk/Impact: Leftover SD tokens or FEG may remain in the liquidity pool once liquidity is added. The starting SD token price may also not match the intended price specified during the LGE's creation.

Recommendation: This balance check should instead be called when a SD:FEG liquidity pool already exists.

Resolution: The team has resolved this issue.

Description: The loanAll() function intends to only allow multi-token loans if more than one backing token exists in the contract, but can still be called if only one backing token exists.

require(l > 0, "only 1 backing");

Recommendation: The above require statement should be updated to the following:

require(l > 1, "only 1 backing");

Resolution: The team has implemented the above recommendation.

Description: Users can be added to an LGE's "entered" list multiple times by depositing an amount of zero. In addition, if a user emergency exits, they are not removed from the entered list. This allows them another method of adding themselves to the entered list multiple times.

Risk/Impact: As this list serves no purpose within this platform, there is no identifiable impact from potential list inaccuracies.

Recommendation: The project team should consider removing this list or updating its adding and removal logic.

Resolution: The team has acknowledged this issue and stated that this is for UI use only. Users can no longer deposit an amount of zero, but will still remain on the entered list if they emergency exit.

Description: A user's active status, ID, and start time all remain the same after selling their entire SD token balance, but the number of token holders is decremented. Since user IDs are assigned based on the number of token holders, any new user is assigned the same ID as the most recent user.

Risk/Impact: As these fields serve no purpose within this platform, there is no identifiable impact from this Finding.

Recommendation: The team should use a separate counter variable to provide users with unique IDs. The team can also consider restructuring the logic used to track user data to reflect their intentions.

Resolution: The number of token holders is no longer decremented upon selling their entire token balance, so each ID will now be unique.

Description: The following nested conditional statement in the emergencyExit() function is redundant, as the buyer is already confirmed to be included in the whitelist.

if(buyer[msg.sender].whiteListed) {
	whiteListEntered = buyer[msg.sender].whiteListed ? whiteListEntered - 1 : whiteListEntered;
}

Recommendation: The whitelistEntered variable assignment can be updated to the following:

if(buyer[msg.sender].whiteListed) {
	whiteListEntered -= 1;
}

Resolution: The team has implemented the above recommendation.

Description: The following nested conditional statement in the editWhitelist() function is redundant, as the buyer is already confirmed to be included in the whitelist.

if(!buyer[user].whiteListed) { // if not already whitelisted require _live = true and LGE not started
	require(_live);
	require(!started);
	pre.whiteListEnabled = true;
	if(!buyer[user].whiteListed) {
		whitelist.push(user);
	}
}

Recommendation: The above code can be updated to the following:

if(!buyer[user].whiteListed) { // if not already whitelisted require _live = true and LGE not started
	require(_live);
	require(!started);
	pre.whiteListEnabled = true;
	whitelist.push(user);
}

Resolution: The team has implemented the above recommendation.

Description: The oneTokentoBacking() function will provide an incorrect ratio during an active flashloan.

Recommendation: This function currently can only be used for viewing purposes while a flashloan is active, but platform functionality should not rely on this function for any state-impacting decisions in future developments.

Resolution: The oneTokentoBacking() function can no longer be called during an active flash loan.

Description: The only logic inside the _getWorth() function is a _getTValues() call.

function _getWorth(uint256 tAmount, address recipient, uint256 ref) private view returns (uint256 tTransferAmount, uint256 tShare) {
	(tTransferAmount, tShare) = _getTValues(tAmount, recipient, ref);
	return (tTransferAmount, tShare);
}

Recommendation: These functions can be combined by moving the _getTValues() logic into the _getWorth() function.

Resolution: The team has implemented the above recommendation.

Description: The “to” parameter is not necessary in the LGE_Deployer’s admin() function since it is required to be the FEG address.

function admin(address to, bytes memory data) external {
	require(Reader(DATA_READ()).superAdmin(msg.sender) && to != address(this) && to == FEG());
	(bool success, ) = to.call{value: 0}(data);
	require(success, "tx failed");
}

Recommendation: This parameter can be removed and replaced with the FEG() address inside of the function.

Resolution: The oneTokentoBacking() function can no longer be called during an active flash loan.

Description: The following code is present in the loanAll() function:

for(i = 0; i < l; i++) {
	require(timeNow1 >= lendData[user], "Settle existing");
}

Recommendation: This require statement only needs to be executed once.

Resolution: This require statement is now only executed once.