# Upgrade Governance Contract to Compound's Governor Bravo

## Previous Discussion:
[Temperature Check](https://gov.uniswap.org/t/temperature-check-upgrade-governance-contract-to-governor-bravo/13610) | [Snapshot](https://snapshot.org/#/uniswap/proposal/QmScNLeajiF2hQh1z9DYqTFKGgrRhHwrHisV4ynmDEQwxH)
[Consensus Check](https://gov.uniswap.org/t/consensus-check-upgrade-governance-contract-to-governor-bravo/13707) | [Snapshot](https://snapshot.org/#/uniswap/proposal/QmWbgzHJ8nK2TDaj6LF6BxAMPahy97dMmbbU5kRBw1QkXt)
## TL;DR:
Upgrade Uniswap's current governance contract from Governor Alpha to Governor Bravo to improve governance upgradability and protocol safety.
[On-Chain Proposal]()
## Summary and Motivation:
*Co-written with [Getty Hill](https://twitter.com/getty_hill) (@Getty), [Eddy Lee ](https://twitter.com/yesimeddy) (@elee), [Yuan Han Li ](https://twitter.com/yuan_han_li) (@yuan-han-li), [John Wang ](https://twitter.com/j0hnwang) (@johnwang), and [Ali Khambati ](https://twitter.com/alikhambati1) (@alikhambati)*
Governor Alpha, the current governance contract used, was a great start, but in light of Compound's and other protocols upgrade to Governor Bravo, Uniswap should migrate given Bravo's additional safety benefits and upgradability.
1. **Native upgradeability:** Under Governor Alpha, changes to governance parameters require deploying a new contract and completely migrating to a new address. This is particularly damaging to governance participation as it introduces downtime and asynchronicity. Many governance tools and custodians use factory contracts which point to a specific contract address, meaning parties must manually upgrade their infrastructure every time governance parameters are changed under Governor Alpha. This includes tools for creating autonomous proposals like [fish.vote ](https://www.fish.vote/); front-ends such as [Tally ](https://www.withtally.com/), [Sybil](https://sybil.org/#/delegates/uniswap), and [Boardroom ](https://app.boardroom.info/) which aggregate and display governance results for various protocols; and professional custodians which are used by large token holders, delegates, and community members. Enabling a static contract address that has proxy upgradability patterns is paramount for maximizing participation, and maintaining an open and secure governance process.
2. **Voting reason string:** Governor Bravo gives voters the opportunity to add free-form comments (text strings) along with their on-chain votes. Not only does this increase the transparency around the rationale people have behind their votes, but it also facilitates more in-depth and nuanced discussion.
3. **New 'abstain' voting option:** Governor Bravo enables voters to formally abstain rather than forcing them to choose between voting yes/no or not voting at all. This will give voters more flexibility and also increase transparency into delegate behavior.
4. **Proposal numbers won't reset:** Under Governor Alpha, any upgrades to the contract resets the proposal number schema. Notice that ['Proposal 0.4'](https://app.uniswap.org/#/vote/0/4) (which resulted in deployment and migration to a new Governor Alpha contract due to modifying the proposal submission threshold parameter) caused the following on-chain proposal from @HarvardLawBFI to be numbered ['Proposal 1.1' ](https://app.uniswap.org/#/vote/1/1). Under Governor Bravo, this would not be an issue and proposal numbers would be continuous because the contract would be maintained at a single address.
5. **Proposal Cancellation:** Bravo allows user-directed cancellations enabling erroneous proposals to be canceled if need be (rather than forcing people to vote no/abstain).
6. **Review Period:** Governor Bravo allows governance to include a review/analysis period. Currently, Compound uses a 13140 block (~2-day) review period that allows holders to review the proposal. This means that users will have 2-days to prepare for voting (e.g., remove UNI from Aave), unlike Governor Alpha which instantly snapshots users' voting power. A review period substantially improves the accessibility and safety of the governance process.
## Implementation:
After speaking with the OpenZeppelin team about their reimplementation of Governor Bravo, we think using Compound's Governor Bravo contract instead makes the most sense at this stage.
Although Open Zeppelin's Governor contract takes a simpler approach that can include all Bravo functionality, it does not do so by default. The contract uses similar logic, but the code is new. It has gone through an internal audit and review process but still needs to go through an external audit.
For the safety and simplicity of Uniswap, we think using Compound's Governor Bravo contract is the best decision for the time being. Compound's Governor contract has already undergone an [audit](https://blog.openzeppelin.com/compound-governor-bravo-audit/) by OpenZeppelin and has been widely used. We can always change/upgrade to Open Zeppelin Governor contract at a future date if their contract introduces new features/functionality the community is interested in. More details on OpenZeppelin's code can be found here:
[Github](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance)
[Docs](https://docs.openzeppelin.com/contracts/4.x/api/governance)
[More info](https://openzeppelin.notion.site/Comparing-Compound-Governor-to-OpenZeppelin-Governor-2-10d0fdcf61ba476fae492b295822ee13)
As mentioned in the previous Consensus Check, we have deployed the contract on the Ropsten test net for the community to review our code:
[Governor Bravo Delegator](https://ropsten.etherscan.io/address/0x15df15caad12adaa03949014ba5cc49a84803d0f#code)
[Governor Bravo Delegate](https://ropsten.etherscan.io/address/0xD8bf60dfC5115F6cB99bb50502346E7b863800f1#code)
[Github for contracts](https://github.com/gettty/uniswap-gov)
*NB: The `_initiate` function has been slightly modified to take an initial proposal number as an input rather than pulling it from Governor Alpha. This way Uniswap can resume proper proposal numbering.*
## Resource links:
1. [Governor Bravo Development - Protocol Development - Compound Community Forum ](https://www.comp.xyz/t/governor-bravo-development/942)
2. [Understanding Governor Bravo. A review of key changes versus... | by monetsupply | Tally | Jul, 2021 | Medium ](https://medium.com/tally-blog/understanding-governor-bravo-69b06f1875da)
3. [Compound | Proposal Detail #42 ](https://compound.finance/governance/proposals/42)
4. [Compound | Proposal Detail #43](https://compound.finance/governance/proposals/43)

**Uniswap Grants Program v0.1**
co-authored with Ken Ng

**Summary:**
This post outlines a framework for funding Uniswap ecosystem development with grants from the UNI Community Treasury. The program starts small—sponsoring hackathons, for example—but could grow in significance over time (with renewals approved by governance) to fund core protocol development. Grants administration is a subjective process that cannot be easily automated, and thus we propose a nimble committee of 6 members —1 lead and 5 reviewers—to deliver an efficient, predictable process to applicants, such that funding can be administered without having to put each application to a vote. We propose the program start with an initial cap of $750K per quarter and a limit of 2 quarters before renewal—a sum that we feel is appropriate for an MVP relative to the size of the treasury that UNI token holders are entrusted with allocating.

**Purpose:
**
The mission of the UGP is to provide valuable resources to help grow the Uniswap ecosystem. Through public discourse and inbound applications, the community will get first-hand exposure to identify and respond to the most pressing needs of the ecosystem, as well as the ability to support innovative projects expanding the capabilities of Uniswap. By rewarding talent early with developer incentives, bounties, and infrastructure support, UGP acts as a catalyst for growth and helps to maintain Uniswap as a nexus for DeFi on Ethereum.

**Quarterly Budget:**
Max quarterly budget of up to $750k
Budget and caps to be assessed every six months
Grant Allocation Committee:

Of 6 committee members: 1 lead and 5 reviewers
Each committee has a term of 2 quarters (6 months) after which the program needs to be renewed by UNI governance
Committee functions as a 4 of 5 multi-sig
Committee Members

While the goals and priorities of the grant program will be thoroughly discussed and reviewed by the community through public discourse, the decision to start UGP by operating as a small committee is to ensure that the application and decision process will be efficient and predictable, so applicants have clear objectives and timely decisions.

Starting with just six members enables the committee to efficiently fund projects with tight feedback loops and rapid iterations. The purpose of this committee would be to test the hypothesis that the Grants Program can successfully provide value for the UNI ecosystem before scaling the program.

We suggest the grants program is administered by a single lead. Here we propose Kenneth Ng, a co-author of this post. Ken has helped grow the Ethereum Foundation Grants Program over the last two years in establishing high level priorities and adapting for the ecosystems needs.

The other 5 committee members should be thought of as “reviewers” — UNI community members who will keep the grants program functional by ensuring Ken is leading effectively and, of course, not absconding with funds. Part of the reviewers job is to hold the program accountable for success (defined below) and/or return any excess funds to the UNI treasury. Reviewers are not compensated as part of this proposal as we expect their time commitment to be minimal. Compensation for the lead role is discussed below, as we expect this to be a labor intensive role.

Program Lead: Ken Ng (HL Creative Corp) Ecosystem Support Program at the Ethereum Foundation

Reviewer: Jesse Walden (o/b/o Unofficial LLC dba Variant Fund) Founder and Investor at Variant Fund (holds UNI)

Reviewer: Monet Supply Risk Analyst at MakerDAO

Reviewer: Robert Leshner Founder and CEO of Compound Finance

Reviewer: Kain Warwick Founder of Synthetix

Reviewer: Ashleigh Schap Growth Lead, Uniswap (Company)

**Methodology**
**1.1 Budget**

This proposal recommends a max cap of $750K per quarter, with the ability to reevaluate biannually at each epoch (two fiscal quarters). While the UGP Grants Committee will be the decision makers around individual grants, respective budgets, roadmaps, and milestones, any top-level changes to UGP including epochs and max cap, will require full community quorum (4% approval).

The UGP will be funded by the UNI treasury according to the release schedule set out by the Uniswap team, whereby 43% of the UNI treasury is released over a four-year timeline. In Year 1 this will total to 172,000,000 UNI (~$344M as of writing).

Taking into consideration the current landscape of ecosystem funding across Ethereum, the community would be hard-pressed to allocate even 5% of Year 1’s treasury. For context Gitcoin CLR Round 7 distributed $725k ($450k in matched) across 857 projects and YTD, Moloch has granted just under $200k but in contrast, the EF has committed to somewhere in the 8 figure range.

**1.2 Committee Compensation**

Operating a successful grants program takes considerable time and effort. Take, for instance, the EF Ecosystem Support Program, which has awarded grants since 2018, consists of an internal team at the Foundation as well as an ever increasing roster of community advisors in order to keep expanding and adapting to best serve the needs of the Ethereum ecosystem. While the structure of the allocation committee has six members, we propose that only the lead will be remunerated for their work in establishing the initial processes, vetting applications, and managing the program overall as this role is expected to be time consuming if the program is to be succesful. We propose that the other committee members be unpaid UNI ecosystem stakeholders who have an interest in seeing the protocol ecosystem continue to operate and grow.

We propose the lead be compensated 25 UNI/hr (approximately $100 USD at time of this writing) capped at 30 hours/week. This compensation, along with the quarterly budget, will be allocated to the UGP multisig from the UNI treasury. In keeping with the committee’s commitment to the community, hours and duties will be logged publicly and transparently .

**2.1 Priorities**

Initially, the program aims to start narrow in scope, funding peripheral ecosystem initiatives, such as targeted bounties, hackathon sponsorships, and other low-stakes means of building out the Uniswap developer ecosystem. Over time, if the program proves effective, the grant allocations can grow in scope to include, for example, improved frontends, trading interfaces, and eventually, core protocol development.

|624x199

With the initial priorities in mind, some effective measures for quick successes might look like:

Total number of projects funded
Quarterly increase in applications
Project engagement post-event/funding
Overall community engagement/sentiment
2.2 Timeline

In keeping with the fast pace of the UNI ecosystem, we organize time in epochs, or two calendar quarters. Each epoch will see two funding rounds, one per quarter, after which the community can review and create proposals to improve or revamp the program as they deem fit.

|624x245

Rolling Wave 1 & 2 Applications

Starting in Q1 2021, UGP will start accepting applications for events looking for support in the form of bounties or prizes that in parallel can be proactively sourced. During these first two waves of funding projects, the allocation committee lead can begin laying out guardrails for continued funding

Considering the immediate feedback loops for the first epoch, we expect these allocation decisions to be discussed and reviewed by the larger community. Should this not be of value, the community can submit a formal governance proposal to change any piece of UGP that was not effective

Wave 3 & Beyond

Beginning with Wave 3, there should have been enough time with impactful projects funded to be considered for follow-on funding, should it make sense. In the same vein, projects within scope will be expanded to also include those working on integrations and and other key components.

Beyond the second epoch, as the community helps to review and help adapt UGP to be most effective, the scope will continue to grow in order to accommodate the state of the ecosystem including that of core protocol improvements

**Conclusion**
If this proposal is successfully approved, UGP will start accepting applications on a rolling basis beginning at the start of 2021. With the phases and priorities laid out above, UGP will aim to make a significant impact by catalyzing growth and innovation in the UNI ecosystem.

This program is meant to be the simplest possible MVP of a Uniswap Ecosystem Grants initiative. While the multi-sig committee comes with trust assumptions about the members, our hope is the community will approve this limited engagement to get the ball rolling in an efficient structure. After the first epoch (2 fiscal quarters) the burden of proof will be on UGP to show empirical evidence that the program is worth continuing in its existing form and will submit to governance to renew treasury funding.

If this program proves successful, we hope it will inspire others to follow suit and create their own funding committees for allocating treasury capital—ideally with different specializations.



# BIP-2: Establish the Babylon Foundation


### **Goal**


Establish an ownerless, non-profit organization dedicated to supporting the Babylon protocol.

### **Summary**

The goal of the Babylon protocol is to be **completely owned by the community**

At the moment, the Babylon protocol can only operate on-chain through governance proposals submitted through the [Babylon Governor](https://medium.com/babylon-finance/introducing-babylon-governor-6d9e45d7ca3c)

Therefore, the Babylon protocol at the moment cannot take actions in the real world like hiring contributors or transferring assets to bank accounts. 

We want to create an **ownerless Babylon Foundation** that will empower the Babylon community with the power to operate outside the blockchain. 

To do this, the Babylon Foundation will **only execute actions approved by BABL token holders**.

With a Babylon Foundation in place, we’ll be one step closer to Babylon’s complete decentralization.

### **Status & Process**

The proposal is currently being discussed.
Discord will be used first to discuss this proposal with the community.
After some consensus has emerged, an on-chain proposal will be created using Tally.

### **Explanation**

The team has been moving towards [progressive decentralization](https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/).

The first step was when the initial team deployed the [Babylon Governor](https://medium.com/babylon-finance/introducing-babylon-governor-6d9e45d7ca3c) and gave it control over the protocol treasury. 

Now the community is voting to activate the [Babylon Mining Rewards](https://medium.com/babylon-finance/babl-mining-program-4829c313268d) which will allocate 50% of the total BABL supply to Babylon users. 

If the proposal is approved and executes, **Babylon users will also own the controller** and will be able to change the main parameters of the protocol like fees and BABL distribution mechanics.

The next step in decentralization will be to to create a foundation that can represent the protocol and the [BABL token](https://medium.com/babylon-finance/announcing-babl-8f41b58c52c5) holders in the real world.

### **The Foundation**

The proposed Babylon Foundation foundation shall be **ownerless, not for profit, and will only be able to carry out actions approved by BABL token holders** through a governance proposal.

[Ethereum](https://ethereum.org/en/foundation/) itself and other protocols in the space like [dYdX](https://dydx.foundation/about) have created foundations for the same purpose. We believe that a foundation is the best model for a DeFi protocol to operate as a legal entity.

The Babylon protocol will use the Babylon foundation to operate and transfer assets to other corporate entities when needed. For example:

Signing partnerships with corporate entities.
Hiring contributors that require to be paid through bank accounts.
Investments in other asset classes.
Supporting the ecosystem through grants and fellowships.

### **Specification**

No code or on-chain transactions are required.

### **References**

[1] [Babylon Governor](https://medium.com/babylon-finance/introducing-babylon-governor-6d9e45d7ca3c)

[2] [Babylon Mining Rewards](https://medium.com/babylon-finance/babl-mining-program-4829c313268d)

[3] [BABL Token](https://medium.com/babylon-finance/announcing-babl-8f41b58c52c5)

[4] [dYdX Foundation](https://dydx.foundation/about)

[5] [Ethereum Foundation](https://ethereum.org/en/foundation/)

[6] [Google doc of this proposal](https://docs.google.com/document/d/1nrWts9gc_RyX-DEpTMQceGmwmRDDzLr-QpQ6Ugl7yB4)



# DIP-6: Pixel Art + DIP-4 Part 1 + DIP-5 Gas Refunds

A batch proposal for:

## [Commission Dope Wars Pixel Art](https://snapshot.org/#/dopedao.eth/proposal/Qmbhdyn31sMSu2LgFwj36747jcYbhbQWXTA8tuEv9e2NK3)

**10**eth to `0xc2407b34b19d2227addc5c6eae5c5d99432a0c99` 

## [DIP-4: RYO v1](https://snapshot.org/#/dopedao.eth/proposal/QmZmidDFYbvS5L7EqmL8RsqXTZ9t1yZc3MpYSwMTfJLLwY)

First installment of **2.5**eth to `0xa2701f1dadae0e1ee9fa68ab90abbda61cd9e06b`

## [DIP-5: Development Gas Refund](https://www.notion.so/DIP-5-Development-Gas-Refund-a6b7e43af34e4a7682ac06a4bbe7c99d)

Gas refunds for contract deployments.

**2.6572230788**eth to `0xe8d848debb3a3e12aa815b15900c8e020b863f31`

**1.15785465171**eth to `0xba740c9035fF3c24A69e0df231149c9cd12BAe07`

BIP-3: The Prophets Arrival 
# **Goal** 
We want to propose an NFT drop that doubles as an IDO. 

You can read the full proposal here: [BIP-3](https://docs.google.com/document/d/1p751X2x1lf97OdGHB7eNlcVFViYNl0iu9d5P0MY9JVM/edit).


BIP-3: The Prophets Arrival 

# **Goal** 

We want to propose an NFT drop that doubles as an IDO. This proposal is intended to reward beta users, bootstrap BABL liquidity, raise money for the treasury, and finally, as a call to arms to attract more settlers to Babylon. 

You can read the full proposal here [BIP-3](https://docs.google.com/document/d/1p751X2x1lf97OdGHB7eNlcVFViYNl0iu9d5P0MY9JVM/edit#heading=h.9nx23hy4wk5q).


# Add 1 Basis Point Fee Tier  

## **TLDR: Uniswap should add a 1bps fee tier with 1 tick spacing**

This change is straightforward from a technical perspective and would help Uniswap compete in stablecoin <> stablecoin pairs, where the majority of the market share is taken by Curve and DODO.  

## **Background on pool fees** 

Uniswap v3 allows for the creation of new pools via calls to the [factory contract](https://etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984). In order to keep liquidity for pairs consolidated, only a few fee options are allowed–currently, 5, 30, and 100 basis points are supported (10, 60, 200 tick spacing).  Governance should add a 1 basis point fee option for the following reasons: 
* Curve’s stablecoin markets have 3-4 bps fees. 
* Dodo’s stablecoin markets have a 1 bps fee. 
* FTX’s fees for retail are 2/7bps fees and for whales 0/4bps.  However, we recognize there are some potential counterarguments to adding this fee tier: 
* Adding too many fee tiers can fragment liquidity. 
* Liquidity providers may earn less in fees.  

### **We discuss each of these points in greater detail below** 

This will allow for the creation of much more competitive stablecoin<>stablecoin pools.  Offering low slippage on stablecoin<>stablecoin pairs in AMMs is generally easier than other pairs due to their relatively low price volatility.  As such, the determining factor in driving volume is trading fees. Pouring more capital into a 5 bps fee pool won’t necessarily make Uniswap v3’s pricing more attractive, as lower cost pools exist such as [Curve’s 3pool](https://curve.fi/3pool) (3 bps fees) and [DODO’s USDC-USDT](https://app.dodoex.io/liquidity?network=mainnet) pool (1 bps fees). 

Indeed, [most USDC-USDT volume from 1inch is routed to DODO](https://dune.xyz/queries/135498). Very little of it is routed to Uniswap v3.  [In the DEX market as a whole](https://dune.xyz/queries/150801) (not just 1inch), DODO and Curve still take the majority of the market share (60-70%) in USDC-USDT trading. Uniswap v3’s concentrated liquidity helped increase market share, but lower fees can help it grab more.  


The data tells a similar story for DAI-USDC (see [1inch exported volume](https://dune.xyz/queries/152001) and [overall market share](https://dune.xyz/queries/151999)), though in the case of DAI-USDC, DODO is less active. While the case is compelling just from competition in the DEX space, Uniswap also competes with centralized exchanges.  Many centralized exchanges offer lower than 5 basis point taker fees for high volume traders ([Binance](https://www.binance.com/en/fee/schedule) offers < 5 basis point fees above 40K BTC in 30-day volume, [FTX](https://help.ftx.com/hc/en-us/articles/360024479432-Fees) above $25M in 30-day volume, etc.). Lower fees could increase the DEX volume pie by comparing favorably to spot markets on centralized exchanges and drawing volume from large players. 

### **The change is a very light touch**

The change requires just one function call–[`enableFeeAmount(100)`](https://github.com/Uniswap/v3-core/blob/b2c5555d696428c40c4b236069b3528b2317f3c1/contracts/interfaces/IUniswapV3Factory.sol#L77)–on the factory contract. Governance controls this contract, so a simple proposal could make this change.  The enableFeeAmount function takes as parameters 
 1. Fee: the fee amount denominated in 100ths of a basis point. 
2. `tickSpacing`: the granularity one may specify a liquidity range (see the Uniswap v3 Core [whitepaper](https://uniswap.org/whitepaper-v3.pdf) for more details)  

To add a 1 basis point fee option, fee would be 100.  `tickSpacing` requires some consideration. On the one hand, too high of a value restricts LPs’ ability to set granular prices, since initializable price ticks would be roughly [`tickSpacing`] basis points apart. On the other hand, too low of a value could entail liquidity being too low in each tick, meaning that larger orders may need to cross multiple ticks to fill, entailing extra gas cost for each additional tick.  We suggest that a value of 1 for `tickSpacing` would be reasonable for 1 basis point fee pools, allowing LPs to set prices with precision in positions that span ~1 basis point between initializable ticks.  

For a stablecoin market like USDC-USDT, we expect most of the liquidity to reside in 6 ticks. Orders <$1m will like only require 1 tick and larger orders may require a second or third tick. For each tick used it adds about 15k-20k gas costs. 

### **Too many fee tiers can fragment liquidity**

The downside of adding too many fee tier possibilities is that liquidity is then fragmented across pools. However, we believe that LPs will naturally settle over time into the fee tier that is most appropriate for the volatility of the pair.  Pairs with particularly low volatility, like stablecoin<>stablecoin pairs, will likely have a liquidity migration to the 1 bps tier, as the required return to capital should be low in equilibrium given the low risk of impermanent loss.  

### **LPs may earn less in fees**

Assuming overall volume stays stable (although it’s worth mentioning more competitive fees should grow the pie), total fees paid will go down (volume would have to 5X for fees paid to LPs to stay the same).  

However, LPs are not the only constituency to take into consideration–takers will be paying lower fees in aggregate. Growing Uniswap’s market share and being the best place to trade across many pairs is important. These pools could become more enticing to large traders looking to swap stablecoins, for instance.  

## **Concluding Thoughts**

We believe this simple change could boost Uniswap’s competitiveness in low volatility pairs, and the change presents minimal risk for Uniswap.

# BIP-4: Uniswap V3 Pool + Harvest Vault

We want to propose the creation of an Uniswap V3 Pool for BABL/ETH, along with the creation of a Harvest Vault to stake the LP tokens.

This will bootstrap liquidity for BABL, the governance token of the protocol.

Our friends at 🚜 Harvest finance will lead the proposal and assist with the creation of the pool.

Full proposal [here](https://docs.google.com/document/d/1d3ZCVrvekktGhbiPLMNzw_1n8-12iYerm5GI2XAN_MY/edit)

DIP-10: DIP-7 Music Initiative + DIP-9 Development Fund

A batch proposal for:

**[DIP-7: The Dope Wars Music Initiative](https://snapshot.org/#/dopedao.eth/proposal/QmdMpFJy4pu9oSmg5gWfXtFLJvwagW9ya8uqJ71TQ8Ccj2)**

*If this proposal passes, all  DIP-7 related funds and business operations will be controlled by and administered by Game Recordings Inc.*

**16eth to `0x63f9303aeb982b0fba1488d5af25b5ac17994cac`**

**[DIP-9: Development Fund](https://snapshot.org/#/dopedao.eth/proposal/0x760aca3d47e11fbc2c666b9a2d5869544066eb4ec4be24563308581733591aea)**

**5eth to `0xB429Bee46B7DF01D759D04D57DaBe814ECf0341b`**

DIP-16: Hustlers Pay Their Debts

- 2.5eth to **@perama** for DIP-4: RYO v1 [0xA2701F1dADaE0e1ee9fa68aB90ABBdA61cD9e06b] 
- 10eth to **@mrfax** for DIP-11: PIXEL ART Vehicles, Dope Font & accessories drop [0x50258A2aE0b3065754936828Cd7814731C6fC008]
- 5eth to replenish dev fund [0xB429Bee46B7DF01D759D04D57DaBe814ECf0341b]
- $2500 in eth to repay **@Cyberbitz** for putting the down payment on DIP-13: Pixel Art Animation [0xd4b65Db36026dDF08859B8175c02c611FDE0A020]
- 0.293136968879252635eth to **@TimeTravelerBowie** to repay for PAPER contract deployment [0xF0c6644a2C2b64eC45e4731d75Cac5d1852a76C3]
- $4050 to **@HPMNK** for DIP-14 [0x8f968D9e6D4CD79f5eAD9551D7f04b66ebfF1F4E]

# BIP-3: The Prophets Arrival 

## Goal 
We want to propose an NFT drop that doubles as an IDO. You can read the full proposal here [BIP-3](https://docs.google.com/document/d/1p751X2x1lf97OdGHB7eNlcVFViYNl0iu9d5P0MY9JVM/edit).

# BIP-3: The Prophets Arrival

## Goal 
We want to propose an NFT drop that doubles as an IDO. This proposal is intended to reward beta users, bootstrap BABL liquidity, raise money for the treasury, and finally, as a call to arms to attract more settlers to Babylon.  You can read the full proposal here [BIP-3](https://docs.google.com/document/d/1p751X2x1lf97OdGHB7eNlcVFViYNl0iu9d5P0MY9JVM/edit#heading=h.9nx23hy4wk5q).

# Placeholder. Please ignore

When upgrading Uniswap's DAO, someone created 8 empty proposals to keep the proposal sequence at number 9

Canceled proposal: MMM S13 - Funding request

Due to a Tally UI bug, this proposal will just send a tiny amount of dust. No need to vote for or against it.


Canceled proposal: 🚀 Moonshot Collective (MSC) S13 - Funding request

Due to a Tally UI bug, this proposal will just send a tiny amount of dust. No need to vote for or against it.


Canceled proposal: Fraud Defence & Detection (FDD) - S13 Budget

Due to a Tally UI bug, this proposal will just send a tiny amount of dust. No need to vote for or against it.


# BIP-15: Referral Program

Full Doc below
https://docs.google.com/document/d/1mzyW5N1cw3Q_pMZcCyI1G9vAHGwLU35VlPiTwpBOys4/edit#heading=h.9nx23hy4wk5q



# ReactSwap

## ReactSwap V0 testnet, Q1 2022

After working for three months on our first DEX implementation, deploying AMM-V1 (Uniswap V2 + Sushiswap + Pancakeswap fork + RFI) and testing on ropsten testnet, talking to investors, economists, and techs, we concluded that the Market does not currently need such DeFi product and has no prospects in the long term.
Blockchain ecosystems are filled with similar services (uniswap v2 and pancake forks). In this form, the project will not be able to consistently generate revenue for our DAO.
Reactswap in V0 implementation has nothing innovative and cannot attract investments as a start-up in 2022.

### Lacks of ReactSwap V0 testnet

#### Uniswap V2 (amm-v1 contracts)

- blurred liquidity of Uniswap V2 pools
- single commission for all pools without the possibility of change
- constant product formula only
   - non-permanent loss
   - high slippage
- bad stable-stable pairs liquidity providing abilites

#### Network support

- no support for multiple networks
- no cross-chain exchanges
- no cross-chain liquidity

#### Management

- lack of funding
  - initial liquidity
  - marketing
  - development
- tight deadlines for the development and launch of a promising DeX AMM and revenue generating unit

### Some problems of the decentralized markets and exchanges

- liquidity fragmentation
- cross-chain liquidity management issues
- problems with liquidity incentiving for new decentralized projects
- weak capabilities of decentralized order book marker makers
- weak capabilities of cross-chain crypto trading

## ReactSwap: next-gen decentralized exchange

Our DeX project idea is simple - solving problems relevant to the decentralized financial industry of those that we know how to solve.

### Swap at the best price [MVP-1]
- universal DeX SDK
- swap with the best rate
- liquidity aggregation
- formation of the best route

### DeX trading and analytics [MVP-2]
- price charts for all DeX pairs
- token/pair/dex trades, volume

### Cross-chain swap [MVP-3]

Native DeX cross-chain interoperability.

- cross-chain router
- Stability Bridge integration for synthetic assets
- Connext intergration for stable coins

### Order book [MVP-4]

Decentralized order book market maker for fungible tokens.

- on-chain order book
- executing orders on top DeX AMMs

### Various AMM liquidity pools [MVP-5]

- R-pool: 2 tokens, Uniswap invariant (constant-product formula) (AMM-V1 RLP, implemented in V0)
- U-pool: 2 tokens, Uniswap invariant (constant product formula),  liquidity ranges, 5 types of pool fee
- B-pool: 2-16 tokens, constant average formula/value function, different pool weight, 
- C-pools: 2-8 tokens, Stableswap invariant (hybrid formula)

### Liquidity incentive platform

- ReactFarm and React Pools (implemented in V0)
- User liquidity farms
- User rewarding pools

### Possible features

- liquidity lock / provider certification
- trading competitions
- leverage lending & trading

## Fundraising

Implementing a modern competitive decentralized exchange requires significant investment.
This proposal is an attempt to start financing the development of the project from Stability DAO Treasury before project will be ready for venture capital, grants and other investments.
Until the full implementation of the project, project milestones are investment rounds.
To start working on fundraising for development, we want to develop white paper, MVP-1, as well as tokenomics model and pitch decks. Propose to allocate 50,000 PROFIT for these works.

## Stability DAO Unit

Each minimum viable ReactSwap product will generate revenue for the DAO.

## Proposed transaction

Transfer 50 000 PROFIT to Development Fund. ReactSwap RnD, WP, MVP-1.


# BIP-18: ✅ Verify partners’ gardens

![preview image](https://static.tally.xyz/6fd4a192-1cb1-4dc7-b4bf-0f2eb165142f_400x400.jpg)

Full Doc below:

[https://docs.google.com/document/d/1rO_CXw4N9lFv5vWppFjop1QPp05CyHgX8-pJnfkceuc/edit?usp=sharing](https://docs.google.com/document/d/1rO_CXw4N9lFv5vWppFjop1QPp05CyHgX8-pJnfkceuc/edit?usp=sharing)


# Deploy Uniswap V3 on Moonbeam 

### Summary 

In support of furthering the vision of Multichain Uniswap, we at Blockchain at Berkeley are partnering with Nomad to propose that the Uniswap community authorize Nomad (Illusory Systems, Inc) to deploy Uniswap V3 to Moonbeam. The timeline for deployment will be approximately 3-4 weeks following the completion of this Governance Proposal. 

### Proposal Links
 - Governance Proposal: discussion
 - Consensus Check: discussion, snapshot (passed with 9.6M UNI in favor)
 - Temperature Check: discussion, snapshot (passed with 8.3M UNI in favor)

### Description 
Moonbeam is a Polkadot parachain which features EVM-compatibility, allowing it to serve as a port-of-entry for Ethereum-native apps to participate in the greater Polkadot ecosystem.

 We believe deploying Uniswap to Moonbeam will bring the following benefits to the Uniswap community: 
* Expansion into Polkadot: Uniswap will be able to tap into a brand new market and all the community members in the Polkadot ecosystem. Moonbeam’s EVM-compatibility makes it simple to deploy existing Solidity code, while simultaneously providing access to other parachains using XCM. By leveraging XCM and Moonbeam’s position as the DeFi hub for Polkadot, Uniswap has the opportunity to become the premier AMM across Polkadot.
 * Trust-minimized Governance: Per Uniswap’s goal of becoming a multi-chain protocol while remaining trust-minimized, we propose using Nomad’s trust-minimized channels to deploy Uniswap V3 on Moonbeam. This can serve as an opportunity to test this improved decentralized governance application within a safe container, with the potential of rolling it out to other V3 deployments in the future.
 * Rewards for Uniswap Grants Program: Instead of simply offering liquidity mining incentives, we want to fund community members working to develop and enrich multichain experiences built with Uniswap. The Moonbeam Foundation will commit $2.5M to the Uniswap Grants Program to fund cross-chain development deployed within the Uniswap ecosystem, in order to further expand Uniswap’s multi-chain presence.


# ❗️ [canceled] Gitcoin PGF workstream S14 funding request ratification

⚠️ **Note from Simona: This proposal sends the wrong currency, ETH instead of GTC, so don't vote for it! We'll let this one fail, then make a different proposal with GTC.**

The S14 PGF budget request has passed on Snapshot and this vote is to ratify those results on chain and to transfer their budget to them.

The snapshot vote is here for review: https://snapshot.org/#/gitcoindao.eth/proposal/0xbe39c3414e4622a2522dc4d6e9030deb56fa8b90304dae05cd1a2a6d50cb5537

The funds will go to a multisig controlled by PGF and will be distributed as described in the original proposal. The Gnosis safe that funds will be transferred to can be found at: https://gnosis-safe.io/app/eth:0xa7aC9f7087d7197e0047DB9A90562a1364bf897D/balances

*Please note that a denomination in dollar amount has been prioritized in budget proposals over GTC - so if the spot price assumed at posting of a budget changes between then and when the budget executes, the GTC amount will be readjusted to reflect the dollar amount at the time this proposal is moved to Tally or the 20 day moving average (whichever is lower) is moved to Tally.

