Memeswap security record

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 deployFarm function in the MemeswapFarmFactory contract does not enforce a minimum reward rate for farms during deployment. This allows deployers to create farms with a reward rate of zero. Users who stake in such farms will bear gas costs for staking and removing tokens without receiving any rewards, leading to a poor user experience.

The Check-Effects-Interactions (CFI) pattern ensures that internal state updates occur before any external calls. This minimizes the risk of reentrancy attacks and unintended side effects.In the MemeswapFarm contract, the stake and exit functions violate this pattern. External calls to untrusted contracts or tokens are made before updating internal state variables, creating potential risks. While the contract implements ReentrancyGuard, following the Check-Effects-Interactions pattern is still considered best practice to enhance security and robustness.

Within the smart contracts, the current use of postfix incrementation (i++) in loops is identified as a less gas-efficient practice. Switching to prefix incrementation (++i) to update uint variables inside loops can yield gas savings. This optimization opportunity applies to loop iterators and any increment operations within the loop's body. The efficiency gain stems from how Solidity handles these two operations at the bytecode level, with prefix incrementation slightly more gas-efficient due to its direct modification of the variable's state without storing an intermediate value.

In smart contracts, there is a recurring pattern of initializing loop variables and accu- mulators to their default values. While common and clear for understanding, this practice introduces unnecessary operations, as Solidity automatically initializes variables to their default values. Specifically, instances of loop counters being set to 0 (uint256 i = 0) and accumulators being initialized to 0 can be optimized by leveraging Solidity's default initialization to reduce bytecode size and potentially gas costs during contract deployment.

The Memeswap contracts import Ownable.sol from OpenZeppelin, which includes a renounceOwnership function. This function transfers ownership to the zero address (ad- dress(0)), effectively removing the contract owner. As a result, any functions restricted by the on- lyOwner modifier will become inaccessible if renounceOwnership is called, either intentionally, by mistake, or due to malicious activity. This can lead to a scenario where the contract is permanently locked, making it impossible to manage or upgrade the contract, or to access critical functionalities.

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.