Closed nicolasochem closed 4 years ago
I see; I think it isn't specifically because estimated rewards are paid but rather because rewards are being paid prior to the cycle being completed and actual rewards being computed (this may happen depending on payoutDelay
). Is that accurate?
Correct. In the database, when payoutdelay is set low enough, you see delegator entries looking like this prior to finalization:
"tz1XXXXX": {
"balance": "4083109977",
"estimatedRewards": "3972437",
"payoutOperationHash": "oo4XXXX"
},
But then finalization occurs, then it gets updated to:
"tz1XXXXX": {
"balance": "4083109977",
"estimatedRewards": "3972437",
"finalRewards": "3972437"
},
And then, since the operation hash is gone, payout happens again.
Why do you want to pay rewards before the cycle has finished?
In any case, it should be possible, alter line 114 to take the union of the existing delegator map, if present, and the newly created map, and keep the payout hash around if it already exists.
Hi, I recently added the feature
--pay-estimated-rewards
and found it does not behave as expected.https://github.com/cryptiumlabs/backerei/pull/47
The issue is because of this line: https://github.com/cryptiumlabs/backerei/blob/master/app/Payout.hs#L114
delegators = M.fromList $ fmap (\(addr, balance, payout) -> (addr, DelegatorPayout balance (delegatorEstimatedRewards $ estimatedDelegators M.! addr) (Just payout) Nothing)) calculated
The purpose of this line is to add the final rewards for every delegator for a given cycle in the database.
When the estimated rewards have been paid, a payout operation hash is already present in the database, but the line above deletes it. Consequently, the payout is done a second time.
What needs to happen is that the operation hash is kept if it exists.
This is beyond my haskell-fu so I need some help here. @tzemanovic @cwgoes
Thank you!