After taking some time to evaluate the past 8 months for Bao and put lessons here: Learnings from BAO
As well as with the sudden stop of our xDAI farming rewards, it was time to decide what was next for Bao. The community was overwhelmingly in favor of a soft synth proposal on Polygon: Snapshot
A few of the galaxy teams had been coordinating on a proposal for the following:
- A new franchise on Polygon.
- Built off of a modified version of PieDAO’s implementation of indexes using the Diamond Standard and our own custom built recipes.
- The recipe structure will source liquidity from Sushiswap, both as regular tokens and as LP pairs.
- The indexes allow for flexible strategies that mean when you buy an index your underlying tokens are automatically also used in yield farming strategies.
- These index tokens will also have staking farms similar to the Bao farming experience you are all used to, but instead of being an LP of two assets, they will be an LP token representing many assets where those underlying assets are also farming.
This means the assets will gain from farming the LP token, rebalancing on the index, and farming with the underlying tokens.
Why not Balancer V2?
We spent a long time working on customizing and configuring Balancer V2 and had actually deployed versions of their contracts to Polygon already before making agreeing that we should make a proposal to not move forward with Balancer.
There are a few important reasons:
1. AMM Risk:
I mentioned in our learning thread that most hacks that have happened in the past 6 months have been because AMMs (especially those with constant rebalancing) get exploited or had issues with one single token.
This means that the more tokens you add to an index the larger the risk of an exploit.
The index system we’re proposing is not AMM based, it is vault based. This means it isn’t going to be constantly rebalancing.
Instead, when people enter and exit the pool, they will do so proportionally via a Zap. The pools will then rebalance through keeper action on a set timeline/trigger (much more similar to TokenSets than Balancer V2)
This prevents any exploit risk by a single token, which means unlike pool based solutions we can actually be much more aggressive in support new and diverse projects.
2. Asset Managers
The Balancer V2 asset manager system is not ready to be deployed yet.
While that code exists it needs extensive refactors to even deploy to chain as it is bigger than the max contract size.
Unlike with the Diamond Standard, Balancer V2 is not modular. It cannot be added in easily later without migrating some components and it cannot take in simple standalone strategies.
The Diamond Standard lets us create a simple component now and easily move to more advanced strategies later.
We could launch Balancer V2 without the asset manager component, but that simply isn’t competitive in these markets.
3. Building Partners
As mentioned in our learning thread, our move to AMMs on sidechains led us in an awkward position once Sushiswap launched on those chains as well. We were essentially competing for liquidity with the partner whose assets we primarily want to support.
Balancer V2 is an AMM that would do the same.
The Diamond Protocol Indexes are vaults that would use Sushiswap as their liquidity source and bring us closer with Sushi.
We’ve underserved that partnership and I think its important we further invest in it.
There are some other small consideration as well but let me summarize those with bullets from the above:
- No AMM risk.
- Asset managers for underlying yield farming.
- Builds on and honors our partnership being able to use Sushiswap as a liquidity provider.
- The Diamond Protocol Indexes can be run on any chain where there is an existing AMM to partner with.
- The Diamond Protocol is a modular, expandable and upgradable contract spec system.
- There already exists excellent example asset managers from PieDAO that can be expanded upon.
- Since our Index Recipes can plug in to multiple AMMs this means on xDAI and BSC we can source both from Sushiswap and Baoswap/Pandaswap providing value to those AMM systems.
- The Diamond Protocol Indexes could be reworked to run ontop of a Balancer V2 instance in a seamless manner if we ever decide we need those additional features.
- The Diamond Protocol Indexes can still provide time based or conditional based rebalancing similar to TokenSets.
- The Diamond Protocol Indexes limit and in some cases entirely prevent IL in pairings.
- Because the system is modular we can build out future integrations including strategies that used advanced vaults like Yearn or build indexes solely out of LP pairs.
- Because of the Diamond Protocol’s upgradeability it is easy for us to add, remove or adjust fee models for integration with other Bao projects without a full migration.
- The Diamond Protocol Indexes require less infrastructure overhead than the Balancer V2 port and so in the future we may be able to deploy that to any chain or L2.
- In theory, the Diamond Standard being modular means we may be able to build our synth protocols directly into this existing contract without needing separate deploys, this would be a much more unified experience.
In order to enable rebalancing easily we needed a low gas environment but we also need an environment with lots of users and liquidity, and existing AMMs.
xDAI’s overall user base and volume has been low. While we still like xDAI and plan to support it and hope it continues to grow it doesn’t make sense to build out an index tool there right now, especially since many projects haven’t bridged over there and so index options would be limited.
BSC has shown to have major infrastructure problems when it comes to RPCs and being able to run your own indexing nodes. While it is stable enough for users, things like analytics sites, APY calculations and other important tooling isn’t as reliable there.
While we hope to launch our indexes on both these chains one day we still need more development to progress.
Of the remaining chains we knew that there were a few priorities:
- Professional grade nodes and RPC
- Professional grade oracle support
- High liquidity
- Large userbase
- Sushiswap support
- EVM (with no modification)
This left us with Polygon who has:
- Infura nodes
- Chainlink oracles
- Rapidly growing user base
- Sushiswap supported and major liquidity
- Yield farming opportunities.
- Most major assets bridged across.
- Decentralized bridge infrastructure.
- Standard EVM.
This meant that currently as far as sidechains go, Polygon is not only the right option, it is the only option for what we need right now.
If the tests on Polygon are successful we would likely next focus on bringing this to an L2 as we have already been in touch with at least one L2 developer about that.
What is the Diamond Standard?
Diamonds (EIP-2535) are a protocol designed by Nick Mudge (EIP-2535: Diamonds)
Similar to how L2s write to storage contracts on an L1 chain, the Diamond Standard allows you to make a modular smart contract of almost no limit size by writing functions to the memory of a single address to map to interactive modular facets that complete the functionality.
The Diamond standard is a pretty complex piece of work and its not seen a lot of adoption because of this complexity. It’s currently used by only Aavegotchi, Barnbridge, PieDAO and Gelato.
You can imagine it as a way to let many small smart contracts work together as one large smart contract but be constantly upgradeable and expandable. Which is remarkably powerful.
What about PieDAO?
PieDAO is a fantastic index product run by a community as well.
They’ve created a vault factory that stores information for multiple pool holders mapped into the Diamond Standard.
This component which is licensed under the open source MIT license is what we would be using.
The real magic however in these products comes from the ‘recipes’ (the components of what makes up an index, how it is acquired, and the other protocols it interacts with) and the ‘asset managers’ (how those underlying assets are deployed in yield farming)
If we stick with the analogy of pies, we’ve essentially went out and got an open source pie dish that allows us to make and store our own pie.
We’re still going to need to come up with our own crust, our own filling, recipe and process and decide on all the ingredients. We don’t think its the right idea to simple clone all of that from PieDAO, especially when indexes are not our endgame, so we’re just using the pie dish.
Beyond that, I did reach out to a member of the PieDAO team to start conversations on exploring partnerships to work together on our efforts, as I believe we are always better by combining forces rather than competing.
While I haven’t heard anything back yet, I do think either way that we should have some governance proposals to buy some PieDAO $DOUGH, as well as consider having some of the amount of the fees we generate from our indexes being used to buy $DOUGH.
That likely seems odd to many as most projects who reuse part of open source code wouldn’t make such payments, but I think it is the right thing to do and that we will go further if we build bridges. Our main goal long term is not to compete on indexes with PieDAO but to make sure we have the infrastructure we need for a portfolio of synths, and while we will only be using a component of their work I think it is important that we value and respect the hard work, efforts and innovations they put forward.
I also still hope they reach back out and we can continue to find more ways to work together, as I think they are a great technical and design team, and we’re a strong community, economics and product team. So while there is no formal partnership there now, I think both DAO’s should welcome that opportunity in the future.
What are we naming this franchise?
While the community galaxy team has a proposal on name and design for this franchise, I’ve suggested that we don’t include it in this proposal and let it be a surprise given that every time we’ve released a name beforehand other projects have ended up using it.
Would this be a franchise?
Yes it would be a franchise with its own token and a portion of the tokens vault locked for the Bao token holders to own by proxy with thresholds on when the DAO could vote to sell and distribute those tokens.
How could this use Bao?
We would need to work on more refined proposals after launch (which we can thanks to the Diamond Standard) but our indexes can include Bao in them, or the ‘recipe’ to create or redeem an index can charge a Bao based fee in the background.
There are many other ways to integrate Bao into the economics of this system as well and the community is welcome to make additional proposals on that.
It is important to remember though, that indexes are not our final product, they are a utility for synths which is where Bao’s main tie in would be.
Will this get launched on mainnet?
Our first focus is getting this deployed successfully and running on Polygon.
After that the DAO can vote on additional paths forward.
If this runs smoothly on Polygon then there is no reason why we can’t release it to our other chains including mainnet or at the very least some sort of L2.
What is the timeline for launching this?
The maintainer galaxy is still working through components of the deploy process and security tests, and the frontend galaxy is currently working on new front-end integrations.
Plus, we still need time for the governance process.
If everything goes smoothly we’re likely looking at a few weeks to get something live, but as always it could take longer.
What are the next steps?
This concept discussion will be open for the next few days for comments and questions. Then it will move to a formally written proposal in the ‘Proposals’ section of the forum where the final language of the governance proposal will be available for review for 3 days.
After that we’ll put up the formal snapshot vote which will last for 7 days.
Various galaxy teams will continue to work on detailed proposal elements and integrations in the background as well as proposals for initial indexes.