Foundation Mission Request: Votable Supply Framework [RESEARCH]

Foundation Mission Request Summary: Develop a framework for the Collective to set votable supply targets which consider the “cost of attack.”
S6 Intent: Progress towards decentralization
Baseline grant amount: 8K OP
Should this Foundation Mission be fulfilled by one or multiple teams: Up to two
Optimism Unlimited point-of-contact: @oplavande @elizarileyoak
Submit application by: 8 November 2024
Selection by: 12 November 2024
Start date:  18 November 2024
Completion date: 18 December 2024 (extensions possible on case-by-case basis)

How will this Foundation Mission Request help accomplish the above Intent?
Progress towards decentralization requires a further distribution of voting power. This necessitates a strategy involving targets for votable supply. Votable supply is the number of tokens able to cast a vote at any given time. Votable supply targets should be related to an understanding of the dominant attack vectors at different stages of decentralization and how that corresponds to the cost of attack. We define cost of attack as the number of tokens required for an actor to unilaterally ensure governance outcomes in the Token House. In an ideal scenario, votable supply targets would ensure a prohibitive cost of attack, against various attack vectors, at each stage of progressive decentralization.
What is required to execute this Foundation Mission Request?
This Foundation Mission aims to develop forward looking projections for votable supply, informed by a deep understanding of the dominant attack vectors at different stages of decentralization and how that corresponds to the cost of attack. The model used to make these projections should be dynamic so different scenarios can be assessed and so that it can be updated over time.
To execute this Mission Request, the grantee will work closely with the Foundation over a one-month period. The grantee will successfully execute the following steps:

Phase
Activity
Deliverable
How to Measure
Duration

Preparatory work: Research and Data Collection
1.0 Identify key factors and assumptions about the Foundation’s own forecasts relating to decentralization, token supply, growth initiatives, etc.
List of key factors to be considered in model
Comprehensive projection of Foundation milestones relevant to understanding different attack vectors over time
1 week

Preparatory work: Research and Data Collection
1.1 Identify key factors that influence the cost of attack (e.g., token distribution, liquidity, voting participation rates, governance vulnerabilities).
Summary of key factors influencing the cost of attack based on review of existing research
Evaluation of key variables based on relevance to the Collective
1 week (done in conjunction with 1.0)

Framework Development
2.0 Develop a model that calculates the votable supply required to maintain it above a pre-determined threshold under various conditions
Model for calculating required votable supply; Scenario analyses of various conditions
Ability for model to estimate the cost of attack above threshold under various scenarios
2 weeks

Framework Development
2.1. Run sensitivity analysis on key variables such as token supply, market volatility, and other relevant factors
Sensitivity analysis
Ability to understand how projections would change based on a change in assumptions of key variables such as token supply, market volatility, and other relevant factors
2 weeks (done in conjunction with 2.0)

Final Report and Presentation
3.0 Deliver an adaptive model alongside a comprehensive final report outlining votable supply targets, key assumptions, and rationale
Adaptive model and final report
Functionality of the model and thoroughness of the report
1 week

Final Report and Presentation
3.1. Discussion of deliverables from 3.0 with Foundation
Presentation of outcomes to Foundation
Implementation of model by the Foundation
Deliver upon completion date

Delivery of the Final Framework and associated materials (by end of December 2024)

A complete and functional model that defines the votable supply targets based on the required cost of attack and other factors.
The model should be thoroughly tested, reviewed, and capable of making predictions to inform 2025 strategy and beyond.
Provide scenario-based forecasting for votable supply starting with Q1 2025 onwards (per month), with sensitivity analysis on key variables (e.g., token price, liquidity, voter participation).
Provide a list of assumptions, which have been reviewed and validated by the creators of this Mission Request.

How should impact be measured upon completion of this Foundation Mission Request? These should be focused on performance and may be used to assess your Misson’s impact.
To evaluate the impact of this proposal after completion, the following performance measures should be considered:

Adoption of the Framework by the Optimism Foundation:

Measure the extent to which the proposed framework is adopted by the Collective’s governance structures and its influence on token supply-related decisions.

Effectiveness in Preventing Governance Attacks:

Evaluate the extent to which the votable supply targets set by the framework successfully reduced the risk of governance attack at various stages.

Sustainability of the Model:

Assess the framework’s adaptability over time and its ability to remain relevant as market conditions and governance dynamics evolve, e.g. as the Collective enters new phases along the decentralization roadmap.

Application instructions
To apply for this Foundation Mission Request, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until Friday 1 November 2024, at which time the Foundation will review all submissions and select up to two individuals /teams to complete the work defined here.

Submission form
Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.
Foundation Mission Application

Alliance Lead: Please specify the best point of contact for your team
Contact info:
L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Read more about Alliances here
What makes your Alliance best-suited to execute this Mission?

[...]
[...]

Please describe your proposed solution based on the above Solution Criteria (if applicable):

[...]
[...]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

[...]
[...]

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

[...]
[...]

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

[...]
[...]

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

[...]

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[ ] I confirm that I have read and understand the grant policies
[ ] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Alliance Lead: Franco Perez
Contact info: Telegram or<EMAIL_ADDRESS>L2 recipient address: 0xa2bAE33C8Ec8268d88F9917dc11Aa857DF692303
Please list the members of your Alliance and link to any previous work:
Franco Perez Github

What makes your Alliance best-suited to execute this Mission
We are Franco, a Software Engineer specialized in blockchain solutions, and Luciana, a business developer and Product Marketing. We met at a hackathon and since then we have worked on technological projects, forming a multidisciplinary team with great synergy. We have deep knowledge of the Optimism virtual machine and we see this mission as an opportunity to actively contribute to the community and add value with our joint work.
Development of blockchain solutions:
Implementation of an automated alert system for MakerDAO. Its goal is to monitor jobs on the Ethereum blockchain and send notifications to a Discord channel if any job in the master network has not been executed for the past 10 consecutive blocks.
https://github.com/francoperez03/job-sentinel
Platform for depositing tokens and requesting p2p loans
https://github.com/francoperez03/p2p-loan-platform
Development of web3 on-chain game battle system deployed on Solana using NodeJS, Websocket, Solana-sdk and Metaplex-core
More than 5 years of experience architecting technological solutions based on NodeJS and AWS
Financial Analysis and Costing: Detailed financial analysis to assess the viability and performance of companies, including the calculation of service costs per client and financial projections.
Analysis and Restructuring of Business Plans: Analysis and restructuring of business plans to adapt them to target markets, creating attractive offers and modifying products according to market needs.
Implementation of "Profit First" Models in companies.
Creation and Definition of innovative Business Models: by analyzing existing data, identifying risks, advantages and disadvantages, and designing strategies when there were no previous models.
Data Analysis for Projections and Marketing: analysis of data from advertising and financial campaigns to make projections

Please describe your proposed solution based on the above Solution Criteria (if applicable):
Our solution is to develop an interactive model in a Jupyter notebook to analyze and evaluate the cost of attack on Optimism governance. The model will have parameterizable inputs (OP token supply, voter turnout, prices, release dates, etc.) and will generate graphs and visualizations under different scenarios. We will include monthly forecasts of the votable supply since Q1 2025 and a detailed report with methodology, assumptions, results, and recommendations to strengthen governance.

Problem Definition and Literature Review:
Research governance models on other blockchains and methods for calculating attack cost.
Clearly define the model's objectives and establish attack cost and threat voting power thresholds.
Identify and document initial assumptions and key variables.
Data Collection and Preparation:
Obtain on-chain data from Dune Analytics on OP token transfers, balances, and voting participation.
Collect market data (historical prices, trading volumes, liquidity, and volatility) from sources such as CoinGecko.
Obtain the schedule for the release of locked tokens.
Clean and consolidate the data for analysis.
Week 2: Data Analysis and Model Definition
Goal: Analyze the data to inform the development of the model and establish its structure.
Exploratory Data Analysis (EDA):
Visualize the distribution of token balances and the evolution of voting participation.
Identify relevant patterns and correlations.
Evaluate market volatility and its impact on the OP token.
Variable Definition and Model Formulation:
Establish the input and output variables of the model (token supply, voter participation, token price, etc.).
Formulate the mathematical model to calculate the attack cost and forecast the votary supply.
Document and justify the key assumptions.
Week 3: Model Development and Interactive Tool
Goal: Implement the model and create an interactive tool for its use.
Model Implementation in Python:
Develop the model using Python and specialized libraries.
Ensure efficiency and clarity in the code.
Creating the Interactive Jupyter Notebook:
Design a public Jupyter notebook with parameterizable inputs (token supply, participation, prices, release dates, etc.).
Integrate the model and add explanations to facilitate its use.
Generate graphs and visualizations that illustrate the results under different scenarios.

Week 4: Validation and Monthly Forecasts
Goal: Ensure the accuracy of the model and generate future forecasts.
Model Evaluation and Validation:
Perform tests with historical data.
Run sensitivity analysis by varying key variables.
Refine the model based on the results.
Monthly Forecast Generation:
Project the votarable supply from Q1 2025 onwards.
Consider variables such as token release, expected participation, and market factors.
Develop scenario analysis (optimistic, neutral, pessimistic).
Cost of Attack Analysis:
Calculate the cost to significantly influence voting.
Identify risk scenarios and assess the economic viability of potential attacks.

