[CLOSED] Governance Fund Mission Request: Open-source Monitoring & alerting

Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer

Total grant amount: 114,000 OP (funding 52,000 OP per team, for up to 2 teams)

Should this Governance Fund Mission be fulfilled by one or multiple teams: Up to 2

OP Labs or Optimism Unlimited Sponsor: Pierce

Reviewing Body: Developer Advisory Board Foundation Mission Team

Submit by: October 10, 2025

Selection by: October 17, 2025

Start date: October 20, 2025

Governance Fund Mission Request

Open-source SDK for onchain monitoring and alerting:

  • Users can set monitoring on OP chains with custom invariants

    • Invariants can touch one or multiple addresses
  • Users can define the action to be taken automatically when invariants fail

    • Example, pause the protocol
  • Alerts via popular paging solutions (Slack, Telegram and PagerDuty)

  • Dashboard UI to add invariants, fetch ABI from sourcify/etherscan, set hooks for slack/tg/pagerduty

    • Admin privileges

    • Add rpc or multiple rpc for load balancing

    • See history of alerts

The SDK should be bundled with rulesets relevant for the following DeFi protocols:

  • Uniswap V3

  • Aave V3

The SDK and ruleset repo should be delivered with extensive documentation to enable contributions from the community.


How will this Mission help accomplish this Season’s Intent?

Reduce the cost of monitoring, enable the community to contribute and progress much faster. Think what happened after foundry/echidna/halmos released: standard of smart contract testing increased due to these open-source tools. We want to have the same impact on security with real-time monitoring.

Rulestes will enable community-maintained rich corpus of invariants and can be modified by projects to suit their needs.

This SDK and ruleset corpus can be extended to monitor for cross-chain operations when interop ships.

What is required to execute this Mission?

  • A framework for specifying rulesets. This framework should be extensible to enable diverse rulesets (protocol invariants, movement of disproportionate amount of funds from or to protocol etc.)

  • To start, there should be example rulesets for Uniswap V3 and Aave V3.

  • Mission proposer should submit a set of rulesets they intend on implementing for the initial release, to capture a variety of scenarios. (For example, detecting invariant breakage on a pool, detecting interacting with a sanctioned address, detecting changes to a controlling multisig, etc.)

  • An SDK which can be self-hosted and plugs with this ruleset framework and various tools (slack, tg, pagerduty, RPCs) for alerting.

  • Extensive documentation and contribution guidelines to enable community contributions.

  • Code released under a permissive OSS license (e.g. Apache2, MIT, etc.)

How should progress towards completion be measured?

  • Milestone 1:

    • SDK which triggers alerts on Slack, Telegram and PageryDuty for ERC20 transfers.
  • Milestone 2:

    • Framework to build rulesets.

    • Validation of proposed initial rulesets.

    • Uniswap V3 and Aave V3 reference rulesets in this framework

  • Milestone 3:

    • Fully-built SDK and accompanying UI

Application Instructions

To apply for this Governance Fund Mission, please complete the form in the expandable section below and leave your response as a comment on this forum thread. Submissions will be open until Oct. 10th, at which time the Developer Advisory Board will review all submissions and select up to 2 individuals/teams to complete the work defined here.

Submission Form

Submission Form

Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Developer Advisory Board may reach out using the contact info provided to request more information as necessary.

Governance Fund Mission Application

Please verify that your team members below:

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

What makes your team best-suited to execute this Mission?

  • […]
  • […]

Please describe your proposed solution based on the above:

  • […]
  • […]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece 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:

  • […]
  • […]

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

  • I understand my grant for completing this Governance Fund Mission will be locked for one year from the date funds are transferred to the locked multisig wallet.
  • 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 Collective Grant Policies
  • I confirm that I have read and understand the Collective Grant Policies
6 Likes

Governance Fund Mission Application

Team Lead

Contact info

  • timdaub on TG, timdaub.eth on FC

L2 recipient address

  • timdaub.eth

Team members and previous work

Why this team?

  • Shipping the crawler in production for years on Optimism mainnet; the ETL architecture in src/boot.mjs and src/lifecycle.mjs already handles retries, LMDB persistence, and queue concurrency.
  • Configuration is Ajv-validated (ajv) via src/schemata/configuration.mjs, so new rules can be enforced with schema upgrades rather than ad hoc code.
  • Proven ability to turn requirements into maintained docs + SDKs; comfortable operating under GPL-3 today and willing to rebrand and relicense under MIT if that unlocks adoption.

