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

# Proposal to Backfund Successful STIP Proposals

**Empowering STIP to measure the impact of incentives for new builders**

[<img height="500" width="500" alt="STIP_Backfund_Opportunity" src="https://global.discourse-cdn.com/standard17/uploads/arbitrum1/optimized/2X/3/394a4797e0b4068e1290ae30aaf14db7e8b7ff72_2_500x500.jpeg" />STIP\_Backfund\_Opportunity3374×3374 884 KB](https://global.discourse-cdn.com/standard17/uploads/arbitrum1/original/2X/3/394a4797e0b4068e1290ae30aaf14db7e8b7ff72.jpeg "STIP_Backfund_Opportunity")

**Call to Action for Arbitrum ecosystem**

This proposal represents a critical opportunity for our community to:

* Support diverse, emerging builders and make Arbitrum a welcoming environment for new projects
* Double the sample size and diversity of stages and categories in the STIP data set
* Uphold constitutional values of Inclusion vs Exclusion
* Avoid potentially irreversible harm of crushing small, high potential builders

**Notes:**

* This proposal draft has been prepared by the Arbitrum STIP Inclusion Working Group following a series of community calls and workshops involving various stakeholders. As a preliminary document, it seeks input from both the Arbitrum DAO and the Liquidity Working Group.
* This proposal frequently cites AIP-9.
* For all of our resources see here: svy.gg/stip-backfund 

# Abstract

This proposal outlines a one-time backfund to all "approved but not funded proposals’’ from Arbitrum STIP. The proposed AIP increases the total budget by 21.4M to 71.4M while increasing the total participating protocols by 26, for a total of 56 funded projects. The program plans to allocate DAO-owned ARB towards incentives while leveraging distribution systems, consensus, and delegate diligence already created from STIP 1.

This program is designed to backfund approved protocols while maintaining the timelines and systems of STIP 1:

* Timeline: The program is scheduled to commence and conclude concurrently with STIP 1, or within a similar timeframe, starting from the first week of November and running through January 31, 2024.
* KYC: The program will utilize the same KYC system as STIP 1.
* Reporting: Participating grantees are required to self-report data, maintain dashboards, and regularly summarize grant performance

# Considerations

Before this proposal was drafted, a working group was formed to gauge sentiment, gather key data points, and outline the proposal’s structure. The working group collaborated with delegates and projects affected by the STIP, engaging in multiple calls—including sessions with the creators of the STIP and the Incentive Working Group—to solicit feedback and refine the proposal accordingly.

Key concerns discussed include:

### Why not just push towards a round 2 and go through voting for all proposals again?

First and foremost, we believe that the successful execution of this Backfund proposal will, in time, serve as a crucial catalyst for future grant structures, including a successful STIP round 2. Why? This opportunity will unify the Arbitrum ecosystem by addressing key weaknesses in the original STIP 1 structure by quickly providing approved projects and other stakeholders with the resources/data needed to design and support future programs.

Key issues associated with delaying an immediate backfund and moving towards a round 2 include:

* Proper design and execution add considerable time delay to a highly competitive environment within Arbitrum and other L2s
* Requires teams with limited resources approved already for STIP 1 to spend significant time lobbying delegates
* Removes attention away from new Round 2 proposals
* Adds additional burden to delegates that should be focused on long-term design improvements and new STIP grants not yet approved
* Removes key data for STIP experiment analysis by skewing learnings towards larger, well-established projects
* Delays the alignment of the STIP with the Arbitrum constitution values of inclusivity and diversity
* Negatively impacts new builder sentiment towards Arbitrum at a critical time in the L2 Wars

### The budget set aside was 50M, and the DAO decided that was the acceptable spend for a short-term incentive.

While the budget was set at 50M, the original working group proposed 75M so that:

> “The budget was raised to 75M ARB to accommodate larger protocols (Pinnacle Grants) without compromising smaller applications.” [tnorm, September 3rd 2023.](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131/12)

Excess demand was a significant possibility due to the high interest in STIP and the absence of a cap for Pinnacle grants. Voters lacked the data to ascertain whether the initial 50M would be adequate to achieve the objectives of STIP.

Noteworthy is that, in the event of excess demand, measures including backfunding were already outlined as potential options.

Proper design and fulfillment of a Round 2 or similar future funding programs may take time to develop. Meanwhile, projects that received approval but no funding have immediate initiatives requiring support. Our opportunity is to fund these initiatives, level the competitive playing field, and enhance the data available for the STIP process.

[<img height="285" width="624" src="https://global.discourse-cdn.com/standard17/uploads/arbitrum1/optimized/2X/3/3698b8811ac5887c127ab2bbfc94d7f6dcbd554a_2_624x285.jpeg" />**1600×733 150 KB**](https://global.discourse-cdn.com/standard17/uploads/arbitrum1/original/2X/3/3698b8811ac5887c127ab2bbfc94d7f6dcbd554a.jpeg)

[<img height="356" width="624" src="https://global.discourse-cdn.com/standard17/uploads/arbitrum1/optimized/2X/8/8487c56a2a8f7c7f6dd102ad36e9a20b7459b041_2_624x356.png" />**1458×832 92.8 KB**](https://global.discourse-cdn.com/standard17/uploads/arbitrum1/original/2X/8/8487c56a2a8f7c7f6dd102ad36e9a20b7459b041.png)

### Voting behaviors for a 50M proposal shouldn’t carry over to a proposal that includes the additional backfunded amounts.

During our consultation process, we engaged in numerous discussions that brought forth questions about backfunding. Despite the criticisms, backfunding remains the most straightforward method to address the current STIP’s skewed sample size. We advocate that backfunding is the optimal approach to achieve the STIP’s intended outcomes—specifically, to examine the impact that incentives have on the growth of the Arbitrum ecosystem.

Furthermore, if the STIP continues without rectifying the issues with its sample, the analysis will be compromised by a significant methodological flaw. Backfunding is not just the “best” option; it is essential for preserving the integrity of the STIP overall.

Voting behavior might have differed if the budget cap were set at 75M or 100M. The only way to determine this would be to repeat the experiment with a raised cap (an option that is unfeasible as time travel has not yet been realized).

It’s helpful for us to remember the original objectives of the STIP:

* To provide incentives to a diverse and inclusive group of Arbitrum projects.
* To quickly establish an incentives program that is in harmony with Arbitrum’s values and constitution.
* To generate robust, meaningful data to shape the future design of Arbitrum grants for projects of all types and sizes.

# Motivation

> Motivation - A statement on why the Arbitrum community should implement the AIP.

How can Arbitrum create an incentives structure to grow the ecosystem? STIP started when the community began investigating creative uses for incentives. A short-term program was devised to act quickly, collect data about how incentives are used by Arbitrum protocols, and learn from the results to design new programs and grow the Arbitrum Ecosystem.

An unexpected budget problem caused many successful STIP applications to receive no funding. The real-world consequence of this mistake caused the STIP sample to be cut in half - but not at random. To determine the final STIP cohort, the applications were sorted by approval, which inadvertently skewed the sample towards incumbent protocols. This sampling bias is most egregious for collecting data about the smallest protocols; over 70% of Beacon grants were rejected due to the sorting algorithm that was used. Consequently, STIP may not be collecting sufficient data about new builders on Arbitrum.

This AIP seeks to achieve STIP’s original motivations by:

1. nearly doubling the sample size;
2. adding protocols across a broad array of industry categories; and
3. including protocols at different stages of development.

This AIP will ensure an important builder population is included in the study, while increasing the validity of the STIP results.

One of the most important questions facing Arbitrum today is how to grow the ecosystem and win the L2 Wars. STIP is a novel study on the impact of incentives for growing the Arbitrum ecosystem. In practice, the STIP excluded most new builders from the study, severely limiting the data that will be collected about the early stages of the builder pipeline. This AIP includes a broader range of protocols in the STIP study, ensuring that Arbitrum gets the data it needs about how incentives impact new builders in the Arbitrum ecosystem. It stands to reason that extending incentives to smaller projects could serve to incubate projects that grow into the high-usage dApps of tomorrow. Extending the STIP may not only increase the inclusivity of the program but also incentivize significant growth for the broader Arbitrum ecosystem at a lower cost per project, and this possibility is worth exploring.

# Rationale

`Rationale - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values`

Arbitrum’s community values highlight the importance of diversity, which increases the fitness of the entire Arbitrum ecosystem by representing the needs of many kinds of participants. The original work to design STIP was careful to consider how both large and small protocols would fare under the framework. However, the unexpected budget cutoff caused the sample to skew towards large protocols, which is at odds with the values of the Arbitrum community. The cost of falling short of this ideal is that STIP systematically overlooks the possibility that incentives might be uniquely interesting to small and new protocols. By failing to incorporate protocols at the first stages of the builders onboarding pipeline, Arbitrum will be unsure about how incentives operate among this crucial group of protocols.

The Arbitrum community also values neutrality, which received careful consideration during the STIP design stages. It was well-understood that incumbent protocols were likely to prevail with their STIP applications - but it was hoped this would not preclude smaller participants from also being funded. Unfortunately, this wish for inclusion was not fulfilled and - unintentional though it may have been - funding was nevertheless distributed according to a ranking that was likely to favor incumbents. Again, despite the best efforts of the DAO and the STIP designers, the result was at odds with the values of the Arbitrum community.

Above all, Arbitrum seeks to create and nurture a thriving ecosystem - and the DAO’s values are designed to provide guiding values that will always trend towards the health of the ecosystem. When the values aren’t met - even unintentionally - it is possible the best interests of the ecosystem aren’t met, either. In the case of STIP, accidentally excluding Beacon grants falls short of the community values - which, in all likelihood, is a critical oversight that Arbitrum would benefit from fixing.

# Key Terms:

* Approved but not funded STIP proposals
* AIP-9
* Backfund
* Extension
* STIP
* STIP Round 1
* STIP Backfunded

# Specifications:

`Specifications - A detailed breakdown of the platforms and technologies that will be used.`

Will approve funding of an additional 21.4M ARB through the end of January 31, 2024.

Please note the STIP Backfund will leverage the multiple sections of [AIP-9 1](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131) such as [Specification section](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#financial-proposal-5) and [Outstanding Questions and Concerns](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#outstanding-questions-and-concerns-13) and specifically:

* [Financial Proposal](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#financial-proposal-5)
* [Multisig Setup](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#eligibility-and-evaluation-guidelines-7)
* [Eligibility Requirements](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#what-are-the-eligibility-requirements-6) and [Eligibility and Evaluation Guidelines](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#eligibility-and-evaluation-guidelines-7).
* [KPIs](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131#what-are-the-eligibility-requirements-6)

Steps to Implement - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. For the avoidance of doubt, any AIPs involving transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.\`

NOTE: A 20,000 ARB operational budget for community/project facilitation.

 • 1,000 ARB to [@tnorm](https://forum.arbitrum.foundation/u/tnorm) as retroactive payment for conducting community moderation:

 • Draft and review of multiple iterations of the STIP framework.

 • Moderation of community calls and working group telegram.

 • Coordination individually across dozens of stakeholders and community members over the past three weeks.

 • 9,000 to ARB Multisig Signers (1,000 ARB per Signer).

 • 10,000 ARB to StableLab streamed weekly for organizing and highlighting applications and managing review processes. This includes:

  • Overseeing forum application and review stages.

 • Monitoring progression of applications throughout the application and review process.

 • Monitoring progression of applications throughout the application and review process.

 • Collaboration with the Foundation for forum setup and oversight.

  • Facilitation of Delegate x Grantee Community Calls during review periods.

100,000 ARB Data and Monitoring Budget for Plurality Labs consistent with the specific objectives and requirements outlined in detail in the "RFP - Abitrum Short-Term Incentive Program (STIP) Data Monitoring and Reporting" proposal by Plurality Labs

## Specific Recipients and Amounts for Backfund Proposal

**We used data provided by** [**ARB STIP — raho.me 13**](https://www.raho.me/stip) **to determine which successful STIP proposals did not receive funding. This list is also available** [**via google docs 33**](https://docs.google.com/spreadsheets/d/1e_HagHx883ezMlRKH3E0Ir6K_ZkoEEXzDIxPRHxKTng/)**.**

Which protocols are included in this AIP?

We used data provided by [https://www.raho.me/stip 13](https://www.raho.me/stip) to determine which successful STIP proposals did not receive funding. This list is also available [via google docs 33](https://docs.google.com/spreadsheets/d/1e_HagHx883ezMlRKH3E0Ir6K_ZkoEEXzDIxPRHxKTng/).

[<img height="500" width="641" alt="The 26 Backfunded Builders" src="https://global.discourse-cdn.com/standard17/uploads/arbitrum1/optimized/2X/0/01d44beaa8e7db92f79464c3287d20487f67320d_2_641x500.jpeg" />The 26 Backfunded Builders1920×1497 356 KB](https://global.discourse-cdn.com/standard17/uploads/arbitrum1/original/2X/0/01d44beaa8e7db92f79464c3287d20487f67320d.jpeg "The 26 Backfunded Builders")

**Total ARB for backfund**

* 21.4M ARB
* 26 protocols

**ProjectARB Amount**

WOOFi 1,000,000

Gains Network\[1] 4,500,000

DefiEdge 200,000

Synapse 2,000,000

PancakeSwap\[2] 2,000,000

RabbitHole\[3] 1,000,000

Notional 500,000

Rodeo Finance 250,000

Magpie 1,250,000

Stargate Finance 2,000,000

Savvy 200,000

Tales of Elleria 50,000

Thales 500,000

TIDE 80,000

Solv Protocol1 50,000

Furucombo 59,500

dForce 1,000,000

Sanko GameCorp 500,000

Ramses1, 248,000

Vela 1,000,000

Thetanuts Finance 200,000

JoJo 200,000

Wormhole 1,800,000

Shell Protocol 750,000

Realm 300,000

unshETH 375,000

StakeDAO 200,000

WINR\[4] 38,000

\[1] Gains Network originally asked for 7M ARB, but reduced their ask to 4.5M ARB. See [announcement. 8](https://twitter.com/GainsNetwork_io/status/1712399633790497199)

\[2] PancakeSwap has removed their proposal from consideration because of KYC requirements.

\[3] RabbitHole’s inclusion in backfunding would replace their proposal titled: [“Proposal: Grow Arbitrum & STIP Teams by leveraging Quest Protocol built by RabbitHole” 1](https://forum.arbitrum.foundation/t/proposal-grow-arbitrum-stip-teams-by-leveraging-quest-protocol-built-by-rabbithole/19185)

\[4] Currently, WINR will receive 462,000 of their ask - with backfunding WINR would receive 500,000.

### Overall Cost

`Overall Cost - The total cost to implement the AIP.`

Overall Cost - 71.4M ARB

## Projected Timeline

`Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.`

*\*Note: Timeline may change based on option selected or amount of work needed to update and develop. For DAO proposals and voting procedures please see* [*Section 2 in the constitution.* 1](https://docs.arbitrum.foundation/dao-constitution#section-2-dao-proposals-and-voting-procedures)

**PhaseDate / DurationTitleDescription**

**Phase 1 Temp check (1 week)**

Th, Nov 2nd, Draft posted to forum.. Discussion hosted on forum, revisions to draft, broader working group call and revisions to AIP.

Mon, Nov 6th Temp check posted to snapshot by sponsor delegateReconvene in forum to post results and conclude temperature check

**Phase 2: Formal AIP and call for voting (3 days). Weds, Nov 15th**

**Phase 3: DAO votes on AIP, on Arbitrum One (14 days)**

Saturday, Nov 19th Onchain vote begins on Tally. During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP. Vote to approve AIP for non-constitutional funding. Tally voting: Quorum ~71.4M ARB; greater than 50% voting in favor.

Saturday, Dec 2nd DAO vote ends, results are final

**Phase 4: L2 Waiting Period (3 days) Waiting period of 3 days; then schedule on-chain txs to disburse ARB**

# [RGP-18] Radicle Org Proposal 2024

If executed, this proposal will:

1. Transfer 1,370,482 USDC from the Radicle Treasury to a multi-sig controlled
by the Radicle Org to support the 2024 development work of Radicle.

**How was this proposal discussed?**
* Discussion: https://community.radworks.org/t/discussion-rgp-18-radicle-org-proposal-2024
* Formal Review: https://community.radworks.org/t/formal-review-rgp-18-radicle-org-proposal-2024/
* Snapshot Poll: https://snapshot.org/#/gov.radworks.eth/proposal/0xfe6261592c5337b55ff6ef0c4bb8e6d2cd35e01505a97baea1d8807bef73ca8e

## Notes
* `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` is the USDC contract (https://etherscan.io/token/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48).
* `0x8da8f82d2bbdd896822de723f55d6edf416130ba` is the Radworks Treasury address.
* `0x4016Ce2f73100138831CAf716f30EEC3ef1dFa1D` is the Radicle Org Multisig


## ACTIONS ##
```
0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 0 "transfer(address,uint256)" 0x4016Ce2f73100138831CAf716f30EEC3ef1dFa1D 1370482000000
```

Diva Staking

Diva is an ETH Liquid Staking protocol powered by Distributed Validators that's both trustless and permissionless.

# [DIP-04] Adopt Diva Staking DAO Community Guidelines
# DIP-04: Adopt Diva Staking DAO Community Guidelines

## Description

The Diva Staking DAO was launched 3 months ago, and has now gone through several Drafts and Voting Proposals.

A set of Community Guidelines was proposed and used in practice, and has been recently updated with changes like:

- Deprecating the "DCP, DIP, DUP" terminology in favor of a simpler unified DIP-XX + Low/Medium/High Impact classification
- Updating all values to the most recent voting periods, which were modified by DUP-01
- Clarifications on the Request For Comments step
- Writing improvements

This proposal proposes to ratify the following document as the current Diva Staking DAO Community Guidelines.

- [Github's Pull Request](https://github.com/staking-foundation/diva-dao/pull/3)
- [Discord discussion](https://discord.com/channels/1041618287500460083/1133466096763158629)
- [Forum discussion & temperature check](https://commonwealth.im/divastaking/discussion/12343-voting-periods)

With this proposal passing, the DAO resolves to adopt the following Community Guidelines:

```
# Diva Staking DAO INITIAL COMMUNITY GUIDELINES 

## Section 1. Definition and Purpose

The Diva Staking Decentralized Autonomous Organization (the ‘Diva Staking DAO’) is an unincorporated association of individuals, entities, associations and/or other persons or groups of persons holding the DIVA token AND having completed a process referred to as “delegation”. The Diva Staking DAO is not intended to, and shall not be deemed to, be a legal person or have a legal personality separate from the DAO Members. Without limiting the generality of the foregoing, the DAO is not intended to be, and shall not be deemed to be, a partnership.

The primary objective of the Diva Staking DAO is to curate and maintain the publicly available software resources known as the Diva Staking protocol. It is important to note that the Diva Staking DAO does not engage in administering or managing the Diva Staking protocol in any way. Instead, its mission is focused on enhancing the accessibility, efficiency, and resilience of the blockchain interaction commonly referred to as 'staking' through the utilization of non-proprietary software.

## Section 2. Governance Tokens

Diva Staking DAO governance tokens (the "DIVA Tokens" or "Governance Tokens") means the effectively delegated tokens associated with the Diva Staking protocol and referred to in https://github.com/staking-foundation and designated as Delegated DIVA, D-DIVA, or any other designation the Diva Staking DAO may find appropriate from time to time.

## Section 3. Excluded Tokens 

DIVA Tokens that have not been revocably delegated, either through self-delegation or delegation to third parties, using the designated governance smart contract of the Diva Staking DAO, are not considered as Diva Staking DAO governance tokens. These tokens do not possess the authority to submit any type of DAO proposal or participate in the voting process for any DAO proposals.

## Section 4. DAO Resolutions.

As per the token amount thresholds outlined in Section 5 below, every holder of Governance Tokens holds the right to submit and participate in the voting of proposals, referred to as 'DAO Proposals.' Once a proposal is duly approved by the Governance Token holders and has not been invalidated by the DAO governance mechanism, it is recognized as a 'DAO Resolution'.

## Section 5. DAO Proposals. 

Proposals may be submitted by any D-DIVA Token holder holding **at least 1 Million D-DIVA Tokens** subject to any applicable threshold, and/or any frequency restriction or other parameter designated by the Diva Staking DAO through the passage of a Diva Improvement Proposal (as defined below).

There are three types of Proposals based on risk and potential impact levels:

1.	**Low Impact** - intended to distribute governance power among communities, sealing strategic partnerships, etc.
2.	**Medium Impact** - aiming to adapt or modify a configurable feature of the Diva Staking protocol.
3.	**High Impact** - complex proposals aiming to update core infrastructure and require some code implementation.

## Section 6. DAO Proposals Quorum and Thresholds. 

In order for a Proposal to be valid a **Quorum of at least 10 Million D-DIVA Tokens** is required (as of the time of this writing).

The thresholds initially set for each kind of proposal are as follows, 

- **Low Impact** - more than 50% of favourable votes
- **Medium Impact** - more than 66% of favourable votes
- **High Impact**- more than 75% of favourable votes

## Section 7. DAO Proposals Procedures

Any DAO proposal starts with an idea, which can discussed organically by the community. Several channels in use are:

- [Diva's Discord](https://discord.gg/diva)
- [Commonwealth forum](https://commonwealth.im/divastaking/discussions)

Once the idea start to formalize, it should follow the steps below.

### 7.1. Request For Comments (RFC) / Temperature Check

In order for a proposal to be formally considered by the community, a Request for Comments and Temperature Check must be carried.

This process has two parts:

- A **Request For Comments (RFC)** discussion thread to collect community feedback.
- A **non-binding poll** to evaluate if the proposal gains enough interest and community support.

The [Commonwealth forum](https://commonwealth.im/divastaking/discussions) is a good way to do this, as it allows for both discussion and off-chain voting, but any openly accessible platform or channel can be used.

The RFC is intended to provide all necessary information and collect feedback to prepare the formal proposal which would later be submitted for its voting and subsequent approval or rejection.

Any member of the community at large may open a thread in the Diva Forum outlining the proposal which needs to be debated or any suggestion which may be deemed as beneficial to the community at large. 

The RFC shall contain at least the following: 

- **Title**: RFC + Proposal title.
- **Description**: Short and concise description of the proposal.
- **Rationale**: why the proposal is necessary and what benefit will bring to the community.
- **Tentative classification**: Low, Medium or High Impact proposal.
- **A non-binding community poll** to indicate the level of support the proposal may have.

### 7.2. DAO Proposal submission

Proposals can only be submitted by those which have **at least 1 Million D-DIVA Tokens** (as of the time of this writing) and it implies an on-chain transaction.

Proposals can be submitted on [Tally](https://tally.xyz/gov/diva) by selecting “Create a new proposal”.

The proposal shall include the following structure: 

- **DIP code**: Proposals start at DIP-01, DIP-02, and continue sequentially.
- **Title**: Short name of the proposal 
- **Classification**: Low, Medium or High Impact
  - *Low Impact* proposals shall include a short description of the proposed action to be taken
  - *Medium Impact* proposals shall include a risk assessment of the proposed implementation of such proposal and the executable code (Tally provides a list of executable functions which can be implemented) 
  - *High Impact* proposals shall include a thorough description of the technical features aimed to be implemented, executable code and test cases. 

Any proposal shall include a copyright waver. Further, any code or material included in any proposal shall be open sourced and released to the public domain without any restriction whatsoever.

### 7.3. Proposals Voting Delay

Once the proposal has been created “on-chain” there is a waiting period (voting delay). During that period token holders can still delegate their tokens (either self delegate or delegate to third parties). Such delegation will affect the necessary quorum for a proposal to become valid as only Delegated DIVA tokens are accounted for any governance purpose. 

**The voting delay period is set to 2 days** as of the time of this writing.

### 7.4. Proposal Voting Period

Once the voting delay period has elapsed, all the proposals have a voting period upon submission under which any Delegated DIVA token holders can vote in favour or object.

**The voting period is set to 5 days** as of the time of this writing.

After such period has elapsed, considering **a valid quorum of 10 Million D-DIVA Tokens** (as of the time of this writing) has been met and the correspondent voting threshold has been exceeded the proposal shall be considered passed and will become a DAO Resolution

## Section 8. DAO Resolutions

### 8.1. Queueing for Execution and Cooldown Period

Upon successful confirmation that the corresponding threshold and quorums have been met, an on-chain transaction is required to set the approved DAO Resolution in queue for its execution, starting a Cooldown Period.

The current Cooldown Periods (as of the time of this writing) are:

- **Low and Medium Impact** proposals: 9 days.
- **High Impact** proposals: 14 days.

The Cooldown Period is designed to provide a window for cancelling malicious proposals by submitting a Cancellation Proposal.

During the Cooldown period, an approved DAO Resolution still can be disputed and cancelled, as detailed in Section 9.

### 8.2 Execution 

Once the Cooldown Period has elapsed, anybody can execute the transaction to implement a DAO resolution.

As the required functions to effectively implement the desired outcome have been previously registered within the proposal, the execution of said transaction does not alter in any manner the terms of the DAO Resolution. 

## Section 9. Disputes

Any DAO Resolution can be challenged before it is executed due security considerations such as governance attacks or fraudulent code implementation. 

In order to challenge a DAO Resolution, a Cancellation Proposal must be submitted by a community participant counting with a governance power of **at least 1 Million D-DIVA Tokens** (as of the time of this writing).

The Proposal shall clearly specify “Cancellation Proposal” and set clearly and consciously what is the harm prevented by the cancellation and other remedies proposed to avoid further damage to the Diva Staking protocol and or community. 

In order to be valid a cancellation proposal requires a quorum of at least 10 Million D-DIVA Tokens and more than 50% of favourable votes (as of the time of this writing).

The execution of said Cancellation Proposal can be fulfilled after 2 hours cooldown period after its approval.
```



## Classification

Low risk, no executable smart contract code.

## Copyright waiver

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