Expanding Governance Decentralization and Process

Currently users vote on all matters.

But I’ve been reviewing how we can continue to have technology that matches our values to better create processes that keep Bao secure and decentralized and encourage other participants.

For this I am proposing a governance and process megabill that will:

  • Further decentralize decision making.
  • Define clear contributor processes.
  • Rework the management of the treasuries.
  • Clearly define properties ownership within the DAO.
  • Clearly define governance process within the DAO.
  • Kick off phase 2 of our roadmap.

From the point of this governance vote passing, we’d have an aim of integrating each of these changes within a 3 month time period.

For this reason, some elements are clearly defined with preset structure, and others are just commitments for us to work with the stakeholders to define and implement that process within that time period.

Section #1: Defining Roles

The DAO shall consist of ‘members’ who are Bao token holders. The members proportionally vote on the decisions for Bao.

Core Team:
Due to the logistic challenges of having members vote on every small decision, the members will in turn vote in a ‘core team’.

The core team will act as an elected management for the project, serving for a period of two-years or until recall by the DAO.

Their goal is to:

  • With the feedback and involvement of the DAO, set a product direction and plan. The core team is not defining the product direction, but acting as a curator to organize, vet and clarify the ambitions of the DAO.
  • Create and maintain a clear and secure process for contributing to the Bao products via open source.
  • Managing and maintaining core infrastructure that can not be directly held by the DAO (such as domain names, servers, logos and trademarks)
  • Reporting on the DAO’s treasury budget.
  • Managing other team members that the DAO has hired.
  • Bringing forward established binding proposals to the core voting section of Bao’s Snapshot voting.
  • Holding a veto authority over community votes that they feel are detrimental or damaging to the community (can be over-turned by a 2/3rds majority vote with a >30% quorum)
  • Being multisig holders for the deployer and treasury wallets.

Community Team:

The Community team shall report into the core team. The DAO shall vote in by core proposal a head of community management and operations on a yearly cycle or until recall, or dismissal by the core team.

The team shall also consist of volunteer or compensated Community Managers who help to manage the various social assets (such as the Discord, Docs and Forums) for Bao.

The goal of these individuals are to:

  • Maintain the social channels in an orderly and helpful fashion.
  • Establish and maintain avenues of support for using Bao’s products.
  • Establish, keep and maintain up to date documentation that supports Bao users.
  • Create and deploy information and content that helps users learn about Bao.
  • Support in managing governance and contributor workflows where applicable.
  • Enforcing community rules and orderly governance.

To ensure decentralization, these roles are their own separate entity from the Bao core team. While the core team can remove the head of community/operations, they do not have the ability to directly remove Community Managers. It must be done by vote between the core team and the head of community; and while the core team can remove the head of community, they cannot replace a new one without a broad vote.

The members of this team are not given privileged development information except in rare cases where it is required to do their jobs (such as using an alpha product to create documentation).

BaoFriend is an unofficial rank given to contributors within the Discord and community.

These individuals are ones who have demonstrated they are helpful contributors to the Bao community at broad either in their support of the community or in their technical contributions.

They serve in this role by vote of the core team, the community managers and the head of community/operations. The expectations for their role vary, but they often hold this role so long as they remain active, set a good standard for community behavior and continue to contribute to the product.

Given their arms-length role and lack of compensation. They are able to neutrally serve as a multisig holder.

External Teams:
External teams are any team, individuals, or entities that have put forward a budget or build proposal and been approved to work on developing Bao in exchange for payment or bounty.

These teams do not have decision authority of any type. They serve at the pleasure of the DAO. Their day to day operations can be overseen and reviewed by the core team, who has the ability to pause their work and bring forward a community vote to end the agreement if they feel there is an issue.

It is possible for external teams to create a positive and long-lasting/recurring relationship with the DAO where they become a primary services provider. While this is allowed, the core team should take measures to ensure that there are clear transition and contingency plans for the assets developed and maintained by these teams, so that no critical components can be used to hold the DAO hostage to an external entity.

All products external teams deploy should be governed by the DAO and a multisig wallet.

Small features and contributions are not eligible for development bounties and should be built out by contributors. The goal of allowing external teams is to allow an avenue for compensating entire development teams to build out robust extensive product features (or new products) in the Bao ecosystem.

Contributors are what make up the bulk of Bao. Volunteer contributors, both who contribute to the code through Github, but also to governance and product decisions in the governance forum.

These individuals do not get paid for their work but instead are a critical component of building Bao which rewards them for their efforts through the growth and adoption of the product.

In cases of exceptional consistent and on-going contribution, the core team may choose to provide a bounty to some contributors from the community fund.

Section #2: Securing Decentralization
To secure our decentralization the Bao DAO will seek to:

  • A) Establish two multisig wallets.

One multisig wallet will consist of 4 members of current teams (2 core team members, 1 head of operations/community, 1 community manager) this operations wallet will manage the deployer addresses to the timelock and require 3/4 signatures to deploy.

The second multisig wallet will consist of 8 members. (2 core team members, 1 head of operations/community, 1 community manager, 2 baofriends, and 2 external signers) it will require 5/8 signers for a transaction to go through. This will be our treasury management wallet.

To establish these wallets we’ll use a Gnosis Safe, and we’ll be able to implement these wallets on both xDAI and mainnet.

  • B) We will move all current treasury addresses in the contracts to point to the Gnosis Treasury Safe, so all future Bao printed for those treasuries is printed there. This will exclude the founder treasury share.

  • C) We will end the founder treasury share on xDAI and Mainnet. Lowering the total future printing of Bao.

  • D) We will move all the current $BAO in the treasury wallets over to the Gnosis Treasury Safes, excluding the founder treasury share and assets that cover bounties, payments, fees or pre-determined salaries for a two-year period as established in previous governance votes.

  • E) We will establish and update clear governance voting guidelines (outlined below).

  • F) We will begin to onboard additional code reviewers from our technical community, and set up our Github PRs to allow a multisig style review process. To begin only the core team will have merge and deploy access, but we will work to expand this over time when the community has trusted technical stakeholders.

  • G) We will create a formalized grant process that will allow external teams to put forward proposals to be paid for developing part of Bao.

  • H) This configuration will last until the community is confident that the new Gnosis Snapshot integration is ready for direct DAO management.

Section #3: Voting

Until such a time that it is feasible to implement a fully technical on-chain DAO solution without gas issues, our voting shall take place on the established Snapshot page on mainnet.

The core team shall administrate the voting site.

Any one with >0.25% of voting authority may put forward a community proposal. These votes are considered directional but non-binding.

Any one with >1% of the total voting authority, or the core team may sponsor a proposal to become a core proposal. That proposal shall be considered binding.

To become a core proposal it must either:

A) Have been deemed urgent and critical by the core team.


B) Have spent at least 1 week in the “Concepts” section for feedback, then at least 1 week in the “Governance Proposals” section of the forum with its final wording before moving to a vote. The vote in this case may last no less than 1 week.

For a vote to pass it must have at least a 51% majority, and a quorum of 5% of total voting power.

For a vote to pass in a case where it will recall a team member or override a veto power, it must have a 2/3rds majority and a quorum of at least 20% of total voting power.

New proposals may be considered to overwrite previous approvals.

In the case of Bao voting on governance related to franchises, the vote shall be non-proportional. If the Bao community were to vote on a Yes/No question related to Yetiswap, and “Yes” got 51% of the vote, then 100% of the votes held by the Bao Community will vote Yes on yeti governance.

Section #4: Asset Clarity

Currently the Bao community owns Baoswap and the Bao farms on mainnet and xDAI.

With this vote, Yetiswap and Pandaswap would become official assets of the Bao family to be deployed over the coming months.

Other than these assets and the Bao in the vault, the Bao community will have to vote to officially absorb future assets as they appear. Until then they are the property of their creators.

This is to prevent contributors from creating assets that could be legally problematic for the DAO. As the DAO will have to specifically approve and accept an asset before it is considered their property.

These assets along with those outlined in the treasury section constitute the full extensive property of the DAO.

Section #5: Deploy and Activate Staking + Fees on Baoswap

This section votes to move Baoswap out of alpha.

It will deploy and activate an xBAO staking model (based 100% on the xSUSHI staking model) and deploy that to xDAI.

It will also deploy and activate a staking model called tBAO on mainnet after the deployment of Yetiswap and Pandaswap. The fee collection from Yetiswap and Pandaswap will be moved to the mainnet across trustless bridges and will be used for the tBAO staking.

Section #6: Treasury Management

To clean up the treasury management, we will:

  • Move all treasury Bao, excluding founder share, to the new Gnosis Safe treasury wallet.

  • End all new founder share payments.

  • End all new LP share payments. We no longer should be issuing this excess Bao.

  • The remaining Bao from the Community fund and Bao from the Dev fund and from the LP share will be moved into the new treasury minus any amounts needed to cover an additional 2 years of current salaries which are extended through that period.

Section 7: Timelock

We’ll add a timelock to the xDAI farms to be governed by the same multisig as mainnet.

Section 8: SushiLP Tokens

Now that token minimums have been fixed on the Omnibridge, we’ll enable more SLP farms on xDAI to meet the original plan of any farm that was >$250k liquidity being transferred.

Section 9: Grants

Due to challenges with hiring we’ll begin to move to a Gitcoin grants process to encourage developers to build non-critical infrastructure for Bao.

Section 10: Voting Modification

Since Snapshot does not support multichain voting, there is an importance on ensuring a secure voting process on the mainnet as most active users move to xDAI. For this reason we should modify the existing voting power contract to include a 3x boost in voting power for locked Bao and a 50% reduction in voting power for each of LP and unstaked Bao on their current proportions.

For clarity:

This bill shall supersede, unbind and/or nullify all previous votes and actions in order to prevent any conflict of terms.


Overall this megabill as you put it looks promising. Having a core team will help prevent the DAO from getting bogged down voting for every little thing and that in turn will facilitate faster development. Holding a veto authority over community votes does seem like a good idea but should be limited to a single veto per proposal, followed by a predefined period of time before the second community vote is taken on whether or not to over-turning the veto. This will prevent stalemate scenarios where some members of the community feel like they are being stone walled by the core team.

For the head of community management and operations position you propose, am I correct in assuming that is the same position we just hired Chickn for or are you suggesting an additional role? The list of responsibilities although worded slightly different are essentially the same. Having a community team to act as a buffer between the core team and the rest of the community will help keep things focused and moving in the right direction.

External teams are great but one or more of the core team should be tasked with familiarizing themselves with any submissions. Not only will this help prevent components being held hostage as you describe but if the external team leaves the community for whatever reason, despite it not being hostile, could put the community into a position where we need to rush onboarding developers for those contributions to maintain their functionality. That step isn’t easily rushed, better to have it at least partially out of the way ahead of time as an insurance policy.

For the voting section a 5% quorum seems extremely low but as has already been noted, there isn’t much community involvement there so I guess that really leaves us no choice but to have it low. Having the quorum to overturn a veto be 6x as high seems a bit much if we are only seeing enough of a turn out to votes to make initial votes only need 5%.

Yetiswap and Pandaswap are eagerly awaited by much of the community so I don’t see anyone having an issue with that lol.


So this means that Yetiswap and Pandaswap will not have their own governance tokens to acquire fees?

i agree with everything i understand here, but there could be clarity about the BAO movements; the financials breakdown could be more descriptive on the purpose* of these decisions

