Incorrect UniversalDividend computation in GCli?

Clients Ğcli
, ,
1

Post made in english but feel free to answer in French :smiley:

I just claimed my Universal Dividend for one of my acccounts (5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6) in GDev:

gcli ud claim
(Vault: Base[address:5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6, name:Some("Nicolas80-GDev"), crypto_scheme:Some(Sr25519)])
> Password ********
transaction submitted to the network, waiting 6 seconds...
claimed 426 UD, for a total of 1550169647596.10 ĞD

From that information, I can do a simple division and have an estimate of the minimum amount that the UD should be at this moment:

1550169647596.10 ĞD / 426 = 3638895886.38 ĞD (should be the minimum possible UD value since UD grows in time)

I’ll try a transfert of 1 cent of UD value, which should be at least:

0.01 UD = 36388958,8638 ĞD (also I wonder how do we resolve the rouding to cents of ĞD)?

Using the -u argument to make the transfer in UD amount

gcli account transfer 1 5Funkng8dL397H9ZEJ9sXDjFhStCqRYUj1a62ngcrEMy7ivn -u
(Vault: Base[address:5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6, name:Some("Nicolas80-GDev"), crypto_scheme:Some(Sr25519)])
> Password ********
transaction submitted to the network, waiting 6 seconds...
transfered 18358942.33 ĞD (5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6 → 5Funkng8dL397H9ZEJ9sXDjFhStCqRYUj1a62ngcrEMy7ivn)

From this, I see that 1 cent of UD was only 18358942.33 ĞD that were transfered; which doesn’t make any sense…

  • Unless someone lowered the UD value at some point in time in GDev :question:
  • Or other possibility, the ud claim command before gave me a wrong number of UD received :question:

Just to show the difference of amounts:

  18358942.33 ĞD # Amount transfered when requesting 1 UD cent
3638895886.38 ĞD # Minimal amount expected for 1 UD cent

The value that was transfered is about 200 times smaller than what I expected…

1 Like
2

It doesn’t work that way. Your 426 UDs do not have the same quantitative values: on ĞDev, the UD value changes every 24h. And we have 4 UDs a day.

Looking at the code, I’m afraid we don’t have the details logged into an event, so even an indexer wouldn’t have the details of each UD amount we claimed:

Self::deposit_event(Event::UdsClaimed {
    count: uds_count,
    total: uds_total,
    who: who.clone(),
});

Consequently, if you want to verify that the claimed value is correct you have to check the value of the last (426 / 4) UDs and do the math.

You can have the values using RPC API:

image
image1186×138 6.85 KB

But be quick! 426 / 4 means 107 UDs implied in the computation, and Duniter only stores the last 160 last UD values. So you had (160 - 107) = 53 days left at the time of your claim. :slight_smile:

2 Likes
3

But doesn’t the UD increase all the time (every 24h if I understand what you say) ?

Or did you mean it actually gets a non deterministic and non-always increasing value every 24h ?

4

What happens if I would have claimed only in say 55 days ?
I would have lost a few of those UDs ?

5

Yes in that case you lost UDs, but this case is supposed to be impossible because wallets are expected to claim the UD at least during the membership renewal.

So as long as (UdReevalPeriod * MaxPastReeval) >= MembershipPeriod no one can lost UDs.

Note that the UDs are automatically claimed by the runtime when the membership expires: pallets/universal-dividend/src/lib.rs · master · nodes / rust / Duniter v2S · GitLab

2 Likes
6

However, nothing forces wallets to do so, so if a wallet does not follow the recommendations, the lost of UDs remains possible. I created an issue: Auto-claim UDs when membership renew (#288) · Issues · nodes / rust / Duniter v2S · GitLab

1 Like
7

Yes it does, exponentially (5% / day on ĞDev I think).

On the production Ğ1, with 10% / year, you can prove that all the monetary mass produced 80 years earlier represents less than 1% on current monetary mass, so UDs which were not produced 80 years can safely be dropped.

Also, given the fact that UD is reevaluated every 6 months, we need to store 80*2 = 160 reevaluations.

Here in ĞDev,1 day represents 6 months from the UD point of view.

Exactly. :slight_smile:

1 Like
8

My bad, I’ve kind of forgotten the basics of the RTM over time, so closing the issue :sweat_smile:

1 Like