dApps Staking v2 - Delegated Reward Claim (cont.)

@Mouthmouth68 do I agree with you! :joy: :joy: :joy:

Let me share some pain-points and worries with this approach though:

  • If we took more than the minimum fee from the stakers, it still keeps open the possibility of people complaining and making a ruckus (time & energy waster for all of us)
  • This would require me to make greater changes to the runtime logic to achieve. I’ve thought about charging exactly the amount used for transaction, but it’s not simple nor straightforward to implement. The thing is, with runtime logic development, we have to be super careful not to introduce any bugs. And when I first thought and investigated this, it seemed to me like lots could go wrong if I’m not careful. One major factor here is time - we need to start delegated claiming within next day in order to be ready for dApp staking v3 launch.

With that being said, it’s safer to take the predefined minimum fee (simple to implement & test), and to keep these last minute changes as simple as possible.

Technical limitations & limited time play a huge factor right now.

@SasoLithops
There’s no need for this, we’ll make a script that will execute these claims.
The foundation will pay for the fees & tips.

Given the nature of blockchain, it doesn’t help if multiple people are doing delegated claiming. It’s important people are aware of what’s going on though.

Although, as @Mouthmouth68 noted, the inactive ones should be happy that the rewards ended up in their wallets :joy: .

6 Likes

How about an airdrop of the same?

2 Likes

I see.
I’m affraid that unless you set a bot for that, not many people will accept to claim over 6 million era (i.e. minimum 600k claim) if not incentivized.

As astar Degen council member, I will include this task in our upcomming Zealy sprint. with over 500 participant last time, if everybody do one claim, it will be already that done.

3 Likes

Bot will claim the rewards, it’s not expected from anyone in community to participate in this.

2 Likes

okkkkk, did not get this one :sweat_smile:

In this case, your proposal make 100% sens

1 Like

Understood. Agree in keeping it simple. Maybe after daily countdown notifications in socials it could be left way less unclaimed eras. Maybe it would be good to explain in post that not claiming is causing an unnecessary cost to the foundation, so please go and claim.

2 Likes

Hello, I was wondering if it’s technically possible to use something like Batch Claims Processing to aggregate multiple reward claims into fewer transactions?

2 Likes

Also why is it also important to not allow leaving v2 stake rewards unclaimed during the migration to v3? Maybe we can consider leaving these rewards unclaimed?

Also, we can consider automatically unstaking the full amount from dApps for users who have not claimed rewards for, let’s say, more than 10 eras. Then, later on, when time permits, we can consider implementing a ‘Claim V2 rewards’ feature. This feature would enable users to claim all their v2 rewards in a single batch transaction and then stake their balance in v3 once it’s completed.

This approach reduces the immediate strain on the system and provides the necessary time to develop a user-friendly and efficient solution for batch claiming.

This two-step process could offer a balanced approach, ensuring that no one loses out on their rewards while managing the current constraints.

I am also against burning rewards as it’s not fair to the users.

2 Likes

Great work done, congratulations.
As said above, at first I would also accept the burnings since a lot has been shared about the update, but I understand the inconvenience that would be generated, I believe that in a massive approach to X, even if there were advertising expenses, it would be interesting to at least reduce this amount of 6 million, so that at the final date we have a better idea of ​​how much would have been trapped and so the community can vote to decide whether to burn it or not.

1 Like

Take a snapshot, move the unclaimed rewards to treasury. after V3 maybe create a faucet for unclaimed addresses. Oh and also charge a “storage fee” on every transaction when the faucet is used.

3 Likes

Unpopular opinion. What if instead of burning the unclaimed reward, we distributed all the unclaimed reward equally to all active wallets on Astar who had Existensial Deposit?

From my PoV actually both burn unclaimed or distributing unclaimed brings active staker community a good vibe. Although I rather burn the rewards though.

The pain points for the team are (correct me if I’m wrong):

  • timing, as dApp Staking v3 need to be launched asap so Tokenomic 2.0 can be 100% implemented
  • Tokenomics 2.0 played a pivotal role to eliminate passive builders.
  • Also those 2 points above ensures that Astar zkEVM can have a smooth launch.
  • team source is limited, can’t sacrifice anymore hours for deploying a sophisticated solution in this very limited time.

I’m still stand with my opinion that every individual responsible for their own assets investment.

2 Likes

I agree with this solution.

I am opposed to the idea of burning. In this case, there will always be people who complain later. It is a waste of resources to deal with that, and furthermore, if the burn triggers a backlash on social media, it could potentially damage Astar’s brand value.

This is off-topic, but I see occasional comments in this thread about insufficient announcements. This is certainly true, and there have been many inquiries from community members, including about the Ledger (Native) issue. Learning from this experience, it would be better to make smart announcements for future upgrades.

2 Likes

