Les calculs internes sont-ils effectués avec plusieurs décimales ou avec un nombre de décimales fixe? Les valeurs sont-elles toujours arrondies?
Calculated versus displayed precision
L'arrondi est généralement effectué au nombre entier le plus proche pendant le calcul et tronqué lorsqu'il est affiché.
Les fonctions "Obtenir des informations sur les actifs" et "Obtenir des paires d'actifs tradables" fournissent des informations sur le nombre de décimales des différents actifs et le nombre de décimales affichées.
Matching local values with API values
Values derived from local calculations (such as calculating balance changes from a trade's price and volume) often have more decimal places than required, and need to be rounded/truncated to match the values provided by the API.
For example, a SHIB/USD order to buy 50,123 SHIB at $0.00002901 results in a trade worth $1.45406823 (50,123 x 0.00002901 = 1.45406823), but the REST API Ledgers endpoint shows that the USD balance decreased by a smaller precision value of $1.4541:
"L2A7BN-OLRUR-DGZH7F":{"refid":"T5JORM-HM432-GQ3RGY","time":1639991413.4671,"type":"trade","subtype":"","aclass":"currency","asset":"ZUSD","amount":"-1.4541","fee":"0.0000","balance":"124.7277"}
The solution to this type of decimal precision discrepancy is to round/truncate local values to match the decimal precision provided by the REST API Assets endpoint.
Continuing the SHIB/USD example, the Assets endpoint indicates a USD calculation precision of 4 (see the previous section above), hence the locally calculated value of $1.45406823 should also be rounded/truncated to a decimal precision of 4:
- •
50,123 x 0.00002901 = 1.45406823 rounded to 4 places = 1.4541
As shown, by rounding/truncating to the appropriate decimal precision, the final value of $1.4541 corresponds exactly to the value provided by the Ledgers endpoint, allowing local values to be matched with API values successfully.
Calculated versus displayed precision