Ethereum Mainnet

Ether

Ethereum Testnet Rinkeby

Rinkeby Ether

Ethereum Testnet Görli

Görli Ether

Optimism

Ethereum Testnet Kovan

Kovan Ether

Binance Smart Chain Mainnet

Binance Chain Native Token

Optimism Testnet Kovan

Binance Smart Chain Testnet

Gnosis

xDAI

Polygon Mainnet

MATIC

Optimism Testnet Görli

Moonbeam

Glimmer

Arbitrum One

Arbitrus Nova

Avalanche Fuji Testnet

Avalanche

Avalanche C-Chain

Polygon Testnet Mumbai

Base Goerli Testnet

Goerli Ether

Arbitrum Rinkeby (Deprecated)

Arbitrum Testnet Rinkeby

Arbitrum Rinkeby Ether

Arbitrum Görli Rollup Testnet

Arbitrum Görli Ether

Scroll Alpha Testnet

Ethereum Testnet Sepolia

Sepolia Ether

# 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).

# Empty Uniswap Proposal

When upgrading Uniswap's governance contract, 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.



# Fund Lil Nouns Prop House

Proposal for Lil Nouns DAO to match 1:1 with Prop House Funds to fund the Lil Nouns Prop House: Lil Nouns puts up 15 ETH while Prop House Funds puts up another 15 ETH for a total of 30 ETH.

The rounds proposed are the following:

- Round 1: 5 winners for 2 ETH each
- Round 2: 11 winners for 1 ETH each.
- Round 3: 3 winners for 3 ETH each.

Each round is composed of a proposal period in which anyone with an Ethereum address can propose. Once the proposal period ends, a subsequent voting period starts where Lil Nouns vote for the proposal they believe should get funded (1 Lil Noun = 1 vote). Winners are simply those proposals which have the most votes.

The mandate of all rounds would be “All Things Nounish”. That is, proposals which are the most Nounish are most encouraged. For examples of what _nounish_ looks like - take a look at previously funded efforts:

- [Previous Prop House rounds](https://prop.house/0x9c8ff314c9bc7f6e59a9d9225fb22946427edc03)
- [Nouns DAO on-chain proposals](https://nouns.wtf/vote)
- [Small Grants](https://noun22.notion.site/noun22/Nouns-DAO-Small-Grants-ac22114a6c004bafa500e2d824e32dc3)

If passed, the funds would be managed via the Prop House multi-sig which would distribute funds at the end of each round’s voting period to the winners.

For more information on Prop House, please visit [https://prop.house](https://prop.house).


# BIP-20: Idle Finance Bounty

Through this governance proposal, we want to reward @adamb (username in discord) for the development of the Idle Finance Integration with 250 BABL.

https://docs.google.com/document/d/1CJb827-tRJnCHEJHoNQuMSzzOkJDovk5ph5kA6blUR4/edit#



# BIP-21: Security Bounty- Rewards

Awarding 2200 BABL to cover an Immunefi security bounty.

The vulnerability could have exploited our rewards distributor and stolen up to 15k BABL in a single transaction.

# BIP-25: Security Bounty- Rewards

Awarding 5000 USD (+500 USD as 10% as Immunefi fee) to cover an Immunefi security bounty (min high category reward). The vulnerability could have exploited our garden transfer function to increase user considered balance eligible for rewards up to double.

# CANCELED: Public Goods Funding S15 Budget Request

## NOTE

This proposal passed, but it expired before being executed. It cannot be executed anymore, so it'll be retried as [proposal 39.](https://www.tally.xyz/governance/eip155:1:0xDbD27635A534A3d3169Ef0498beB56Fb9c937489/proposal/39)
## Original Description:
This vote is looking to pass the S15 budget for the Public Goods Funding Workstream.

The total amount requested is $664,550, to be paid in GTC.

For more details, please see this post: https://gov.gitcoin.co/t/s15-proposal-integrated-pgf-budget-request/11220/5

The GTC total will be determined, based on (a) the current market price of GTC at the time this proposal is moved to Tally, and (b) the remaining balance in the PGF Multisig (which will determine how much net new funding we require).



# CANCELED: Public Goods Funding S15 Budget Request


## NOTE

This proposal has the wrong transfer amount  – 318 GTC instead of 318000 GTC – so don't vote for it.  See [proposal 39](https://www.tally.xyz/governance/eip155:1:0xDbD27635A534A3d3169Ef0498beB56Fb9c937489/proposal/39) instead.


# HIP 9: Hop Community Grants 

Author(s): Jack Clancy, Benji Cohen 

Contributors: N/A 

Status: RFC 

Date Posted: 2022-09-21

**Motivation:**

Hop is an emerging protocol with a large community of developers and users. It is one of the most used crypto apps in the last few months due to its utility and support for many of the most popular blockchain networks.

Establishing a grants program that funds independent developers to build on top of HOP will increase developer interest. Protocol developments could be alternative frontends, in depth analytics sites or dune dashboards, or sdks that make it easier to integrate with HOP, just to name a few. There have been several successful grants programs like Uniswap grants, Liquity, and Maker, which this proposal attempts to emulate.

**Renewal/Sunset:**

This program is intended to be reviewed after 6 months. After the trial period ends, if the program is not renewed, any unused $HOP token will be returned to the treasury.

**Funding**

The initial grants program will allocate 750k HOP to the grants program (~$100k), which holds a multisig at 0x1ECC9Ee9980348a2373c1F2EFbfDF520a389f35C. This should give the grants program enough funding to allocate several sizable grants to the HOP development program. The intention of this funding amount is not to definitely allocate all funds, but to have enough funds to give out several sizable grants if there are worthy candidates. As stated previously in this RFC, any unused funds will be returned to the treasury or rolled over into a more formalized grants program after the 6 month trial period.

**Reporting and administration:**

Developers wishing to seek a grant from the HOP grant program will have to apply via a forum post here, outlining what they plan to build, milestone deliverables, and the amount of funding they require to develop in line with their specifications.

DAO governance will select several eligible candidates (based on their technical expertise, prior contributions to their protocol and their willingness to contribute time to this initiative) to administer this grant program.

Grants under this program will receive a maximum of 100k HOP, which is ~$16k USD given current market pricing for HOP. The grants committee will allocate funds to developers as they see fit. The grants committee members could be as follows:

* Lito Coen - Hop Growth
* Getty Hill - GFX Labs
* 4Poops - HOP Delegate
* Jack Clancy - Developer and DAO contributor
* Chris Winfrey

The grants multisig is at the address 0x1ECC9Ee9980348a2373c1F2EFbfDF520a389f35C.

This is not a hard recommendation, would like to have community input from the DAO on committee members. Most importantly, members of this committee will be engaged, have a stake in HOP and have technical expertise to review grants proposals.

The grants committee will be added as admins to a Gnosis Safe that holds the funds allocated to the grants program. They will vote with a simple majority quorum whether or not to fund grants. Grant submissions will come via forum postings with a lightweight template developed if/when this proposal passes

**Disclaimer:** Jack Clancy and Benji Cohen are writing this on behalf of Web3 Equities, a liquid token fund run by Benji Cohen. The fund has a sizable $HOP position.


[Canceled]: Make $SUDO Transferrable

Note: the proposer wishes to withdraw this proposal. This proposal doesn't call the executable code that will make $SUDO transferrable.

## Original text

Will keep this short and sweet - the goal of this proposal is to make $SUDO transferable. Proposals around incentivizing liquidity for $SUDO can come at a later date. First priority is to release $SUDO into circulation as that is table stakes.

**As per the $SUDO** [announcement blog](https://blog.sudoswap.xyz/sudo-distribution.html): 

> “SUDO will initially be non-transferable. A governance proposal to initiate transferability may be put forward through the standard governance process for the sudoAMM protocol, which will be addressed at a later time. This is done as a measure to ensure SUDO does not go into circulation unless and until there can be assurance that there will be sufficient participation from SUDO holders in governance.”

By voting “yes” on this proposal, tokenholders are voting to make $SUDO transferable.

By voting “no,” you do not want your $SUDO tokens to be transferable.



# Add 1INCH to Aave v2 market
--
title: Add 1INCH to Aave v2 market
status: Proposed
author: Governance House - [Llama](https://twitter.com/llama), [Matthew Graham](https://twitter.com/Matthew_Graham_), [defijesus.eth](https://twitter.com/eldefijesus)
shortDescription: Add 1INCH as collateral on the Aave V2 market
discussions: https://governance.aave.com/t/arc-add-1inch-as-collateral/8056
created: 2022-07-18
---


## Simple Summary

Llama proposes listing 1INCH, the governance token of the 1inch Network, on Aave v2 mainnet as collateral with borrowing enabled. The risk parameters detailed within have been provided by Gauntlet. 

## Abstract

1inch is a network of decentralized protocols designed to provide the fastest and most efficient operations in the DeFi space. The 1inch Network was launched in May 2019 with the release of its Aggregation Protocol v1. The 1inch Aggregation Protocol is both the oldest and most trusted DEX aggregator in the DeFi space.

Listing 1INCH on Aave v2 will enable lenders to receive yield and borrowers of 1INCH to partake in 1inch’s tokenomics to vote and be reimbursed their gas cost to perform swaps on 1inch’s Aggregation Platform.

## Motivation

Listing 1INCH on the Aave v2 market would allow Aave to benefit from the first mover advantage and recognise the efforts of the 1inch team for being supportive of Aave since before v1.  

Since the original proposal to list 1INCH the team has removed minting roles on the token, introduced a progressive vesting schedule and created use cases for aTokens. The 1INCH token is supported by a Chainlink oracle feed and has favourable on-chain liquidity conditions.

## Specification

This proposal initializes the 1INCH reserve, enables variable borrowing, sets a reserve factor and configures the reserve as collateral. As needed, it also connects a price source on the AaveOracle.

## Test Cases

All the components involved in this proposal (tokens' implementations, interest rate strategy, oracle feed, proposal payload) have been tested and reviewed, including simulations on mainnet of the whole proposal lifecycle.

Link to Test Cases: [End-to-end test suite](https://github.com/defijesus/bdg-labs-aave-v2-listings/blob/master/src/test/Validation1InchListing.sol), [aToken/stableDebtToken/variableDebtToken verification](https://github.com/defijesus/bdg-labs-aave-v2-listings/tree/master/diffs), [deployment script](https://github.com/defijesus/bdg-labs-aave-v2-listings/blob/master/scripts/1InchListingPayload.s.sol)

## Implementation

We recommend the following risk parameters.

### Risk Parameters:

LTV 40%

Liquidation Threshold 50%

Liquidation Bonus 8.5%

Reserve Factor 20%

### Variable Interest Rate Parameters:

UOptimal 45%

R_0 0%

R_s1 7%

R_s2 300%


The snapshot vote to add 1INCH on Aave v2 mainnet market can be found [here](https://snapshot.org/#/aave.eth/proposal/0x2ea76814a0dfcad7ea1a7b3c597f059a8d574f8143886b23043918998505f5a7).  


- [ProposalPayload](https://etherscan.io/address/0xd417d07c20e31f6e129fa68182054b641fbec8bd#code)
- [aINCH implementation](https://etherscan.io/address/0x130FBED7dBA2b370f0F93b0Caea2cfD9b811D66D#code)
- [Variable Debt 1INCH implementation](https://etherscan.io/address/0x4d3707566Ee8a0ed6DE424a262050C7587da8152#code)
- [Stable Debt 1INCH implementation](https://etherscan.io/address/0x9C2114Bf70774C36E9b8d6c790c9C14FF0d6799E#code)
- [Interest rate strategy](https://etherscan.io/address/0xb2eD1eCE1c13455Ce9299d35D3B00358529f3Dc8#code) 
- [1INCH/ETH price feed](https://etherscan.io/address/0x72AFAECF99C9d9C8215fF44C77B94B99C28741e8#code)

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


#  stMATIC SupplyCap Increase Polygon v3"
---
title: stMATIC SupplyCap Increase Polygon v3"
status: Proposed
author: "Llama"
shortDescription: Llama proposes increasing the stMATIC Supply Cap on …"
discussions: https://governance.aave.com/t/arfc-increase-stmatic-supply-cap/12038
created: 03-03-2023
—

# Summary
    
    Llama proposes increasing the stMATIC Supply Cap on Polygon to facilitate an expansion of the stMATIC/wMATIC loop strategy. 
    
    # Abstract
    
    The utilisation of the stMATIC reserve has reached 100% and this proposal seeks to increase the SupplyCap to 15M units up from 7.5M units.  
    
    Increasing the SupplyCap will enable users to deposit stMATIC and enter the recursive stMATIC/wMATIC yield strategy.  
    
    Lido DAO currently has the ability to distribute LDO rewards on the Polygon v3 deployment. Due to the stMATIC SupplyCap being reached there is little to no incentive for Lido DAO to distribute LDO rewards. This proposal seeks to encourage Lido DAO to distribute LDO rewards, as early as March on the Aave v3 Polygon liquidity pools.
    
    # Motivation
    
    Over the previous months, Llama has been working with various communities to craft favourable conditions on Aave v3 Polygon to facilitate the creation of several yield aggregation products. The below proposals details are applicable to stMATIC:
    
    * [Proposal: Add Support for stMATIC (Lido)](https://governance.aave.com/t/proposal-add-support-for-stmatic-lido/7677)
    * [ARFC Aave v3 Polygon wMATIC Interest Rate Update](https://governance.aave.com/t/arfc-aave-v3-polygon-wmatic-interest-rate-update/10290)
    * [ARFC LDO Emission_Admin for Polygon v3 Liquidity Pool](https://governance.aave.com/t/arfc-ldo-emission-admin-for-polygon-v3-liquidity-pool/10575)
    * [ARFC stMATIC & MaticX Emission_Admin for Polygon v3 Liquidity Pool](https://governance.aave.com/t/arfc-stmatic-maticx-emission-admin-for-polygon-v3-liquidity-pool/10632)
    
    This proposal is a continuation of the above work.
    
    Analysis performed by [Gauntlet](https://governance.aave.com/t/gauntlet-methodologies-borrow-and-supply-cap/11487) generated a conservative and aggressive SupplyCap ceiling of 16.17M and 24.26M units respectively.  
    
    Chaos Lab's supports increasing the SupplyCap to 15M units. This follows the general rule of thumb that SupplyCap should not be more than doubled in any single proposal.
    
    As Chaos Lab's recommendation is less than the maximum conservative SupplyCap presented by Gauntlet's methodology, Llama proposes increasing the SupplyCap to 15M SupplyCap.
    
    With reference to the new [ARFC Aave V3 Caps update Framework](https://governance.aave.com/t/arfc-aave-v3-caps-update-framework/11937/1) it is possible to ship several upgrades to gradually increasing Aave's exposure to stMATIC over time.
    
    # Specification
    
    The following risk parameters being proposed have been reviewed by Gauntlet and Chaos Labs.
    
    Ticker: stMATIC
    
    Contract: [`polygon: 0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4`](https://polygonscan.com/address/0x3a58a54c066fdc0f2d55fc9c89f0415c92ebf3c4)
    
    |Parameter|Current Value|Proposed Value|
    | --- | --- | --- |
    |SupplyCap|7.5M units|15M units|
    
    # Implementation
    
    A list of relevant links like for this proposal:
    
    * [Governance Forum Discussion](https://governance.aave.com/t/arfc-increase-stmatic-supply-cap/12038)
    * [Test Cases](https://github.com/bgd-labs/aave-proposals/blob/master/src/test/polygon/AaveV3PolSTMATICCapUpdatePayloadTest.t.sol)
    * [Payload Implementation](https://github.com/bgd-labs/aave-proposals/blob/master/src/contracts/polygon/AaveV3PolSTMATICCapUpdatePayload.sol)
    * [Deployed Contracts](https://polygonscan.com/address/0xaa7ef2f9b31fa26e802ca9b3e33990ada4143fb9#code)
    
    Chaos Labs and Gauntlet both contributed to the development of the ARFC forum post. 
    
    The proposal Payload was reviewed by [Bored Ghost Developing](https://bgdlabs.com/).
    
    # Copyright
    
    Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
    


Upgrade Proposal: Bedrock 

This proposal outlines the Optimism Collective’s first Protocol upgrade of Optimism Mainnet to the Bedrock release. This upgrade aims to provide unprecedented modularity, simplicity, and Ethereum equivalence to the L2 network, with positive impacts on performance and security. 

Bedrock is the codebase which will help Optimism stand the test of time, and is also preparatory step towards the multi-chain future. 

This Protocol Upgrade proposal is eligible for voting in Voting Cycle #11: https://gov.optimism.io/t/final-upgrade-proposal-bedrock-v2/5548


Delegate Suspension: Fractal Visions

All Optimism Delegates are bound by the delegate code of conduct (https://gov.optimism.io/t/delegate-code-of-conduct/3943.) Severe code of conduct violations are subject to a three month suspension and are decided via Token House vote. 

This Delegate Suspension Proposal is eligible for voting in Voting Cycle #11: https://gov.optimism.io/t/delegate-suspension-fractal-visions/5710 

// Note: the approval threshold for this proposal is 51%, or 20424975 OP. The value displayed by the frontend may differ.


# Intent #4 Budget Proposal

Season 4 lays the groundwork to align the entire community around Collective Intents. Intents are directional goals that allow the Collective to align and focus. Intent #4 is: Governance Accessibility. The Foundation has set this Intent and proposed a budget of 3M OP to support Proposed Missions in Season 4. Any budget that is not allocated to Missions under this Intent will be returned to the Governance Fund. 

This Season 4 proposal is eligible for voting in Special Voting Cycle #12a: [https://gov.optimism.io/t/collective-intents/5874#intent-4-governance-accessibility-6](https://gov.optimism.io/t/collective-intents/5874#intent-4-governance-accessibility-6)


# Intent #2 - Council Intent Budget Proposal

In Season 3, we experimented with a Grants Council. If renewed, the Grants Council would manage Intent #2: Innovate on Novel Applications. If this Council Intent Budget is approved, it will renew the Council for another Season and elect the proposal author, Dane Lund, as Council Lead. Reviewer Elections will take place in Special Voting Cycle #12b, if this budget is approved. Any budget that is not allocated to Missions under this Intent will be returned to the Governance Fund.

This Season 4 proposal is eligible for voting in Special Voting Cycle #12a:
- [https://gov.optimism.io/t/draft-season-4-council-intent-budget-proposal/5925](https://gov.optimism.io/t/draft-season-4-council-intent-budget-proposal/5925)
- [https://gov.optimism.io/t/council-framework-and-renewal/5884](https://gov.optimism.io/t/council-framework-and-renewal/5884)

# Intent #1 Budget Proposal

Season 4 lays the groundwork to align the entire community around Collective Intents. Intents are directional goals that allow the Collective to align and focus. Intent #1 is: Progress Towards Technical Decentralization. The Foundation has set this Intent and proposed a budget of 1M OP to support Proposed Missions in Season 4. Any budget that is not allocated to Missions under this Intent will be returned to the Governance Fund.

This Season 4 proposal is eligible for voting in Special Voting Cycle #12a: [https://gov.optimism.io/t/collective-intents/5874#intent-1-progress-towards-technical-decentralization-2](https://gov.optimism.io/t/collective-intents/5874#intent-1-progress-towards-technical-decentralization-2)

# Protocol Delegation Program Renewal

In Season 3, the Protocol Delegation Program was piloted as a way to enable protocols, some of our most important stakeholders, to participate in governance. The Protocol Delegation Program temporarily delegates up to 5M OP from the Governance Fund to value-aligned protocols based on pre-defined criteria. This program was designed to last two Seasons in total, and this proposal would continue the program for duration of the final Season (Season 4.)

After Season 4, particpating protocols will need to reaffirm their commitment to Optimism governance via their own treasuries. This Season 4 proposal is eligible for voting in Special Voting Cycle #12a:

[https://gov.optimism.io/t/protocol-delegation-program-renewal/5883](https://gov.optimism.io/t/protocol-delegation-program-renewal/5883)

# Intent #3 Budget Proposal

Season 4 lays the groundwork to align the entire community around Collective Intents. Intents are directional goals that allow the Collective to align and focus. Intent #3 is: Spread Awareness of the Optimistic Vision. The Foundation has selected this Intent from commnunity suggestions and proposed a budget of 1M OP to support Proposed Missions in Season 4. Any budget that is not allocated to Missions under this Intent will be returned to the Governance Fund.

This Season 4 proposal is eligible for voting in Special Voting Cycle #12a: 

[https://gov.optimism.io/t/collective-intents/5874#intent-3-spread-awareness-of-the-optimistic-vision-4](https://gov.optimism.io/t/collective-intents/5874#intent-3-spread-awareness-of-the-optimistic-vision-4)

Treasury test proposal

This proposal doesn't do anything

Core Test Proposal

This proposal does nothing. No need to vote for this one

Uniswap

Uniswap is a decentralized protocol for automated liquidity provision on Ethereum.

# Governance Proposal - Uniswap V3 Launch on zkEVM
Point of Contact: Jack Melnick, 
TG: jackmelnick, email: jmelnick@polygon.technology

# Proposal summary
## Uniswap V3 launch on Polygon zkEVM.

### Overview of proposal
We propose to authorize Polygon Labs to deploy Uniswap’s protocol to the Polygon Zero Knowledge Ethereum Virtual Machine rollup known as “zkEVM” on behalf of the community.

We believe this is the right moment for Uniswap v3 to deploy on Polygon zkEVM, for several major reasons:

* Polygon zkEVM is a new zk-rollup that provides Ethereum Virtual Machine (EVM) equivalence (opcode-level compatibility) for a transparent user experience and existing Ethereum ecosystem and tooling compatibility.
* An Ethereum L2 scalability solution utilizing cryptographic zero-knowledge technology to provide validation and fast finality of off-chain transaction computations.
* A new set of tools and technologies were created and engineered and are contained in this organization, to address the required recreation of all EVM opcodes for transparent deployment and transactions with existing Ethereum smart contracts.
* Polygon is aligned with Ethereum and its values.

### About Polygon Labs

Polygon Labs is the leading platform for Ethereum scaling and infrastructure development. It is rapidly building a suite of protocols that will offer developers easy access to all major scaling and infrastructure solutions:

- L2 solutions/Rollups (Polygon Hermez 2, Polygon Miden 2);
- Sidechains, stand-alone and enterprise chains (Polygon SDK 1);
- Hybrid solutions (Polygon PoS);
- Data availability solutions (Polygon Avail 2) and more.

The Polygon network is by far the most adopted scaling effort in the Ethereum ecosystem, with 3,000+ applications hosted, 1B+ transactions processed, 100M+ unique user addresses and ~$5B+ in assets secured.

### Motivation
There’s significant value in Uniswap being available on an EVM compatible ZK rollup. Deploying early on zkEVM helps solidify Uniswap’s place as the number one DEX and a thought leader.

Importantly, it will help grow a large list of projects that can be built on Uniswap V3. Additionally, given the community and user uptake Uniswap has seen on Polygon PoS, it’s only natural to make its deployment on Polygon zkEVM a priority.

## Partner Details
### Polygon Labs

This proposal is being made by Jack Melnick, DeFi BD Lead, an employee of Polygon Labs. Polygon Labs is a legal entity focused on the ecosystem growth and maintenance of the suite of Polygon Networks.

### Partner Legal

The legal entity that is supporting this proposal is Polygon Labs Services (Switzerland) AG, a Swiss corporation known as “Polygon Labs”.

### Delegate Sponsor

There is no delegate co-authoring or sponsoring this proposal. Instead, this is a proposal submitted by Jack Melnick of Polygon Labs to support the growth of Polygon as part of the overall Polygon community.

### Conflict of Interest Declaration

There are no existing financial or contractual relationships between Polygon Labs and any of Uniswap’s legal entities, including Uniswap Labs, UNI tokens, nor investments of Uniswap Labs Ventures.

## KPI & Success Criteria

### Target KPIs
There are generally 2 forms of projects:

1) Growth-driven projects: on-chain, trackable metrics preferred here.
 
![a7f2d31aea283aae96a2e18a8c30badeba702d6f.png](ipfs://bafkreic7vtw65gqmqgrs46pbhdh4n6bbvd6kusbj77jz3cfsuwq4inj2mm)
    
2) Strategic Initiatives: that targets a specific goal (e.g. Uniswap Foundation core initiatives). These are more completion based.

![cb3bb480aa0a9ae1b520f73a0e0c16654f8f9e33.png](ipfs://bafkreidivzmticu723vvql57p6suqwurkd3lekjmfsbspy3h72pjn4ul6u)
 
### What does success look like?

Success Criteria: A successful zkEVM deployment will, in an organic and sustained manner, grow Uniswap’s Total Addressable Market across TVL, unique interacting wallet, volumes, and integration with partner dApps. As demand for zk-blockchains and proximity to Ethereum rises, users and builders will increasingly look to zkEVM solutions to build and trade.

### What potential risks are there for this project’s success? How could they be mitigated?

Risk Profile: Deploying on zkEVM should pose minimal risks, relative to deploying on alternate blockchains. As an Ethereum Layer Two, it uses Zero Knowledge proofs to inherit Ethereum’s core safety, while allowing developers to easily deploy existing EVM codebases. 

The bridge has been disintermediated, and Uniswap can expect reputable Oracle providers to be available as data providers from Day One. Polygon’s zkEVM testnet has been running for the past six months, and has accumulated over 84,000 wallets, 75,000 ZK proofs, and 300,000 blocks. Additionally, the deployment has been audited multiple times, by auditors including Spearbit and Hexens. 

Primary risks, as always, include still unforeseen vectors, which can be mitigated through close work with Polygon developer support (whenever needed) and gradual deployment of liquidity on the new chain.

### Protocol security
Please address the following questions if you’re proposing a cross-chain deployment:

**Does the bridge support arbitrary message passing?** Yes

**Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?** No trusted entity, multi-sig, or a protocol/set of incentivized nodes, only L1 and L2 security. Pure smart contract interactions only.

**Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?** All based on L1 and L2. L2 security is based on the L1.

**Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?** There are two ways to use the bridge:
- Native supported messages: Allow only bridging of ERC-20 and ETH. Here there is nothing someone can do other than that.
- Custom Messages: Custom receiver logic on the other side of the bridge. When you send a message the message needs to be received by a smart contract, so you have to build the receiver smart contract, which is specific to the logic of that smart contract. Here the security is up to the person building the receiver smart contract. These custom messages do not take custody of any funds. All we guarantee is that the message will pass the bridge if implemented correctly. We are just the message carrier.

**What are the ramifications of fraud to the malicious actor?** Here we assume no possibility for fraud.

**Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?** There is an ongoing audit process by a third party. We will not go to Mainnet without the results from the audit and vulnerabilities remedied.