# 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

# [OLD] AIP-1.1 - Lockup, Budget, Transparency

*Note: Due to an incorrect vesting date, this proposal has been replaced by [a new version of the same proposal](https://www.tally.xyz/gov/arbitrum/proposal/70545629960586317780628692755032548222173912190231545322320044688071893662480)*

## Abstract
tl;dr: AIP-1.1 proposes (1) a lockup, (2) a budget and (3) transparency reporting regarding the 7.5% of the $ARB tokens distributed to the Foundation’s “Administrative Budget Wallet”.

The Administrative Budget Wallet will be used for covering ongoing administrative and operational costs of The Arbitrum Foundation, payment of service providers, and for the purpose of fostering the growth and development of the Arbitrum ecosystem. In respect to the 7.5% that has been distributed to the Administrative Budget Wallet, a transparency report regarding the 0.5% that has already been transferred is available here 163.

The remaining 7% of tokens will not be used until the approval of a budget, such as the one proposed in this AIP. The proposed budget is in-line with the Foundation’s strategic needs to represent and service the DAO and the allocation is smaller than initial allocations to peer foundations. This AIP proposes placing the 7% outstanding distribution in a smart contract-controlled lockup – linearly unlocking over 4 years – alongside transparency report structures to allow the DAO to periodically monitor expenditures and other activities of the Foundation.

The Administrative Budget Wallet will be used in pursuit of the Foundation’s mission statement as set out in the bylaws 24, which includes financing technical improvements and operations of the Arbitrum network, fostering ecosystem growth through grants to align with partner projects and educational initiatives with in-person and online events.

## Motivation
On March 16, 2023, the Arbitrum networks (Arbitrum One and Arbitrum Nova) were decentralized and given to the newly formed Arbitrum DAO. Included in this transition were:
- Control of the upgradeability and technical future of the chains
- Control over the DAO treasury
- Control over net fee revenue - i.e. the net difference between fees collected by on-chain operations and L1 fees paid by the Sequencer
- All Arbitrum social media platforms and accounts
- Ability to elect and, if deemed appropriate, remove the Security Council and Directors

Full responsibility of the chain’s technology, future, and fee revenue were given to the DAO directly. With the DAO assuming those rights and controls, the DAO also assumed the responsibility to fund the ongoing operations of the chains and the costs of running critical chain infrastructure, including RPCs, the Sequencer, and third-party vendors and service contracts.

While there are many activities that the DAO can do directly on-chain, several of its responsibilities require a representative that can engage, maintain and enter new agreements with service providers to run infrastructure that’s critical for the ecosystem (e.g. servers, RPCs, block explorers, data feeds and analytics platforms, and tooling), and ensure that both the chain and the ecosystem have the support they need to continue to thrive. In order to ensure a smooth transition to the DAO without any interruption of services, it was necessary to create an organization that would be ready to service the DAO immediately from launch.

The Arbitrum Foundation was created to fill this need, with its mission and scope outlined across the Foundation Bylaws 24. Prior to the launching of the DAO, The Arbitrum Foundation assumed responsibilities for funding and running chain infrastructure. However, in an arrangement that appears to be unique amongst Arbitrum’s peers, the Foundation does not receive or control the net revenue from transaction fees as this is given directly to the DAO treasury.

The DAO is also tasked with fostering and developing the Arbitrum ecosystem, where the DAO may seek to partner with companies or organizations that either cannot or will not publicly negotiate collaborations or partnerships due to confidentiality and other operational requirements. Often, large enterprises negotiate partnership opportunities in private without public processes, where these relationships can only be disclosed after they are agreed upon. Having a well-funded Foundation empowered to represent the DAO in this arena, alongside peer foundations, is in the best interests of the DAO to further develop the growth of the Arbitrum ecosystem.

## Rationale
While the need for the Foundation to exist and represent the DAO is well-motivated, it became clear through community discourse around AIP-1 that it was important to have additional insight and restrictions on the Foundation’s initial funding. This AIP-1.1 proposes a detailed set of controls and initiatives to achieve that goal.

1. Smart Contract Lockup:

The remaining 7% of ARB tokens in the “Administrative Budget Wallet” will be subject to a four year lockup schedule, unlocking on a continuous linear time basis commencing from the date of the Snapshot approval of AIP-1.1 by the DAO (i.e., a total of 175m $ARB released over each year for 4 years). The lockup will be enforced on-chain through a smart contract which will designate a multisig wallet controlled by The Arbitrum Foundation as the beneficiary. The lockup contract will be configured in a manner that allows the DAO to adjust future funding and/or modify the unlock schedule.

2. Operating Budget:

Below is a proposed annual operational budget for the first year of the Foundation. While the operational costs are denominated in USD, the expectation is that approximately half will be paid in USD and half will be paid in locked $ARB tokens.

As this will be the first year of the Foundation’s operation and as the Foundation is still young at the time of this AIP, it goes without saying that these are estimates with the expectation that this will be an upper bound on the operational costs for the first 12 months. The transparency reports described in the next section will be an opportunity to track the actual expenses against the budgeted categories and keep the community informed.

- Operating Budget: Cost ($USD)
- General and Administrative: $16,000,000
- R\u0026D: $9,000,000
- Technical Infrastructure: $5,000,000
- Events, Marketing \u0026 Communications: $6,000,000
- Total - Next Twelve Months: $36,000,000
- (50% $USD/50% $ARB)

*The General and Administrative line-item includes personnel, contractors, legal, insurance and other operational costs. As of the date of this AIP, the Foundation currently has five full-time contributors, 8 contractors, and the Security Council engaged to support the Arbitrum ecosystem. The Foundation’s budget anticipates the need to hire an additional 15 full-time contributors across technical, growth and community functions over the course of this year.

This operating budget presents best-faith estimates of the Foundation’s anticipated budgetary needs which may be subject to change.

3. Ecosystem Growth Initiatives

Any additional funds released in compliance with the lock-up schedule above will be made available, but not necessarily deployed, to opportunistically pursue ecosystem growth opportunities and strategic partnerships on behalf of the DAO. The expectation is that the vast majority of ecosystem growth funds will be paid in tokens, and thus will not require the Foundation to sell any tokens. Wherever reasonable, the Foundation will include additional lockups and/or vesting when making distributions in tokens.

The Mission Statement in the Foundation’s bylaws 24 highlights the varied nature of the opportunities the Foundation intends to pursue, and a set of KPIs that can track all of these opportunities being developed. The basis of those KPIs will stem from a focus on onboarding and growing both the developer and user base of the Arbitrum ecosystem, attracting best-in-class infrastructure providers to the network, expanding across various industries, use-cases and scope of projects that engage with Arbitrum technology. The ultimate goal of the Foundation is to continue to foster the development of the technology and expand the Arbitrum ecosystem globally.

In addition to the Foundation’s processes for selecting grants, it is important to note that the DAO maintains control over the 3.527 billion $ARB and has the ability to distribute any additional grants as it sees fit. Additionally, should the DAO choose, it has the ability to trigger the inflation of the total supply of $ARB which will supplement the on-chain DAO treasury with 2% growth of the total supply of $ARB each year.

4. Transparency Reports

The Foundation understands and agrees that the community should have oversight across how these funds are being utilized to gain comfort that spending is in the interest of the community. In furtherance of this goal, the Foundation is committed to providing a comprehensive annual report and a semi-annual progress update. This will provide the community with a better understanding of the Foundation’s expenditures, balance sheet and its pursuit of ecosystem growth opportunities alongside partnership developments, as well as the various internal and external committees and stakeholders that are involved in the decision making process.

The Foundation is continuing to build out its internal personnel to service grant requests and has already engaged a DAO service provider to assist with the administrative components of servicing grants. The Foundation is also talking with a number of different external service providers to assist in both the review and diligence processes.

The financial element of these transparency reports will include a breakdown of operational costs incurred while running the Foundation, including infrastructure spending for the Arbitrum chains, events, community building efforts, grants, etc.

In addition to the aforementioned reports, the Foundation is providing an initial transparency report alongside this AIP covering all major actions and decisions the Foundation made during set-up, including the costs incurred up until now, which can be found [here](https://docs.arbitrum.foundation/foundational-documents/transparency-report-initial-foundation-setup).

Links:
- Snapshot temperature check: [https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae](https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae)
- GitHub PR: [https://github.com/ArbitrumFoundation/governance/pull/44](https://github.com/ArbitrumFoundation/governance/pull/44)
- Forum discussion thread: [https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/1](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/1)

# [UPDATED] AIP-1.1 - Lockup, Budget, Transparency

## ATTENTION:

This is an updated version of a similar proposal that has been put up for a vote a day prior to this one. We have discovered that the target vesting contract in the previous proposal had an incorrect \"start\" date. A more detailed explanation is provided below. Please do not vote on the other proposal and vote on this proposal instead.

### What happened?

The way this proposal works is that there is a special AIP smart contract (AIP1Point1Target) that references the location of the vesting vault for the Foundation Administrative Budget Wallet. The on-chain action that the proposal is executing is changing of the “passed” parameter on this AIP smart contract from false to true, documenting DAOs approval for the Foundation to use this referenced vesting vault, after the vote the Foundation will move 700M ARB tokens that are subject of AIP 1.1 to this contract and will be able to retrieve the vested amount to the Foundation’s multisig. 

One parameter of this setup is a “start” timestamp, which determines the point in time from which the vesting schedule is being calculated. According to the text of AIP-1.1: “…ARB tokens in the “Administrative Budget Wallet” will be subject to a four year lockup schedule, unlocking on a continuous linear time basis commencing from the date of the Snapshot approval of AIP-1.1 by the DAO…”. So this timestamp should be set to 1681754400, which translates to Monday, 17 April 2023 18:00:00 GMT, the date of the Snapshot approval. However, in the vesting contract that was subject to the original vote, it has been wrongly set to the date of the ARB Airdrop (1679590871, which translates to Thursday, 23 March 2023 17:01:11 GMT). This means that the smart contract configuration did not reflect the text of the AIP and would result in the effective unlocked vested amount being too large.

### Resolution

Since we cannot cancel the vote at this point (it could be canceled by the Security Council, but only after the vote has passed), after thorough discussion, we have decided to create a new proposal with the correct smart contracts that are referenced in the vote. We recommend that the DAO ignore the other AIP-1.1 vote, and instead vote on this one.

If you’d like to check the parameters are set correctly this time, you can check (for example using Arbiscan) the AIP smart contract referenced by this vote: [https://arbiscan.io/address/0x9E43f733Da0445b35f038FB34a6Fb8C2947B984C#code](https://www.tally.xyz/gov/arbitrum/proposal/79904733039853333959339953965823982558487956291458141923259498272549038367575). In the Contract tab you can go to the Read contract sub-tab and check that the arbitrumFoundationWallet parameter references smart contract at [0x15533b77981cda0f85c4f9a485237df4285d6844](https://arbiscan.io/address/0x15533b77981cda0f85c4f9a485237df4285d6844), which is the vesting vault. You can now go to this smart contract and, again, go to the Contract tab, and Read as Proxy sub-tab to see that the “start” parameter is set correctly to 1681754400. 

We hope that this resolution will cause as little confusion as possible among delegates. We plan to publish \"lessons learned\" from this case at a later date to elaborate on this case and suggest certain procedures to be implemented in the future to minimize the chances of such mistakes happening again. 


***


Category: Non-constitutional

### Abstract

tl;dr: AIP-1.1 proposes (1) a lockup, (2) a budget and (3) transparency reporting regarding the 7.5% of the $ARB tokens distributed to the Foundation’s “Administrative Budget Wallet”.

The Administrative Budget Wallet will be used for covering ongoing administrative and operational costs of The Arbitrum Foundation, payment of service providers, and for the purpose of fostering the growth and development of the Arbitrum ecosystem. In respect to the 7.5% that has been distributed to the Administrative Budget Wallet, a transparency report regarding the 0.5% that has already been transferred is available here 163.

The remaining 7% of tokens will not be used until the approval of a budget, such as the one proposed in this AIP. The proposed budget is in-line with the Foundation’s strategic needs to represent and service the DAO and the allocation is smaller than initial allocations to peer foundations. This AIP proposes placing the 7% outstanding distribution in a smart contract-controlled lockup – linearly unlocking over 4 years – alongside transparency report structures to allow the DAO to periodically monitor expenditures and other activities of the Foundation.

The Administrative Budget Wallet will be used in pursuit of the Foundation’s mission statement as set out in the bylaws 24, which includes financing technical improvements and operations of the Arbitrum network, fostering ecosystem growth through grants to align with partner projects and educational initiatives with in-person and online events.

### Motivation

On March 16, 2023, the Arbitrum networks (Arbitrum One and Arbitrum Nova) were decentralized and given to the newly formed Arbitrum DAO. Included in this transition were:

- Control of the upgradeability and technical future of the chains
- Control over the DAO treasury
- Control over net fee revenue - i.e. the net difference between fees collected by on-chain operations and L1 fees paid by the Sequencer
- All Arbitrum social media platforms and accounts
- Ability to elect and, if deemed appropriate, remove the Security Council and Directors

Full responsibility of the chain’s technology, future, and fee revenue were given to the DAO directly. With the DAO assuming those rights and controls, the DAO also assumed the responsibility to fund the ongoing operations of the chains and the costs of running critical chain infrastructure, including RPCs, the Sequencer, and third-party vendors and service contracts.

While there are many activities that the DAO can do directly on-chain, several of its responsibilities require a representative that can engage, maintain and enter new agreements with service providers to run infrastructure that’s critical for the ecosystem (e.g. servers, RPCs, block explorers, data feeds and analytics platforms, and tooling), and ensure that both the chain and the ecosystem have the support they need to continue to thrive. In order to ensure a smooth transition to the DAO without any interruption of services, it was necessary to create an organization that would be ready to service the DAO immediately from launch.

The Arbitrum Foundation was created to fill this need, with its mission and scope outlined across the Foundation Bylaws 24. Prior to the launching of the DAO, The Arbitrum Foundation assumed responsibilities for funding and running chain infrastructure. However, in an arrangement that appears to be unique amongst Arbitrum’s peers, the Foundation does not receive or control the net revenue from transaction fees as this is given directly to the DAO treasury.

The DAO is also tasked with fostering and developing the Arbitrum ecosystem, where the DAO may seek to partner with companies or organizations that either cannot or will not publicly negotiate collaborations or partnerships due to confidentiality and other operational requirements. Often, large enterprises negotiate partnership opportunities in private without public processes, where these relationships can only be disclosed after they are agreed upon. Having a well-funded Foundation empowered to represent the DAO in this arena, alongside peer foundations, is in the best interests of the DAO to further develop the growth of the Arbitrum ecosystem.

### Rationale
While the need for the Foundation to exist and represent the DAO is well-motivated, it became clear through community discourse around AIP-1 that it was important to have additional insight and restrictions on the Foundation’s initial funding. This AIP-1.1 proposes a detailed set of controls and initiatives to achieve that goal.

1. Smart Contract Lockup:

The remaining 7% of ARB tokens in the “Administrative Budget Wallet” will be subject to a four year lockup schedule, unlocking on a continuous linear time basis commencing from the date of the Snapshot approval of AIP-1.1 by the DAO (i.e., a total of 175m $ARB released over each year for 4 years). The lockup will be enforced on-chain through a smart contract which will designate a multisig wallet controlled by The Arbitrum Foundation as the beneficiary. The lockup contract will be configured in a manner that allows the DAO to adjust future funding and/or modify the unlock schedule.

2. Operating Budget:

Below is a proposed annual operational budget for the first year of the Foundation. While the operational costs are denominated in USD, the expectation is that approximately half will be paid in USD and half will be paid in locked $ARB tokens.

As this will be the first year of the Foundation’s operation and as the Foundation is still young at the time of this AIP, it goes without saying that these are estimates with the expectation that this will be an upper bound on the operational costs for the first 12 months. The transparency reports described in the next section will be an opportunity to track the actual expenses against the budgeted categories and keep the community informed.

- Operating Budget: Cost ($USD)
- General and Administrative: $16,000,000
- R\u0026D: $9,000,000
- Technical Infrastructure: $5,000,000
- Events, Marketing \u0026 Communications: $6,000,000
- Total - Next Twelve Months: $36,000,000
- (50% $USD/50% $ARB)

*The General and Administrative line-item includes personnel, contractors, legal, insurance and other operational costs. As of the date of this AIP, the Foundation currently has five full-time contributors, 8 contractors, and the Security Council engaged to support the Arbitrum ecosystem. The Foundation’s budget anticipates the need to hire an additional 15 full-time contributors across technical, growth and community functions over the course of this year.

This operating budget presents best-faith estimates of the Foundation’s anticipated budgetary needs which may be subject to change.

3. Ecosystem Growth Initiatives

Any additional funds released in compliance with the lock-up schedule above will be made available, but not necessarily deployed, to opportunistically pursue ecosystem growth opportunities and strategic partnerships on behalf of the DAO. The expectation is that the vast majority of ecosystem growth funds will be paid in tokens, and thus will not require the Foundation to sell any tokens. Wherever reasonable, the Foundation will include additional lockups and/or vesting when making distributions in tokens.

The Mission Statement in the Foundation’s bylaws 24 highlights the varied nature of the opportunities the Foundation intends to pursue, and a set of KPIs that can track all of these opportunities being developed. The basis of those KPIs will stem from a focus on onboarding and growing both the developer and user base of the Arbitrum ecosystem, attracting best-in-class infrastructure providers to the network, expanding across various industries, use-cases and scope of projects that engage with Arbitrum technology. The ultimate goal of the Foundation is to continue to foster the development of the technology and expand the Arbitrum ecosystem globally.

In addition to the Foundation’s processes for selecting grants, it is important to note that the DAO maintains control over the 3.527 billion $ARB and has the ability to distribute any additional grants as it sees fit. Additionally, should the DAO choose, it has the ability to trigger the inflation of the total supply of $ARB which will supplement the on-chain DAO treasury with 2% growth of the total supply of $ARB each year.

4. Transparency Reports

The Foundation understands and agrees that the community should have oversight across how these funds are being utilized to gain comfort that spending is in the interest of the community. In furtherance of this goal, the Foundation is committed to providing a comprehensive annual report and a semi-annual progress update. This will provide the community with a better understanding of the Foundation’s expenditures, balance sheet and its pursuit of ecosystem growth opportunities alongside partnership developments, as well as the various internal and external committees and stakeholders that are involved in the decision making process.

The Foundation is continuing to build out its internal personnel to service grant requests and has already engaged a DAO service provider to assist with the administrative components of servicing grants. The Foundation is also talking with a number of different external service providers to assist in both the review and diligence processes.

The financial element of these transparency reports will include a breakdown of operational costs incurred while running the Foundation, including infrastructure spending for the Arbitrum chains, events, community building efforts, grants, etc.

In addition to the aforementioned reports, the Foundation is providing an initial transparency report alongside this AIP covering all major actions and decisions the Foundation made during set-up, including the costs incurred up until now, which can be found [here](https://docs.arbitrum.foundation/foundational-documents/transparency-report-initial-foundation-setup).

### Links:

Previous version of this proposal with misconfiguration issue: [https://www.tally.xyz/gov/arbitrum/proposal/79904733039853333959339953965823982558487956291458141923259498272549038367575](https://www.tally.xyz/gov/arbitrum/proposal/79904733039853333959339953965823982558487956291458141923259498272549038367575)

Snapshot temperature check: [https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae](https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae)

GitHub PR: [https://github.com/ArbitrumFoundation/governance/pull/44](https://github.com/ArbitrumFoundation/governance/pull/44)

Forum discussion thread: [https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/1](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360/1)

# AIP 4: Update Security Council Election Start Date to Ensure Time for Security Audit

**Category: Constitutional - Process**

-   Disclaimers:

1.  The text changed slightly since snapshot (becuase of L2Beat's forum comment)
2.  This proposal and the attached executable were created by the Arbitrum Foundation *

High Level Overview
-------------------

The ArbitrumDAO Constitution specifies that the first Security Council election should start on the 15th September alongside a specification for the election.

An on-chain implementation of the entire election is still a work in progress. The Arbitrum Foundation has sponsored the implementation of a smart contract suite by Offchain Labs, an extension of Tally's user interface, and the respective audits.

This proposal seeks to revise the ArbitrumDAO Constitution to provide flexibility for the start date of the election. If passed by a Constitutional Vote, the new start date will be on the 15th September or the earliest possible date in which an on-chain election can begin.

The motivation to change the election's start date is to provide time for the implementation to be completed, security audits to be performed, for the community to gain confidence in the quality of its implementation and for the Arbitrum DAO to vote on a separate Constitutional AIP to install an on-chain election system.

The overarching goal is to still allow the election to begin on the 15th September, but it is prudent to provide leeway and ensure all parties, especially the Arbitrum DAO, are confident in the election software's security and completeness.

Path to a Smart Contract Enabled Election
-----------------------------------------

This proposal seeks approval from the Arbitrum DAO that the first and all subsequent security elections should be performed via the on-chain election process.

The activation of the Security Council election is dependent on:

-   Complete implementation for the on-chain smart contracts,
-   Complete implementation of the user interface,
-   Smart contract audit by a highly regarded auditing firm,
-   All parties, including the Arbitrum DAO, have gained confidence in the implementation's completeness and security,
-   Successful Constitutional Vote by the DAO to install the new election software.

A vote on this proposal is approving that the above conditions are mandatory for any election software before it can be installed into the on-chain smart contracts.

Modified Start Date for Election
--------------------------------

The implementation sponsored by the Arbitrum Foundation should be ready for the start date of the 15th September.

Even so, given the naunces of implementation details and the potential security risks to a critical part of the system, we believe it is still prudent to provide leeway and extra time for the Security Council elections to begin some time after the required date set out by The Arbitrum Foundation.

After all, it is not just about having a complete implementation, but ensuring all parties have confidence that all efforts have made been to minimize the risk of bugs in the implementation.

### Revision to ArbitrumDAO Constitution

The revised text focuses on the election beginning at the earliest possible date from the 15th September. Additionally, the election can only begin once an on-chain election system is installed via a separate Constitutional Vote.

All future elections can begin exactly six months after the previous election. As such, the chosen date for the first election will decide the earliest start date for the next election.

For extra clarity in the text, we have renamed "September Cohort" to "First Cohort" and "March Cohort" to "Second Cohort"

Finally, to remove any ambiguity, all security council members are expected to serve the time until the new Security Council members are installed in the respective smart contracts.

### Current text of ArbitrumDAO Constitution:

> The Security Council has 12 members, who are divided into a September Cohort of 6 members, and a March Cohort of 6 members. Every year on September 15, 12:00 UTC, an election starts for the 6 September Cohort seats; and every year on March 15, 12:00 UTC, an election starts for the 6 March Cohort seats.

> This means that the initial September Cohort will serve an initial term of 6 months, whereas the initial March Cohort will serve an initial term of 1 year.

> The initial Security Council Cohorts were determined by randomly splitting the 12 members into two 6-member cohorts - 6 members in the September Cohort and 6 members in the March Cohort. The members of the initial Security Council Cohorts are detailed in a transparency report

### Proposed Revision of Arbitrum Constitution:

> The Security Council has 12 members, who are divided into two Cohorts of 6 members.

> The initial Security Council Cohorts were determined by randomly splitting the 12 members into two 6-member cohorts - 6 members in the 'First Cohort' and 6 members in the 'Second Cohort'. The members of the initial Security Council Cohorts are detailed in a transparency report here.

> The first security election is scheduled to begin on the 15th September 2023 or the earliest possible date. The election can only begin upon the availability of an on-chain election process that was approved and installed by the Arbitrum DAO. This first election replaces the 'First Cohort'. The next election replaces the 'Second Cohort' and so forth.

> The date chosen for the first election will form the basis for all future elections. Every election should begin 6 months after the previous election has started and it will replace its respective cohort of 6 members.

> All Security Council members are expected to serve their term until the election is complete and the new Security Council members are installed.

AIP 4 executable code
---------------------

This document explains how to create a governance proposal, which can trigger an [AIP action contract](https://arbiscan.io/address/0x85792f6BF346e3Bfd3A275318aDd2c44A1058447#code).

The AIP can be created in https://www.tally.xyz/gov/arbitrum/proposal/create

To go through the [governance lifecycle](https://github.com/ArbitrumFoundation/governance/blob/main/docs/overview.md#proposal-lifecycle), the proposal's executable code must first trigger a L2 to L1 transaction through the ArbSys precompile.

For AIP 4, the `Arbitrum Core` should be selected since this is a constitutional proposal.

Target contract address: `0x0000000000000000000000000000000000000064`

Calldata

```
0x928c169a000000000000000000000000e6841d92b0c345144506576ec13ecf5103ac7f490000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000026401d5062a000000000000000000000000a723c008e76e379c55599d2e4d93879beafda79c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000004508d56e2b8cb6f9dad5f2e980f1abab0d96f7d0f4c5d924ae3fd9e9d98ac6d2000000000000000000000000000000000000000000000000000000000003f48000000000000000000000000000000000000000000000000000000000000001800000000000000000000000004dbd4fc535ac27206064b68ffcf827b0a60bab3f000000000000000000000000cf57572261c7c2bcf21ffd220ea7d1a27d40a82700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000841cff79cd00000000000000000000000085792f6bf346e3bfd3a275318add2c44a105844700000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000004b147f40c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

```

To verify the above the calldata, you can generate it yourself with the code from https://github.com/ArbitrumFoundation/governance/pull/130. To do so, you want to run `scripts/proposals/AIP4/generateProposalData.ts` then encode it as an L2 to L1 transaction to ArbSys, as seen in `sims/arbcore-aip4.sim.ts` from https://github.com/ArbitrumFoundation/governance-seatbelt/blob/117639ff19b3c9a664fd92db4e0f4dbabb2a932b/sims/arbcore-aip4.sim.ts#L19

The deployment can be checked with https://github.com/ArbitrumFoundation/governance/blob/57758a4e203f43566f587a77282e8a078d1a9ce2/scripts/proposals/AIP4/verifyDeployment.ts

The side effects of running the proposal can also be verified with [governance-seatbelt](https://github.com/ArbitrumFoundation/governance-seatbelt)

Rari Foundation

This is a Rari DAO that fully controls Rari Foundation and it's on-chain treasury

# RRC-11: On-chain Protocol Governance and Security Council
**Abstract**

This RRC-11 proposes to establish a process by which the RARI DAO will be able to propose, vote on and execute updates and changes to the Rarible Protocol’s core contracts directly on-chain via self-executing actions. This RRC-11 also proposes to implement a committee consisting of a DAO-appointed 3-member multi-sig (“Security Council”) which will have the ability to perform emergency upgrades, as well as minor, routine maintenance, to the Rarible Protocol. 

**Motivation**

As part of the path to a more decentralized Rarible Protocol, the power to govern the Rarible Protocol contracts should be within the hands of the RARI DAO, which currently has direct on-chain governance authority over the RARI DAO treasury.

**Rationale**

By growing the robustness of the RARI DAO governance, the DAO will be able to fully adopt the Rarible Protocol and grow its ecosystem by onboarding new communities and expanding NFT use cases.

**Key Terms**

N/A

**Specifications**

***RARI DAO Governance:* **

The RRC Process as laid out in “Specifications” section of RRC-0 shall apply to Rarible Protocol core contract updates and changes.

1. Phase 1: RRC Idea
          a. An RRC Idea must be submitted as a post in the Forum, where it should gather feedback for a period of 7 days

2. Phase 2: RRC Draft
        a. After Phase 1, the RRC Idea author must generate an RRC Draft with the required fields as laid out in RRC-0.

3. Phase 3: Live RRC
        a. Once an RRC Draft is ready, the RRC author (provided that they have at least 5,000 veRARI) must post it as a Live Draft on Tally, where it will undergo a 5 day voting period.
        b. The Live RRC must reach the quorum requirement dictated in RRC-0, and voting options are “in favor” and “against”. A Live RRC which meets the quorum requirement and receives more votes cast “in favor” than cast “against”, it shall be deemed an Accepted RRC.

4. Phase 4: Cooldown Period
       
   a.  An Accepted RRC undergoes a 2-day Cooldown Period, during which the Security Council and the Board of the RARI Foundation may each reject such Accepted RRC* if it would:

- Directly conflict with a proposal that is currently up for vote;
- Directly conflict with another proposal approved by the RARI DAO;
- Not include the required proposal terms as detailed in Phase 2 of the RRC Process;
- Compromise the Board’s fiduciary duties as they are owed to the RARI Foundation;
- Be in violation of the RARI Foundation’s bylaws or articles, any statutory requirements of Cayman Islands laws or the laws or regulations of any other applicable jurisdiction;
- Cause harm (including reputational harm) to the RARI Foundation (as determined in the Board’s sole discretion); and/or
- Cause the RARI Foundation to be in breach of any contracts, agreements or any other arrangements.

   b. * This RRC-11 is proposing this update to Phase 4 of the RRC Process – that is, the Security Council as well as the director of the RARI Foundation, has the ability to reject an Accepted RRC during a Cooldown Period.


5. Phase 5: Implementation




***Security Council:* **


1. This RRC-11 establishes a 3-member Security Council, which will be able to reject an Accepted RRC during a Cooldown Period, but also perform emergency actions in critical security scenarios (e.g., a hack, serious bugs, etc.).

2. The initial members of the Security Council are as follows:

- Campbell Law; wallet address: 0xd9C3EeD65968443F8587Bb068e6530A48dB5d177
- Andrei Taraschuck; wallet address: 0x25Ad94C7768108666BfDB6742aB66b109CA82946
- StableLab; wallet address: Stablelab.eth
- The multisig wallet the Security Council will use to perform veto or upgrade function is: 0xd35ec9F67Aa082Ae666be1716C79291f1f6e4E0a



3. Appointment and Removal

- The members of the Security Council may be appointed and removed during a yearly review or at any time, pursuant to the RRC Process.
- The members of the Security Council must act upon the direction of the director of the RARI Foundation as well as the RARI token-holders pursuant to the RRC Process. [Failure to act in accordance with directions from either the director of the RARI Foundation or the RRC Process may result in suspension of ]. 
- The number of members on the Security Council may also be expanded or reduced pursuant to the RRC Process, provided that (i) there must be at least 1 member on the Security Council and (ii) at least 1 member of the Security Council must be a director of the RARI Foundation.
- Security Council members are entitled to compensation of 2,000 USDC per month if requested. 



**Steps to Implement**


1. Update the RARI Foundation’s governing documents to refer to the Security Council and its authorities
2. Update the RARI DAO’s governor contract to add the Security Council’s powers, exercisable during the Cooldown Period


**Timeline**

Solution ready for implementation.


**Overall Cost**

72,000 for the first year. Cost to be approved as part of the Rari Foundation’s operational budget.

