Exchange, Part 2

Privileged addresses have authority over many functions that may be used to negatively disrupt the project. Some important privileges include:

GoldenGate

• owner can withdraw all funds.
• owner can set admins which are able to dilute allocation of other pools.
• owner can set the migrator contract which can lead to loss of LP if malicious.

TokenVesting

• owner can arbitrarily set the fee and fee address which can lead to loss of user funds.

BridgesRef

• feeToSetter can arbitrarily set the distribution rate.
• feeToSetter can withdraw any ERC-20 token in the contract.

BridgesRouter

• feeSetter can set a arbitrary referral and dividend tracker contract.

Ensure that the privileged addresses are multi-sig and/or introduce timelock for improved community oversight. Optionally introduce require statements to limit the scope of the exploits that can be carried out by the privileged addresses.

Bridges Team: - All centralized BNB and token withdrawal functions have been removed from the GoldenGate contract,

• The possibility to change fees on the TokenVault has been removed as well.
• The GoldenGate migrator has to be there for an eventual V2 in the future.
• For the same reason all update functions on the tracker are necessary.
• Every privileged address will be a multi-sig with trusted members in production.

Due to require(block.timestamp >= user.stakeUntil, "Locked") in emergencyWithdraw, if a user has LP tokens that are not locked alongside LP tokens that are indeed locked, the user would have to wait until their locked LP tokens become unlocked before they can emergencyWithdraw.

If this is intended behavior, keep as is. Otherwise, refactor emergencyWithdraw such that users may withdraw their unlocked positions.

Bridges Team: - This is indeed expected behavior, if you have a locked position you cannot emergencyWithdraw any part of your position.

The GoldenGate address is not set after the constructor and can therefore be declared immutable.

Either make a setter for GoldenGate or declare it immutable.

Bridges Team: - Implemented a setter for GoldenGate.

The rewards for the BridgesPair contract are ignored on line 232 by adjusting the rewardDebt, but they are not excluded in the magnifiedDividendPerShare calculation, therefore decreasing the dividends received by every other holder.

Subtract the BridgesPair’s balance from the totalSupply on line 229.

Bridges Team: - Removed the BridgesPair contract balance from the dividends calculation.

nullAddress is not changed anywhere and can therefore be declared constant.

Declare nullAddress constant.

Bridges Team: - Declared nullAddress constant.

The UserInfo struct now only contains a rewardDebt, therefore the userInfo mapping can simply be a mapping of address => uint where the uint is the rewardDebt.

Delete the UserInfo struct and convert the userInfo mapping to a simple address => uint mapping storing the rewardDebt directly.

Bridges Team: - The mapping is now simply rewardDebt.

The sendToGate, sendToGateFrom0, sendToDevFromGate, and sendToDevFrom0 functions all do the same thing just with different addresses.

Make one function that does this computation that accepts configurable addresses as arguments and add a require statement to limit the scope of which addresses can be used.

Bridges Team: - Combined these functions into one withdrawSpecial function.

Because the tradingFee is taken after the calculation of getAmountsIn, the user will receive 1000-tradingFee/10% of amountOut, rather than getting the whole amountOut. If the tradingFee is 30, the user will receive only 97% of the specified amountOut.

If it is desired to receive the amountOut at minimum, take the fee in the same manner as in getAmountsIn, where the amountIn is simply increased in order to maintain the amountOut.

Bridges Team: - Removed the fee calculation logic as 3% slippage is handled on the frontend.