Midaz v2.x.x system uses a flexible scale mechanism to ensure consistent storage and processing of monetary values while avoiding rounding errors. The Amount indicates the value being moved, adjusted by an appropriate scale for precision. Managing precision and scaling is critical for handling transactions and balances accurately. Each transaction is recorded with two key attributes:
  • amount: Represents the value of the transaction as an integer.
  • scale: Specifies the number of decimal places associated with the amount.

​
Understanding amount

The amount is the value to be debited and credited from the origin or to the destination accounts. It can be specified in three ways:
  • amount: This is the direct definition of the value according to the scale. For example, an amount of 10 (:amount BRL 100|2).
  • share: This indicates a percentage of the total amount that will be distributed to a given account. For instance, if you want to send 90% of the amount, it should be formatted as :share 90, meaning 90%.
  • remaining: This indicates that the remaining total amount will be sent to an account.

​
Understanding scale

The scale is a parameter designed to define how the transaction amount is interpreted.
ImportantThis parameter is supported only in Midaz v2.x.x and earlier.
The scale can be set to a positive integer to specify the number of decimal places for interpreting the transaction value. For example, if scale is set to 2, a value of 1000 will be interpreted as 10.00.
AttentionThe scale only accepts non-negative values, including 0. Negative integers (e.g., -1) will result in an error.
In the following table, you can find a few examples of how the scale works.
AssetAmountScaleInterpretation
BRL57625.76
ETH3850.00038
BTC1460.000014
JPY1540154
If the scale field is not specified, it defaults to 0, ensuring that transaction values are processed as whole numbers (integers) with no decimal places applied.

​
Balance calculation

The balances are dynamically adjusted based on the biggest scale encountered among all recorded transactions. This ensures consistency while preserving precision. Example Workflow:
  • Transaction 1: BRL 0.1 using amount = 1000 and scale = 4.
  • Transaction 2: BRL 0.02 using amount = 2000 and scale = 5.
  • Transaction 3: BRL 10 using amount = 10 and scale = 0.
  • Transaction 4: BRL 10 using amount = 100 and scale = 1.
  • Transaction 5: BRL 0.03 using amount = 30 and scale = 3.
As new transactions are added, the balance adjusts to reflect the biggest scale used so far:
  • After Transaction 1, the balance is stored with scale = 4.
  • After Transaction 2, the balance adjusts to scale = 5.
  • After Transaction 3, the balance remains at scale = 5 as no biggest scale is encountered.
This approach ensures that balances reflect the greatest level of precision required by the transactions recorded.
AttentionFor security reasons, the scale cannot be decreased once it has been increased. For example, if the scale was adjusted from 2 to 5, you cannot change it to 3 or go back to 2.