Proposed solution

  • Interview prospective users before implementation to collect the rules language requirements and UX expectations.
  • Add a WebSocket/newHeads listener strategy to stream blocks and events through the existing Extractor/Transformer/Loader pipeline, eliminating the current polling delay.
  • Reuse the loader.end hook to dispatch alerts and package adapters for Slack, Telegram, and PagerDuty.
  • Introduce a ruleset specification section in the configuration model so invariants live alongside extractor definitions; validated by Ajv with strong typing in docs.
  • Ship reference Uniswap V3 and Aave V3 rulesets that show how to plug protocol invariants into the configuration model; keep them editable without code changes.
  • Release a dashboard UI on top of LMDB to manage invariants, alert targets, and RPC load balancing; align styling with the existing docs site for continuity.
  • Default license stays GPL-3, but I am happy to rename/unbrand the crawler if that increases the chance of getting the grant.

Step-by-step plan (target dates)

  • Oct 20 – Nov 1, 2025: Conduct structured interviews with target users to synthesize rules-language requirements and alerting UX.
  • Nov 3 – Nov 21, 2025: Implement the real-time listener strategy, update worker lifecycle, and wire Slack/Telegram/PagerDuty loaders; publish docs + quickstart configs for ERC20 transfer monitoring.
  • Nov 24 – Dec 23, 2025: Design the ruleset framework, extend the configuration schema, and build a reference library of composable predicates; integrate execution into the loader pipeline with test coverage.
  • Jan 6 – Feb 7, 2026: Finalize Uniswap V3 and Aave V3 invariant packages, validate against Optimism historical replays, and document extension patterns.
  • Feb 10 – Mar 7, 2026: Deliver the dashboard UI, polish SDK packaging, update attestate.com docs, and run end-to-end alert rehearsals.

Critical milestones

  • M1 (Nov 21, 2025): Real-time listener shipping, ERC20 alerts firing through Slack/Telegram/PagerDuty using production configs.
  • M2 (Dec 23, 2025): Ruleset framework merged, validated with replayed Uniswap V3 and Aave V3 scenarios, and fully configurable through the schema.
  • M3 (Mar 7, 2026): Dashboard UI + SDK release tagged, documentation live, and community onboarding guide published.

Additional support requested

  • Advisory support on designing a rules-language that balances expressiveness with safety; introductions to experts in runtime verification or DSL ergonomics.
  • Direct access to Optimism ecosystem stakeholders willing to be interviewed and provide ongoing feedback (opt-in DMs, small cohort of early adopters).
  • Help coordinating user research sessions so the ruleset framework reflects real operational workflows.

Terms confirmation

  • :check_box_with_check: I understand my grant will be locked for one year.
  • :check_box_with_check: I understand KYC is required.
  • :check_box_with_check: I understand my grant may be clawed back if milestones aren’t met.
  • :check_box_with_check: I confirm that I have read and understand the Collective Grant Policies.
4 Likes

Governance Fund Mission Application: Open Source Monitoring & Alerting

Team Lead

  • Name: Daniel Martin Jimenez (@damarnez)

  • Contact: Telegram: @damarnez Twitter: @damarnez

  • L2 Recipient Address: damarnez.eth


Team Members & Previous Work

I bring extensive experience building production-ready systems in DeFi and Web3, including contributions to Aave, Lens and Euler, among other protocols.

  • 20 years building things that work.

  • Over 5 years of blockchain and Web3 development.

  • Strong background in designing, deploying, and maintaining mission-critical applications.

  • Proven ability to identify pain points and deliver practical solutions in fast-moving, high-impact environments.


Why This Team?

My track record in launching and maintaining top-tier blockchain products gives me:

  • Deep understanding of the technical challenges protocols face at scale.

  • The ability to design robust, production-grade implementations.

  • Firsthand knowledge of DeFi ecosystems, making me well-suited to design a monitoring and alerting system that meets real-world needs.

  • Beyond understanding these challenges, I have personally dealt with incidents where missing or delayed alerts caused real risks for protocols. This direct experience shapes my approach to building a system that is practical, reliable, and easy to adopt.

This combination of development expertise and domain knowledge ensures the delivery of a reliable open-source monitoring and alerting framework for Optimism and beyond.


Proposed Solution

The goal is to build an open-source monitoring and alerting system tailored for DeFi protocols and L2 infrastructure.

Key Features

  1. Flexible Configuration

    • Rules defined in YAML (simple, declarative format).

    • Configurations can be updated via UI or locked during deployment.

  2. Backend Service (Rust)

    • Core monitoring logic built in Rust for speed and safety.

    • Support for multiple chains with configurable ranges, triggers, and hooks.

    • Local storage with SQLite (fast setup), plus optional PostgreSQL integration for persistence and analytics.

  3. Alerts & Integrations

    • Connect alerts directly to Telegram, Slack, or custom webhooks.

    • Extensible alert logic for custom protocol needs.

  4. Invariant Logic

    • Easy framework for defining invariants (e.g., liquidity checks, solvency checks).

    • Extensible/composable design to detect advanced patterns such as flashloan abuse or suspicious behaviors.

  5. Dashboard & SDK

    • React frontend for monitoring, user management, and configuration.

    • Lightweight SDK for protocol teams to integrate quickly.


Step-by-Step Plan (Target Dates)

  • Oct 20 – Oct 23, 2025 → Gather requirements from protocol teams, compile needs list.

  • Oct 23 – Nov 21, 2025 → Develop initial Rust backend, contract watchers, and chain connectors.

  • Nov 21 – Dec 28, 2025 → Implement invariant framework (extensible detection logic).

  • Dec 28 – Jan 15, 2026 → Build React dashboard, user management, and SDK integration.

  • Jan 15 – Feb 7, 2026 → Implement invariants for Aave, Euler, and Uniswap as examples.

  • Feb 7 – Feb 10, 2026 → Final polish, QA, and documentation.


Critical Milestones

  • Nov 21, 2025: Backend in Rust functional.

  • Dec 28, 2025: Invariant framework designed and implemented.

  • Jan 15, 2026: Dashboard and SDK completed.

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

  • :check_box_with_check: I understand my grant for completing this Governance Fund Mission will be locked for one year from the date funds are transferred to the locked multisig wallet.

  • :check_box_with_check: I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant

  • :check_box_with_check: I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies

  • :check_box_with_check: I confirm that I have read and understand the Collective Grant Policies

6 Likes

WakeUp Labs Governance Fund Mission Application: Open-source Monitoring & alerting

Team Lead

Contact info

Team members & previous work:

  • WakeUp Core Engineers (10 FTEs): Solidity, TypeScript, Node.js, React, infra & monitoring. Delivered Optimism RFG1 Indexer (open source), Interop Alerts SDK (cross-chain monitoring for OP Stack), Arbitrum Stylus SDK (AssemblyScript integration), Velora/ParaSwap DAO automation (PIP-55), Starknet Privacy ERC20, among others.
  • UX/UI Designer (1 FTE): Responsible for the dashboard interface and usability.
  • DevOps Engineer (1 FTE): RPC infra, AWS nodes, and deployment automation.
  • Project Manager (1 FTE): Coordination, milestone reporting, and DAO communication.

Repos: WakeUp Labs · GitHub
Website: https://wakeuplabs.io
X: x.com/wakeuplabs

What makes your team best-suited to execute this Mission?

WakeUp Labs is a long-standing Optimism contributor focused on developer tooling and open infrastructure.

The team has a proven record of delivering Optimism-funded projects such as the RetroPGF Indexer and the Interop Alerts SDK, and also builds core infrastructure for Coinbase, Arbitrum, Starknet, Aztec, ParaSwap, Rootstock, among others .

Unlike solo-developer competitors, WakeUp brings a multidisciplinary structure with engineering, UX, DevOps, and project management, along with established trust within Optimism governance.

With this Mission, WakeUp aims to deliver an open source Monitoring & Alerting SDK + Dashboard that helps every protocol on Optimism detect anomalies, track on-chain health, and respond faster. The proposal builds directly on our prior work with Optimism and reinforces our long-term commitment to strengthening the Superchain’s reliability.

Proposed solution

Protocols on Optimism currently lack a standardized, open source tool to monitor smart contract health and receive timely alerts. Existing approaches are ad-hoc or closed source, making incident detection slow and inconsistent.

