# xDai + BadgerDao LiquidityPool DAO

Reason: Migr Stable Badger Liquidity to xDai

Old Idea:

<!--BadgerDAO and xDaiDAO can supply farming rewards for STAKE <> iBBTC pair on a popular xDai DEX (Sushiswap, dxDAO, Honeyswap). BadgerDAO is a massive mover on mainnet Ethereum and other side chains and this would act as incentive for Apes and Degens to move over to xdai. Further reward systems can be imagined on platforms like Shenanigan, Agave, -->

## Simple Summary

Structure a liquidity DAO around BadgerDAO expanding iBBTC over to xDai.

## Abstract
Phase 1: Move iBBTC
Provide an opportunity for mutual benefit between DEXs, BadgerDAO, and xDAI by initiating tokenswaps with all major DEXs on xdai (SWAPR, Sushiswap, Honeyswap). BadgerPOOL DAO will trade STAKE <> iBBTC LP Tokens with any DEX for an equal amount of the DEXs native token, and vested inside BadgerPOOL for 3 months. The LP tokens exchanged to the DEX will be minted on the DEX itself. After the tokenswap, BadgerPOOL will pair iBBTC with the native DEX token on the DEX. This is a double incentive for DEXs to partake in the token swap.

Phase 2: Community Liquidity
Once DEX liquidity has been instantiated, open BadgerPool to the community. Community can offer iBBTC or STAKE in exchange for LOOT shares at a fixed rate. Tokens will be vested for 3 months.

Phase 3: iBBTC Farms
Farms can be made by collaborating with the DEXs that participated in the token swap, or by BadgerPOOL itself using SWAPRs custom farms.

## Motivation
BadgerDAO is a major player in the DeFi space. Expanding its reach to a chain holding some major DAOs like Raid Guild, DAOHaus, 1Hive, and dxDAO| could pose for some awesome opportunities for the Badger Community

## Specification

**Step 1:** Get iBBTC and Stake onto xDAI

It would be preferrable to have all DAO votes on xDAI for the gas fees.

Mainnet iBBTC and STAKE can be transferred over the xDai [omnibridge](https://omni.xdaichain.com/)

**Step 2:** Open to the Community
There are two paths:

!. Create two DAOs
One DAO on Mainnet and one DAO on xDAI.

## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is works in other environments. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
Rationale goes here.

## Implementation
<!--The implementations must be completed before any SHEiP is given status "Final", but it need not be completed before the SHEiP is accepted.-->
Implementation goes here.

## Security Considerations
<!--All SHEiPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. SHEiP submissions missing the "Security Considerations" section will be rejected. An SHEiP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.-->
Security considerations go here.

## Copyright
Copyright and related rights waived via [CC0](https