You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Had a report that for larger wallets, the little bit of rewards that aren't autostaked can amount to something substantial:
because the APR is so high, when the first part of the REStake TX occurs (claiming), it claims that available balance. Then, the 2nd part (restaking) of course stakes what was claimed - but, in between those 2 TX's, because of really high balances (millions of CRBRUS staked) + really high APR, you've earned more tokens. After that 2nd tx takes place, it then claims that newly earned amount in that time to your balance.
I've watched this happen on a few of my wallets that have like 5M+ CRBRUS - over time there becomes a slight buildup of tokens from this space of autoclaimed tokens after the staking process occurs. Curious if there is something we can do about this long term (i.e., maybe every X REStake transactions, we also do a check for balance, and then if it meets a certain threshold (say, 100 CRBRUS), it then attempts to stake that as well. I know this would once again start the cycle (because it's claiming tokens automatically after staking), but at least cuts down on tokens sitting in the wallet.
I think we need to stay on the safe side here, to make sure we don't delegate any of the users existing balance. But worth making sure we aren't leaving anything, and see if the delay between getting balance + actually sending the TX batch can be reduced.
The text was updated successfully, but these errors were encountered:
Had a report that for larger wallets, the little bit of rewards that aren't autostaked can amount to something substantial:
I think we need to stay on the safe side here, to make sure we don't delegate any of the users existing balance. But worth making sure we aren't leaving anything, and see if the delay between getting balance + actually sending the TX batch can be reduced.
The text was updated successfully, but these errors were encountered: