Provide brief recap / summary
@michael , Thanks for letting me introduce Optimism Town Hall on such short notice.
If possible I’d love to speak more about Optimism Town Hall and provide an update on Optimism Fractal Season 3 at the next joint house call. Our work creates immense value for all stakeholders in Optimism and we’d appreciate more support from the wider Collective. Please let me know if we can schedule some time earlier in an upcoming call for this.
For anyone who missed the recent joint house, you can watch me introduce Optimism Town Hall at blank and read an overview in the following recap:
See rosmari’s summary message
recording: May 21st Joint House Call Upgrade AMAs.mp4 - Google Drive 7
slides: May 21st, joint house call slides - Google Slides 2
recap:
- To know more about the application process: Retro Funding 4: Onchain Builders sign up and application | Round Details
- There is going to be a Deliberative process on the definition of profit and all relevant information and proposed definition of profit will go to a Citizens’ house vote and be ratified. The two sessions will be on May 30th and June 6th.
Retro Funding 4: Onchain Builders sign up on May 23rd!
Operating budgets for councils and boards are out:
Zach Obront - Developer Advisory Board Operating Budget
[Draft] Code of Conduct Council (CoCC) Operating Budget for Season 6
Upgrade proposals AMA eng team: (Special Voting Cycle #23a starts on Thursday, May 23rd, the next upgrade proposals and other proposals will go into a vote)
Upgrade Proposal: Fault Proofs
- No permissions anymore on who is allowed to submit a proposal.
- Anyone can challenge a proposal.
- When a proposal is submitted, the FaultDisputeGame contract along with the off-chain OP-challenger, will work together to either properly invalidate malicious proposals or defend valid proposals.
- Main safety nets are an off chain monitoring system to monitor all proposed roots, window delays that allow the Guardian to reject the root and stop invalid withdrawals; and DelayedWETH contracts that handles bonds that people put up.
- If this proposal is accepted, withdrawals that have been proven but not finalized will need to prove again.
- A Sherlock audit contest was made, mainly focused on safety mechanisms.
- The sequencer will continue to provide one output per hour, there is no limit on how many outputs can be submitted.
- Increase of the Security Council Safe’s signing threshold, from 4 to 10, out of 13 owners.
- Reassigning the role of Guardian from the Foundation to a new Guardian Safe with the Security Council Safe as its sole owner for additional safety.
- Reassigning the owner of the L2 proxy admin to the 2 of 2 multi-sig that is jointly held by the Foundation and Security Council.
- The concern that a high threshold of 10 of 13 has is around key loss of Security Council safe signers, liveness extension system provides a strong confidence that the Security Council signers are live, if they’re not, it gives a recourse to recovery, so every 14 weeks a signer needs to be seen simply by executing a transaction or calling the system and confirming that they still have their keys and they are live. If they are not seen during that 14 week period they can be permissionlessly removed.
- What the DeputyGuardian module allows is for the Foundation to continue being that incident response actor while allowing us to meet the decentralization properties of the Security Council, being able to enforce the exit window. That means if the Foundation were ever to pause withdrawals and then refuse to unpause, the Security Council is able to remove, revoke the Foundation’s authorization to act as the guardian, and then the Security Council can unpause the system so that withdrawals can proceed.
Governor Update Proposal #2: Improvements to advanced delegation allowance calculations
- This is a further enhancement to how absolute and relative vote calculations for advanced delegation users are made.
- It’s a proactive upgrade we’re doing where there’s a chance that if you mix using relative voting power and absolute voting power with our advanced delegation alligator contracts, you could get into a situation where you’re voting with slightly less voting power than you actually are
- Fixes the issue found when mixing relative voting power and absolute voting power with advance delegation alligator contracts and getting into a situation where you are voting with less voting power than you actually are.
Special thanks to @revmiller and @amy for review and feedback on this post as part of the Feedback Commission 22
If you have questions on the Retro Funding sign up, please see the FAQ below. If you re experiencing issues please contact us via the #retro-funding-discussion channel in the Optimism Discord 44
Overview
Retro Funding 4 will reward onchain builders who have deployed contracts to the Superchain and contributed to the success of Optimism. This round seeks to expand the reach and impact of the network by rewarding those building across the Superchain who have increased demand for blockspace and driven value to the Collective.
Timeline
Please note that all dates are preliminary and might change. This post will be updated to reflect future changes.
- Sign up: May 23rd - June 6th
- Application Review Process: June 6th - June 18th
- Voting: June 23rd - July 8th
- Results & Grant delivery: July 15th
What impact will be rewarded?
Retro Funding 4: Onchain Builders will reward impact which has been generated between October 2023 - June 2024. Impact will be rewarded within the following topics:
- Demand generated for Optimism Blockspace
- Interactions from repeat Optimism users
- Interactions from Optimism users with high trust scores
- Interactions of new Optimism users
- Open Source license of contract code
Eligibility Criteria
In Retro Funding 3, the Retro Funding sign up process saw a large influx of spam and low-quality applications. By setting stronger eligibility criteria in Retro Funding 4, the Foundation aims to provide clarity to builders and reduce the amount of human review required for spam and low-quality application. In addition, qualifying criteria reduce the number of applicants who have not generated sufficient impact to receive rewards (such as the below requirement of a minimum number of unique address interactions). The below eligibility criteria aim to strike a balance between broad inclusivity and sufficient requirements to allow for an operationally viable Retro Funding round.
Builders are eligible who have:
- Deployed their onchain contracts on one or multiple of the following OP chains: OP Mainnet, Base, Zora, Mode, Frax and Metal, and meet the following criteria:
- Onchain contracts have interactions from 420 unique addresses during Jan 1st - May 1st 2024
- Onchain contracts had their first transaction before April 1st 2024
- Onchain contract had more than 10 days of activity during Jan 1st - May 1st 2024
- Verified their onchain contracts in the Retro Funding sign up process
- Made their contract code available in a public Github repo, for which ownership has been verified in the Retro Funding sign up process
- Confirmed that they will comply with Optimism Foundation KYC requirements and are not residing in a sanctioned country
- Submitted a Retro Funding application before June 6th, 2024 and comply with application rules
Round Sizing: 10m OP to reward Onchain Builders
Retro Funding 4 will allocated 10m OP to reward the impact of Onchain Builders. The OP token allocation for Retro Funding 4 should reflect the impact generated by onchain builders, as well as set a strong incentive for the continuous generation of demand for Optimism blockspace.
Below you find some considerations which informed the Foundation’s round sizing decision:
- Underallocation to Onchain Builders in Retro Funding 3: Previously, Retro Funding 3 allocated a total of 1.5M out of 30M OP 73 to the top 20% of applicants who generated network usage. There has been strong feedback from badgeholders and community 73 members that this allocation was too low and should be increased in future rounds.
- Growth in developer activity since last round: The Collective is focused on growing the number of active onchain developers. Developer activity, across the Superchain, has seen a large increase over the past six months 11. Thus, Retro Funding rewards to these types of contributions should increase to reflect this increase in impact.
- Collective sustainability: In Retro Funding 3, badgeholders have raised concerns around Retro Funding sustainability 73. Retro Funding currently relies on the Retroactive Public Goods Funding token allocation of 850M OP for rewards. In the future 6, Retro Funding will rely on surplus protocol revenue as the source of rewards. Currently, Total Collective Contributions 7 (of surplus protocol revenue) fall short of what is needed to sustain Retroactive Public Goods Funding. Additionally, in Retro Funding 3, badgeholders raised points around the relationship of rewards to the sequencer revenue 73, to ensure rewards don’t exceed the sequencer revenue itself. By allocating a significant amount of OP to rewarding onchain builders, the Citizens’ House is incentivizing developer growth and increased network activity.
Future round sizing
The Foundation will size Retro Funding 4 & 5, and will proposes round sizes for Retro Funding 6 & 7, to be ratified by the Citizens’ House. In the future, this process will gradually transition to be more community-led, which may involve the creation of a Budget Board, or similar, in future Seasons. Round sizing decisions are currently informed by the amount of impact observed within the Collective, considerations for incentivising contributors to take action, and sustainability of Retro Funding rewards. In the future, these decisions should be made based on a framework which takes a number of established measurements and criteria into. We invite Data NERDs to explore measurements and criteria which will inform governance participants to make informed budgeting decisions in the future.
Voting design
Retro Funding 4 experiments with Metrics-based Evaluation 93, with the hypothesis that by leveraging quantitive metrics, citizens are able to more accurately express their preferences for the types of impact they want to reward, as well as make more accurate judgements of the impact delivered by individual contributors.
In stark contrast to other Retro Funding experiments, badgeholders will not vote on individual projects but will rather vote via selecting and weighting a number of metrics which measure different types of impact. You can find out more about prototypes and explorations that informed this design here 48.
Impact metrics
All Citizens will be asked to vote in Retro Funding 4 and will be invited to actively shape and input on the design of impact metrics via discussions on the forum as well as a workshop. More details on the process of selecting impact metrics and their design will follow soon.
Voting interface
Opensource Observer 39 is leading the development of impact metrics and relating infrastructure.
The Agora team 14 is building the voting API for Retro Funding 4, with the team building the voting interface being selected via a Foundation Mission Request 16. The Foundation will provide designs and specs for the voting interface and will invite badgeholders to participate in user testing and user experience research.
KYC & Grant delivery
The Optimism Foundation is making active improvements on the KYC & grant delivery process. Grants will be streamed to recipients over 100 days, following the announcement of results and approval of KYC. Superfluid is providing infrastructure for the streaming of Retro Funding grants.
Updates on Retro Funding 4 Implementation
Below you find relevant forum posts which go into depth on the implementation of different components of the round.
- Retro Funding 4: Application process 292 - Overview of how projects will sign up and apply to the retro round
- Retro Funding: Application Review Process 45 - Process by which applications are reviewed to enforce eligibility criteria and application rules
- Retro Funding 4: Deliberative process on the definition of profit 21 - the definition of profit, within the impact = profit framework, via a deliberative process
- Retro Funding 4: Voting Experience 22 - overview of the voting experience and its components
FAQ
When will grant disbursements happen? Where can I ask questions? What happens if my application violates the Application Rules? Where can I nominate projects? Why do I need Farcaster to sign up for Retro Funding?
The easiest way to sign up for a Farcaster account is via the [Warpcast](https://warpcast.com/) app, which acts as a wallet to easily manage the keys of the newly created account. Upon sign-up, Warpcast currently charges a $7 fee to rent storage on the network. As a decentralized social network, Farcaster content is not stored on centrally controlled servers, but rather in Hubs, which are a [distributed network of servers](https://docs.farcaster.xyz/learn/architecture/hubs). Each unit of storage buys 5000 casts, 2500 reactions and 2500 follows. For those who prefer to register a Farcaster account via contracts directly, this can be done via the [ID Registry Contract](https://docs.farcaster.xyz/learn/architecture/contracts). Storage can be rented via the [Storage Registry Contract](https://docs.farcaster.xyz/learn/architecture/contracts). There are alternative Farcaster clients beyond Warpcast that also support account creation and storage renting.
Can I apply with two different projects? Does my project need to be on OP Mainnet? Are Superchain projects (e.g. deployed on Base or Zora) eligible? Can individuals apply or just projects? Can artists get accepted for Retro Funding? Can a team that has gotten a grants council grant, partner fund grant, mission grant get Retro Funding? Do I need to report my Airdrops and past Retro Funding grants under "Grants & Funding"? I can't verify my contract because it was deployed by a factory? Are Token sales considered as Funding?
I would still like an expert committee to walk through the implications of each metric and how it would impact funding. Having badgeholders publicly share their analysis for how they voted would be of great help
Love these changes overall, great job in undertaking such a radical overhaul of the program!
system: design of impact metrics
I have raised this concern before and also take this logic into consideration when I vote. When measuring impact, we should definitely consider the past value that a project has extracted from the DAO. It’s possible that a project has a high transaction count compared to others simply because it has already received funding from the DAO, while others have not.
Secondly, I would like to see a note on the time duration considered in this round.
Seeking for clarification here.
system: Retro Funding 4: Onchain Builders will reward impact which has been generated between October 2023 - June 2024. Impact will be rewarded within the following topics: • Demand generated for Optimism Blockspace • Interactions from repeat Optimism users • Interactions from Optimism users with high trust scores • Interactions of new Optimism users • Open Source license of contract code
For N projects/builders applied for the upcoming round, there will be at least N * 5 definite traceable onchain/opensource datapoints right? Or are there qualitative factors in play here?
system: In stark contrast to other Retro Funding experiments, badgeholders will not vote on individual projects but will rather vote via selecting and weighting a number of metrics which measure different types of impact.
And the only differentiating factor in the voting process seems to be the impact variables and weights of impact variables assigned by badge-holders.
So if we were to take it to the extreme, if all badge-holders agree on the same impact variables and assign the same weights, citizen house’s role simplifies to selecting a cutoff score while maintaining the budget constraints?
If such extreme case will happen, how do we ensure independent valuation amongst badge-holders? Or maybe “collusion” amongst badge-holders is not a concern?
Selecting impact variables may seem straightforward for badge-holders but assigning weights may be more difficult. What constitute as an optimal weight? As @LauNaMu pointed out in the Funding the Commons event, people have hard time recognizing exponential values 2.