Week 5: Documentation and Final Presentation
Goal: Compile the findings and prepare the final delivery.
Detailed Report Preparation:
Document methodology, assumptions, results, and analysis.
Include graphs and visualizations to support conclusions.
Present potential areas for improvement and recommendations.
Jupyter Notebook and GitHub Repository Finalization:
Improve the user experience of the notebook.
Ensure code and technical documentation are complete and accessible.
Presentation and Delivery of Materials:
Prepare an executive presentation summarizing key findings.
Present the model and report to the Optimism Foundation.
Deliver all agreed-upon materials and address feedback

Alliance Lead: Franco Perez
Contact info: Telegram or<EMAIL_ADDRESS>L2 recipient address: 0xa2bAE33C8Ec8268d88F9917dc11Aa857DF692303
Please list the members of your Alliance and link to any previous work:

Franco Perez Github
MuyAmarilloTodo LInkedin

What makes your Alliance best-suited to execute this Mission
We are Franco, a Software Engineer specialized in blockchain solutions, and Luciana, a business developer and Product Marketing. We met at a hackathon and since then we have worked on technological projects, forming a multidisciplinary team with great synergy. We have deep knowledge of the Optimism virtual machine and we see this mission as an opportunity to actively contribute to the community and add value with our joint work.
Development of blockchain solutions:
Implementation of an automated alert system for MakerDAO. Its goal is to monitor jobs on the Ethereum blockchain and send notifications to a Discord channel if any job in the master network has not been executed for the past 10 consecutive blocks.
https://github.com/francoperez03/job-sentinel
Platform for depositing tokens and requesting p2p loans
https://github.com/francoperez03/p2p-loan-platform
Development of web3 on-chain game battle system deployed on Solana using NodeJS, Websocket, Solana-sdk and Metaplex-core
More than 5 years of experience architecting technological solutions based on NodeJS and AWS
Financial Analysis and Costing: Detailed financial analysis to assess the viability and performance of companies, including the calculation of service costs per client and financial projections.
Analysis and Restructuring of Business Plans: Analysis and restructuring of business plans to adapt them to target markets, creating attractive offers and modifying products according to market needs.
Implementation of "Profit First" Models in companies.
Creation and Definition of innovative Business Models: by analyzing existing data, identifying risks, advantages and disadvantages, and designing strategies when there were no previous models.
Data Analysis for Projections and Marketing: analysis of data from advertising and financial campaigns to make projections

Please describe your proposed solution based on the above Solution Criteria (if applicable):
Our solution is to develop an interactive model in a Jupyter notebook to analyze and evaluate the cost of attack on Optimism governance. The model will have parameterizable inputs (OP token supply, voter turnout, prices, release dates, etc.) and will generate graphs and visualizations under different scenarios. We will include monthly forecasts of the votable supply since Q1 2025 and a detailed report with methodology, assumptions, results, and recommendations to strengthen governance.

Problem Definition and Literature Review:

Research governance models on other blockchains and methods for calculating attack cost.
Clearly define the model's objectives and establish attack cost and threat voting power thresholds.
Identify and document initial assumptions and key variables.

Data Collection and Preparation:

Obtain on-chain data from Dune Analytics on OP token transfers, balances, and voting participation.
Collect market data (historical prices, trading volumes, liquidity, and volatility) from sources such as CoinGecko.
Obtain the schedule for the release of locked tokens.
Clean and consolidate the data for analysis.

Week 2: Data Analysis and Model Definition
Goal: Analyze the data to inform the development of the model and establish its structure.

Exploratory Data Analysis (EDA):

Visualize the distribution of token balances and the evolution of voting participation.
Identify relevant patterns and correlations.
Evaluate market volatility and its impact on the OP token.

Variable Definition and Model Formulation:

Establish the input and output variables of the model (token supply, voter participation, token price, etc.).
Formulate the mathematical model to calculate the attack cost and forecast the votary supply.
Document and justify the key assumptions.

Week 3: Model Development and Interactive Tool
Goal: Implement the model and create an interactive tool for its use.

Model Implementation in Python:

Develop the model using Python and specialized libraries.
Ensure efficiency and clarity in the code.

Creating the Interactive Jupyter Notebook:

Design a public Jupyter notebook with parameterizable inputs (token supply, participation, prices, release dates, etc.).
Integrate the model and add explanations to facilitate its use.
Generate graphs and visualizations that illustrate the results under different scenarios.

Week 4: Validation and Monthly Forecasts
Goal: Ensure the accuracy of the model and generate future forecasts.

Model Evaluation and Validation:

Perform tests with historical data.
Run sensitivity analysis by varying key variables.
Refine the model based on the results.

Monthly Forecast Generation:

Project the votable supply from Q1 2025 onwards.
Consider variables such as token release, expected participation, and market factors.
Develop scenario analysis (optimistic, neutral, pessimistic).

Cost of Attack Analysis:

Calculate the cost to significantly influence voting.
Identify risk scenarios and assess the economic viability of potential attacks.

Week 5: Documentation and Final Presentation
Goal: Compile the findings and prepare the final delivery.

Detailed Report Preparation:

Document methodology, assumptions, results, and analysis.
Include graphs and visualizations to support conclusions.
Present potential areas for improvement and recommendations.

Jupyter Notebook and GitHub Repository Finalization:

Improve the user experience of the notebook.
Ensure code and technical documentation are complete and accessible.

Presentation and Delivery of Materials:

Prepare an executive presentation summarizing key findings.
Present the model and report to the Optimism Foundation.
Deliver all agreed-upon materials and address feedback

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Week 1 Milestone:

Completed research on governance models on other blockchains and on methods to calculate the cost of attack.
On-chain and market data acquisition completed ready for analysis
Document with list of key factors and how they influence the cost of attack

Week 2 Milestone:

Completed visualizations of token balance distribution and the evolution of voting participation.
OP token volatility analysis over time completed
Documentation on input and output variables of the model to be applied
Key assumptions documented and justified.

Week 3 Milestone:

Public Jupyter Notebook designed with parameterizable inputs (token supply, participation, prices, release dates, etc.).
Model integrated into the notebook with added explanations for ease of use.
Charts and visualizations generated illustrating results under different scenarios.

Week 4 Milestone:

Model validated and refined through testing with historical data and sensitivity analysis varying key variables.
Monthly forecasts of the votarable supply generated since Q1 2025, considering variables such as token release, expected participation, and market factors.
Cost of attack analysis completed, including calculation of the cost to significantly influence voting and assessment of the economic viability of potential attacks, identifying risk scenarios.

Week 5 Milestone

Detailed report finalized, documenting methodology, assumptions, results, and analysis, and including charts and visualizations supporting conclusions. Presentation of potential areas for improvement and recommendations.
Github repository with the finalized Jupyter Notebook to share with the Collective
Executive presentation prepared
Model and report presented to the Optimism Foundation, with delivery of all agreed materials and attention to the feedback received.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
In order to carry out this mission effectively and efficiently, we need support in the following areas:

Financial Support:

Dune Analytics Plus Plan License: We require a Dune Analytics Plus Plan license or the equivalent of $399 USD to acquire it. This tool is essential to be able to download CSV files of data from the Optimism network, which is critical for data collection and analysis in our project.

Project Dedication Compensation: We request compensation of 800 OP upon completion of the project, as an advance on the total reward of 8000 OP that we understand will be frozen for one year. This advance will allow us to cover the resources invested and fully dedicate ourselves to this mission, leaving aside other projects, in order to provide maximum value to the Optimism community.

Collaboration with Experts:

Validation and Feedback: We would welcome the opportunity to consult with members of the Optimism team or governance experts to validate our assumptions and get feedback during model development. This will ensure that our work is aligned with community needs and expectations.

Foundation Mission (RFP) Application

Alliance Lead: Chain_L

Contact info: Telegram (Chain_L)

L2 recipient address: 0x82d514dFe285f14B83C6ac9B5D13C7d5A55634E5

Please list the members of your Alliance and link to any previous work:

chain-l - has 4 years of experience in the blockchain industry, Chain-L has developed and built various projects across multiple ecosystems. He deeply understands the underlying technologies and has worked extensively with Layer 2 solutions. He is proficient in evaluating and modifying economic metrics to assess complex blockchain governance structures. He enjoys contributing to the Collective in various capacities building experimental projects on applications layers or identifying the need and developing a dashboard for Season 5 Missions.

Twitter Profile
Dework Profile (20 tasks - numbaNERDs)

ARDev - is skilled in data warehousing, ETL processes, and database management systems like MySQL and PostgreSQL. He is proficient in using blockchain data analysis tools like Dune Analytics, and creating interactive Dune Dashboards. He is proficient in quantitative analysis and integrating advanced metrics into data dashboards. He also has a strong background in analyzing the efficiency of governance mechanisms and economic models within blockchain networks.