WakeUp Monitoring & Alerting SDK + Dashboard will provide a complete and extensible monitoring system:

  • SDK for invariant checks: Define customizable rules to observe on-chain conditions and detect anomalies in real time. The SDK connects to Optimism nodes via WebSocket subscriptions (eth_subscribe) for real-time event streaming, while maintaining compatibility with standard JSON-RPC polling when WebSocket endpoints are unavailable.

  • Slack notifications (extensible): Out-of-the-box Slack alerts, with a modular design ready for future channels (Telegram, PagerDuty, Webhooks).

  • Integration hooks: Trigger off-chain responses or user-defined scripts when invariants fail, enabling automated reactions without requiring contract ownership or admin privileges. WakeUp will not require contract ownership; all responses occur off-chain through safe, configurable hooks.

  • Dashboard-first UX: A web interface to configure rules, view alert history, manage users, and visualize contract data, designed for both developers and operations teams.

  • Multiple RPC endpoints: Support for configuring multiple RPC providers for load balancing and redundancy, ensuring reliable performance even under high network activity.

  • Example invariants: Provide reference templates for Uniswap v3 (pool price ratios, liquidity range) and Aave v3 (health-factor thresholds, oracle-update delays) to demonstrate the SDK’s flexibility.

  • Superchain-ready architecture: Built to support monitoring across multiple OP Stack chains in the future.

This approach balances immediate usability with extensibility, helping Optimism standardize security practices while remaining fully open source.

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

Phase 1 (Weeks 1–5) – MVP & Basic Alerts

  • Build the core SDK in TypeScript.
  • Implement ERC-20 transfer monitoring using WebSocket subscriptions for real-time detection, with Slack alerts as the first supported notification channel.
  • Deliverable: SDK repo, documentation, and working demo.

Phase 2 (Weeks 6–12) – Rule Framework & Protocol Examples

  • Implement modular rule definition (JSON/YAML configs).
  • Develop example invariants for Uniswap v3 (price ratios, liquidity checks) and Aave v3 (health factor, oracle frequency).
  • Extend dashboard for rule creation and management.
  • Deliverable: SDK, dashboard, and reference examples.

Phase 3 (Weeks 13–16) – Full Release

  • Finalize dashboard (rule editing, visualization, alert history).
  • Conduct end-to-end testing and publish documentation.
  • Deliverable: Monitoring & Alerting Suite v1.0 (open source release on npm and GitHub).
  • Documentation & contribution guidelines: Publish extensive developer documentation, usage examples, and contribution guides to help the community extend the SDK with new rules or alert channels.

Estimated timeline: November 2025 → February 2026.

Milestones

  1. M1 – MVP (end of Nov 2025): SDK live in repo; WebSocket-based event streaming operational; Slack alerts working end-to-end.
  2. M2 – Rule Framework + Libraries (end of Dec 2025): Modular rule system implemented; Uniswap v3 and Aave v3 templates validated.
  3. M3 – Full Release (Feb 2026): Dashboard and SDK 1.0 published; documentation, contribution guidelines, and public announcement complete.
  • Long-Term Support:
    WakeUp Labs will provide two years of maintenance and production support post-release, ensuring ongoing compatibility with future OP Stack versions and addressing bug fixes or security updates.

Support requested

  • Introductions to teams such as Uniswap and Aave for validation of reference invariants.
  • Optional audit support if a minimal on-chain helper contract is introduced.
  • Delegate and community feedback to guide future alert-channel extensions.

Terms

  • :check_box_with_check: I understand my grant for completing this Governance Fund Mission will be locked for one year from the date funds are transferred to the locked multisig wallet.
  • :check_box_with_check: I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
  • :check_box_with_check: I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies
  • :check_box_with_check: I confirm that I have read and understand the Collective Grant Policies
4 Likes

Walnut Governance Fund Mission Application: Open-source Monitoring & alerting

Team Lead: Roman Mazur

Contact info: Email: roman@walnut.dev | Telegram: @rmazur

L2 recipient address: 0x368ac9da9f793baa41fa75cb2d75a7d6229cf35b

Team Members and Previous Work:

Walnut Labs is a team of experienced Web3 developers specializing in Ethereum, EVM internals, transaction debugging, compiler technology, simulations and monitoring.

We have ongoing multi-year partnerships with StarkWare and Offchain Labs, contributing to projects around Cairo and Cargo Stylus, and our team includes design and product expertise to deliver complete, production-ready tools end-to-end.

