follows.app

The price of each token is computed in the getTokenPrice function as a difference of two 3rd degree polynomials. The final result is multiplied by the _priceFactor. This local variable equals either the alpha of the token (if the creator of the token has set it), or a standard value (the global variable priceFactor).

Suppose that the user has not set the alpha of a token. Suppose also that we execute a buyToken operation, followed by a sellToken operation, with no change of supply or demand in between, and with the priceFactor remaining constant. In this case, the user will simply get back the money originally invested. However, if the _priceFactor changes between a buy and a sell operation, the symmetry between buying and selling is broken. A malicious owner could drain the protocol, manipulating the price of the tokens through the priceFactor, as follows:

• He sets a low, or even zero, priceFactor.
• Creates a new token without setting its alpha (therefore the priceFactor will be used for the computations of the token price).
• Buys a huge amount of this new token (the price will be extremely low or even zero).
• Increase the priceFactor.
• Sell all his tokens at the new increased value. The amount of native tokens (NaT) he will get back suspases his initial deposit and if the increase in the priceFactor was significant he could get back even the total amount of NaT paid to the protocol for all the tokens.

We suggest either making the priceFactor immutable or storing the priceFactor for all the tokens with no set alpha, at their creation and using this for all the price computations.

The impact of an increase in the priceFactor described above can also be taken advantage of by a malicious user as follows:

• Frontrun an increase of the priceFactor and create a new token, without setting its alpha, and buy a large amount x of token using y native tokens.
• The owner increases the priceFactor.
• The attacker sells all his tokens (except of the last one, which is not allowed by the protocol) at a higher price (since the priceFactor has increased) and therefore should get back an amount of native tokens greater than y i.e. he gets also funds deposited for other tokens. If x was sufficiently large, the attacker can drain the protocol.

Even if no one manages to frontrun a priceFactor change, a change in priceFactor is problematic per se. All the tokens bought before the change will have a different price after and therefore any user willing to sell his tokens will also get funds corresponding to other tokens.

We suggest either making the priceFactor immutable or storing the priceFactor for all the tokens with no set alpha, at their creation and using this for all the price computations.

The addReferrer function currently requires a referrer to be invested in the protocol by having created a token with a certain supply. However a new user can easily circumvent this process by creating a new referrer account with just one token (which costs nothing) and then executing a buy or sell operation using that referrer account, pocketing the referrer fee himself.

The functions buyToken and sellToken perform a number of call operations to transfer native tokens for the purpose of fee distribution.

If the address on the receiving end of the call is a contract, then this will trigger its fallback function. There can be any code inside such a fallback function, including malicious code.

One way this could be exploited by an attacker, is for the attacker to create a malicious referer contract. Once this contract has been registered as the referrer of a token, it will simply revert each time its fallback function is triggered. This will cause every buy and sell operation on that token to fail, causing a denial of service for that token.

Due to the nature of the contract we could not find another way of exploiting the call operations. However one would do well to keep this problem in mind when the contract is expanded in the future, especially when it comes to reentrancy attacks.

In general, when funds need to be disbursed by a contract, the safest pattern is to have users withdraw funds, instead of sending funds to them, as this avoids the problem with transfer of control. However this would require a more sophisticated accounting system than the one currently employed by the contract.

When a user wants to buy or sell tokens, he only specifies the amount of tokens and the protocol computes the amount of native tokens he should pay or get back. The user cannot explicitly set an acceptable maximum (when he is buying tokens) or minimum (when he is selling) amount of native tokens. He can only check the current price of the tokens using the getTokenBuy(Sell)PriceAfterFee functions, but the price he will get and the actual price he will pay when we will execute the action could be different if the state of the contract has changed in between i.e. if the current supply of the tokens has changed.

In buyToken there is an (indirect) protection of the users. There, the user does not only provide the amount of tokens he wants to buy, but also sends the corresponding amount of native tokens. If the price has increased, the transaction will revert.

In sellToken there is no protection and a user trying to sell his tokens could get back less than the expected amount of native tokens. Moreover, an attacker could frontrun a sellToken action, selling his tokens before the victim, decreasing the price of the token.

We suggest adding an extra variable minAmountOut in sellToken to mitigate this problem, allowing the user to specify a minimum sale price and to revert if this is not achieved.

Even though the formulas for the computation of the price and the fees are additive i.e. the total amount a user should pay and the fees do not change if the user splits the transaction into smaller ones, this holds only in theory (infinite accuracy). Rounding errors break this additive nature of the formulas. Therefore the total native tokens a user should pay and the corresponding total protocol fees are less if the user buys x tokens in several steps e.g. x buys of 1 token, compared to a single buy of x tokens. Users could exploit this issue if they buy several tokens one at the time and then sell them all together.

An attack of this kind is probably not economically feasible, given that the user should pay extra transaction fees to execute these extra small transactions, but extra care and extensive simulations to identify the possibility of such an attack are needed.

A common mitigation for this type of issue is to set a minimum amount a user should be allowed to buy or sell.

