Description
We can implement a property of the payment spec that allows to divide a token to any arbitrary number of decimals, and use that unit internally
then, when the state tree is signed, it would be divided to get the real token unit (e.g. if we were dividing to 10**30
, and the real unit is 10**18
, we'd mul by 10**-12
and round down)
useful for AmbireTech/adex-validator#14
this can help going both ways - if the token multiplier is, say - 18, and we want to pay out 3*10**12
, there's no point to increment aggregates by 3*10**12
; we can just increment by 3 and set 10**12
to be the multiplier
Precision
- USD - We can take a precision of
1 USD
to be1 * 10**6
(i.e. 6 decimal places) - DAI has a precision of
10**18
- USDT (Tether) has a precision of
10**8
This means that we can use a base of 10**12
for internal database storage, four couple of reasons:
- CPM has 3 decimals places precision, but that's for
1 000
, this means we need 3 decimals places of precision more for a total of 6 - Since DAI has
10**18
and is the most precise of them, we can use it as a base, meaning we get the base
10**12 = 10**18 - 10**6
(6 decimal points less precise than DAI)
This should only be applied to Sentry and it's internal representation in the Database of the payouts.
Benefits
- easy support of multiple tokens cause we restrict the maximum precision
- easier aggregation
- easier analytics
Multiple tokes support
Combined with AmbireTech/adex-validator#324 we can have the whitelisted tokens
Sentry changes:
- Check on creation of
Channel
if thedepositAsset
is on the Whitelisted tokens - Define a list of available tokens and their precision as well as their chainId
- Impl
ChannelSpec
depositChainId
(optional) - if it's not specified, try to infer the chain ID from thedepositAsset
(token address)