Upload Banana Vaults Contracts


This proposal will add the Banana DAO’s designated Osmosis outpost contract address (osmo1622a2new62qlyr7ke8g6sv23emspv6zlt3kjkwx84xfax6xulugq3wdkdx) to the list of those authorized to upload CosmWasm contracts to Osmosis, in order to upload the core Banana Vaults contract and any required updates to the vault contract. In the future, Banana DAO may seek to upload additional contracts to improve and extend the functions of Banana Vaults. If this is the case the DAO will seek approval for each specific contract.

How does it work?

Over the past 6 months, Banana DAO engineers have been working on creating an automated protocol for optimizing Osmosis Supercharged Liquidity yields. Banana Vaults represents the culmination of those efforts.

The Banana Vaults contract serves a similar function to other vaults. It is a repository for deposited funds and allocates shares based on deposit value. The contract’s operator computes the optimal ranges for the liquidity on deposit and sends instructions to the contract to move the deposited liquidity into the specified concentrated liquidity position. For simplicity, the current contract serves one Osmosis pool per vault. More information on the vaults can be found in the docs link at the bottom of this post.


As the contract, and Osmosis Supercharged Liquidity which underlies it, are still new technology, the initial beta rollout will have tight deposit caps The DAO will closely review performance and safety over this period, and a security fund will be established. It is expected that the beta phase will last between 1-3 months, after which deposit limits will be gradually increased at the DAO’s discretion.

Future developments

There are two planned improvements to Banana Vaults intended to be ready shortly after launch. The first is a wrapper contract that will allow liquidity providers to access multiple vaults (Osmosis pools) with a single deposit, to be optimally split between them. Relatedly, vault tokenization will be implemented to allow liquidity providers to more easily enter and exit vault positions, and allow further derivative use of vault assets.

What is Banana DAO?

Banana DAO is a decentralized bunch of buidlers, degens, and idea havers whose individual contributions to the Cosmos Ecosystem include core development, apps on several chains, and numerous public goods.

On Osmosis, Banana DAO as already made an impact by shifting incentives towards lower swap fee pools, with the goal of increasing liquidity efficiency and protocol revenue.


Contract: https://github.com/banana-dao/banana-vaults
Docs: Intro - banana DAO


I support this proposal because it enables Banana DAO to enhance liquidity optimization on Osmosis through the deployment of Banana Vaults, fostering innovation and efficiency in the ecosystem. The proposal’s cautious approach with tight deposit caps and a security fund demonstrates responsible governance and risk management.

1 Like

Since this is an “Outpost” does Banana have a home chain/DAO deployment? Is there a multisig interface where deposit cap increases/new vault additions can be viewed?

Glad that someone is open-sourcing this code for regular users - as a random user I would probably be unlikely to use this since it isn’t clear who runs this, but I recognise at least one of the main Contributor’s github names.

Does Banana take into account the wider positions that will be required post-uptime incentives? I.e. in a highly volatile market the optimal position might be quite wide, or does it purely focus on maintaining single tick range liquidity and offsetting the realised impermanent loss through fee collection?

The on chain DAO itself has not been launched. We are still deciding between a deployment on a permissionless CosmWasm chain for our custom DAO contracts, or a sovereign rollup or chain. Given that the DAO has no grants or outside funding, we are hoping to use revenue earned from this initial vaults deployment to bootstrap our core development.

Changes to the deposit caps and additions of new vaults will be undertaken by proposals enacted by the uploader/outpost contract on Osmosis (given that this will be the admin of the vault contracts) and should be viewable using its DAODAO interface

As the vault contracts are still new we aren’t looking to promote this to a wide userbase immediately, hence the closely monitored initial beta phase. More info on Banana DAO and our efforts will be made available as the DAO is fully launched. I anticipate this will happen before Banana Vaults comes out of beta. A general roadmap can be found here.

Concerning tick ranges, we currently use a volatility index to determine if a given tick width is acceptable based on the cost of rebalancing. With the amount of liquidity currently deployed, narrow tick ranges are often most effective, however as the vault TVL increases it will be possible (and prudent for liquidity robustness) to employ wider ranges to capture the maximal amount of fees in times of volatility. As discussed elsewhere, reasonable minimum uptimes shouldn’t initially impact our operations much but we will need some empirical data and will adjust accordingly if necessary.

