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
The rewards was distributed to non-registered stake address #415
Comments
🤦 Looked at this for a while and then suddenly realized that the first query does not show what @dmitrystas thinks it shows. By joining on For most operations related to staking, actions (like registrations, increases in amount staked etc) that occur in epoch That means the first query should actually be:
and the second:
@dmitrystas Does that all add up? Would it help adding an extra |
@erikd Good day. That is original issue Emurgo/yoroi-frontend#1832 (comment) Yoroi & Adalite show wrong 192 FAKE ADA reward but actually it is 0. The last 2 rewards are withdrawn through adawallet.io (it does not use db-sync) Short description of the issue in steps:
|
There are at least two possibilities;
I only deal with Is |
@erikd yes the stake key is stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |
If some online wallets have this bug and others do not, and all of these depend on |
@erikd But adawallet.io does not use db-sync and shows correct reward balance (0ADA) and it let me withdraw last rewards |
Again that suggests this is a Yoroi bug, not a |
Exodus encountered this bug as well. |
This is definitely a cardano-db-sync bug and not a Yoroi bug given how this affects not just Yoroi but multiple other users of cardano-db-sync as well. cardanoscan and adawallet both do not use cardano-db-sync which is why they aren't affected. What cardano-db-sync reportsHere is the SQL query that gives the reward history for the address provided by @IlyaSofronov
and gives the following result
Note: Sum of these rows is 3,765,004,402 Current (incorrect) state from our backend
You can see our backend returns the sum of the db-sync rows for the You can also verify the
Registration history for the walletBy looking at the history of this staking key, you can see:
Current state from cardano-nodeAccording to my cardano-node instance, this is the current value inside the staking address
So you can see that according to the node, the balance of the wallet is epoch 235 + epoch 236 (100702 + 102078 = 202780) So what is the issue?By looking at cardanoscan we can see the full withdrawal history of the wallet. Let's see what each withdrawal corresponds to:
HOWEVER You can see epoch 231 in cardano-db-sync (192969560) is not included in any of these! Sure enough, if you look at our backend response, ConclusionBased on my investigation, it seems cardano-db-sync includes row 231 in the reward history result even though it shouldn't. |
I simplified the first query and validated that I get same results (I did).
I would prefer to get all information from a single source so:
and:
both of which agree with your figures. Interestingly
So is that reward for epoch
Note that for both the registration and the deregistration i have included the Looking at the active epoch numbers, the stake registration should have been active in epochs
Ie, there are rewards for every epoch except Therefore I think your conclusion:
is incorrect, that stake address should have rewards for epoch Furthermore, I believe that your comment:
is actually correct. The difference between the rewards value and the withdrawal value is the current unwithdrawn reward balance. |
That can't be the case because we know the node returns
You should expect two epochs to be missing:
The missing |
Why? According to the operations on this stake address:
it was only deregistered for a single epoch ( Why would there be two epoch's without rewards? I am pretty sure the two cases you mention are actually the same thing and hence only one epoch goes without a reward. |
@SebastienGllmt in Slack said:
If deregistration takes pace immediately, this one happened in I think we need @JaredCorduan on this. |
@SebastienGllmt 's explanation is consistent with the ledger rules. It's a bit philosophical "when" a stake credential is deregistered, but I would phrase it like this: deregistration takes place immediately, but rewards are delayed. If a credential is de-registered in epoch |
This sounds like we have some confusion with nomenclature. From the POV of
|
if the stake credential was in a deregistration certificate from a transaction in epoch 232, then it would not be included in the snapshot taken on the 232/233 boundary. this means that it would not be a part of the reward update that is handed out on the 235/236 boundary. which, in @erikd 's terms, is the 234 rewards. moreover, if the (re)registration certificate landed in a transaction in epoch 233, then this would be the only reward update that it would miss out on. |
it's worth noting that things like "de-registered when", "rewards at", and "active when", etc, can be confusing if we aren't really clear. so it's not clear to me who all I am agreeing with :) |
Since there seems to be confusion, I made a picture that shows the two expected missing epochs (db-sync 231 and db-sync 234) I think the confusion comes from the fact that 231 may not technically be missing -- it could be the ledger state just considers it distributed to the reserves instead of the user. From the ledger state point of view, the rewards exist (distributed to the reserves), but from the user's point of view 231 shouldn't be included |
But the actual rewards as reported by
and only epoch Your diagram does not match this table, so your diagram is likely incorrect. There may also be a bug in the |
In your diagram you have "rewards delivered" crossed out for epoch 233, and both Jared and I think that is incorrect and that rewards should be delivered (because they are based on the snapshot at the start of epoch 231, not the current state of the chain). |
@SebastienGllmt says:
But the |
I was wrong when I said:
In fact, @SebastienGllmt was exactly right when he said:
By not being registered on the 232/233 epoch boundary, the stake credential both:
I can guess how db-sync is reporting rewards being handed out on the 232/233 boundary (which is really just @SebastienGllmt 's guess :) ). The ledger state cannot know until the last moment before the epoch boundary which credentials are still registered. We return rewards for unregistered credentials to the reserves. (See |
@SebastienGllmt 's picture above looks great, but note that in fact the arrows need to span another epoch to account for the block producing phase. for example, the rewards from the snapshot taken on the 230/231 boundary is not actually handed out until the 233/234 boundary. |
Ok now we have an explanation of this. The solution is to also pull the set of valid |
It would be great if this 'phantom' rewards will be put in a new table like 'nondistributed_rewards' or something like this. This will allow us to correctly calculate the pool profitability |
I can see that these undistributed rewards (that go back to the reserves) could be used to calculate poll profitability but I am pretty sure that is not the best or the easiest way to calculate it. I have created a ticket specifically for this issue. |
Ok, I have a solution that filters out invalid rewards from the rewards list before being inserted and indeed there is on reward for that address in epoch I now need to modify that so that these "invalid" rewards can be added to a separate table. |
Using the version of
and it is also absent from the rewards table:
|
Mainnet, db-sync 6.0.1, stake address stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
registration history
de-registration history
as we can see, the address has not been registered at the end of the 232 epoch, and the rewards for the epoch 231 should not be distributed to this address, but
The text was updated successfully, but these errors were encountered: