- Please remember the community will vote on all changes, features, announcements and proposals in this blog through governance vote. Details might be changing if the community votes differently.
PandaSwap + Farms:
As everyone has been waiting for it is finally time to start the community approved rollout of PandaSwap and Panda Farms.
The last of the contracts have gone out on the BSC chain. We expect the UI to be up in the next few days on farms.pandaswap.xyz and then actual farms will start on Monday specifically at block 6906900 (👀 nice!)
The PNDA token is at: 0x47DcC83a14aD53Ed1f13d3CaE8AA4115f07557C0
Because we know that Binance Smart Chain has a different user community, we’ve worked to make some changes to the Panda farms and PandaSwap to better support the tools these community members use, and so going forward PandaSwap and Panda Farms will both support new wallets including WalletConnect, Binance Chain Wallet, TrustWallet and MathWallet.
We’ll also work to ensure that these wallets will be added as supported wallets to other Bao Finance products in cases where that wallet supports other chains like Ethereum and xDAI.
Starting today we’ll be dripping $PNDA tokens into the PNDA/BNB pool on Pandaswap.xyz creating liquidity for users who want to set up their LP tokens ahead of time.
We’ll drip out 1M $PNDA tokens from the initial issuance with 200k of them being added each day between now and launch. As a reminder to users, this is a small fraction of the total tokens and so it will be highly over inflated and is meant for users to be able to set up their farming and staking early.
You’ll be able to create your LP tokens on PandaSwap as of today and get them ready for depositing into the farm UI when it launches in the next day or two.
Panda Changes:
In our governance vote we approved a large number of pools and specific mechanics for the PandaSwap rollout, however, some of those have had to change due to the following reasons:
- Security issues with certain coins, or those coins being scams had the removed from planned pools.
- Due to trouble BSC has with lots of block information indexing for stat sites, we needed to reduce the number of pools we were using to keep the site stable.
- After reviewing the contract code for each farming asset, we decided to be safe we should remove or minimize the number of pools containing assets that have governance control that include infinite minting, forced transactions, freezes or reclaims, as this could impact the contract.
- The initial week of Panda was supposed to have 0 rewards allowing time to get ready, but having a 0 value here would have caused math problems for the system, and starting with a low number would have altered the tokenomics. So the current version of the contract goes straight into rewards with the 2048 multiplier starting in week 1 which changes the chart to look like the one below.
All of these changes will be approved in an additional emergency governance vote over the next few days to ensure they are approved by the community.
Panda as our Playground:
Many people asked, that since our main goal is to build synthetics with LP assets from partners like Sushi on xDAI, why are we spending time on Panda?
There are two causes:
- We want our synths to be accessible across chains. To be on many chains a synth needs strong liquidity pools on different chains to support liquidations.
- We needed a testing ground.
We had decided not to build our synths on the main Ethereum network right now as it is just too expensive for users, and so we migrated to xDAI and linked Bao to xDAI using our Bao.cx coupon.
This meant anything we do on xDAI impacts the mainnet tokenomics for Bao, and so it didn’t make sense to make risky experiments.
But, as we started to design synths, it became clear that a lot of the economics for making robust multi-collateral synthetics were theoretical and not things that have been tested in real environments by teams.
We saw a lot of unexpected behaviors in how users used the initial Bao Finance farms, which were designed so we could monitor liquidity behavior for the synth protocol. But this means we need to do the same sort of testing for other features.
That is part of why in the design proposal for Panda, I suggested the franchise model.
Panda on BSC sits on its own chain and has its own governance token. The Bao community owns a portion of that token locked in a vault and has governance control over it.
If Panda is successful, then the Bao community prospers from the experiments both in new technologies but also potential value flowing back into the Bao ecosystem.
If Panda has glitches, failures, bugs, or problematic code in new features though, it is separate enough that it doesn’t harm the main Bao ecosystem.
For this reason, we can view the Panda ecosystem as the playground for Bao. Meaning we can move much quicker, launch experimental features, try new features faster and experiment with parameters and riskier models on Panda before bringing them to Bao.
This means we expect PNDA, Pandaswap, Panda Farms and any sub projects or features launched on BSC to be much higher risk, quicker changing and more experimental than regular Bao products. They should be treated as if they are always a high-risk alpha/beta experiment and not assumed to be stable.
While we’ll still have a governance process for Panda, we’ll also make an accelerated proposal model for proposals to be deployed more quickly into the Panda ecosystem and give elected community representatives (currently called “Core team and external teams”) a bit more room to make quick changes and deploys in this ecosystem compared to Bao.
On Bao’s ecosystem we’ve been one of the projects that moves slowly with caution and security. Our community thinks that is important, especially in a decentralized project run by anonymous team members. We’ll continue to have this practice of best in class security and planning on Bao, while letting Panda be like our crazy cousin off to explore the wild west.
Panda Tests:
Given that Panda will be our testing playground, lets outline a few of the tests that are ready to roll out either at launch or in the next few weeks.
Most of these are what we call ‘sub-products’ they are like modular standalone features that can be added to or removed from any Bao Finance product in the future.
While each product in Bao is represented by a Bao in a costume as a logo (like Panda), sub products fall into two categories:
- Items: Subproducts that make idle assets intended to be held in a wallet or used for a set purpose are represented by items. These have simpler mechanics or use cases in other Bao/Panda related products.
- Creatures: Subproducts that are new complex features or entirely standalone features that expand the Bao/Panda ecosystems are represented by creatures (like a Rhino or a Robot) and their logo is a cute creature that is not a Bao in a costume. This is a sign that this is a complex subproduct that has complicated mechanics and drastically changes parts of the ecosystem and should be actively interacted with.
High level the following subproducts are ready to begin roll out and testing at different stages:
- Bamboo (xSushi style staking for swap rewards)
- Rhino (complex liquidity staking for Panda)
- Ponds (a soft synth index product for Panda)
- Robo (an automatic farming vault system for Panda)
Bamboo:
Bamboo staking is like xSushi style staking for Panda. While Bamboo is fast growing, it is also flexible and forgiving. It’s easy to move in and out of Bamboo staking and there is no penalty for using the Bamboo maker.
Users will be able to stake their Panda as Bamboo from both the Panda Farms and Pandaswap interfaces.
Just like xSushi the Bamboo pool is on a curve where the amount of Bamboo a user gets starts off equivalent to the amount of Panda they put in, but changes as the amount of Panda held in the Bamboo maker grows.
The Bamboo maker receives fees from the farm contract and Pandaswap trades. Any one can call the Bamboo maker contract at any time to convert the fees it is holding. When the convert call happens, the Bamboo maker takes the fees it earned in different currencies and uses Pandaswap to trade those fees into Panda and Rhino (outlined below).
The Panda purchased is then allocated proportionally to users holding the Bamboo and when they redeem their Bamboo they’ll have a higher amount of Panda than they started with.
The Rhino purchased will be burned.
Rhino:
Unlike Bamboo, Rhinos are strong, sturdy, stubborn and defensive. They like to stay put and they love to protect their territory.
As the goal with Bao products has always been to incentivize long term stakers and robust liquidity, the community noted the need for ways to incentivize long term locked liquidity that has strong incentives for using it long term, but penalties for removing it, to create stability in the ecosystem.
For this experiment we’re proposing Rhino.
Many users on BSC are familiar with the (now likely rugpull) called Safemoon. While this project itself was not good, it used some interesting concepts in managing liquidity.
We had been following the code, and the projects it was based on for a while before the project even got famous to evaluate liquidity lockup incentives, and worked on our own fork that makes improvements to the Safemoon model to remove the ponzi elements and bad code, while keeping locked liquidity rewards.
Panda users will be able to choose to convert their tokens to Rhino, using a modified 1:1 swap contract that has a 2% fee in both direction, with a fee that goes to a liquidity pool.
The Rhino LP pair on Pandaswap will have one of the highest rewards on Panda farms (even higher than most Panda pools) and will receive a portion of Pandaswap fees through buy-and-burns from the Bamboo maker which buys Rhino. This will make it the highest capture point of the ecosystem in earning various governance token rewards.
The catch is that Rhino trades incur a 12% penalty.
Of that 6% is added to the LP as permanent locked liquidity.
Another 6% is distributed back to Rhino holders.
However, to further this burn effect, 50% of the total supply of Rhino will be burnt at the start to the ‘dead address.’ Since it will be counted as a Rhino holder, each time there is a fee on Pandaswap, or from the Bamboo Maker buying Rhino, or from anyone buying or selling Rhino, then a 3% fee is essentially burnt.
Since the only way to get Rhino is from the 1:1 swap, every time 1 Rhino is burnt that means 1 Panda can no longer be claimed.
We’ll also drop this penalty over time. For the first 6 months, we’ll lower the 12% by 1% for each month until it reaches 6%. After that it will be lowered by 2% each year until finally the fee no longer exists.
When token projects like SafeMoon and SafeMars launch tokens like this without any other purpose or products, its a clear money grab that makes people interest with ‘reflexive earning’. But, that doesn’t mean the mechanics aren’t useful.
By integrating these into the Bao ecosystem we can create a two tiered governance reward system. Unlike other protocols, earning Rhino isn’t just about earning Rhino, as Rhino is just a holder for your Panda governance tokens.
Instead, this means that users who lock up their Panda longer term and expose themselves to a set exit penalty and put some permanent liquidity into the pool earn their governance tokens from staking and from proportional governance fees. It is like earning Panda from 3 sources instead of just one.
It allows users to choose their level of risk and commitment to the ecosystem and its liquidity, in exchange for deciding how quickly they want to acquire governance tokens from Panda.
The Rhino experiment is risky and volatile, but self contained where community members can decide if they want to opt in to this higher risk experiment.
What we are trying to establish is:
- Will incentives and penalties convince people to stay in liquidity pools longer, which can give stability and floors to small synths that normally lack enough liquidity to trade?
- Can the incentives and penalties be fine tuned to reduce volatility enough that we can have a lower collateralization rate needed for synths?
- Can a partially locked liquidity pool create enough of a liquidity floor that even if an asset is crashing and people are leaving the pool, the pool has enough of its own liquidity to safely liquidate bad synth positions without risking the protocol?
- Are people willing to opt in to a second level system that burns governance tokens at a higher rate if ti means they also get more governance tokens but also take on more risk?
We don’t expect that Rhino will succeed in all of these but even when an experiment fails at a question we get valuable information on how to improve the process and get it right.
Ponds:
Perhaps the biggest surprise that we have is that the first version of soft synths are nearly ready.
We’ve already deployed the soft synth contracts to a test net and been running tests on the infrastructure.
Based on a blend of custom code and Balancer, this is the core code we plan to use for Bao Baskets which we didn’t expect to have at a test stage until at least the end of May.
One of the challenges with the Bao Basket plan is once again not the code, but the fine tuning of the economics. Most teams run simulations before launching projects with delicate economics, but people don’t behave like computers.
So we are going to start slowly building out a test of Bao Baskets on BSC that we’ll call Ponds.
We’ll use the Panda ecosystem to power it, and focus on testing with low value soft synth indexes at first. We’re proposing to the community that the first index could be something like “Memedex” a simple index that is an index of meme coins that are available on BSC.
Over the coming weeks we’ll deploy Ponds to BSC, initially without an interface, and begin to run small tests with advanced users directly interacting with the contracts until we’re confident that we can scale it up.
To start Ponds will not have any incentive to use it and will only be a testing function. Once we’re confident in its scale, we’ll deploy a user interface and create Panda Farms that reward people for staking the synths they create in ponds. Once we test that for a few weeks we’ll be able to roll out versions to other networks to power more complex indexes and reward systems.
Robo
Robo is the subproduct that is still in the earliest stages but that we are ready to propose.
We know that users on chains other than Ethereum are used to automated farming, but that most automated farming contracts are not designed to support complex ecosystems, synths, indexes, or protocols that have a penalty fee.
As you know Baos stands for Balancer Automated Options and Synths, and this is the first stage of building out that automation.
Robo will be system for users to automate vaults automatically in the Bao and Bao franchise ecosystems, with strategies that any developer can design and contribute.
You can think of it as YFI+AutoFarm but for the Bao ecosystem. It will allow users to create automatic compounding, farm switching, LP rebalancing and other complex strategies.
The very first version of Robo will be on BSC and integrate with Panda for automatic compounding of farming rewards.
After some testing we’ll open up a strategies module and roll out versions of Robo on each chain.
Our intention is for either a V2-V3 of Robo to integrate the Gelato Network and arbitrary network bridges to let users manage their vaults on all EVM networks from one wallet. Meaning in the future Robo will hopefully be able to manage balancing your mainnet, xdai and BSC positions back and forward for you.
While Robo will exist to make the lives of users easier, its main priority is to actually act as an automated crosschain liquidation keeper. Robo will automatically identify synth positions that are over their liquidation amount and leverage a strategy to gracefully unwind them by selling the liquidity across multiple swap sites on multiple chains in order to get the best liquidation price at the least impact. On the backend Robo will also leverage its own instance of Hummingbot to arbitrage the slippage of these networks against centralized exchanges, allowing us to manage much larger positions than other onchain protocols. This was why we set up such a strong funding grant for new features for our friends at Hummingbot.
We expect to have very basic versions of the V1 of Robo ready for BSC auto compounding in the next month or so, but the more complex cross chain automation is something that is a larger vision that will take time and a number of development versions to reach.
Right now, we don’t plan to have Robo have its own token, it will simply be a feature that can be used within the Bao Finance ecosystem and all of its franchises, but we’ll continue to evaluate this as often cross chain infrastructure needs to be able to incentivize validator nodes and pay gas fees on two different chains so some sort of functional utility token may be needed in the future but ideally we’ll leverage Bao and Panda if we need to do token payments for Robo.
NFT Badges:
We announced the other day that we took snapshots for the first claimable NFTs that users will be able to claim.
These will be rolling out over the next few weeks with more details to follow.
We wanted a way to reward participants in our ecosystem for the contributions they made to Bao by being a contributor, a community member, and a participant in our ecosystem, as well as to think of ways we could better encourage people to take part in the community project rather than try and treat Bao as some speculative token.
To do this we’re designing NFT badges.
Badges will be a type of NFT that users in the Bao Finance family of products can earn. Some will be transferable, some won’t be.
Badges will be earned by completing various actions, completing achievements, or contributing to the ecosystem.
In turn, all future versions of Bao products will start to look for the different types of Bao Badges in a users wallet when interacting with the product.
These badges will allow users to unlock extra product features, reduced fees, early alpha access, higher rewards and other types of bonuses that we are still exploring. Some other badges will just look cool and unlock bragging rights.
We’ll have another blog post exploring badges more in-depth, and revealing the two upcoming badges that we already took a snapshot for, as well as what other achievement badges are upcoming.
Decentralization Process:
One of the most important things for Bao is continuing to expand the decentralization process.
In part of this, we’ve recently trialed a new Baonty program to encourage more outside development, and started to structure our community into what we’re calling “Galaxies”
Most projects are “Solar Systems” where there is a leadership team that does all the work, comes up with all the ideas, and manages everything. Any one else in the community revolves around them. Some element of that is impossible to avoid in the start.
We want to operate more like “Galaxies”. Galaxies are collections of solar systems inside them, where different teams may have a leadership structure for the project they are working on but that is independent within a larger galaxy and within the larger universe.
While these galaxies move in clusters and may interact with each other, they are distinct and independent. Yet they still exist in the same universe, and move towards the same goals.
We continue to make progress in this model by:
- Refining our governance model in having everything approved by community vote and having a proposal process.
- By ensuring we treat ideas and code from the core team as regular proposals from users that the community still must vote on to approve and accept.
- By starting to create galaxies.
We think of galaxies as a clustered team who works together for a specific goal, like our Community Team.
A team may be volunteers, they may receive a grant, they may have on going Baonty funding, or they may be paid by others in the community who want to see more contribution to the Bao ecosystem.
The teams work together towards a certain goal, in the case of the Community Team its managing our community and educating them.
Initially the plan was for this team to report into ‘the core team’ (Baoman and Rocky) but that doesn’t create the structure we want or properly support external teams.
So now it is its own galaxy that is self run by the members of that team. While they communicate with Baoman, it isn’t under his direction or control and often he doesn’t know the initiatives they are pursuing. The Community Galaxy instead sets their own goals and steps to achieve them.
For things they create to be accepted into the ecosystem it goes through votes. If they want to extend additional funding, that goes through votes as well showing the community that they’ve reached important goals and milestones.
In the same way, the community team often doesn’t know what Baoman is working on or proposing until the rest of the community does, except in rare cases where it is needed to get documentation or designs ready.
For the ‘Core Team’ we’re renaming it to the ‘Maintainer Galaxy’ the maintainers have a few special permissions that the community grants them around keeping the ecosystem running, such as managing servers, contracts, deploy processes etc. But, just like all other users their product proposals come up to vote before being executed.
As we expand out this galaxy concept, in future Baonty applications, users can apply for Baonties for individual contributions, one time projects, short-term galaxies or long-term galaxies.
Some galaxies may come and go. An external team may come together to form a galaxy for a one time project and dissolve it once it is no longer needed.
Some galaxies may be rewarded when it needs full time specialty skills, has set costs, or is worthy of a small bounty. But, many of them will be volunteer based contributions.
As we shift our governance towards this model, we also plan to integrate Gnosis Multisig processes and the new Gnosis version of Snapshot that will replace the timelock, so that we will not need to create multisigs and instead can govern the entire ecosystem directly by community member votes and not need to have set officials with signing authority.
We’ll all continue to work together over the next few months to better build out the processes for galaxy based governance.
But so far it has gone well. Over this past two months Baoman stopped giving direction and insight to the community team and stepped back to let them fully self manage. Despite not telling them about this at first, the community team came together and began to self direct building new documentation, overhauling chat channels, working on partnerships and new community initiatives. This ended up being more productive than ever before and shows how strong this model can be.
Many projects try and become centralized by having community members vote for representatives, but I think we can build an ecosystem of temporary galaxy clusters that come and go and that this is the best way to have a long life time.
Then in the future if there is no need for a team as Bao is self sustained, all the galaxies would dissolve until a time when there are problems to solve and then the community can directly vote on putting together new galaxies.
This is how we build products and systems that outlast us.
The $1M Baonty Fund:
To end our discussion we should note that the Baonty program that we put out through Gitcoin was a big success giving us new upgrades and updates very quickly and affordably.
Because of this, I am proposing a $1M Baonty fund for the continued growth of the Bao ecosystem.
We will continue to work on a governance process for Baonties but right now the idea is:
- A requested Baonty is something that the Bao ecosystem needs done and we will post to Gitcoin.
2. Community members can propose that we create a Gitcoin Baonty for something even if they can’t fulfill that Baonty themselves.
3. Individuals may also create requests for a Baonty that they want to work on full time (the community member must have already made open source or volunteer contributions to the community to be eligible for this)
4. Individuals may request Baonties for a short term or long term galaxy.
5. Individuals may request a small Baonty to cover costs of maintaining infrastructure related to Bao or its franchises.
Baonties are focused on covering costs, full time work or full time contract work.
Small part time contributions are not normally Baonty eligible.
The minimum size for a one time baonty is $2500. Tasks under that size will not be eligible for baonties.
Concluding:
That is all the announcements for now!
We have made lots of progress in the world of Bao and have exciting times ahead with our new Panda playground, new features and new processes.
I am very proud of what our community is building. Many other projects may build things fast and flashy but that is because they are centralized. Taking the time to do things the right way is hard but it is worth it. :)