Twitter Profile
Dework Profile (18 tasks - numbaNERDs)

Jason - is highly skilled in statistical analysis and data mining techniques. He is proficient in using programming languages like Python for exploratory data analysis and identifying patterns within complex datasets. Jason has extensive experience with econometric modelling and quantitative analysis, which are critical for assessing financial mechanisms and cost-effectiveness.

Twitter Profile
Dework Profile (15 tasks - numbaNERDs)

Dhruvi - Gold medalist in Bachelor of Science in Information Technology and Master of Science in Data Science, Dhruvi specializes in data visualization and reporting. She is an expert in creating visualizations using tools like Tableau, Power BI, and Matplotlib. She excels in translating complex data into easy-to-understand dashboards and reports. She has strong skills in storytelling with data to drive business decisions and is knowledgeable in front-end development for creating custom visual analytics solutions. She is proficient in developing temporal visualizations to track changes and trends.

LinkedIn Profile

Here is the link to our Previous Work for the collective.
What makes your Alliance best-suited to execute this Mission?

Chain_L, ARDev and Jason have actively contributed via the Open Contributions Path of numbaNERDs, leading the leaderboard. This extensive hands-on experience demonstrates our commitment and capability to handle complex tasks successfully.

Chain_L's blockchain ecosystem experience, including active governance participation, provides crucial insights into decentralized organizations like the Optimism Collective. His understanding & commitment to Optimism Collective can also be understood by Forum stats (visited 382 days & read ~6k posts)

ARDev's data warehousing and quantitative analysis expertise enables the collection, processing, and analysis of data.

Dhruvi's data science master's background and data visualization skills along with the recent learnings from CPI will help us answer many gaps in different type of supplies.

Chain_L, ARDev, and Dhruvi’s previous work on "Measuring the Concentration of Power in the Collective (CPI)" has been instrumental in enhancing our understanding of the governance system, especially in analyzing delegate token holdings, Citizen House dynamics, and the roles of various Houses, Councils, and Committees.

Jason’s addition to the team will help us complete the project on time. His experience in collecting data on token holdings for the Token Resurrection project provides critical insights into locked tokens, while his work on the BadgeHolder Onchain Analysis offers valuable perspectives on Badgeholder engagement.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

As detailed in the attached research document, we have conducted secondary research related to the Votable Supply Framework task. Our governance research experience, especially from our work on the “Measuring the Concentration of Power (CPI)” task, has granted us a thorough understanding of Optimism’s ecosystem. During this CPI task, we collected and analyzed token holdings data from genesis to present, member data for the Citizen House across RPGF Rounds 2 to 4, and detailed datasets on Optimism’s various houses, councils, and committees. These datasets provide a comprehensive foundation, which we will leverage to develop a robust model for the Votable Supply Framework in this task.

We have also begun examining the risks associated with coordination attacks in the Citizen House, aiming to determine a safe governance threshold. Additionally, we documented OP tokens distributed via Token House proposals. With our existing datasets and findings, we can focus more directly on developing an adaptable model, using our prior work to speed up this framework’s creation.

As in our “Measuring the Concentration of Power” task, the submission format was also determined by our initial research and exploration. Similarly, for this task, we plan to finalise the model’s format—whether a Jupyter notebook, dashboard, or interactive frontend—based on our initial week’s research and ongoing findings, choosing the most effective format.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:
Our approach aligns with the mission’s requirements and follows a structured, step-by-step plan to achieve each milestone effectively. We have created this plan to match the steps outlined in the Foundation’s Mission Request (FMR) proposal exactly, as it does not require further changes. The plan is outlined as follows:
Step 1: Initial Alignment with Foundation Members (Preliminary)

We will engage with Foundation members to align on mission objectives and gather insights that will further inform our framework. This preliminary step ensures our approach is well-matched to Foundation expectations. We may try to do this before the selection period as well if there is an availability from the Foundation.

Step 2:- Preparatory Work: Initial Research and Data Gathering (Week 1)

We will build on our existing dataset and prior research to identify core factors influencing governance security, such as token supply, known attack vectors, and other key metrics. This preparatory stage will establish a baseline understanding, which we can expand upon with additional research if needed.

Step 3: Identification of Key Cost of Attack Variables (Week 1)

In parallel with Step 2, we will identify and define the main variables affecting the cost of governance attacks. These key variables will include factors like token distribution and voting behaviors, which will be summarized in a detailed document to ensure the model is robust and includes all essential parameters.

Step 4: Flexible Model Development - Votable Supply Framework Creation (Weeks 2-3)

We will develop a flexible model for calculating the votable supply threshold, incorporating scenario analyses to evaluate how varying governance conditions impact security. We will also ensure that the model is adaptable to integrate new insights and findings as the research progresses.

Step 5:- Sensitivity Analysis for Core Variables (Weeks 2-3)

Concurrently, we will conduct a sensitivity analysis on core variables, such as supply fluctuations and participation rates, to assess the model's adaptability. This ensures the framework can respond to changing conditions within the governance environment.

Step 6:- Final Report and Presentation (Week 4)

We will compile all findings into a comprehensive report, detailing our model, results from scenario analyses, and governance security recommendations. This final presentation will demonstrate the framework’s practical applications and potential benefits for governance security.

This plan is structured to optimize our existing knowledge and data resources, allowing for an efficient and high-quality deliverable by the end of the four weeks.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
To ensure the successful execution of this proposal, we have outlined the critical milestones exactly as provided in the RFP, as they do not require further modification. These milestones, along with specific deliverables and deadlines, will guide progress tracking and ensure that the mission objectives are met within the designated time frame, from November 11, 2024, to December 11, 2024.
Milestone 1:- Foundational Analysis of Governance Risks and Cost of Attack Variables

Milestone 1a: Preparatory Work and Data Collection

Completion Date: November 18, 2024
Deliverable: A comprehensive document summarizing key factors influencing governance security, including token supply, attack vectors, and foundational aspects relevant to the framework’s development. This research will provide context for later stages and clarify essential parameters.

Milestone 1b: Identification of Cost of Attack Variables

Completion Date: November 18, 2024
Deliverable: Summary of key variables affecting the cost of governance attacks, focusing on token distribution and voting participation rates. This step will ensure the model includes relevant parameters for accurate assessments.

Milestone 2:- Votable Supply Model Development and Sensitivity Analysis

Milestone 2a: Development of Votable Supply Model

Completion Date: December 2, 2024
Deliverable: A functional model for calculating the votable supply threshold, along with scenario analyses under different governance conditions. This model will assess risks associated with varying attack potentials.

Milestone 2b: Sensitivity Analysis of Key Variables

Completion Date: December 2, 2024
Deliverable: A sensitivity analysis report outlining the impact of variable changes on governance security, including token supply and participation rate fluctuations. This analysis will help verify the model’s adaptability to evolving conditions.

Milestone 3: Final Report and Presentation

Completion Date: December 11, 2024
Deliverable: A comprehensive report and presentation that summarizes findings, presents the votable supply model, includes scenario analysis results, and outlines recommendations. This presentation will serve as the proposal’s conclusive deliverable, showcasing the framework’s potential impact.

We have divided our work into Milestones and created a roadmap to work on this research bounty. Sharing it here for reference.
Milestone Breakdown of this Research
Please list any additional support your team would require to execute this mission (financial, technical, etc.):

We would request 2 hours divided into two one-hour sessions with the members of the Optimism Foundation to clarify the expectations from this Mission. This will help us deliver a solution that gets utilised.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

We would appreciate any support, financial or otherwise, for getting access to a paid data provider solution, wherever open-source data isn’t available. Particularly we are interested in identifying the gap between Circulating Supply & Votable Supply by analysing wallets holding OP.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual.
[x] I confirm that I have read and understand the grant policies.
[x] I understand that I will be expected to follow the public grant reporting requirements outlined here.

-- end of application --

Foundation Mission (RFP) Application

Alliance Lead: Bilal
Contact info<EMAIL_ADDRESS>L2 recipient address: 0x04681fDADd6e8D561B998c7e37E7451057561091
Please list the members of your Alliance and link to any previous work:
Bilal Bai, Yujie Yang,
op-vica
Portfolio Stress Test (Scenario Analysis)
Generalizable Training Algorithms

