Autcompounding of staking rewards

Hey everyone,
If there was a proposal to implement automated compounding of staking rewards and it passed, how difficult would it be to implement? Who would write the code changes? Just spit balling here.

3 Likes

How exactly would this look like? Would auto compounding be enforced if a proposal like this passed? Currently there are multiple platforms for people to sign up for auto compounding if they wanted to and I think it should stay that way - some people donā€™t want to auto-compound.

3 Likes

Not exactly sure how it would look, which is why i posted. There are other chains where rewards auto compound and Iā€™m wondering how something like that could be implemented. I love not having to claim and restake those tokens and thereā€™s no 3rd party involved. Plus, itā€™s tax friendlier and requires less record keeping.

Please help me understand why someone wouldnā€™t want their rewards to automatically compound.

4 Likes

I understand all of your points, however there are already really good solutions out there that many users use and those solutions arenā€™t limited to the Cosmos Hub only so in my opinion, theyā€™re more efficient already.

With respect to the ā€˜who wouldnā€™t want their rewards to automatically compoundā€™, thatā€™s a good point. But, maybe there are some people who have a set allocated limit and just want to sell their rewards. Guess there can be a toggle to turn it on and off however again, solutions already exist out there.

2 Likes

Yes, but theyā€™re 3rd party solutions.

1 Like

Nobody else cares to weigh in?

1 Like

There is an issue (and we were discussing auto compounding for a long time in fact). Itā€™s not trivial.

1 Like

Thanks for posting. Forgive me for this seemingly naive question. Iā€™m marketing, not tech so will you please dumb it down a bit and tell me what the screenshot in your post means, thatā€™s ā€œnot trivialā€?

1 Like

ā€œnot trivialā€ - means, takes time, it is difficult

1 Like

I am also not a developer and donā€™t feel a strong urge to auto-compound. I also think Iā€™m probably missing some perspective since I donā€™t actually know of all the tools out there that enable people to do this.

If solutions that do this already exist as 3rd party tools, what is the benefit of including the option natively in the sdk, as in that pull that Robert linked? Are the benefits so great that a dev team could be convinced to essentially make a duplicate tool implemented in a different place to the existing solutions?

Who would write the code changes?

This is kind of an interesting question, governance-wise. If thereā€™s a good idea proposed by someone without the technical ability, could you do a signalling proposal to prove support and budget for it (e.g., ā€œVote yes to commit to allocating X ATOM from the community pool to the development of this featureā€) and then turn it into a bounty where a team could submit a community spend proposal to fund their work in coding the feature?

1 Like

It would be pretty useful for most users to not have to log in everyday just to claim and compound their rewards. Chains such as Ethereum already have widespread liquid staking solutions that donā€™t have a heavy user overhead, auto-compounding on their own which is pretty simple for more to understand. In addition, ledger isnā€™t automatically supported with REStake. It requires a lot of user effort and skill that most do not possess. It would be great if this could be coded into the cosmos SDK!! Just a 5 cents from me.

1 Like

Ledger will be supported pretty soon though. It will come.

1 Like

Cardano auto compounds, plenty of projects on Ethereum auto compound, Solana is automatically liquid staked and compounds and there are others. IMO, if Cosmos wants to be competitive we must do at least what the competition is doing and natively, without 3rd parties involved. REstake requires extra setup from validators and extra work from delegators. Plus, Iā€™ve seen people online complaining that REstake is down or not working on several occasions.

I have no idea who would do the coding, nor do I have any idea how much funding would be needed. Those things Iā€™m hoping to get from this forum post. I love the guidance about the signaling proposal, but have no idea how much ATOM would be needed. Any idea how many ATOM would be needed for the bounty?

Also, if it all went through and was then written into the SDK, would the auto compounding be retro and suddenly work for all current projects, or only for future projects that used the updated SDK?

3 Likes

I donā€™t think autocompounding is a killer feature, but I agree, we should have it, rather than ignore it.

There are few options for get it:

  1. The Core SDK team will do it
  2. Someone external will make a bounty proposal for ICF
  3. Someone external will make an on chain proposal to get funding from Community Fund. (maybe I could team up with someone?)

I think ICF has full backlog with different asks for funding, so not sure how long it will take for them to consider it.

Once this is implemented, Ideally it will land in the cosmos-sdk directly. This will be a breaking change, so will require on chain upgrade. Now we are in the Cosmos SDK 0.47 release cycle. So if things are done smoothy, the optimistic scenario is to have it in 0.48ā€¦ Probably will be out somewhere in late Q2 2023. Then chains will need to update to 0.48 which usually takes few months.

1 Like

I appreciate your response. The feedback Iā€™ve received so far is that REstake and Yieldmos exist so thereā€™s no need. My argument is that those are 3rd party and thus vulnerable. I agree that there needs to be funding to implement the code changes and raising the transaction tax takes priority to fund the community pool.

Hopefully @lexa can pass this along and put it on the ICFā€™s to-do list.

I think the best way to push this forward would be to talk directly to the SDK team and other developers, not ICF.

Marko is the SDK lead and I believe their team hosts biweekly community calls. Might be a good place to start!

1 Like

Ok, thanks Lexa. Do you know Markoā€™s handle to tag him and keep the conversation here on the forum? I canā€™t find it.

Marko is @marbar but I donā€™t think heā€™s super active here!

1 Like

I want this badly in the sdk, it is a matter of priority right now in the sdk. We are working on a few other parts that will help working on this. We have a design in mind, and itā€™s not super complex but the main issue is we would also like to tie this into a larger rewrite of some modules in order to provide safer gurantees.

2 Likes

@jtremback will you please weigh in on this thread?