Precision

PRECISION

Since doing mathematical computation such as cubic root, allocating extra bits for computation to avoid overflow could be costly, a specific precision is chosen here (divided by 10**14) for the calculation of selling before the cubic root function is called.

Due to the asymmetry feature of the mathematical implementation in the mintOnBuy() and burnOnSell() functions, the precision is different in the two functions.

The computational cost could vary with a different version of Solidity, the one that is implemented here is 0.7.6

Overflow

Although in the Ethereum blockchain network most ERC20 tokens use uint256 to store the supply and the balance of individuals, the Solid Protocol won’t be able to max at uint256(2**256) but however would overflow before that, because the multiplication operation is being called upon on calculation during mintOnBuy() and burnOnSell().

For uint256, it can handle numbers up to 10**76 before overflows, doing a cube of input would overflow when the input is larger than 85 bits (25 decimals places). However, by taking the square of the input and then divide by 10*14, then multiple by the number itself again, although precision is lost, it frees out space that allows calculation of larger input before overflow.

Check on input before calculation to avoid overflow is not implemented as an intent for computational optimization purposes as the case of having over-sufficient decimals in any ERC20 token should be avoided. Described the above condition, the precision should be high enough which would not bring much price impact.

Gaping down left-over balance

Since there is a precision loss on each trade, which would round down in mathematical calculation, meaning there would be more balance leftover as trades go on.

By reading the balance of ERC20 the contract has, combined with the supply of Solid-ERC20, the price of each trade could be calculated in such a way that left-over from precision loss is taken care of. So, every trade afterward always takes the arbitrage chance of the left-over balance, this could ensure the left-over balance would not grow overtime.

If the last mintOnBuy() function is called and afterward the burnOnSell() function triggers an overflow, all funds would be permanently locked up in the pool, but such a situation is unlikely to happen since people would know and sell off before an overflow occurs