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.
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.
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.
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.
Yes, but they’re 3rd party solutions.
Nobody else cares to weigh in?
There is an issue (and we were discussing auto compounding for a long time in fact). It’s not trivial.
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”?
“not trivial” - means, takes time, it is difficult
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?
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.
Ledger will be supported pretty soon though. It will come.
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?
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:
- The Core SDK team will do it
- Someone external will make a bounty proposal for ICF
- 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.
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!
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!
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.
@jtremback will you please weigh in on this thread?