-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
queryFeesCollected should be more or equal (queryFeeRebates + delegationFees) #94
Comments
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 |
Because of the way the rebate formula works the following statement is not always true When there is a rebate claim the rebate formula does:
Being:
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. |
What I am saying that correct relatonship should be I that correct? |
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 |
The Collect: https://github.com/graphprotocol/contracts/blob/master/contracts/staking/Staking.sol#L926 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. |
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 The only issue is some allocation can be "Unclaimed" yet. |
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 |
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 |
So, on a big picture scale: 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 |
I think, in |
As per fee distribution logic:
queryFeesCollected > = queryFeeRebates + delegationFees
But if you query (for instance: id 0x5a8904be09625965d9aec4bffd30d853438a053e )
you will find that almost in all cases (41 out of 49 )
queryFeesCollected < queryFeeRebates + delegationFees
Could you please take a look into this.
The text was updated successfully, but these errors were encountered: