Wemix Retainer 150 WEMEME

The `WEMEME` token inherits the standard `ERC20` contract, which does not have any transfer restriction. If a user purchases the `MEME` token via the bonding curve, he could create a token pair via `playSwapRouter` between the `MEME` token and Wemix using any arbitrary ratio between the two tokens, even before the bonding curve's wemix reserves and token holder count reach their thresholds. This effectively determines the price between the two tokens on the `playSwapRouter`. When the wemix reseves and token holder count do reach the threshold, the `_complete()` function would add liquidity to the token pair at the price determined by the `playSwapRouter` and the corresponding token pair contract, which could be very different from the price of the bonding curve (i.e. the price of `WEMEME` token could be higher via `playSwapRouter` than via the bonding curve). With the price discrepancy, the original liquidity provider of the token pair, or other buyers of the `WEMEME` token via the bonding curve, could potentially sell large amount of `WEMEME` token immediately after the token is "complete" on the bonding curve and profit off of the price discrepancy and extract a large portion of WEMIX token from the token pair.

The `buy`, `sell`, and `complete` functions of the `WEMEME` contract do not follow the checks-effects-interactions pattern, as token transfers including native token transfers take place before the relevant state variables are updated. In normal circumstances, these functions are called via the `Router` contract which contains the `nonReentrant` modifier, which offers the necessary reentrancy protection. However, the `router` address could theoretically be changed via the `WEMEMEpolicy` contract. If a new `router` contract does not contain reentrancy protection, the deviation from the checks-effects-interactions pattern could become a vulnerability. For example, the creator fee recipient could potentially reenter the `complete` function and receives fee multiple times.

If an event is not indexed in a smart contract, it means that the event's parameters are not tagged with the `indexed` keyword. This has implications for how the event data can be searched and filtered when looking through blockchain logs. Without indexing, the event will still emit the data as part of the transaction log, but users won't be able to query for these events using the parameters. They'll have to retrieve the entire set of logs and manually sift through them to find events with the specific data. This can be less efficient and more time-consuming, especially on a blockchain with a high volume of transactions and events.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The variables `wemixThreshold`, `listingFee`, and `creatorIncentive` should satisfy the condition that `wemixThreshold >= listingFee >= creatorIncentive` (or `>`). However, only the `setCreatorIncentive()` function contains input validation, and the `setListingFee()` and `setWemixThreshold()` functions do not. If these parameters are not set correctly, the `_complete()` function of `WEMEME` could potentially always revert due to underflow.

The `WEMEME` contract inherits both `Ownable` and `WEMEMEBase` contracts. The `WEMEMEBase` contract inherits `WEMEMERole` contract which also inherits `Ownable` contract.

The `WEMEME` and `WEMEMERouter` contracts contain payable `receive()` and `fallback()` functions, but other than fee payment and liquidity provision which have their own accounting records, no other mechanism to retrieve native tokens sent to the contract.