I support the implementation of the dApp staking v3 mechanism as soon as possible. Additionally, a 5-day countdown period will be more than sufficient.

It will be more critical for Astar Network to release it by February 5th at the latest. It would be good to hurry in this matter before the launch of Astar ZkEvm. With dApp staking v3, restructuring the revenue mechanism while ensuring many projects have fair access to rewards will be healthier.

For example, many projects with over 40 Million are receiving excessive rewards. It would be nice to regulate this with a tier system. As a result of the increase in ASTR price, the reward amounts have reached a very large sum.

My idea is to enough to make coutdown just 5 day

2 Likes

In fact, users who keep an eye on Astar’s updates and engage in community play will all likely support burning for their own benefit.

However, casual users may come later asking where their rewards went, and it will be the project’s responsibility to clarify and explain this every time, which could potentially lead to spreading FUD. This could also be quite a tiresome task, and frankly, burning legitimate rewards might bring more loss than gain.

However again, if there’s a risk of bugs in the process of claiming on behalf of others, dealing with inquiries from the community over a long period could require a vast amount of resources. Therefore, if there’s a potential for bugs, I would support burning, but if bugs are unlikely, I think it would be acceptable to claim on their behalf, deducting fees and tips. I don’t believe that acting on behalf of those who didn’t claim, when burning could have been an option, would be seen as a significant complaint.

Would it be technically impossible to have the Astar Core Contributors or the Community Treasury pool pay the fee for claims and automatically migrate that volume to the Astar Core Contributors or Community Treasury? If this is feasible, I think it would be an ideal solution.

2 Likes

Thanks for the continued post!

I disagree with the burn of unclaimed rewards. Unfortunately, not all stakers continue to acquire information. I think this will be improved in v3, but there is no mechanism in v2 to keep staker’s interest, which creates a huge frustration.

By the way, what is the minimum fee you are referring to, is it a proprietary fee set for Delegated Reward Claim?

If so, I think it should be set at least above the transaction fee so as not to be a burden on the substitute claimant.
Otherwise, the current staker would be incentivized not to claim the fee because it would be more profitable not to claim the fee.
However, we will not take into account the extra gas cost (tip) to prevent malicious behavior.
→ minimum fee >> transaction fee

Now, if we had a specific date and a call for people to claim themselves along with a countdown, I think the situation would be much better.

Still, I think it is inevitable that stakers who do not claim are getting less than they should be getting in staking rewards.

3 Likes

we ve been stakng on astr for nearly 2 years and now u guys say claim ur rewards asap or they will disappear immediately. if the team or foundation has planned that upgrade or update, why is it that the stakers handle the responsibility of moving or losing rewards?

I think all the rewards and assets should be transferred by the foundation.

1 Like

I Agree
I think this solution is the least criticized.

1 Like

The bot will use batch claims. That has minimum effect on consuming block resources however. The issue isn’t the number of transactions, but their weight. If one transaction consumes 50% of block or 50 transactions consume 1% of block resources each, we’re still at 50% consumption.


That’s an very interesting suggestion.
However, notice how much work additional work that brings for the future, and for v2.
It also means we’d need to support v2 functionality for a prolonged time, maintaining it.

Foundation dev resources are very limited (especially now with zkEVM in the fold as well). It’s better to spend those resources on developing something new instead of features for users who hadn’t claimed their rewards in 2 years.


That’s an interesting proposal, however it moves a lot of trust off-chain which is damaging for the reputation. People can say we burned their rewards and then re-calculated them off-chain, which sounds bad.


My personal opinion on this is - what did passive token holders do to deserve someone else’s rewards? Nothing.

That aside, this is same thing as burning, from the perspective of unclaimed reward beneficiaries.

The thing is, delegated claim & the bot have been implemented & tested (since yesterday evening), so there biggest pain point now is to get started ASAP.


I agree!

And the technical risks have been minimized in the proposed solution.
Adding additional (complex) logic would serve to increase the possibility of a bug.


It would be 0.057950348114187155 ASTR.
That’s the minimum possible amount user has to pay to execute a single claim_staker transaction to claim rewards for a single era.

It would only be charged for the new delegated reward call.

I agree but it’s an unfortunate situation, and only valid for a week.
Active stakers will still be at an advantage here since when they claimed before, they could have re-staked, compounding their rewards, earning much more rewards than their passive counterparts.


I’ve noticed that people are concerned about this, and I will definitely relay this to our marketing team. However, I’m not sure why the countdown is so important here? E.g. if people know that something is coming in e.g. 2 weeks, shouldn’t be enough to spur them into action?

4 Likes

@Dino out of all the bad options, it may be the least bad option to take trust off-chain for unclaimed rewards. We can also communicate the decision so that its documented so no one can blame the team in the future.

2 Likes

Agree with that users whos claiming late, should pay the fee. It’s not that high amount and we spread this for a long time.

2 Likes