Galleon DEX

`GalleonPool.upsertAsset` and `GalleonPool.getMarketShare` assume that the listed tokens' decimals are always lower than 18 decimals. Such implementation will prevent listing tokens with higher decimals since the transactions will throw due to underflow. Please note that the [ERC20 standard](https://eips.ethereum.org/EIPS/eip-20#decimals) does not require the decimals value to be fixed or lower than any specific value.

The fee logic inside the `withdrawInto()` and `withdraw()` functions will always leave assets in the contract, meaning that the last user to withdraw his asset will see his calculated fees being left out in the contract. Depending on the amount left, an attacker can deposit an extremely small amount of tokens (compared to the left out fees) and withdraw the majority of the remaining asset in the pool.

The `GalleonPool.findBalanceAndMultiplier()` and the `GalleonExchangeInterface.invariant()` functions use the price from the call to the [deprecated API function](https://docs.chain.link/docs/deprecated-aggregatorinterface-api-reference/#latestanswer) `oracle.latestAnswer()` of Chainlink. This approach is vulnerable to price manipulation and stale prices according to the Chainlink documentation: 1. [under current notifications](https://docs.chain.link/docs/developer-communications#current-notifications): "if answeredInRound < roundId could indicate stale data." 2. [under historical price data](https://docs.chain.link/docs/historical-price-data#solidity): "A timestamp with zero value means the round is not complete and should not be used."

On L197, the `withdrawInto()` function computes the `invariantFractionIBurned` using `theExchange.fullyDilutedSupply()`, which has been updated after `amount` LP tokens have been burned through `GalleonPool.swapBurn()`. Based on the code comments and the implementation of `GalleonExchangeInterface.withdraw()`, it seems like the correct invariant check needs to be using the initial fully diluted supply before it is updated.

Blocked addresses cannot swap, but they can still deposit into the pool, receive LP tokens, and withdraw assets.

The `GalleonPool` pool smart contract allows changes to the exchange interface, deposit contract, and the triage address. However, the functions for these changes do not emit events.

We understand that the intention of Galleon DEX is to use ETH as the numeraire asset and we can also see that in the current list of Chainlink oracles all oracles of the form `<ERC20>/ETH` return 18 decimals. However, there is no guarantee that this will be the case for such Chainlink oracles in the future. The require statement on L151 in `GalleonPool.sol`: `require(oracle.decimals()==18, "Galleon: Invalid oracle");` prevents adding Chainlink price feed contracts which do not have exactly 18 decimals digits. One Chainlink price feed contract which has a value different from 18, namely 8 decimals is the [ETH/USD price feed contract](https://etherscan.io/address/0xb022E2970b3501d8d83eD07912330d178543C1eB#readContract). Many other Chainlink price feed contracts, which do not have 18 decimals can be found [here](https://docs.chain.link/docs/ethereum-addresses/). <br><br> The code inside `GalleonPool.findBalanceAndMultiplier()` assumes that the `latestAnswer()` function of the Chainlink price feed contract always returns a result with 18 decimal digits. However, this is not guaranteed as described above. We also refer to the [FAQ section of the Chainlink documentation](https://docs.chain.link/docs/faq/) where the following question and answer are listed: > **Why is latestAnswer reported at 8 decimals for some contracts, but for other contracts it is reported with 18 decimals?** > >For crypto quotes, 18 decimals is typically used because they usually require more precision. For FX quotes, 8 decimals are used because that is the precision data sources typically report them at. If at some point in time oracles that return a number of decimals different than 18 will be needed and included, it will have a significant impact on all trading activities.