I don’t want to be that guy, but I feel like this is straying way off course from the original proposal when I found this project. Way too many irons in the fire so to speak. The original focus was supposed to be synthetic assets, and then gas fees spiked so moving to xDai became a priority. Now it’s swap exchanges and new tokens for staking models. Not sure how the community benefits from this, especially when it comes to fees collected. Also what about tokens for these swap exchanges? If there are any, how will those be distributed and will early BAO adopters get priority, or will this be another announcement on a forum post where the discord group finds out only after the price has spiked up?
This was always billed as a “community driven” project, and now we need to implement a core team with veto powers?
This is starting to take a whole new shape, and with the small team working on this, I’m not entirely sure I like the direction this is heading to be quite honest.


Great work guys! hahaha looking forward to the next few developments

I was hoping for synthetics on sushi and uni. looks like we are way off that for now?
Good job on the other stuff anyway,

This megabill should add more value to small and large holders, way better than simply controlling the inflation. Not that the inflation control shouldn’t be considered in the future if the price keeps falling.

1 Like

The original focus was supposed to be synthetic assets, and then gas fees spiked so moving to xDai became a priority. Now it’s swap exchanges and new tokens for staking models. Not sure how the community benefits from this, especially when it comes to fees collected.

The focus is and always has been the synthetics.

It’s been clearly communicated though that the synths take time to build and require a few core things:

  1. Liquidity on LP assets.
  2. A useable chain experience.
  3. Multiple supported markets to support liquidations.

That is the reason for making sure we have the swap protocol. You can’t handle collateral or synthetics without that.

Otherwise where do you get the price of collateral and how do you sell off liquidations?

Also what about tokens for these swap exchanges? If there are any, how will those be distributed and will early BAO adopters get priority, or will this be another announcement on a forum post where the discord group finds out only after the price has spiked up?

It sounds like you’ve not been keeping up with the discussions. BAO holders by default get a 15% locked proportional ownership of the franchise chains.

Those components are a lower priority than synths, but they are easy to maintain and drive value for the ecosystem. They also are required for us to be able to offer synths cross-chain in the future.

This was always billed as a “community driven” project, and now we need to implement a core team with veto powers?

First off, this is a proposal to discuss. Second when it comes to governance you have two options:

  1. Absolute governance: This means you have to have all votes be >51% in favor and >51% in quorum.

  2. Guided governance: This means you can have votes be >51% in favor but a lower quorum but need a safety check.

The idea of the veto is to provide a safety check.

Right now, the average range of vote participation in most major DeFi projects is 3% - 10% (the high end of that range being YFI). Our average is 2%-3%.

This means even in a controversial vote less than 10% of holders show up to actually vote.

So you need a low governance quorum or you can’t pass any changes.

If you have a low governance quorum, what happens when a mega-whale puts forward a vote to dramatically change the system? There are whales out there that if they combined their voting could easily meet the quorum and try and pass things for the protocol that could be detrimental.

That’s why the proposal for a veto, but one that can be overruled by further vote. So it isn’t as if the veto stops anything from happening, it simply pushes it to require another vote at a higher level of involvement.

I’m also happy to hear other proposals on that mechanic.

That doesn’t make it any less community run, it just means we have a safety measure for major concerns.

It’s basically like the vote is put forward and passes, then the core team sees the vote and goes “hey are you sure about this, this seems like it could be bad, so we want to make sure the community is really sure about this?” and then the community can vote again to decide if they are for it or not.

I don’t want to be that guy, but I feel like this is straying way off course from the original proposal when I found this project. Way too many irons in the fire so to speak.

I think we are still very much on the original course, other than having been forced off to xDAI. The reality is that there are just a lot of steps to take a long the way that most people didn’t seem to realize.

So far, we’ve still hit every milestone promised despite the fact we are a community driven team that is bootstrapped.