Core team members for this project:

  • Roman Mazur — Product Lead 10+ years of experience (ex-Argent, Microsoft). Full-time in Web3 since 2020 with deep expertise in Ethereum/EVM, RPCs, transaction simulations. [LinkedIn] https://www.linkedin.com/in/mazurroman

  • Simon Arvaux — Full-Stack Web3 Developer 10+ years of professional experience (5+ in Web3). Strong background in EVM, blockchain indexing, Foundry, and Anvil. [GitHub] https://github.com/saimeunt

  • Marija Mijailovic — Full-Stack / Web3 Engineer 8 years of experience (5 in Web3). Skilled in Rust, Python, Node.js; strong experience with infra, nodes and transaction monitoring. [GitHub] https://github.com/marijamijailovic

Selected projects:

  • walnut.dev – Web-based transaction debugger and simulator for Starknet, live for 2+ years and widely used across the ecosystem.

  • GitHub: walnuthq – Collection of open-source projects built in collaboration with Offchain Labs, Miden, Optimism, Starknet and others.


What makes your team best-suited to execute this Mission?

  • Proven Track Record: Established team with a history of delivering and maintaining high-quality developer tools across Ethereum, with long-term partnerships with Offchain Labs and Starkware.

  • Technical & Product Expertise: Deep experience in web3 development, infra, monitoring, and compiler internals, combined with BD skills to ensure both technical excellence and adoption.

  • Established Network of Partnerships: Our connections with Solidity developers and Rollup infra teams through Walnut ensure we build what’s needed and that the tool gets used. Already discussed with the OP Labs Infra team (they actually pointed us to this mission), guaranteeing adoption and continuity beyond the grant.

  • Long-Term Alignment & Sustainability: Monitoring is part of our roadmap for Walnut, our open-source transaction debugger and simulator. We plan to integrate this tooling directly into Walnut which will bring distribution, sustained use and recurring revenue to fund further development.

  • Already Completed Technical Exploration: We’ve already researched the monitoring framework in depth, focusing on the Ruleset SDK design. This work shaped our proposal to cover all key features — including cross-chain monitors and data persistence across executions. See Technical Exploration Document.

Please describe your proposed solution based on the above:

We propose to build a fully open-source monitoring framework (Apache 2.0) that allows developers to define, deploy, and manage blockchain-specific monitors.

Our proposal is highly inspired and influenced by our discussions with OP Labs infra team, their in-house monitoring implementation (link) and recently open sourced openzeppelin-monitor.

Features:

  • Real-time Monitoring: Continuously observe blockchain activity for defined events and transactions.

  • Custom Rulesets (Invariants): Define flexible logic to detect on-chain conditions and behaviors that matter to your system.

  • Cross-Chain Monitors: Initial support for monitoring SuperchainERC20 transfers and related cross-chain activity.

  • Data Persistence: Each monitor execution can store data in a DataBag, allowing context to be shared between executions.

  • Multi-channel Alerts: Send notifications through Slack, Discord, Telegram, Email, Webhooks, or custom integrations.

  • Web UI: Manage monitors, explore historical actions, and visualize trends through rich interactive charts. See mockups.

  • Extensible Framework: Easily extend support for additional chains, monitor types, and integrations.

We will also implement 17 initial monitors to provide a rich reference. There will be basic monitors, advanced, cross-chain as well as specific monitors to Uniswap and Aave. See this document for full list with detailed descriptions and pseudocode implementation.

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

Phase 1 (Months 1-2) – Core SDK & Action Integrations

  • Finalize spec for monitors, invariants, actions, and the config schema; review with OP Labs.

  • Implement TypeScript SDK primitives: data sources (OP RPC), evaluation engine, scheduling hooks.

  • Implement action connectors: Slack, Telegram, PagerDuty.

  • Provide sample monitors: ERC20 balances (including SuperchainERC20), Global Events and Fault proof withdrawals.

  • CI/CD, tests, docs, example repo; pilot on an OP test env and validate real alert delivery.

Deliverables: SDK v0.1 + docs, 3 action connectors, 3 sample monitors, pilot report.

ETA: December 2025

Phase 2 (Months 1-2) – Ruleset Framework & Reference Monitors

  • Build ruleset composition/validation (JSON/YAML schema).

  • Publish 17 reference monitors covering protocol-level invariants, including Uniswap V3 and Aave V3 reference rulesets (see full list with details).

  • Cross-chain validation via custom RPCs; performance testing and tuning.

  • Expand docs with canonical templates and troubleshooting.

Deliverables: Ruleset framework + schema docs, 17 reference monitors, Uniswap V3 & Aave V3 rulesets.

ETA: February 2026

