> For the complete documentation index, see [llms.txt](https://funarchy.gitbook.io/funarchy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://funarchy.gitbook.io/funarchy/security-for-prediction-market/operation/calculation-logic-error.md).

# Calculation Logic Error

### Share payment error due to `ceilDiv()` logic implementation error

#### Description

The Split/Merge process in prediction markets relies on accurate share calculations.However, the EVM does not support decimal points, so all divisions are processed on integers. 

The resulting dust, however, is not simply a "1-wei error" due to the nature of prediction markets. It can quickly escalate into a 1-share error or a distortion of the entire probability and settlement structure.

When these Arithmetic Precision Mismatches accumulate, the following structural problems arise:

* **Discrepancies between the actual liquidity pool and the ledger (Accounting)**
* **Over/under allocation of shares to certain participants**
* **Incorrect Settlement or Insolvency**
* **In the worst case, the entire market is locked, making settlement impossible.**

For this reason, rounding rules must be designed to favor the protocol (=disadvantage the user).\
Conversely, if rounding is applied in a way that favors the user (e.g., rounding up the paid Share), an attacker can repeatedly acquire Shares far exceeding their actual value with just a microscopic input of 1 wei.

This vulnerability leads to the following economic attacks:

* **Flash Mint** — Secure a large number of overminted shares in a single transaction.
* **Dust Inflation** — Excessive accumulation of repeated shares relative to the amount
* **Share Over-Mint** — The total supply becomes greater than the actual collateral value.

Therefore, in prediction markets, Arithmetic Precision Mismatch is not a simple ‘precision problem’, but a structural vulnerability that can collapse the share-based probability and settlement model itself and cause economic losses.

#### Attack Scenario

{% code expandable="true" %}

```solidity
function ceilDiv(uint256 a, uint256 b) internal pure returns (uint256) {
        // (a + b - 1) / b
        return a == 0 ? 0 : (a + b - 1) / b;
    }

function vulDeposit(uint256 assets) external { // 1 wei to make 1 share
        require(assets > 0, "Deposit must be > 0");
        
        asset.transferFrom(msg.sender, address(this), assets);

        uint256 shares;

        if (totalSupply == 0) {
            shares = assets;
        } else {
            // When calculating Share, use 'Ceil' to calculate in the user's favor.
            // Formula: shares = (assets * totalSupply) / totalAssets
            // Vulnerability: 1 Share is paid even if the result is 0.000...1
            shares = ceilDiv(assets * totalSupply, totalAssets);
        }
        totalSupply += shares;
        balanceOf[msg.sender] += shares;
        totalAssets += assets;
    }
}
```

{% endcode %}

{% stepper %}
{% step %}
The attacker finds a misapplied Ceil logic in the stake calculation function and attempts to purchase a Share with a very small amount of assets, such as 1 wei.
{% endstep %}

{% step %}
The contract pays the attacker at least 1 Share, despite the contract having a very low actual value, due to incorrect rounding (Ceil) processing.
{% endstep %}

{% step %}
Attackers use scripts to repeat these microtransactions thousands or tens of thousands of times, accumulating a large amount of Shares at virtually zero cost.
{% endstep %}

{% step %}
By selling these over-minted shares to the liquidity pool at normal market prices, a large amount of ETH/USDC within the pool is stolen.
{% endstep %}
{% endstepper %}

#### Mitigation

* **Set strict rounding rules (Favor the Protocol)**\
  Rounding rules must never be implemented in a way that is detrimental to the protocol.
  * User pays (Input):\
    Should pay a little more by rounding up the calculated amount.
  * User receives (Output):\
    Should floor the calculated value to get a little less.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://funarchy.gitbook.io/funarchy/security-for-prediction-market/operation/calculation-logic-error.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.