Closed patrickdugan closed 4 years ago
We should split this into getContractVolume(id, start, end) and getSpotvolume(id1, id2, start, end)
Turns out we have an mdex and dex volume RPC already, so these just need to be integrated with Trade Channels (e.g. TC volumes for these pairs also count).
Then, an RPC for contract volume can be factored separately for the Oracle release.
Hey @santos177, is the getDexVolume RPC to get the LTC-denominated volume across all of TradeLayer for a specific period and a specific volume, or is it a given property's volume specifically against LTC on the level 1 Dex? I'm thinking it's the prior and we can still create a getSpotVolume RPC for the latter, while renaming the existing RPC to "getLTCTotalVolume".
To restrict any attempts to game the spirit of the vesting system, we will apply the following logic when parsing mDex trades of both the Trade Channel and open order varieties:
1) mdex trade (TC or orderbook) is confirmed 2) check the denominator in the trade (property desired), if >=1000 LTC direct volume against it in the last 10,000 blocks then true, otherwise false, check the numerator, if it fails move on, otherwise -> 3) look up the 12-block VWAP of the denominator vs. LTC 4) increment cumulative LTC volume by tokens traded * the 12-block VWAP
working in integration branch
Was documenting the API, we had a getVolume call from a while back, but we don't have an RPC. Since we're already taking volume, (not yet integrating Trade Channel volume but this call should cover that as we integrate TC volumes) it shouldn't be too hard to calculate cumulative LTC volume or cumulative notional volume for different contracts and tokens. Doing this by block might be more complicated, but ideally a pair of integer parameters to take volume for some period: starting_block_height, ending_block_height, if second is null then assume ending block is current block.