The goal of these proposals is to further decentralize governance, remove team roadblocks and make it easier for more people to contribute to the protocol specifically so we can move faster and involve more people.


It’s always been said that we expect soft synthetics sometime in the Spring, after Balancer launches their V2.

The hard synths have always been expected for mid-to-late Summer.

We are still on that path.


They will, but 15% of that comes back to Bao holders, and a staking mechanism is what I am proposing to manage that distribution.


excellent, keep it up baoman! thanks

1 Like

Looks awesome. Glad to be a part of one of the most exciting defi project. Love staking on xdai, it has been a really great experience. Its for sure the best place for yield farming until ether gas prices normalize. Keep up the great work you magnificent Baoman.


It is true, I keep up as much as possible, but BAO is not my only investment. Like you I have many things that keep my attention spread out. I try to stay informed on what I going on, but I do miss things here and there.

I appreciate your response, and I understand that the project has stayed on schedule, but I am still not understanding the usefulness of adding multiple swap exchanges. One I can understand, but until other side chains have more traffic, I don’t see the benefit other than being first to market on those side chains. (Maybe that’s the goal idk)

As far as governance goes, I had no idea that the vote turnout was so low, so yes I can understand why the ability to veto could be necessary in the case of a whale voting to change something that would have a negative impact.


Can we change the name from yetiswap to APESWAP

One I can understand, but until other side chains have more traffic, I don’t see the benefit other than being first to market on those side chains. (Maybe that’s the goal idk)

Because we are building on xDAI we already have to figure out how to settle some components across multiple EVM chains to support xDAI<>Mainnet

If we implement those kind of bridge solutions, then it is also easy for us to settle across multiple EVM chains, and since the farm codebase is the same, it makes it easy to deploy.

That would allow us to tap into liquidity in other ecosystems. While other chains don’t have lots of transactions or volume, they do have a ton of idle liquidity, which is really good for spreading out liquidations.

When we take LP tokens instead of top bluechip assets for collateral, we have to be really careful about liquidations. If a position is liquidated and it drops too fast as a result of the liquidation then it is the Bao protocol that loses the money.

That’s why liquidation management strategy is important, and its why so few protocols deal with LP tokens let alone many LP tokens from smaller projects.

It’s one thing we want to spend a lot of time and effort in to making sure we’ve got the most robust, spread out and least impactful liquidation options for :)

I appreciate your follow up and glad that we are on the same page after some discussion. At the end of the day, this project will always move slower and in different ways than the large well funded protocols. But it is that careful and strategic methodology that makes us different. It is by doing things that other teams don’t see, that we stand out.

And, at the end of the day, even concepts I put forward here are just proposals. Remember that because this is a community driven project, the community can choose not to approve these proposals (heck they can even vote to remove and replace me!) these are just proposals to get feedback on. But while it can seem a bit chaotic, there is usually a strategy behind the decisions and I’m always happy to take time to explain that better :)


Thanks for taking the time to explain in further detail. I did understand that liquidity was important, just didn’t realize that was the focus of the other swap exchanges.


Quite a reasonable explanation. However we do have to be selective and careful when applying the team’s veto power. Maybe some kind of check/balance + review for every veto applied?

1 Like

I think Veto power as a fail-safe circuit is a good idea. This way the community interest is protected from a DAO takeover. Case in point: TrueSeigniorage token. Our participation is incredibly low. In the case of True Seignoiorage token, Dev account has only 9% of the DAO. Dev account does not have enough stack to vote against someone who held enough voting rights to make a proposal that ultimately allowed hostile takeover and minting that went to the attacker. Thread here for those interested: https://twitter.com/TrueSeigniorage/status/1370956726489415683?s=20


Well there can only be one veto per voted proposal and the community can do an extended vote to overrule the veto.

The goal is for it to never be exercised.

In the future it may make sense to shift it to having to have a majority of all the multisig holders sign to exercise that power since that has representation from the broader community.