At the moment, the platformFeeDestination is set directly in the constructor, and there is a comment indicating that this assignment will be removed in the future. If this occurs, the result would be problematic. For instance, if a transaction takes place before the platformFeeDestination is set, the fees will be sent to address(0). We suggest that platformFeeDestination is provided as a parameter to the constructor.

When selling tokens, the getTokenSellPriceAfterFee function charges a trader fee, but when sellToken is called, no trader fees are deducted.

The owner of the protocol can set (and change) several critical parameters: the fee factors/percentages, and the priceFactor. All these parameters affect the buy and sell prices of the tokens (check for example C1). There are no restrictions posed by the contract for the values of these parameters.

A malicious owner could, for instance, change the protocol fee to 100%.

Alternatively, a user who bought tokens under a given fee structure, coud have the fee change without warning before he can sell the tokens back.

In relation to the priceFactor, except for the more serious issues related to an increase of its price, a decrease could be also problematic, breaking the invariant that the alpha of each token is less than or equal to the priceFractor.

We suggest either making these parameters immutable or at least adding restrictions/bounds on their possible values, when they are getting set in the setFee function.

The owner can no longer change the priceFactor, but is able to change the protocol fees at any time.

The getTokenPrice function has a parameter called currrentSupply instead of currentSupply (3 r’s).

The contract makes use of a number of magic numbers such as 16000 and 10 when calculating the token’s price. We suggest that these be declared as constants with an appropriate name to enhance the transparency of the protocol.

There are instances of code duplication in the code base which can be refactored out. For instance, the computation of the fees in getTokenBuyPriceAfterFee and getTokenSellPriceAfterFee are identical. There is also duplicated code relating to fee transfers between buyToken and sellToken. There is also duplicate code within buyToken and sellToken itself, between the if and else branches relating to fee transfers. We recommend that these be factored out to help in the future maintainability of the protocol, so that changes only need to happen in one place.

Duplicated code related to fee computations was refactored.

In buyToken, the user sends his trader fee as part of the call, and is then refunded the same amount at the end of the transaction. Similarly, when a user creates a token when calling buyToken, he first gets charged a creator fee, which is then refunded again at the end of the transaction.

After consulting with the team, we understand that this is part of the protocol’s marketing. However the fees could simply be computed and corresponding events emitted, avoiding the actual transfer of funds, if so wished.

In sellToken the requirement that the amount is positive should be added, similarly to what is done in buyToken.

In getTokenPrice the variable s2 should be directly assigned the 0 value not only whenever currentSupply == 0 but also when it equals 1 (for gas savings).

We have thoroughly investigated the possibility of altering the alpha of a token after its creation and we were not able to find any possible way to do so, but as an extra measure, and as a defense to possible future changes of the code of the contract, we suggest also adding a reentrancy guard in setAlpha.

Users can buy tokens by sending native tokens (NaT) to the protocol. The protocol does not distinguish between the funds invested in different tokens. Even though each individual user is not guaranteed that he will get back, when he is selling, the exact amount he had paid when he bought the token (the price could have changed due to changes in supply and demand), the total NaT paid for each type of token can be collectively withdrawn (minus the fees) and it should not be possible to withdraw funds associated to holders of other tokens. This is an important invariant of the protocol.

Under normal circumstances this invariant seems to hold (check C1 for exceptions), but as an extra safety and a good practice we suggest explicitly storing, not only the current supply of each token, but also the total amount of NaT deposited for that token and checking that when a user sells his tokens, he does not get back more than the total deposited NaT corresponding to the type of token he is holding.

The getTokenSellPrice function checks whether the supply is non-zero before returning the price, but does not check whether the amount is greater than the supply, thus returning a wrong price in this situation.

function getTokenSellPrice
    	address tokenAddress,
    	uint256 amount
	) internal view returns (uint256) {
    	uint256 _supply = tokensSupply[tokenAddress].currentSupply;
    	uint256 _priceFactor = tokensSupply[tokenAddress].alpha == 0
        	? priceFactor
        	: tokensSupply[tokenAddress].alpha;
    	return
        	_supply == 0
            	? 0
            	: getTokenPrice(_supply - amount, amount, _priceFactor);
	}

We recommend altering the last check before the return in the following way.

function getTokenSellPrice
    	address tokenAddress,
    	uint256 amount
	) internal view returns (uint256) {
    	uint256 _supply = tokensSupply[tokenAddress].currentSupply;
    	uint256 _priceFactor = tokensSupply[tokenAddress].alpha == 0
        	? priceFactor
        	: tokensSupply[tokenAddress].alpha;
    	return
        	_supply <= amount
            	? 0
            	: getTokenPrice(_supply - amount, amount, _priceFactor);
	}

The getTokenPrice function can underflow if both supply and amount are equal to zero. In this case it would be better if the function returned zero instead.

The code is compiled with Solidity 0.8.19. Version 0.8.19, in particular, has some known bugs, which we do not believe affect the correctness of the contracts.