Memeswap

The MemeswapVault contract manages staking, enqueuing, renting, and claiming processes for the Memeswap protocol. Users can stake their Ether, join the queue, and claim rewards through various functions within the contract.A significant problem occurs with the trigger modifier, which attempts to dequeue items and send Ether to the queued user. If the recipient is a malicious contract that reverts the transaction through its receive or fallback function, the entire operation fails. This creates a Denial of Service (DoS) condition, halting the protocol and causing funds to be stuck.

A critical Denial of Service (DoS) vulnerability in the MemeswapVault contract. The vulnerability is related to the enqueue and dequeue logic, specifically how the dequeuePossible function interacts with the enqueue process, potentially leading to a state where the contract becomes unusable due to arithmetic underflow or overflow.The MemeswapVault contract allows users to enqueue ether and stake it. The staking process involves renting liquidity to newly deployed tokens. However, the logic in the dequeuePossible function can be manipulated to create a situation where the dequeue function can never be called successfully, leading to a critical DoS scenario.

The createPair() function is using && instead of ||, this will allow an actor to create a pair with just one whitelisted token. Instead both the tokens should be checked for being whitelisted to make sure that pairs are only created with whitelisted tokens.

In the ` MemeswapCollector::liquidate` function, the parameters amountAMin and amountBMin for removing liquidity are set to zero. This configuration allows for up to 100% slippage during liquidity removal, potentially resulting in significant losses or unexpected behavior.Impact Setting these parameters to zero means the contract does not enforce any minimum amount for the tokens received from liquidity removal. This could result in all of the liquidity being removed at unfavorable rates, potentially leading to a significant loss of funds or exploitation.

The initialize() function can be called multiple times by the owner and he can eventually change the vault once it is assigned. This possesses a centralization risk in the contract that could be abused by the owner. There is no condition in the initialize() function that would check if the contract has already been initialized.

DOMAIN_SEPARATOR variable should be declared as immutable as it is not getting changed once getting initialized in the constructor.

Certain functions in the Memeswap contracts perform state changes without emitting corresponding events. This reduces transparency and makes it harder to track these changes off-chain. The following functions should emit events:Functions to Update: • MemeswapTokenFactory.setMaxTax(uint256) (src/MemeswapTokenFactory.sol#100-102) • MemeswapVault.setParams(uint256,uint256,uint256,uint256) (src/MemeswapVault.sol#146-160) • MemeswapVault.setChadBar(uint256) (src/MemeswapVault.sol#332-336) • MemeswapVault.setValhallaFee(uint256) (src/MemeswapVault.sol#355-361)

The variable naming conventions and conditions in the lock() function should be consistent with the function name. Instead of using `unlocked`, use `locked` as that would make more sense with the function name.

There is no error handling on the _burn() function for the scenario when the `from` address has less balance than the `value`. This would break the flow of the execution.

The error handling in transferFrom() function is not done properly, it should also verify that allowance in `allowance[from][msg.sender]` is greater than the `value` else it should throw an error.