[SCP-TBD] Pre-Proposal Polls for the IBC Auto Compounding Integration

These set of polls will serve as signaling before an official thread is put into proposal. There’s a lot to cover, so please bear with me.

I will also be putting in sprinkles of ideas here and there for future integrations, but obviously the ideas are just to get creative juices of the community flowing.

For more information / context please refer to the following threads:

  1. UX/UI

A Cosmos staking interface does not mix well with EVM based staking / opportunities IMO. Too many different sets of parameters, different rewards systems, etc. → I am proposing to create a separate section solely for Compounding Tools. Why stop at IBC? There’s plenty of tools and protocols available that allow for compounding, and it could be a lucrative feature set when we have L2 launch.

Anyways, back on topic. I decided to keep the UX/UI fairly similar to existing platforms, as I’d assume many of the delegators would be most comfortable with this format. Open to feedback, of course.

At the moment, this page was designed to serve only the purposes of the auto-compounding tool.

(State: Delegating but not Compounding)


Figma for those who prefer. (P.S. cosmos related components seem to have disappeared from the Figma. No worries though, I had a blast making this)

(State: Compounding, Authz Granted)


Pretty much the only three modals needed for the tool. I’m assuming we can re-use the re-delegate modal from the Earn section.


Alright, let’s pause for a moment.

UX/UI Poll #1: Autocompounding tool should be on its own page

UX/UI Poll #2: The page shows just the right amount of relevant information.

UX/UI Poll #3: Overall, I like the direction of where the UX/UI is going

  1. Wallet Integration

I know the team is working hard on wallet integrations, but I’ll be honest I’m a bit confused on the status of the integrations. I’ll take a look at github later today to get up to date – but besides the wallets themselves, the issue of hdwallet and what Cosmos chains are currently supported is another issue I’ll have to look into.

ShapeShift currently has four active validators on Cosmos – ATOM, OSMOS, JUNO, and UMEE. At the moment I’m only seeing ATOM integration on the platform, which was a bit concerning, but I’m seeing Osmosis is close to completion (?) and see some codebase for JUNO as well.

I will most likely be looking for a helper with wallet integration and tx signing, because it’s the most logical thing to do.

With all that being said, the timeline/deadline for the bounty can get a bit murky… Not sure if I feel comfortable making hard deadlines when a lot of it is dependent on external factors.

Wallet Poll #1: A hard deadline should not be enforced from the get-go

Wallet Poll #2: If Umee and Juno is properly integrated via hdwallet with the ShapeShift app by workers of this bounty, there should be a considerable bonus to those involved.

  1. Feature Spec

A. ShapeShift platform users and more specifically, delegators to our validators, are rewarded with an all-expenses paid vacation to compound town.

Essentially what this means for the end-user, is that if they are delegating to ShapeShift validators (and thus increasing our revenue), they are rewarded with higher APY that comes 1) obviously from the compounding assets; 2) the fact that they never have to spend gas to claim or restake (as long as they are still delegating).

This auto-compound tool has been tested for quite some time now, and besides from the occasional RPC timeouts, or running out of gas on the compound bot wallet, I am confident in the bot and tool.

B. Through the ShapeShift app, users will be able to view their current delegations, an estimation of APY when compounded, and the ability to restake all their delegations with other validators straight into ShapeShift’s validators (along with all useful and relevant information).

(See figure 2).

C. Proper logging and watchdogs for bot failures and/or insufficient gas.

This is more for maintenance / backend, but definitely something that should be properly implemented.

To be continued. I’ve only covered ~half of what needs to be addressed, i.e. backend infrastructure, handing off of the wallet with all the grantors to the DAO, some out of scope things, ideas on spreading ShapeShift’s name across the Cosmosverse with NFT minting + some sort of rewards if holding that NFT and delegating, the original FOX bounty ask vs. current market conditions, etc. etc.

  • Please let me know if you have any concerns or thoughts regarding the proposed UX/UI.

  • Will be PMing you in the next day or two - hope to work closely with you on getting this out fast.

  • Let me know if I missed anything, besides the second half of the entire thing. But procedural-wise ahah.

Hey LPX, browsing twitter this morning.

Found this super slick UX/UI here. I think maybe something closer to this may be easier to understand.



Very slick indeed! Thanks for the share. I’ll give the UX another go, but I still do think its important to show users exactly what they are authorizing and the grants. Maybe an accordian style dropdown with the technical details would de-clutter the interface and make it easier on the eyes.

Osmosis LP re-staking was also something that I explored briefly, but wasn’t sure how people would feel granting access to move funds around on Osmosis. Could be a recipe for disaster. I’m curious to see how yieldmos plans to implement LP re-staking. (Last time I checked, a slew of more authorization grants not from Cosmos SDK were required, but perhaps its changed since - will check)

Thanks again for the new perspective. Appreciate it

edit: Also, interesting that they charge 1% for the restaking service. I guess it makes sense when the service is benefiting validators they they do not own.

hey LPX! First off I just want to say that I think this auto-compounding idea is freaking awesome and I’m super excited for it and you’ve clearly put a lot of work and thought into it!

I’d like to suggest that maybe you can primarily focus on the details of the integration without the UX/UI at this point, and then work alongside the product workstream, to plow through the UX together. I know this stuff is very time consuming and the way we’re currently building the application is scalable, using a system of reusable parts. For this to work with the current web app, we’d want to use that system and take this through several rounds of usability testing, with several rounds of iterating (most likely) based on clickable prototypes. Curious to hear your thoughts. Thanks!!