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.
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. github.com/cosmos/cosmos-sdk docs: ADR-059 Auto-Compound Rewards `cosmos:main` ← `cosmos:bez/adr-auto-withdraw-rewards` opened 04:27PM - 17 Apr 22 UTC alexanderbez +196 -3 <!-- The default pull request template is for types feat, fix, or refactor. Fo … r other templates, add one of the following parameters to the url: - template=docs.md - template=other.md --> ## Description 👉 [Rendered](https://github.com/cosmos/cosmos-sdk/blob/bez/adr-auto-withdraw-rewards/docs/architecture/adr-050-auto-compound-rewards.md) 👈 --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR…
Excerpt (1133 of 2500 characters). Read the whole post on the forum ↗
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?
Unpopular opinion:
Auto compounding rewards will lead to an increase in people who dont give a $$$$ about the chain governance, etc. As they dont need to even open their computer now to restake
Automatic compounding can be an option, not mandatory and i believe it’s a great convenience. If people get lazy then it’s important to teach how to choose a validator.
Good point. Having the need to log in might have a side-effect to check governance…
Counter-argument; what is the difference compared to having Yieldmos and Re-Stake where auto-compounding is already enabled?
Not entirely sure if auto-compounding is the elephant in the room, or whether we have another problem to fix with low delagator-participation in governance?
Yieldmos and REstake are 3rd party and thus points of vulnerability. My point in raising the question here on the forum is to keep us resilient and competitive.
If automatic compounding of staking rewards can be written into the SDK as an option for stakers, let’s do it because competing ecosystems, like Cardano offer it. And I’m in no way saying that Cardano is better.
I’m sorry for the developers of REstake and Yieldmos, but natural evolution should make those services redundant.
For that matter maybe liquid staking could be written into the SDK and reduce the inherent risk of 3rd party apps running liquid staking too. But, that’s a separate conversation.
And again, let’s teach people how to choose validators and why it’s important to vote instead of withholding a phenomenal convenience for stakers. The option to automatically compound staking rewards will help to encourage staking and thus strengthen the network.
Yeah, I was also just wondering what the difference in effect for people only caring about $$$$ instead of he chain was. And having it native or with a 3rd Party provider, that risk stays the same imo
That’s why I asked if the problem is auto-compounding or something else. I believe auto-compounding is not the issue on the bigger scheme of things, and should in theory thus also be an option to be natively embedded.
I think that the desire to fix laziness is a great recipe for negativity and arguments from people ==)