-
Notifications
You must be signed in to change notification settings - Fork 10
AdEx v5: Issue #384 Unified precision - primitives::UnifiedNum #386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
69424c5
to
080b517
Compare
what's the reason for having a |
Reason
The way I understand it is that this will help us to have a unified representation of values that is good enough for all applications. We won't need more precision than this, it will ease the calculations and we can convert to the on-chain values when we create the MerkleTree we can use the full precision of the stablecoin. Maybe @Ivshti could give a fuller answer here? Why 8 in particularFrom AIP#61:
If the CPM price is 0.01 then with a precision of 8 and a fee of 1% we will get a value of 0.00000001 in Unified Precision |
The main reason behind using unified precision is being able to use easy-to-work with and fast types such as u64. Furthermore, it keeps numbers in the database consistent if we switch between stablecoins with different decimal precision, and we don't need to account for that when calculating stats/aggregate data. But most importantly, using unified precision allows us to use native number types in databases (mongo, postres), allowing for much easier updates and aggregations, opening the door towards more analytics features. There's no real reason for supporting more than 8 decimals. EDIT: sorry, closed by accident |
4b9f2e2
to
310ea23
Compare
Changelog:
primitives::UnifiedNum
for AIP #61 v5: Unified precision (8) #384 with precision of 8