# Solidity Design Patterns: Multiply before Dividing

Author: Markus Waas

Published: 2019-07-21T06:49:53.000Z

Updated: 2026-09-13T14:25:30.000Z

Source: [https://soliditydeveloper.com/solidity-design-patterns-multiply-before-dividing](<https://soliditydeveloper.com/solidity-design-patterns-multiply-before-dividing>)

## Compatibility and review

Before you start · Reviewed Sep 13, 2026

Reviewed for Solidity 0.8 integer arithmetic. Multiplying first reduces truncation but can overflow; literal-only expressions use different compile-time arithmetic. No full application is deployed by this article.

[Official reference](<https://docs.soliditylang.org/en/latest/types.html>)

There has been a lot of progress since the beginning of Ethereum about best practices in Solidity. Unfortunately, I have the feeling that most of the knowledge is within the circle of experienced people and there aren’t that many online resources about it. That is why I would like to start this tutorial series called *Solidity Design Patterns*.

We are going to start it off by one straight-forward about math. I hope everybody is using [SafeMath](<https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/math/SafeMath.sol>) or something similar by this point in time. Nonetheless, there are still things to consider.

Do your multiplication before division!

This one is actually even true in JavaScript. To see why this is important, open up your browser console and type

```javascript
console.log((30 * 100 * 13) / 13)
< 3000
```

Now, let’s do the division first. After all, `abc/c == a/c * bc` , right?

```javascript
console.log((30 / 13) * 100 * 13)
< 2999.9999999999995
```

Now in the case of JavaScript, this is due to [floating point errors](<https://en.wikipedia.org/wiki/Floating_point_error_mitigation>). In Solidity we don’t have floating points, but instead we get rounding errors. With runtime `uint256` values, `(uint256(30) / 13) * 100 * 13` yields **2600**: the first division truncates to 2. By contrast, a literal-only expression such as `(30 / 13) * 100 * 13` is evaluated with rational precision at compile time and yields 3000.

By doing all our multiplications first, we mitigate rounding related issues as much as possible. The computations can be much more complex and forming them into a multiplication first formula can be challenging at times.

![watch\_out](<https://soliditydeveloper.com/img/1_avngzc02zxtmhpdawpuzmg.png>)

##

![Red “Watch out” stamp.](<https://cdn0.scrvt.com/b095ee27d37b3d7b6b150adba9ac6ec8/ecc2970d5cf0f62d/36af614e1d33/v/40a566e1713c/watchout.png>)

## Not always sufficient!

Sometimes this is not good enough. For payouts, choose rounding deliberately and account for the remainder. The loss is not necessarily a single wei: later multiplications can magnify an earlier truncation, and repeated payouts can accumulate a difference. Check conservation and fairness requirements rather than assuming small-looking rounding is harmless.

This does not mean that it is always fine. Depending on your use case, you might want to favor an implementation using a numerator and denominator.

```javascript
uint256 numerator = 30 * 100 * 13;
uint256 denominator = 13;
```

You can always store the number pair and do your computations according to proper math. In most cases, having a number rounded down will be fine though. Just know that this can happen and deal with it when you have to.

**Solidity 0.8 update:** Arithmetic overflow is checked by default outside `unchecked` blocks, so ordinary checked arithmetic no longer needs SafeMath. Multiplying first can still overflow even when the final quotient fits. For that case, consider [OpenZeppelin Math.mulDiv](<https://docs.openzeppelin.com/contracts/5.x/api/utils#Math>) and choose the rounding direction your accounting requires.