1 Like

Is it also possible to highlight a bit on the performance of the current vaults? Because I understand that currently you are already running the service (succcessfully)? What is the added value if we upload the contract on the Osmosis chain?

The goal of uploading the contracts is to make automated liquidity management more accessible. I would refer you to Quasar as an example of a similar product already on Osmosis.

It’s hard to predict performance as it’s highly dependent on market conditions, and the public vault product will not be exactly as performant as theoretically possible due to the need to exercise extra caution when dealing with deposited funds. Actual APR data will be available on the Banana Vaults UI shortly after launch.

1 Like

With this you mean that the positions will be slightly wider compared to the theory? To make sure people using the vault get returns on their deposits?

Referring to limiting the costs of rebalancing (swap slippage, fees, impermanent loss) so that we don’t actively lose money. Of course, funds will be exposed to market conditions but we want to ensure that our strategies don’t cause undue loss

1 Like


I am all ears for enhanced competition.

I am not able to assess the quality of contracts though, is there something done on that field?

1 Like

An audit of the current mainnet contract will be available shortly after launch, and we plan to rigorously test and audit any improvements going forward.

So to make a long story short; we are going to approve a contract where an audit will be done AFTER it has been uploaded?

Have there been any checks from outside the banana-team on these contracts?

I understand your concern. However I feel your “short story” to be inaccurate. Given that the initial launch will be tightly controlled, we judge the risk of proceeding before the audit is finalized to be acceptable, and of course anyone participating will be informed of such risk. It is important to remember that an audit cannot catch all vulnerabilities. To quote Oak Security: “A security review is no substitute for other best practices and should be accompanied by a security-focused design process, extensive unit, integration, and end-to-end testing, internal code reviews, bug bounties, secure development and development processes, as well as strictly followed operational security processes”. This is why as mentioned we will be prioritizing building a security fund. Unlike a security fund, an audit will not reimburse users after an exploit or pay bug bounties.

It is also important to note that in the case of giving permission to an address to upload instead of a specific contract, the final code that is uploaded doesn’t necessarily need to be what was audited. The case where an audited contract was changed before upload causing tangible harm to users has already occurred at least once that I am directly aware of. Furthermore, the total number of codes uploaded to Osmosis is 565 as of this writing, meaning that roughly 500 contracts (including upgrades to existing contracts) have been uploaded without specific approval. It is almost assured that this will include a decent amount of unaudited code.


To be fair, the audit for Nomad bridge caught the specific thing that ended up draining the entire protocol on Evmos, and marked it as “insignificant” at the time.
Audits miss a ton of stuff all the time, and the amount they charge is astronomical… it’s one of the main things that is seriously inhibiting development in this sector IMO. Of course always DYOR and if you are uncomfortable with what you see, or you don’t understand, etc then maybe re-assess whether you would like to take that risk.

Nomic, which has been operating for quite a while now (not in full capacity obviously) has around 7BTC locked up, and a hardcap on deposits of 21BTC. This has been fully integrated and is traded on Osmosis since launch with no mention of this, and nobody really thinks otherwise.
However in my opinion they are doing this “in-production” development in the correct way,. Taking it slowly, testing as much as possible and placing sensible limits on deposits to maintain a managable level of both activity and attention (potentially from any baddies).

I imagine a ton of other projects and entire blockchains also are not audited. It’s kind of just a risk that most of us take every day without realizing it. A smart contract is no different.


Point taken!

I also learned from @maxpower that the code is open source (which is also good imo).

And you are totally right about the addresses which are whitelisted and are able to upload any contract without any barrier.

Just check-check-doublecheck, the code is running off-chain for a while already I think?

1 Like

The liquidity management algorithm has effectively been in production for months at this point. Our main security concerns surround the actual vault mechanism itself whereby users’ shares are assigned and tracked. This is the likely avenue for a potential exploit. However this risk will potentially be completely mitigated in our planned future update to a tokenized model, which will negate the need for outside parties to interact with the vault directly.

I believe this was addressed above. If you’d like clarification on a specific point I’d be happy to provide.

Thanks for offering info on topic, but I figured it out. Thanks again.

This proposal has passed in the meantime :slight_smile:

1 Like