What makes your Alliance best-suited to execute this Mission?
Our Alliance is uniquely equipped to execute this Mission, combining both prior experience and complementary skills that are directly applicable to the task. We recently developed the Voting Influence and Concentration Analysis (VICA), a model tailored for the Optimism Collective, which provides a systematic framework for analyzing voting concentration, influence distribution, and governance risks. This model used a combination of network analysis, logistic regression, and counterfactual analysis to estimate voting blocs' influence and to develop concentration metrics. The skills and insights gained through VICA are directly transferable to this new mission’s objectives, as both projects address governance, risk of voting concentration, and the resilience of decentralization structures.
Our team consists of:
Bilal Bai, a seasoned quantitative analyst and certified risk manager with extensive experience in scenario analysis, stress test, sensitivity analysis, and risk factor modeling.
Yujie Yang, a PhD candidate in statistics at the University of Hong Kong, brings deep knowledge in the theory and application of complex networks and statistical modeling, providing a strong foundation for data analysis and network-based insights.
Together, our team’s experience in governance metrics, concentration analysis, and network-based risk assessment uniquely qualifies us to develop a dynamic model for votable supply projections, addressing both the decentralization targets and the associated governance attack risks.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
The VICA model laid the groundwork for understanding how voting concentration affects governance stability, making it an ideal foundation for this project. By applying VICA’s clustering algorithms, influence metrics and concentration analysis, we can more accurately determine the votable supply required to minimize governance risks. Moreover, VICA’s counterfactual scenarios and sensitivity analysis have provided valuable insights into network behavior under different assumptions, which will inform our dynamic projections and cost of attack modeling.
Solution Components

Risk Factor Identification: Building on VICA’s clustering analysis, influence and concentration metrics, we will perform a thorough risk factor analysis to identify key variables that could impact the cost of attack and governance security. This includes understanding token liquidity, voter turnout, market volatility, and potential governance vulnerabilities. By analyzing these risk factors, we aim to capture potential points of failure or concentration that could threaten the system's integrity. We will also consider the correlation across different factors.
Scenario Analysis: We will extend VICA’s counterfactual capabilities to conduct scenario analysis that simulate various conditions of token distribution, market conditions, and governance participation rates. Each scenario will assess how changes in these factors impact the system's decentralization targets and the cost of attack. The goal is to create a flexible model that provides insight into how different scenarios affect votable supply targets and governance resilience.
Stress Testing: To ensure the model's robustness, we will conduct stress tests under extreme conditions, such as sudden changes in token liquidity, sharp declines in voter turnout, or large-scale token concentration in few hands. These tests will provide insights into the model's ability to handle shocks and sustain a high cost of attack even under adverse conditions. Stress tests will enable the Foundation to gauge the system’s resilience against governance risks and adjust targets accordingly.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:
Execution Plan:

Stage 1: Preparatory Research and Data Collection
Stage 2: Risk Factors Identification and Initial Cost of Attack Analysis
Stage 3: Model Development and Sensitivity Analysis
Stage 4: Final Reporting and Adaptive Model Delivery

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Initial Data Analysis and Risk Factors Identification: Early-stage feedback on the relevancy and robustness of identified attack vectors and votable supply projections.
Prototype Development: A functional model prototype, tested with dummy and real data, to validate votable supply targets.
Final Adaptive Model: A fully developed model and report, delivered for the Foundation's review and ready for scenario-based forecasting.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
To ensure the accuracy and applicability of our model, we request ongoing communication with the Optimism team to gain insights into token distribution plans, governance changes, and voting behavior patterns.
Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
N/A
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here
-- end of application --

Foundation Mission Application
Alliance Lead: Pavel Fedotov
Contact info<EMAIL_ADDRESS>L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Lead Developer Pavel Fedotov

LinkedIn Profile
GitHub profile
X profile
Dspyt Profile
Ethereum Stack Exchange
Professional Background: Pavel is a Full Stack Blockchain Developer with over four years of experience in engineering decentralized applications using cutting-edge technologies such as Rust, Solidity, Python, JavaScript, TypeScript, React, and Next.js.
Key Achievements:
Pin Save: Successfully completed the Filecoin grant aimed at advancing decentralized Identity standards (ERC-725) integrated with NFT frameworks. Notably, Pin Save secured a RetroPGF grant from the Optimism Foundation with 25 votes.
Academic Background: Holds a BA in Business Studies and Economics from the University of Manchester, graduating with Honours. Pavel also published a highly regarded academic article titled "Critical Analysis of the Electric Vehicle Industry: Five Forces and Strategic Action Fields," which garnered over 50,000 downloads.
Governance Expertise: Demonstrated involvement in governance with approximately 20 million ARB tokens delegated in two committee elections on Arbitrum: Arbitrum Procurement Committee and Arbitrum Research & Development.
Speaking Engagements: Pavel has presented at notable events such as ETH Belgrade 2024, IPFS Camp 2024, ETH Bucharest 2024, and the Web3 Family Conference.
Data Science Contributions: His notable data science achievements in the web3 space include: Lifetime Gitcoin Grants Data Analysis and Hypothesis Testing report. Insights into Filecoin Storage Network Energy Consumption. Proposals for Ethereum Security Data Collection. Key discussions on "On-chain Builders Delivering Metrics Data."
What makes your Alliance best-suited to execute this Mission?
Our alliance benefits from a unique combination of technical expertise and hands-on experience in governance and decentralized applications. Pavel's background as a full-stack developer, coupled with my practical experience in governance mechanisms and risk management in blockchain ecosystems, positions our team to effectively deliver the votable supply framework.
We are well-equipped to analyze complex data sets and develop innovative solutions tailored to governance challenges faced by the Optimism Collective. Our familiarity with the technical and economic aspects of blockchain governance, combined with our commitment to community engagement, ensures that we can design a framework that significantly contributes to Optimism's decentralization and security objectives.
Our previous work on projects like Pin Save and our active participation in governance activities demonstrate a proven history of delivering valuable, impactful contributions to the community.
As a team, we are eager to harness our skills to create an adaptive, data-driven model that supports effective governance and minimizes vulnerabilities within the system. Our experience in scenario analysis and risk assessment will be critical in building a robust framework that accurately reflects the complexities of the Optimism ecosystem while prioritizing decentralization and long-term sustainability.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
Our proposed solution is to develop a comprehensive and dynamic framework for calculating votable supply targets that minimizes the cost of attack while facilitating effective governance within the Optimism Collective. This framework aims to ensure a well-distributed and secure governance structure essential for advancing the decentralization objectives of the Optimism ecosystem.
Solution Components:

Data Collection and Analysis:
We will initiate our work by gathering on-chain data from reputable sources such as Dune Analytics. This data will include information on token distribution, voting participation rates, and governance history. The analysis will help us identify historical trends, voting behaviors, and patterns of token utility. We will conduct a thorough Exploratory Data Analysis (EDA) to visualize key factors influencing governance, such as:

Distribution of token holdings.
Participation trends in governance votes.
Historical context of governance engagements.

Risk Assessment:
Building on our initial data analysis, we will perform a risk assessment to identify potential governance vulnerabilities and the primary attack vectors that could be exploited at different stages of decentralization. This will involve evaluating various aspects, including:

Token liquidity and concentration of holdings.
Historical data on governance vulnerabilities. We will calculate the cost of attack—defined as the number of tokens required to unilaterally influence decision-making within the governance framework—using our analysis of token distributions and participation dynamics.

Model Development:
We will create a flexible and adaptive model capable of computing the necessary votable supply targets that ensure a prohibitive cost of attack. This model will include:

Scenarios and sensitivities allowing us to assess changes in key variables such as token supply, governance engagement, and market conditions.
An interactive implementation in a user-friendly Jupyter Notebook, enabling stakeholders to input different parameters and visualize the impact on votable supply and associated governance risks.

Scenario Planning:
The framework will involve conducting scenario analyses to simulate various conditions (e.g., high participation vs. low participation and fluctuating market values). For each scenario, we will generate forecasts for votable supply starting from Q1 2025 onward, outlining the implications for governance resilience and security.

Final Report and Recommendations:
The culmination of our efforts will be documented in a comprehensive final report that outlines our findings, key assumptions, and results from the scenario analyses. It will include:

Actionable recommendations for the Optimism Collective to implement, aimed at achieving optimal votable supply structures.
Strategies for proactive measures against governance risks.

This robust approach endeavors not only to fulfill the immediate requirements of the Foundation Mission but also to provide valuable insights that will shape the future governance dynamics of the Optimism Collective. By developing a targeted framework for votable supply, we aim to enhance decentralization, security, and resilience in governance processes.
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:
Step-by-Step Plan to Execute the Mission
To effectively execute the mission of developing the votable supply framework, we have outlined a detailed plan that aligns with the mission's objectives. This plan includes specific tasks, expected deadlines, and deliverables for each stage of the project.
Week 1: Preparatory Work, Research and Data Collection

Task 1.1: Identify Key Factors and Assumptions

Conduct research to identify key factors and assumptions about the Foundation's forecasts relating to decentralization, token supply, and growth initiatives.
Expected Deadline: November 23, 2024
Deliverable: List of key factors to be considered in the model.

Task 1.2: Identify Key Factors that Influence the Cost of Attack

Document key factors influencing the cost of attack (e.g., token distribution, liquidity, voting participation rates, governance vulnerabilities) based on a review of existing research.
Expected Deadline: November 23, 2024
Deliverable: Summary of key factors influencing the cost of attack.

Week 2: Framework Development

Task 2.1: Develop Model for Calculating Required Votable Supply

Build a model that calculates the votable supply required to maintain governance integrity above a pre-determined threshold under various conditions.
Expected Deadline: December 2, 2024
Deliverable: Functional model for calculating required votable supply.

Task 2.2: Run Sensitivity Analysis

Conduct sensitivity analysis on key variables such as token supply, market volatility, and other relevant factors to evaluate the model's resilience against changes.
Expected Deadline: December 2, 2024
Deliverable: Sensitivity analysis report detailing how projections are impacted by variable changes.

Week 3: Final Report and Presentation

Task 3.1: Deliver Adaptive Model and Comprehensive Final Report

Prepare a comprehensive final report outlining votable supply targets, key assumptions, and a rationale for the model developed.
Expected Deadline: December 9, 2024
Deliverable: Adaptive model and final report.

Task 3.2: Discussion of Deliverables with the Foundation

Present the outcomes of the project to the Optimism Foundation for feedback and discussion regarding implementation.
Expected Deadline: December 9, 2024
Deliverable: Presentation materials and summary of discussion points.

Milestones for Execution

Milestone 1: Completion of Preparatory Research and Data Collection (By November 23, 2024)

Deliverable: Lists of key factors and summarized influences on the cost of attack.

Milestone 2: Completion of Votable Supply Model and Sensitivity Analysis (By December 2, 2024)

Deliverable: Functional model and sensitivity analysis report.

Milestone 3: Delivery of Final Report and Presentation (By December 9, 2024)

Deliverable: Final report and presentation materials ready for discussion with the Foundation.

This structured plan ensures that we systematically address each critical aspect of the mission while adhering to the project timeline, facilitating the timely delivery of a robust framework that fulfills the goals of the Optimism Collective.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Critical Milestones to Determine Execution of the Proposal
To effectively assess the execution of this proposal for developing a framework to set votable supply targets, the following critical milestones will serve as key indicators of progress and success. Each milestone corresponds to significant deliverables and phases of the project.
Critical Milestone 1: Completion of Preparatory Research and Data Collection

Deadline: November 23, 2024
Criteria for Success:

Comprehensive identification of key factors and assumptions relevant to the Foundation's forecasts related to decentralization, token supply, and growth initiatives, documented in a clear list.
Thorough summary detailing the key factors influencing the cost of attack based on a thorough review of existing research.

Deliverables:

List of key factors for model consideration.
Summary report of factors influencing the cost of attack.

Critical Milestone 2: Completion of Votable Supply Model Development and Sensitivity Analysis

Deadline: December 2, 2024
Criteria for Success:

Delivery of a fully functional votable supply model capable of calculating required votable supply targets under various conditions.
Completion of a sensitivity analysis report that assesses how changes in key variables (e.g., token supply, market conditions) impact the model’s projections.

Deliverables:

Votable supply model documentation.
Sensitivity analysis report.

Critical Milestone 3: Delivery of Final Model and Comprehensive Report

Deadline: December 9, 2024
Criteria for Success:

Submission of a comprehensive final report outlining the developed votable supply targets, key assumptions, and the rationale behind the framework.
Production of presentation materials summarizing the outcomes of the project for discussion with the Foundation.

Deliverables:

Adaptive model and final report document.
Presentation materials.

Critical Milestone 4: Presentation and Discussion of Deliverables with the Foundation

Deadline: December 9, 2024
Criteria for Success:

Successful presentation of the project outcomes and deliverables to the Optimism Foundation, facilitating discussion about the framework’s implementation.
Feedback received from the Foundation regarding the deliverables and next steps for adopting the model.

Deliverables:

Summary of feedback and discussion points from the presentation.

Overall Completion Assessment
Upon reaching these milestones, a final assessment will be conducted to evaluate the effectiveness of the framework developed for votable supply targets and its alignment with the goals of the Optimism Collective. Each milestone will be measured against predefined criteria to ensure that the project meets the established objectives related to governance, decentralization, and the reduction of attack risks within the governance structure.
By adhering to these milestones, we will ensure the successful execution of the proposal, providing the necessary framework to enhance the governance mechanisms within the Optimism ecosystem.
Please list any additional support your team would require to execute this mission (financial, technical, etc.):
Additional Support Required to Execute This Mission
To effectively carry out this mission, our team would require the following support:

Financial Support:

Dune Analytics Plus Plan License: We require funding for a Dune Analytics Plus Plan license or equivalent financial support of approximately $399 USD. This tool is essential for downloading CSV files of data from the Optimism network and is critical for our data collection and analysis efforts.
Project Dedication Compensation: To ensure full dedication to this mission and to concentrate our resources on delivering maximum value to the Optimism community, we request an advance of 800 OP. This advance would help cover the resources and time invested in the project, as the total reward of 8000 OP is inteded to be locked for one year.

Technical Support:

Collaboration with Optimism Team Members: Engaging with members of the Optimism Foundation or governance experts for validation and feedback on our assumptions during the model development process would greatly enhance the relevance and alignment of our work with community needs and expectations.

By securing this additional support, we will be better positioned to execute the mission efficiently, ensuring high-quality deliverables that benefit the Optimism Collective.
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x]  I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x]  I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x]  I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x]  I confirm that I have read and understand the grant policies
[x]  I understand that I will be expected to following the public grant reporting requirements outlined here

Foundation Mission Application
Alliance Lead: Christian Ziegler
Contact info<EMAIL_ADDRESS>L2 recipient address: 0x9c489E4efba90A67299C1097a8628e233C33BB7B
StableLab and its Forse team consist of:
Christian Ziegler
Johannes Loewe
Raphael Spannocchi
Doo Wan Nam
Oskar Firei
What makes your Alliance best suited to execute this Mission?
StableLab is one of the leading teams in decentralized governance operations. It has recently expanded its offering with FORSE, a DAO analytics platform pioneering deeper insights into on- and off-chain parameters and their effect on DAO governance and its goals.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
We posit that governance security as measured by the ability of a single actor unilaterally deciding a token-weighted poll is not directly coupled to votable supply per se, but instead to other factors. Primarily voting power inequality (think one massive whale and the rest shrimp). Another important factor for the cost of attack is that the chance to succeed can be drastically reduced with execution timelocks coupled with a capable Guardian role (in the case of OZ Governor contracts).
Our proposed solution therefore aims to track voting power inequality first, suggest a dynamic quorum based on multiple relevant metrics second, and introduce a path to a truly decentralized Guardian role third.
Multiple factors influence the cost/reward of a successful governance attack:

Cost of token acquisition so that a sufficient amount of tokens is available at the desired time (factoring in liquidity/slippage considerations)
Cost of developing the smart contracts and exploit infrastructure
Minus the total extractable amount
Divided by a risk premium to compensate for the legal and operational risk

Further, token issuance increases token liquidity and decreases the cost of an attack somewhat, though the relationship is not linear or direct.
We propose setting votable supply distribution inequality targets instead or in addition to total votable supply targets. The former is more relevant to governance security than the latter.
We propose introducing a dynamic quorum (as pioneered by MakerDAO). MakerDAO features a quorum, where each successive proposal needs to surpass the previous one in the amount of MKR that voted. Instead of this simple measure, we propose to do ongoing data analytics that computes potential future voting power as a function of the sort:
~ quorum_n ( vp_c, quorum_n-1, votes_n-1)
While a full model will be built in coorperation and to the desires of the OP Foundation, current planning would follow these limitations:

Adjustment of Quorum follows a roughly 3rd polynomial function of voting-power quorum overachievement in the last proposal.
A third polynomial approximation would ensure:
When everything runs smoothly, small changes to the quorum guarantee consistency in the voting process over time and avoid annoyance from an ever-changing and uncertain quorum.
Bigger adaptations are necessary when a larger difference in cast votes and quroum is found to adjust to the new landscape of power distribution of active voters.
There should be an upper and a lower end to the dynamic quorum, so that quorum can always be reached, even as the votable supply expands, and that a minimum of governance security is established, even in the worst case of voter passivity.

Further constraints would include:
All Proposals would ensure that the next Quorum is at least the biggest last voting power + X % where X is a percentage to be defined. This ensures that no big player can pass proposals alone, while minimizing the impact on the running governance process.
If proposals repeatedly fail to reach quorum, quorum power will fall off in a similar inverse fashion, with change starting gradually before entering a faster rate and finally trailing off again.
This magnitude will asymptotically approximate a value computed from the token distribution and voting supply over the last N proposals.
Change_quroum = cq(last_passed_quroum, recent votingsupply, N quorum misses proposals, MN max N that will reach the lowest possible quorum)  Cq ~ sigmoid(-1*(N + MN/2)) + f(last_passed_quroum, recent votingsupply) Where MN has to be bigger than the top X addresses that have voted in the last M proposals.
Deliverables

We would develop a report that outlines the required additional token emissions to maintain decentralization and governance security. We would use FORSE user segmentation to identify ideal user-profiles and addresses (if possible) to ensure that token emissions go to the most effective recipients.
We also suggest monitoring voter participation rates and adjusting emission mechanics to favor a broader set of active addresses over a smaller set of (mostly) inactive ones, if necessary. A wider distribution of voters means more eyes are on proposals, and more potential safeguards exist.
Developing and implementing a Guardian role that monitors passed proposals during their execution timelock can enhance security and make successful governance attacks much riskier for potential attackers. This Guardian role can be decentralized from the beginning or as a follow-up.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Step
Deadline
Definition

1
2024-11-30
Analyze the current conditions of $OP distribution inequality, voting behavior, and power concentration and define the model weights that govern dynamic quorum.

2
2024-12-07
Create public-facing charts for the dynamic quorum weight with multiple options that simulate different curves and parameter weights. The dashboard will also display the key metrics that go into the model.

3
2024-12-21
Create a report identifying key conditions necessitating token emissions to maintain decentralization needs, governance security, and functionality. Identify relevant user types and distribution inequality targets for these emissions, with corresponding addresses if possible.

4
2024-12-21
Create a report about implementing a decentralized Guardian role.

Please define the critical milestone(s) that should be used to determine whether you’ve executed this proposal:
Milestone 1: Initial set of criteria weights defined and published as a request for comments on the OP governance forum
Milestone 2: Functional and accurate charts of the dynamic quorum weight and its components published with the ability to simulate different quorum adaptation curves and parameter weights.
Milestone 3: Report about a decentralized Guardian role published.
Milestone 4: Report about distribution inequality targets and emissions targets published.
Please list any additional support your team would require to execute this mission (financial, technical, etc.):
We would need a deeper understanding of the planned emissions schedules and desired governance security of Optimism.
StableLab requests 25,000 OP to create the dashboards and reports mentioned in this report. If you'd like more analysis and consultation, this would require a future engagement and would not be covered by this mission.
Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
We would appreciate a 7,000 OP upfront payment, with the remaining 18,000 OP locked for one year.
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
x I understand my grant for completing this RFP will be locked for one year from the proposal acceptance date.
x I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
x I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
x I confirm that I have read and understand the grant policies
x  I understand that I will be expected to following the public grant reporting requirements outlined here


ci: add reproducibility check

Part of automatic releases.

@Xuanwo @PsiACE @suyanhanx Please take a look and try reply in https://issues.apache.org/jira/browse/INFRA-24880 with this patch merged that you can make a reproducible build of opendal-java .

Thanks for your reviews! Merging..


[CPO][fix job] avoid using docker manifest with local repository

Avoid using docker manifest with local image repository

Thanks. lgtm


TPT without explicit ToTable for each derived type?

We currently have a base class, Entity, for all our entities in its own separate entity table
class Entity { }
class Post : Entity { }
class Blog : Entity { }

Is there a way to tell EF core that all classes deriving from Entity is TPT without explicitly calling ToTable?
modelBuilder.Entity<Entity>().ToTable("entity"); // this is fine

// we'd like these to be handled implicitly by `UseSnakeCaseNamingConvention`: https://github.com/efcore/EFCore.NamingConventions
modelBuilder.Entity<Post>().ToTable("post");
modelBuilder.Entity<Blog>().ToTable("blog");

Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a10898c5-abee-1843-cfff-b2707f8a079a
Version Independent ID: d9399618-488e-20b1-f707-35a191b95cc1
Content: Inheritance - EF Core
Content Source: entity-framework/core/modeling/inheritance.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: avickers

@gojanpaolo if you don't specify ToTable on the child entities, EF Core assumes that they are mapped to the same table as the parent; in other words, it sets up TPH (a single table for the entire hierarchy). ToTable - with a specific table name - is necessary in order to configure TPT.
One thing you can do, is go over all the entities yourself in OnModelCreating, and call ToTable with a transformed table name:
var snakeCaseNameRewriter = new SnakeCaseNameRewriter(CultureInfo.InvariantCulture);

foreach (var entityType in modelBuilder.Model.GetEntityTypes())
{
    if (entityType.BaseType is not null)
    {
        entityType.SetTableName(snakeCaseNameRewriter.RewriteName(entityType.GetTableName()));
    }
}

Note that this makes it impossible to use TPH, which is why EFCore.NamingConventions cannot do it for you. Note also that SnakeCaseNameRewriter is an internal type, so this code may break in the future and require adjustment (though probably nothing major).

After https://github.com/dotnet/efcore/issues/214 Is implemented it should be possible to add a custom annotation that will be picked up by a custom convention that sets up the TPT hierarchy.

Got it! Thanks for the responses! We'll iterate over the entities in OnModelCreating for now and keep track of dotnet/efcore#214. Thank you!


D&D 2.2 compatibility - skill check proficiency

Hi, this line needs to be updated for proper skill label in D&D 2.2.1
https://github.com/jessev14/dnd5e-character-monitor/blob/5129869cef1a18b2e3aaf921114d97f3647a3fc4/scripts/dnd5e-character-monitor.js#L523
to:
label: CONFIG.DND5E.skills[skl].label,

or there could be some check implemented to keep it backwards compatible with 2.1.5


No newline on the website for some reason

This is trying to fix the prep time list. It's not working on the website

It somehow works now


Upgrade to U14

Any plans to upgrade this to work on the new backoffice in v14 ?
Thanks!

No.
I only support LTS versions, and as I'm not a front-end developer I do no have the skills currently to migrate this... I will accept PRs though!
The next version will ve V17 hopefully (The next LTS)

Aw go-wan. Go wan.


[issue-358] remove legacy structure

Note: This is a pretty radical change. The idea behind it is that we can get the refactor-python-tools branch merged to main now that the 0.7.0 release is out, and then gradually add the various parsers and writers. The previous state can always be fetched from the git history (which should prove helpful for the writers in particular)
Signed-off-by: Nicolaus Weidner<EMAIL_ADDRESS>

We should also remove the old tests lest they all fail.


Migration steps fail on non-standards-compliant database systems (Oracle)

Currently, the HibernatePreparationTest is only able to test SQL standard-compliant databases, which isn't very many (neither Oracle nor MySQL are compliant with respect to create table syntax).
The initial goal is to support running the HibernatePreparationTest against an Oracle database.
The further goal is to support Oracle for all the currently dialect-specific database migration tests.

Closed by #38


[ISSUE #6336] [RIP-62] Cold Read Control

Make sure set the target branch to develop
What is the purpose of the change

fix #6336
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

The test report of [RIP-62] Cold Read Control](https://docs.google.com/document/d/1Ppz8V_a4piXQ6fnJjBFq6V7epBACpNQfD0NJOjio-4k/edit?usp=sharing)

Codecov Report

Merging #6507 (a13345c) into develop (24bc8c9) will decrease coverage by 0.27%.
The diff coverage is 16.23%.

@@              Coverage Diff              @@
##             develop    #6507      +/-   ##
=============================================
- Coverage      43.16%   42.89%   -0.27%
- Complexity      9007     9041      +34
=============================================
  Files           1107     1117      +10
  Lines          78269    79042     +773
  Branches       10202    10313     +111
=============================================
+ Hits           33782    33907     +125
- Misses         40248    40866     +618
- Partials        4239     4269      +30

Impacted Files
Coverage Δ

...rocketmq/broker/coldctr/SimpleColdCtrStrategy.java
0.00% <0.00%> (ø)

...ocketmq/broker/processor/AdminBrokerProcessor.java
23.82% <0.00%> (-1.45%)
:arrow_down:

...g/apache/rocketmq/client/impl/MQClientAPIImpl.java
22.55% <0.00%> (-0.64%)
:arrow_down:

...pache/rocketmq/common/coldctr/AccAndTimeStamp.java
0.00% <0.00%> (ø)

...he/rocketmq/common/constant/FIleReadaheadMode.java
0.00% <0.00%> (ø)

...rg/apache/rocketmq/common/constant/LoggerName.java
0.00% <ø> (ø)

...apache/rocketmq/remoting/protocol/RequestCode.java
0.00% <ø> (ø)

...org/apache/rocketmq/store/DefaultMessageStore.java
46.61% <0.00%> (-0.12%)
:arrow_down:

...main/java/org/apache/rocketmq/store/util/LibC.java
0.00% <ø> (ø)

...apache/rocketmq/tools/admin/DefaultMQAdminExt.java
29.28% <0.00%> (-1.01%)
:arrow_down:

... and 16 more

... and 14 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

reopen

LGTM

windows compatibility is ok


Infinite scroll and another jquery scripts

Ok, so thought to ask some help.
I'm first of all completely new to jquery, infinite-scroll is the first one I'm working with.
So, I have gotten infinite scroll to work perfectly but when it loads the 2nd page the other jquery scripts I'm using are not loaded. I have tried to google this up and find a solution but all I have managed to find (actually from another issue) was that infinite-scroll loads only html and that is most likely the reason it doesn't work.
So, what is the way to include further jquery scripts (I'd have to include multiple ones) into next pages? Most likely more than newbie question but if someone could point me out to right path I'd be more than grateful.

Infinite Scroll v3 is out!. It's an all new re-write, so take a look at how to upgrade from v2.
Infinite Scroll v3 'refreshes'


Configuration

i would like to know some information about the configuration
1)what does alias means in the config?
What does secret@localhost mean? and if it is a user name where i can pass  the password (dsn: redis://secret@localhost/1)
What does profile 2.2 means?
What is the usage of incr method? "$val = $redis->incr('foo:bar');"
Does the bundle support  redis  master-to-master replica?
Is there a way to disable redis cache in dev environment and test environment?

1.alias means that you can use the second id of redis service
2.redis doesn't like mysql, there's no username, so secret@localhost which means that secret is the password.
more information please check http://redis.io/topics/security
3.you can imagine that is the version of your redis
4.add 1 on the value of key foo:bar
5.It supports cluster
6.by using different config_xxx.yml file
all your question are easy to get on web, please try to ask more valuable question next time.

All questions have been answered. :) Please close this issue. Related to #263


Issue with jQuery scroll event

Thanks for this great plugin. I am using this plugin for my sites. I am working on a new site and I found an issue while I adding Slidebars plugin. I love this plugin, so I don't want to replace this plugin. I want you to help me resolve this issue
ISSUE
My jQuery Scroll event was working fine. But when I added Slidebar, scroll event is not working. I can't see any jQuery error in console. I have tried scroll event using differnt selectors like document, #sb-site etc..
$(document).scroll(function() {
alert("Hi");
});

$("#sb-site").scroll(function() {
alert("Hi");
});

can you please advice?
Thanks in advance

I have same issue. This code working at another page, but not with the one with slidebars.
$(function() {
  $('a[href*=#]:not([href=#])').click(function() {
    if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
      var target = $(this.hash);
      target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
      if (target.length) {
        $('html,body').animate({
          scrollTop: target.offset().top
        }, 1000);
        return false;
      }
    }
  });
});

Any ideas how to solve this issue?
Thanks

This happens for me as well, but I am unsure if this is a chrome issue only or not. Mine works in firefox but with chrome no matter what I always get 0 for the current scroll offset (and as such, scroll() is never fired). It could be a mix of both.
https://code.google.com/p/chromium/issues/detail?id=157855
It's sad that nearly 4 years later their bug is still not fixed. I have found no way to actually get the scroll position or get it to fire scroll()...

same here, all jquery scroll function are not working, it seems to be caused by slidebars.css, specially:
[canvas=container] {
width: 100%;
height: 100%;
overflow-y: auto;
position: relative;
background-color: white; /* Basic background color, overwrite this in your own css. /
-webkit-overflow-scrolling: touch; / Enables momentum scrolling on iOS devices, may be removed by setting to 'auto' in your own CSS. */
}
any workaround?

This might be of help to you! https://www.adchsm.com/slidebars/help/advanced-usage/scrolling-the-html-or-body-elements/
You need to scroll the canvas container as opposed to the html or body elements.

same bug for me, with slidebars 2.0.2.
I changed these lines:
html, body {
	width: 100%;
	height: 100%;
	overflow: hidden;
}

to:
html, body {
	width: 100%;
	overflow-x: hidden;
}

@adchsm I checked your answer. but the problem is sometimes jquery plugins are based on window scroll event.

@redpik do you have any problems with Slidebars after this change?

@makshh nope. but I need to test on other devices.

It seems like there is a problem with for example "top shift" with fixed navbar when you remove height and overflow-y.
CODEPEN (look at the fixed navbar position during scrolling when slidebar is opened)


func (v Vault) Secret(path string) does not accept context.Context

Feature / Enhancement proposed
It would be nice if func (v Vault) Secret(path string) would accept a context.Context.
Workarounds
N/A
Has the feature been requested before?
Not that I am aware of.

This is still relevant.

This is still relevant.


Nim compiler is running into a recursion limit while trying to expand templates

This issue can happen when there are too many nested templates or when the compiler can't efficiently manage deep template instantiations.
Current template: tests/asyncunit.nim
import unittest2, chronos
export unittest2, chronos
template asyncTeardown*(body: untyped): untyped =
teardown:
waitFor(
(
proc() {.async.} =
body
)()
)
template asyncSetup*(body: untyped): untyped =
setup:
waitFor(
(
proc() {.async.} =
body
)()
)
template asyncTest*(name: string, body: untyped): untyped =
test name:
waitFor(
(
proc() {.async.} =
body
)()
)
How to Reproduce:
Add the below test in file  tests/pubsub/testgossipinternal.nim and then run any of them nim c -r tests/pubsub/testgossipinternal.nim "handle multiple SUBSCRIBE and UNSUBSCRIBE events"
Test file attached.
message.txt
Error Log:
This will crash with log below and when you do the same thing in the new file by adding the same test in the new file and running it works fine without any error.
error.log

Removed assignments so they are properly done during weekly.

I can't reproduce this on NIm v2.0.12, running within nimbus-eth2 nimbus-build-system environment:
$ ../../env.sh nim c -r tests/pubsub/testgossipinternal.nim "handle multiple SUBSCRIBE and UNSUBSCRIBE events"
... it compiles ...
GossipSub internal WRN 2024-12-08 13:42:23.761+01:00 service is already stopped                 topics="libp2p switch" tid=1946825 file=switch.nim:79
WRN 2024-12-08 13:42:23.761+01:00 TCP transport already stopped              topics="libp2p tcptransport" tid=1946825 file=tcptransport.nim:209
. (0.00s)
[Summary] 1 tests run (0.00s): 1 OK, 0 FAILED, 0 SKIPPED

With specific tests/pubsub/testgossipinternal.nim used attached.
testgossipinternal.nim.txt
Nim Compiler Version 2.0.12 [Linux: amd64]
Compiled at 2024-11-04
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: ce7c6f4f3365db2cc63bdd9d460c71ed937ee9e9
active boot switches: -d:release


Support Optimizer-in-the-backward

Context
What is the purpose of this PR? Is it to

[x] add a new feature
[ ] fix a bug
[ ] update tests and/or documentation
[ ] other (please add here)

Please link to any issues this PR addresses.
Changelog
What are the changes made in this PR?
Enable Optimizer-in-the-backward for full_finetune_distributed
If optimizer_in_bwd=True, register hook to run .step() and .zero_grad() at .backwards(), free gradient-related memory earlier to optimize the peak memory.
Test plan
Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

[x] run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
[x] add unit tests for any new functionality
[ ] update docstrings for any new or updated methods or classes
[x] run unit tests via pytest tests
[x] run recipe tests via pytest tests -m integration_test
[x] manually run any new or modified recipes with sufficient proof of correctness
[ ] include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

UX
If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

[ ] I did not change any public API
[ ] I have added an example to docs or docstrings

Codecov Report
Attention: Patch coverage is 2.22222% with 132 lines in your changes missing coverage. Please review.

Project coverage is 66.97%. Comparing base (10b02e0) to head (1c3f389).
Report is 9 commits behind head on main.

Files with missing lines
Patch %
Lines

tests/torchtune/training/test_distributed.py
2.88%
101 Missing :warning:

recipes/full_finetune_distributed.py
0.00%
31 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1737       +/-   ##
===========================================
+ Coverage   25.99%   66.97%   +40.97%
===========================================
  Files         304      305        +1
  Lines       15627    16017      +390
===========================================
+ Hits         4062    10727     +6665
+ Misses      11565     5290     -6275

Flag
Coverage Δ

?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

could we draw loss curves in weights & bias to showcase numerics are the same with/without optimizer-in-the-backward?

could we draw loss curves in weights & bias to showcase numerics are the same with/without optimizer-in-the-backward?

The loss curves have been added in the comments section of the third column on the right-hand side table.


Regen for Gdk-Pixbuf v2.36.8

Apply last gir-files update
cc @GuillaumeGomez , @sdroege

👍

Thanks, I missed this
Strange that rust don't nags

That's a cargo thing, not a rust one. 😉

All good, just waiting for CIs!

You right

Ping

Sorry, forgot about it!


Are these errors normal?

2024/03/06 21:09:21 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:21 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:21 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:22 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:23 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:24 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:27 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:28 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:28 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:28 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:30 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:31 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:34 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:36 read tcp <IP_ADDRESS>:25531: connection reset by peer
2024/03/06 21:09:47 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:50 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:50 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:51 read tcp <IP_ADDRESS>:18123: connection reset by peer
2024/03/06 21:09:51 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:52 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:09:54 connect to <IP_ADDRESS>:443 failed: listen udp <IP_ADDRESS>:443: bind: cannot assign requested address
2024/03/06 21:10:01 read tcp <IP_ADDRESS>:62060: connection reset by peer

@CyrusTheV Can you try the latest version please?
https://github.com/bepass-org/warp-plus/releases/tag/v1.1.0


add support for querying with multiple smiles

Hi,
Could you quickly pull from the main to resolve the conflicts? Please save then without formatting so the PR is only doing the actual implementation.
Thanks


Form: eql? predicate fails with maybe macro

require 'bundler/setup'
require 'dry-validation'

form = Dry::Validation.Form do
  required(:foo).maybe(eql?: '23')
end

result = form.call('foo' => '')
puts result.success?
puts result.messages[:foo].inspect

__END__

Expected:
  false
  ['must be equal to 23']

