Guess Meme Solidity

QuillAudits26 Feb 2025Files named in the report

Audit · firm’s term: audit report

QuillAudits reviewed Guess Meme Rust (Guess Meme Solidity) on 26 Feb 2025: 24 findings, 0 critical; 9 marked fixed, 15 open.

No open critical findings

Open the report Open Guess Meme Rust’s security record

Report hosted on quillaudits.com.

Trustblock does not review code.

Findings24

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	1	0
Medium	5	2
Low	9	7

HighThe updated functionality of the max buy limit can by bypassedOpen

The new change added to validate if the user should be able to buy the tokens based on the max limit introduces a bug where msg.sender will be able to send his tokens to another address while buying, just to buy more amount and pass the check/validation where the current balance of msg.sender plus _amount is validated. Example: 1. User1 bought the maximum amount of tokens that can be bought by one user (based on the maxSupplyPercentage ) 2. User1 calls buyTokens() again but before that the User1 transfers some or the whole amount to another address, so that on <a href="https://github.com/sardar-khan/guess-meme-contracts/blob/main/ethereum/guess_meme_latest.sol#L754" target="_blank">L754</a> when the user’s balance will be fetched, it will be 0. And the user will be able to buy an additional allowedToBuy amount of tokens. 3. This action can be repeated multiple times. (Note: It should be noted that even if other functionality will be used where the user’s bought amount will be stored in the variable for each user’s address, the user can still create different addresses to trick that functionality.)

MediumAdd slippage checksOpen

In buyTokens() the ETH amount that the user needs to pay for buying a certain _amount of tokens can vary if other buyTokens() transactions execute before it. If other buyTokens() transactions execute before the user's buyTokens() transaction then the amount of eth user needs to pay for buying the same amount of _amount would be more than what was calculated before. In this case, care can be taken by sending more amount eth as the buyTokens() allows sending msg.value greater than ethToBuy + fee. (Note: As mentioned in another issue the extra dust ETH amount should be sent back to the user/msg.sender.) In sellTokens() the amount of ETH the user gets after selling _amount tokens can vary if other sellTokens() transactions execute before the user's call where the user was expecting to receive the specific ETH amount calculated with sellQuote(). Because of this, it's important to provide the slippage limit while selling tokens so that it can be checked if the amount is not much less than what was expected to be received.

MediumCare should be taken for an incomplete bonding curvesOpen

According to the code bondingCurve[_token].isCompleted is set to true, if the bondingCurve[_token].realTokenReserves becomes 0 on <a href="https://github.com/sardar-khan/guess-meme-contracts/blob/main/ethereum/eth_guessmeme.sol#L739" target="_blank">L739</a> while the user buys tokens. It should be noted that it’s not guaranteed that all the tokens will be sold in the specific period and hence the ETH accumulated by selling those tokens can’t removed as the bonding curve is not complete because the realTokenReserves has not reached 0.

MediumRestrict the minimum token amount while buying and sellingOpen

While buying, a very small _amount can lead the ethToBuy to 0 and eventually fee calculated based on ethToBuy would be 0, the minimum limit should be added while buying the tokens with buyTokens(). This limit can be added by calculating ethToBuy and fee for a certain _amount and checking that it would not be 0. E.g. In buyTokens() it can be checked that if _amount is 1000000000000000 (i.e. 0.001e18) the ethToBuy and fee are non-zero for hardcoded reserve amounts. so based on that the limit can be set for the _amount to be greater than or equal to 1000000000000000. Similarly, while selling with sellTokens() very small amount can lead ethToReceive to go close to 0. The limit can be added by calculating ethToReceive and fee, for a certain _amount and checking that it would not be 0. E.g In sellTokens() if _amount is 1000000000000000 (i.e. 0.001e18) the ethToReceive and fee is non-zero for hardcoded reserve amounts. so based on that the limit can be set for the _amount to be greater than equal to 1000000000000000.

MediumSend dust/extra eth amount back in buyTokens()Open

buyTokens() allows sending msg.value that is greater than or equal to ethToBuy + fee. This means an extra amount can be sent than what is required to buy _amount. Which will help users to handle some slippage (if ETH price for token goes up than what was calculated). However, since the extra amount will not be utilized every time. It is necessary to send the extra/dust ETH amount back to the msg.sender.

MediumUse multisig wallet to mitigate centralization concernOpen

Since some critical functionality like withdrawals of the fund is managed by a single EOA/owner address. It's important that a multi-sig should be used as an owner for managing the functionality. Additionally, it should be noted that some functions like withdrawStuckEth(), transferStuckTokens() create centralization concerns as they grant direct access to the owner to remove the ETH and tokens without any restrictions.

LowAdd restrictions to avoid token dumpingOpen

Users can sell the tokens after buying even while the sale is live. We encourage your team to analyze and understand the implications of this scenario and add certain restrictions for the users before they start moving the funds.

LowAdd validation in sellTokens()Open

Validation should be added to check if the contract has enough amount of ETH available when the user sells a certain amount of tokens back to the contract to avoid unexpected failing.

LowNote about ownership of the smart contractOpen

It should be noted that when deploying this smart contract the ownership is transferred to the deployer of the smart contract, unlike the current OpenZeppelin ownable implementation where you get the option to pass the initialOwner argument. So the deployer would be able to call the authorized functions like withdraw(), changeFeeBasisPoints(), withdrawStuckEth(), transferStuckTokens().

LowNote about updateMetadataOpen

updateMetadata() updates/reveals the token name and symbol. This should be noted that the updateMetadata() is owner only function and for every token that is created by users, the owner of the factory contract can change the name and symbol, and not the user who created that token.

Show 5 more

LowNote regarding hardcoded reservesOpen

It should be noted that the reserves are hardcoded in the contract that means every time a new token sale is created, the same reserve values will be used.

LowNote regarding withdraw functionalityOpen

This should be noted that for every created token sale/pool only the protocol owner can withdraw the tokens and not the creator of that pool.

LowPause functionality can be addedOpen

While the pausing functionality should be normally avoided. Given that the contracts are non-upgradeable, it would be a good idea to add pausing functionality for buy and sell functionality to ensure the safe withdrawal of funds by the owner in any unexpected event.

LowUnused variableOpen

tokenCount is declared on L652 is increamented in createToken() on L720. This variable is then never used anywhere and the variable is declared as private so no one can directly know how many tokens are created as there would be no getter method created for private variable.

LowVariables can be declared as constant and immutableOpen

initialVirtualEthReserves set the value of 1900000000000000000 and is never changing hence it can be declared as a constant. feeRecipient and tokenFeeRecipient can be declared as immutable variables.