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.
2 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:
- 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.
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?