Phase 3 (Months 1-2) – Orchestration Service & Web UI

  • Build monitor orchestration service (register/schedule/execute, alert routing, persistence of results).

  • Expose REST APIs for monitor lifecycle, alert history, and querying results.

  • Deliver Web UI for managing monitors, actions, and viewing state/alert history.

  • Multi-RPC support, basic auth, audit logs; packaging for self-host (Docker Compose/k8s yaml).

  • Internal acceptance with OP Labs; open-source release under Apache-2.0.

Deliverables: Orchestration service v1.0, UI v1.0, deployment manifests, full docs, acceptance sign-off.

ETA: March 2026

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

Milestone 1: Core SDK and Action Integrations

  • TypeScript SDK and configuration schema for defining monitors, invariants, and actions is created.

  • Basic monitor types (e.g., ERC20/SuperchainERC20 balances, Global events, Fault proof withdrawals) are implemented.

  • Integrations for Slack, Telegram, and PagerDuty alerts.

Milestone 2: Ruleset Framework and Reference Monitors

  • Framework for composing and validating complex rulesets (combinations of monitors and actions) is created.

  • 17 reference monitors demonstrating protocol-level use cases (for full list see this) are developed.

  • Flexibility of the framework across multiple OP Chains via custom RPCs (and multiple) is available.

Milestone 3: Web Service and UI

  • Build the monitor orchestration service (APIs for scheduling, execution, and persistence).

  • Web-based UI for managing monitors, alerts, and actions is created.

  • Historical data visualization and alert history view (leverage Grafana) is created.

Please list any additional support your team would require to execute this mission:

We do not require any additional support to successfully execute this mission. We are already in contact with the OP Labs DevOps team, who can provide early feedback for the project. That said, introductions to other developers who might find this useful — or feedback on our approach — is always welcome and appreciated.

Terms

  • :check_box_with_check: I understand my grant for completing this Governance Fund Mission will be locked for one year from the date funds are transferred to the locked multisig wallet.

  • :check_box_with_check: I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant

  • :check_box_with_check: I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Collective Grant Policies

  • :check_box_with_check: I confirm that I have read and understand the Collective Grant Policies

2 Likes

Hey guys, any updates on the final selection?

Apologies for the delays, just coordinating the final details. We’ll have an update up soon!

2 Likes

Thank you for your applications and interest in this Mission.

The DAB has decided to move forward with the proposal made by:

  • @romanm of Walnut Labs
    We will be reaching out with next steps.

For those who were not selected this time around, we would encourage you to keep an eye on future Mission Requests.

3 Likes

With all due respect for the work done by Walnut Labs — the proposal was open to two teams, but you chose only one, a previous company that had already worked with you ( OP labs ), closing the opportunity for new ones to participate. This doesn’t encourage people to join and build new projects on top of OP to help grow the community.

Thanks a lot @shazow for this message and for the trust the DAB is placing in Walnut Labs — we’ll make sure the work is delivered to the highest standard.

We’ve already received the email from Optimism and plan to start the project soon.

If possible, I’d love to connect with the person or team who initiated this grant request to better understand their goals and ensure our work aligns with their vision. You can reach me directly on Telegram at @rmazur.

cc @blockdev

With all due respect for the work done by Walnut Labs — the proposal was open to two teams, but you chose only one, a previous company that had already worked with you ( OP labs ), closing the opportunity for new ones to participate. This doesn’t encourage people to join and build new projects on top of OP to help grow the community.

The mission budget was allocated for “up to 2 teams”. It’s hard to know ahead of time what kinds of submissions we’ll get and whether it makes sense to have two teams pursue the same mission separately.

We’re trying something a little different this season where instead of doing all of the mission requests upfront, we’re trying rolling mission requests and recycle the unallocated budgets into new mission requests.

We hope that the rolling mission requests approach will create a greater variety of opportunities for different teams to participate.

While we try to coordinate with many stakeholders in the Optimism ecosystem, bear in mind that the DAB is independent elected body (separate from OP Labs) and our mandate is to advance the Season’s intent set by governance.

Thank you again for taking the time to submit your application, it was a strong submission and hope to see more from you!

3 Likes

If possible, I’d love to connect with the person or team who initiated this grant request to better understand their goals and ensure our work aligns with their vision. You can reach me directly on Telegram at @rmazur.

I’ll setup a group chat and we’ll go from there, looking forward to working with you!

2 Likes