Fee Data

[patrickdugan]

This is one of the most important bits of data: how much revenue the protocol is doing.

tl_getcache this is where fees go before someone places an order on the mDex and the protocol automatically buys it with the cache balance.

tl_getvesting_info tells us how far along vesting is based on cumulative volume (which implies total fees)

tl_getunvested is the mirror of the above.

[nmanolov]

@patrickdugan, where do you want this data to be displayed?

tl_getvesting_info returns some general data while tl_getunvested has an address parameter. I don't think they are symmetric. The second fits well on the Address page, i.e. here

[nmanolov]

I am getting an error on tl_getcache rpc. The message is "JSON value is not an integer as expected". I've tried with a wide variety of arguments, most of which I consider correct-ish. Can we check for some additional errors on the node?

[patrickdugan]

The vesting tokens are I think propertyId 2 so you pull the holders list for that property then look through tl_getallbalancesforid you can see everyone. I'm not sure can you post the JSON of what tl_getvesting_info returns? It should show the macro stats that we want and looking through everyone or looking them up would be more appropriate with tl_getallbalancesforaddress.

tl_getunvested would be needed to specifically see vesting tokens, what % of that VT balance is left to juice from ongoing volume?

Vesting tokens are different from other tokens in that they have this additional accounting column that they drag around with them as they are sent.

Looping through wallet addresses to show their remaining vesting potential from VTs, is a move one might use in wallet dev, but not here.

[patrickdugan]

tl_getcache

Very possibly there's a C++ issue here we can fix.

[patrickdugan]

The fee cache is meant to be a very temporary bladder, ideally some trading bots are posting ALL to sell at high prices to harvest trading fee flow, or they are posting best offer, and the fee cache is getting emptied same-block, never has a standing balance, all the fee earned that block goes through the cache and then is pulled into a trade. So if the RPC goof isn't fixed soon* we can simply count on people posting ALL to put some into the insurance fund, and focus on showing that on the top, main dashboard. However the problem there is, that RPC is also unfinished at this time. Another simple thing, I can get some help on that. I actually have Sergei on that ticket, waiting on delivery.

tl;dr don't worry about that cache RPC, we'll route around it and use a pending delivery RPC method.

We can estimate oracle contract fee revenue as 0.0001 of the volume (in collateral currency) and the % that goes to the protocol as 0.00005

*(We've encountered and fixed this JSON type error with other confusing RPCs and it's not complex, just a lack of C++ janitors these days)