queryFeesCollected should be more or equal (queryFeeRebates + delegationFees)

[davaymne]

As per fee distribution logic: queryFeesCollected > = queryFeeRebates + delegationFees

But if you query (for instance: id 0x5a8904be09625965d9aec4bffd30d853438a053e )

{
    allocations (orderBy: closedAtEpoch,  where: {
    indexer: "0x5a8904be09625965d9aec4bffd30d853438a053e",
    status = Claimed
  }) {
      id
    status
    queryFeesCollected
    queryFeeRebates
    closedAtEpoch
    delegationFees
    effectiveAllocation
    allocatedTokens
    }
} 

you will find that almost in all cases (41 out of 49 ) queryFeesCollected < queryFeeRebates + delegationFees

Could you please take a look into this.

[davekaj]

Thank you! Great investigation work. I took a quick look but could not find anything. Seems like it could be a bug .

I am too busy this week to check it out, waiting until Ariel gets back from holiday. Maybe this week @juanmardefago could take a quick look into it. If not, I will look next week

[abarmat]

Because of the way the rebate formula works the following statement is not always true queryFeesCollected < queryFeeRebates + delegationFees.

When there is a rebate claim the rebate formula does:

reward = (indexerFees/totalFees)^(alpha) * (indexerAllocation/totalAllocation)^(1-alpha) * totalFees

Being:

• IndexerFees: tokens collected from queries on the indexer allocation
• TotalFees: total tokens collected for all queries for allocations closed in the epoch
• IndexerAllocation: effective allocated tokens by the allocation (amount of tokens * number of epochs from start to close)
• TotalAllocation: sum of all effective tokens allocated from all allocations closed in the epoch
• Alpha: Rebate ratio configuration that weights capital and work. Capital meaning tokens allocated and work meaning fees collected from queries. This is currently 0.77

Depending on the relationship between those variables the rewards can be higher or lower, sometimes even higher than the indexerFees if the indexer has a better work to capital ratio than other indexers.

[davaymne]

What I am saying that correct relatonship should be queryFeesCollected >= queryFeeRebates + delegationFees,
where
queryFeeRebates + delegationFees = reward = (indexerFees/totalFees)^(alpha) * (indexerAllocation/totalAllocation)^(1-alpha) * totalFees

I that correct?

[davekaj]

Unfortunately, no that relationship is not correct. The cobbs douglas formula (i.e. the reward formula), will return query fee rebates that could be very different from the query fees collected.

The reason I thought it still may be a subgraph bug is because we still only have 1 subgraph in the network. Which reduces the dynamism of this calculation. Still, Ariel could be right, that the formula is working as intended. We need to dig into it a big deeper to confirm if it is right, or find a bug if it is wrong

[davaymne]

I see.
So, for example (roughly), reward (queryFeeRebates + delegationFees) cacluclation would look like:

		K, indexer/total
Indexer Fee Collected	33.5	0.095
Indexer Allocation	464 000 000	0.29
Total Collected	345
Total Allocation	1 600 000 000
Final K, Cobb	0.1228
Reward	42.36	0.1228 x 345

[juanmardefago]

The queryFeesCollected and rebates fields are not calculated within the subgraph, since they just use the same values provided by the contracts in the events. I don't think that it's a subgraph bug.

Collect: https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L926
Claim: https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L1200

Having said that, my understanding of the Cobb-Douglas function is that the rebates can be higher or lower than the collected fees, depending on your performance within the function, but it should be a zero sum game, right? @abarmat

If so, we could probably check that, and if it's not the case then it probably is an error within the subgraph, although it doesn't seem likely since from what I could see, it's just using the value sent by the event and adding it whenever necessary.

[davaymne]

So, let's say if we take Epoch 39 and sum all query rewards across all claimed allocations for this epoch, the total should be equal query fees collected - 10% (curator reward).
Is that correct?

The only issue is some allocation can be "Unclaimed" yet.

[juanmardefago]

I think so, it might not be a zero sum within a single epoch though, as allocations can generate rewards within various epoches, so I'll have to double check that too. @davaymne

[abarmat]

An allocation generates rewards across various epochs but for the purpose of the rebate calculations it is done on the epoch when the allocation was closed. The way the cobbs-douglas formula works could make that not all allocations are optimally claimed due to the proportion of capital to work ratio. Even if all the allocations on the rebate pool for a particular epoch are claimed there could be a remainder of tokens, so not always sum of query fees collected = sum of claimed rewards, the remainder is burnt on the last claimed allocation.

[juanmardefago]

An allocation generates rewards across various epochs but for the purpose of the rebate calculations it is done on the epoch when the allocation was closed. The way the cobbs-douglas formula works could make that not all allocations are optimally claimed due to the proportion of capital to work ratio. Even if all the allocations on the rebate pool for a particular epoch are claimed there could be a remainder of tokens, so not always sum of query fees collected = sum of claimed rewards, the remainder is burnt on the last claimed allocation.

So, on a big picture scale: queryFeesCollected >= queryFeeRebates + delegationFees (considering the totals on the whole network), right?

Epoch by epoch we might not draw any conclusions because of what you just described, but on the totals there could never be more rebates than collected query fees

[davaymne]

I think, in total formula queryFeesCollected >= queryFeeRebates + delegationFees across allocations in epoch could be correct, but not for particular allocation