FortyTwo Auto-compounder Whitelisted Address for Deployment

This proposal grants the address osmo1gl4tggugtxyx6ft0l6dtfghg4sgl7fpxc06xptr7txtny6u4jjsscc7yqt the ability to upload CosmWasm contracts to Osmosis without needing further governance approval for each upload. This address is managed by the Fortytwo team as a multisig.


This proposal would allow the upload of FortyTwo Vaults on Osmosis. The FortyTwo auto-compounding vault is a yield optimizer for automated market making pools. Its core functionality is very simple: Reinvest the rewards accumulated by LP staking. The contract has gone through extensive testing done, with an audit performed by Oak Security. It is already running (in a closed alpha) on Terra2 Astroport and Neutron Astroport (and previously Juno Wyndex before it was deprecated).

The contract is deployed on Our infrastructure provider allows scaling of generalized smart contracts across any CosmWasm-based chain


This proposal only signals approval for the initial FortyTwo Auto-compounder contracts and their potential upgrades.

About FortyTwo was established with a vision to make crypto and Cosmos easy, by offering an array of products that users LOVE. Our core products include interchain auto-compounding vaults, DEX aggregator (in partnership with Skip Protocol, which routes swaps through Osmosis DEX), a clear Interchain portfolio view, one-click liquid staking and Interchain asset management strategies.

Our team believes in providing user-centric solutions that not only simplify crypto transactions but also optimize returns for our users. As the crypto landscape continues to evolve, FortyTwo stays committed to delivering innovative tools and services that cater to both novice and seasoned crypto enthusiasts, as well as corporates and DAOs.


  • Awaiting community feedback and suggestions to enhance the functionality and user experience of the Auto-compounder and to improve this proposal.

Target On-Chain Date: TBD

Note: The exact deployment date and other specific details will be finalized based on the team’s roadmap and feedback from community testing.


Hi. the contract code is not available at maybe a private repo?

Yes, it’s a private repo. FortyTwo has proprietary tech which is critical to keep private for now, but we have a path forward to make repos public once we reach certain TVL and Volume metrics.

Hmmm, there is a tendency to down-vote proposals with closed-source contract uploads in the past.

But as soon as you upload your code will be out in the open, right? Since the code of a smart contact can be queried if I’m correct?

Furthermore, how does this work in cooperation with this draft?

The binary and the hash of a contract uploaded to the chain can be queried plus some additional contract information as long as it has a defined set of queries in the contract logic but you are not going to be able to read the source code through those queries. You could try reverse-engineering the binary though.

Regarding your 2nd question, as part of our auto-compounder product, we will always look for ways for users to maximize their yield, being that auto-compounding incentives on top of pools, validator staking rewards or whatever other source of yield we can auto-compound for you.

Thanks for your reply!

Does that mean it will utilize the automatic staking as mentioned in the other post? Since the other topic already suggests automatic staking the LP rewards without users “interference”. And because it will be protocol-native, it will always be preferred in usage (automatically enabled also btw) over a smart-contract if I’m right. Or do you have some way to work with the new potential setting?

As part of our product offering, we enable staking rewards auto-compounding but only on certain validators that are compatible with authz authorizations (otherwise not possible), so we can think of a user flow where users get a suggestion to stake with these validators and autocompound their staking rewards.

Yeah, but I am wondering if the auto-staking from LP rewards to a pre-defined set of validators (delegator chosen) is already enabled in the protocol… whether there is much for you guys to restake on that area ^^