Actual:
  true
  nil

GIT
  remote: git://github.com/dry-rb/dry-logic.git
  revision: e649fad58546e8e53a048d310c554ad910466a93

GIT
  remote: git://github.com/dry-rb/dry-types.git
  revision: 394fa8b62966fd398f84b83cc712e5b1355f4af7

GIT
  remote: git://github.com/dry-rb/dry-validation.git
  revision: 59fb0a09c4997db95076b49082dc68445ead4630

Similar failure with:
required(:foo).maybe(eql?: '23')
result = form.call('foo' => '')

This look like the maybe macro working as expected. Since in this case it will expand to none? | eql?('23'), passing it an empty string as input will be valid.
If you want a value to equal '23', then a required(eql?: '23') rule seems to make more sense to me here.
Does that make sense to you? If so, feel free to close this issue, or otherwise let me know if I'm misunderstanding your test here :)

@timriley Yes, thanks again for your reply!
As side note, it takes time to grasp how maybe expands. This is something that we should take care of. 😄


Issues/new form flow

Thanks for this, @grdw. Today is a public holiday in the UK so I took it off; I'll take a proper look at this first thing on Tuesday.

Hi Gerard,
Thanks for the pull request; I think the new workflow is a big improvement over what we had before, and I think the client will find it much easier to use.
I have a couple of comments:

While you’re welcome to make as many commits as you want during a work-in-progress, before merging into master it’s best to try to squash new features into fewer commits. Ideally, you want one commit per significant change.
The reason for this is that the Git log for the master branch should be a readable history of what has happened, and it quickly becomes unreadable if it records every small iteration of developing a new feature.
I don’t mean that you have to squash the entire branch to a single commit – despite some people advocating this – although smaller pull requests like “mail setup” or "updating links" could be. In this case, perhaps you might have:

Add default installed technology with InstalledTechnology#template
Add new technology profile selection classes (differentiation).
Add new testing ground form.

It’s also quite hard to comment on specific changes when you have to look through 63 commits to find the one with the change in question. :grin:
My workflow is normally something like:

Rebase branch against master (to minimise the amount of merge commits).
Interactive rebase to reorder related commits to be "next" to each other in the timeline.
Interactive rebase again to squash the related commits together, and update or rewrite commit messages.

If I feel like that's too much trouble (which it might be for this pull request), I'll git reset the entire branch, and use git add --patch to selectively create new commits.
See also: Squashing Github pull requests into a single commit

I’m finding that submitting the new testing ground form after clicking Testing Grounds -> Create submits an empty technology_profiles field. It works fine if I load testing_grounds/new directly. Likely this is caused by Turbolinks.

I have some other comments, but I’ll save those until we’ve dealt with – or discussed – the two issues above.

First issue is resolved (and I finally learned how to interactive rebase :dancers: )

I’m finding that submitting the new testing ground form after clicking Testing Grounds -> Create submits an empty technology_profiles field. It works fine if I load testing_grounds/new directly. Likely this is caused by Turbolinks.

The second issue is kind of vague. Do you mean when importing from ETM?

First issue is resolved (and I finally learned how to interactive rebase)

Great! :+1:  It's such a useful tool, I don't know how I'd manage without it these days.

The second issue is kind of vague. Do you mean when importing from ETM?

I can trigger the error by:

Visit /testing_grounds
Click "Testing Grounds" in the menu, then "Create new"
Enter a "Testing ground name" in the form
Hit submit

If I skip step 1 and 2, and instead directly visit testing_grounds/new (by typing it into the address bar), I can submit the form fine; that's why I'm guessing it's caused by Turbolinks. I'm not really sure why this would happen, though, as the technologies and topology_attributes[graph] parameter are both submitted back to the server, and there doesn't appear to be anything different to the technology_profiles field and ACE editor are set up.
I have posted the backtrace and submitted form parameters. If you can't reproduce it, let me know and I'll investigate a bit more (in case a browser extension is responsible).

I also managed to trigger the error. But only by clicking 'Create new' from the menu, not when browsing there.
A thing I notice though is that the syntax highlighting from ACE is off, whenever I can't submit it properly. So my guess is, that it would have something to do  with ACE.
Right now I fixed it by also updating the textarea directly. It isn't that nice of a fix, but considering time..

@grdw, Chael wants to be able to test this on staging tomorrow, so the any other comments I have can wait; they're not important. :smiley:
I think the only remaining show-stopper is that old testing grounds aren't migrated to your new technology_profiles column, which means they'll no longer work. Personally, I don't think we need separate technologies and technology_profiles (after creating the testing ground, technology_profiles is all we need). Maybe you or @ChaelKruip have reasons for wanting to store both, but that discussion can be had another day...
Will it be difficult to migrate the old testing grounds to use the new column? I think the contents of the old technologies column are in the same format as the new technology_profiles.

I think the only remaining show-stopper is that old testing grounds aren't migrated to your new  technology_profiles column, which means they'll no longer work.

I'll write a migration for this. I don't think it is going to be that hard.

Personally, I don't think we need separate technologies and technology_profiles

I haven't really discussed this in detail with @ChaelKruip. I do think that you can merge the technologies with the nodes and vice versa, skipping the technologies column.

@antw  For now I just migrated the technologies column to the technology_profile column and leaving the technologies column empty (with an empty array)(this can be automatically filled with the data from the technology_profile, once we've decided whether or not to keep or remove this column).

Thanks @grdw! Looks good, so I went ahead and merged this.


The backend does not uses the updated sparql endpoint when the user changes it from the GUI

This happens when trying to download triples.
Steps:

Start the application, download the triples.
Change the sparql endpoint from the GUI and try to download the triples again
The backend still uses the first endpoint

@saggu I tried mimicking the issue but it works fine on my end.


Add lisa-load-kmod --feature-param

WIP DO NOT MERGE
This is to be considered a technological preview until questions around managing multiple feature instances and different option sets are resolved.

I'll have to think a bit more on how multiple simultaneous uses of the module will coexist e.g. the user used lisa-load-kmod to enable a given feature, and then run a test that itself requires the module with another feature set.
So far it was not too bad as the only features around were ftrace-related, and FtraceCollector therefore was simply in charge of loading the module. Also, it would have been quite easy to take the union of features somehow.
But with feature parameters, that opens the door to the same feature being enabled multiple times with different configurations. Either the same loaded module will need to support that, or we will need to support loading the same module multiple times. This is an issue as the module name is simply lisa, and that is somewhat necessary to be able to interact with it in 3rd party scripts (if only for lsmod/insmod/rmmod)

Closing as the project has moved to https://gitlab.arm.com/tooling/lisa/


unmanaged-cluster list is hard to use with other unix tools

Feature Request
Currently, it's hard to use unmanaged-cluster list with other unix tools, like xargs
$ tanzu unmanaged-cluster list
  NAME        PROVIDER
  my-cluster  kind
  woof        kind

If I wanted to pipe this into xargs and perform operations on each cluster, I'd have to first to ignore the first line and also ignore the provider column.
Instead, we should provide some option that only outputs the names of each cluster, making it really easy to work with:
$ tanzu unmanage-cluster list -o list-names
my-cluster
woof

$ tanzu unmanage-cluster list -o list-names | xargs echo
my-cluster woof

This is very similar to what kind does:
$ kind get clusters
my-cluster
woof

Which supports easy operations with xargs like deleting all clusters:
$ kind get clusters | xargs -I _ kind delete cluster --name  _
Deleting cluster "my-cluster" ...
Deleting cluster "woof" ...

TLDR
unmanaged-cluster list should provide a "name" only option in support of it being easily workable with other unix tools.
We should also consider making this the default option so that out of the box it's easily used with other command line tools
Describe alternatives you've considered
I could just use jq to get a list of the names from the --json output but jq can be really tricky and isn't available on most systems by default

Historically, I've really liked docker's usage of -q to list non-table outputs.


Annotations at the start of a codeblock can break codeblock rendering

This is when an annotation is added to the triple-backtick start of a codeblock. It should only be inside the codeblock, after the newline.

Is this the expected output?
It looks like the extension did not parse the backticks into a code block.

@rzhao271 I think has to do with https://vscodeteam.slack.com/archives/C04PKH0BDQS/p1701449237374729
seems like its working for me now?

Clear your chat session and close open editors to reduce distraction.
Send the "repeat this code..." request.
You should get something like this that shows a vulnerability

If it refuses to answer, clear the session and try again


PR 636 miss fix for FusedAddRMSNorm function

In https://github.com/flashinfer-ai/flashinfer/pull/636/, you write const uint32_t smem_size = (ceil_div(num_warps, 4) * 4 + d) * sizeof(float); in GemmaFusedAddRMSNorm but not in FusedAddRMSNorm function.

Hi @Atream , yes I think you are correct, would you mind creating a pull request to fix it?

Yes, I've created a pull request to address the issue. You can find it here https://github.com/flashinfer-ai/flashinfer/pull/646 . Please review and let me know if there's anything else that needs to be adjusted. Thanks for your response!