search

Joystream / status-endpoint-joystream

Status endpoint for the Joystream network
GNU General Public License v3.0
1 stars 4 forks source link

Address endpoints #42

Closed DzhideX closed 1 year ago

DzhideX commented 1 year ago

This PR aims to implement the features outlined in the following issues: https://github.com/Joystream/status-endpoint-joystream/issues/38, https://github.com/Joystream/status-endpoint-joystream/issues/41

To test/display the functionality, we can use the following URL: https://bwhm-distributor.joystream.network

More specifically, for the different endpoints it would look like this:

bwhm commented 1 year ago

@DzhideX Should add that 2. is a result of me focusing on the vesting part when this was discussed, without thinking about this issue. Might be the case for 3. as well. For 1., I might also have sent you down the wrong path wrt. miscFrozen

Regardless, 1 and 3 needs some fix.

bwhm commented 1 year ago

Found a new bug – seems related to 3. above.

For an account with multiple vesting schedules (vesting.vesting(account) returns an array with .length > 1), there will still only be one lock with id: "vesting ". At least for the examples I found.

Furthermore, when a new vesting schedules is added (presumable also on vesting.mergeSchedules), any funds that is vestable at that block is vested. This applies not only to any previously existing locks, but also the one that gets added. For example, if at block n a vested transfer to an account, where startingBlock < n, is included, then any funds not yet vested for both the new and existing schedules are released.

As the state doesn't track when a vesting schedules is created, nor when a lock was last modified (afaict), that means you have to calculate this. Luckily however, for each schedule it will be the same block (unless the startingBlock is greater ofc).

So basically, at a block

  1. Find the actual vesting locked amount in balances.locks -> vesting_locked (I think there will always only be one, but...)

  2. From vesting.vesting, sum up the locked amount in each schedule -> sum_vesting_locks

    • If sum_vesting_locks == vesting_locked -> vestable is just the sum for each schedule.
    • If not, take the schedules where block > startingBlock
    • For each of these schedules, find how much is unlocked in the various intervals. Example: [{startBlock_0,endBlock_0,endAmount_0},..., {startBlock_n,endBlock_n,endAmount_n}]
    • Finally, find where: endAmount_i-1 < vesting_locked < endAmount_i.
    • Unfortunately, this means you have to keep of track of the remainder, as the locked/perBlock can (and mostly is) a float.

I assume there is a more elegant way, but I have yet to find it...

If you want to check and play around a bit, check out the address j4U9AZVNXB5cXDw7NEiK6Z31UDg5Utm3R5XD8ktK821ESGnq4 at blocks:

3278319
3431450
3435000
3436299