# 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.

{% hint style="info" %}
The computational cost could vary with a different version of Solidity, the one that is implemented here is 0.7.6
{% endhint %}

### *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.

{% hint style="info" %}
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
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://soliddefi.gitbook.io/solid-whitepaper/precision.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.