Skip to content

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

Merged
merged 8 commits into from
Mar 23, 2021

Conversation

elpiel
Copy link
Member

@elpiel elpiel commented Mar 17, 2021

Changelog:

@elpiel elpiel added the primitives Changes regarding the `primitives` crate label Mar 17, 2021
@elpiel elpiel changed the title Issue #384 Unified precision AdEx v5: Issue #384 Unified precision Mar 18, 2021
@elpiel elpiel force-pushed the issue-384-unified-precision branch from 69424c5 to 080b517 Compare March 18, 2021 11:25
@elpiel elpiel marked this pull request as ready for review March 19, 2021 14:51
@elpiel elpiel requested review from samparsky and simzzz March 19, 2021 14:51
@elpiel elpiel changed the title AdEx v5: Issue #384 Unified precision AdEx v5: Issue #384 Unified precision - primitives::UnifiedNum Mar 19, 2021
@samparsky
Copy link
Contributor

what's the reason for having a Unified precision?

@elpiel
Copy link
Member Author

elpiel commented Mar 21, 2021

Reason

what's the reason for having a Unified precision?

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 particular

From AIP#61:

validator: unified precision: use a unified number of decimals for all numbers (8), and only convert to the proper stablecoin decimals when generating the balance tree; this will ensure that we can handle precision even with USDT (6 decimals); normal int numbers can be used in DBs (easier, can aggregate stuff values faster)

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

@Ivshti
Copy link
Member

Ivshti commented Mar 21, 2021

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

@elpiel elpiel force-pushed the issue-384-unified-precision branch from 4b9f2e2 to 310ea23 Compare March 22, 2021 11:53
@elpiel elpiel merged commit 7621a77 into aip-61-adex-v5 Mar 23, 2021
@elpiel elpiel deleted the issue-384-unified-precision branch March 23, 2021 11:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
primitives Changes regarding the `primitives` crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants