GIP-142: Should the GnosisDAO fund the Finality SLO Pack — Upstream-first Alerts, Tiny dApp Finality Adapter, and Chiado Chaos Drills?

GIP-142: Should the GnosisDAO fund the Finality SLO Pack — Upstream-first Alerts, Tiny dApp Finality Adapter, and Chiado Chaos Drills?

  • In Favour
  • Against
0 voters

GIP: 142
title: Finality SLO Pack — Upstream‑first Alerts, Tiny dApp Finality Adapter, and Chiado Chaos Drills
author: [Dappsoverapps]
, Dapps over Apps
status: Draft
type: Funding
created: 2025-10-28
duration: 12–14 weeks delivery + 60–90 days maintenance
funding: **$47,000 **


Funding – Service Agreements

Category

Service Agreements — Network Reliability / Developer Tooling (upstream‑first)

Executive Summary

Gnosis Chain lacks DAO‑standardized finality/fork SLOs (alert rules + dashboards), a shared pause/resume SOP for incident response, and a small finalized‑read helper for dApps. Existing monitors (e.g., forkmon, ethstats, beacon explorers) provide visibility but no chain‑wide alert semantics or unified response guidance. We will upstream: (1) Alertmanager/Grafana SLO rules and dashboards tuned to Gnosis; (2) a tiny @gnosis/finality-adapter (getFinalizedBlockTag(), isSafeToSettle()) so apps prefer finalized/safe reads during incidents; and (3) Chiado chaos‑drill scripts plus a Bridge/dApp Pause & Resume SOP. No new long‑running service is introduced. Artifacts land where operators already work (docs, existing monitoring stacks) and ship with a drop‑in bundle for day‑1 use. Thresholds are derived at runtime from consensus/execution APIs.

Service Description

Key aspects (benefits)

  • Finality/Fork SLO Pack (upstream‑first):
    Alertmanager rules for stalled finality (time‑since‑finalization beyond a beacon‑derived threshold) and fork suspicion (cross‑endpoint block‑hash checks).
    Grafana dashboard: finalized‑epoch delta, time‑since‑finality, cross‑endpoint views.
    • Rules use grace windows and CL/EL inputs; they auto‑tune to current chain timing.
  • Tiny dApp helper (@gnosis/finality-adapter):
    • Exposes getFinalizedBlockTag() and isSafeToSettle(txHash).
    • Uses finalized/safe tags where available and falls back to beacon‑derived checks to avoid stale/unsafe reads.
    • Keeps dApps consistent during finality delays without custom app logic.
  • Chiado chaos drills + Pause/Resume SOP:
    • One‑command scripts to simulate missed epochs and shallow reorgs on Chiado.
    • A concise SOP that defines what to pause and when to resume for bridges/dApps—aligned to Gnosis timing and xDAI gas usage.
  • Upstream‑first, dual‑track delivery:
    • PRs to docs .gnosischain. com (Monitoring/Tools), plus small PRs with ready‑made snippets for popular operator stacks (e.g., importable rules/dashboards).
    • If any PR lags, the drop‑in “SLO Bundle” (JSON/YAML/TS) is immediately usable.
    • We do not replace validator monitoring or operate new services.

Service scope

  • In scope: alert rules & dashboards, dApp adapter, Chiado drills, pause/resume SOP, upstream docs/snippets, recorded workshop, short maintenance.
  • Out of scope: running a new monitoring service; per‑validator performance tooling; bridge/Safe simulators; mempool encryption.

Service delivery

  • alertmanager/gnosis-finality.rules.yml (finality delay; fork‑suspicion rules)
  • grafana/GnosisFinality.json (panels for finalized‑epoch delta, time‑since‑finality, cross‑endpoint hashes)
  • packages/finality-adapter (npm: @gnosis/finality-adapter)
  • drills/chiado-finality-{missed-epochs,reorg}.sh + Bridge/dApp Pause & Resume SOP (Markdown)
  • helm/values-snippets.yaml and operator snippets for common stacks (e.g., Sedge/DappNode) to enable one‑line rollout (optional PRs)

Pricing and payment (full scope only)

Total: $47,000 — staged by milestone (below).
Budget notes: No new infra/hosting. We build on existing stacks (Alertmanager/Grafana, docs site, operator tooling). Budget covers engineering, tests, docs, drills/SOP, a small review, and a short maintenance window.

Service Terms and Exit Strategy

  • Duration: 12–14 weeks delivery + 60–90 days maintenance.
  • Exit: All artifacts under MIT/Apache‑2.0. PRs are upstreamed where accepted; the drop‑in bundle remains public. Ownership/maintenance transitions to host repos or a GnosisDAO org.

Implementation Plan — Full Scope ($47,000)

Design principle: thresholds and timings are derived from CL/EL endpoints at runtime; no hard‑coded epoch/slot numbers. No new long‑running service is introduced.

Milestone 1 — Spec & Auto‑Tune Design (1 week) — $4,000

Deliverables: final SLO definitions (stalled finality; fork‑suspicion), rule shapes (grace windows, severities), dashboard layout, adapter API.
Acceptance: design doc posted; two community reviewers sign off; shows beacon/EL‑derived thresholds.

Milestone 2 — SLO Pack & Docs PR (weeks 2–4) — $16,000

Deliverables: gnosis-finality.rules.yml, GnosisFinality.json, docs PR (install/tuning), CI checks.
Acceptance: in a controlled test, a simulated finality delay triggers one de‑noised alert in ≤60s; dashboard panels render as documented; docs PR opened.

Milestone 3 — @gnosis/finality-adapter (weeks 5–6) — $6,000

Deliverables: npm package exposing getFinalizedBlockTag() and isSafeToSettle(txHash); example snippets (ethers/web3); unit tests.
Acceptance: package published; example app confirms finalized‑tag reads during a simulated incident; tests ≥90% coverage for adapter logic.

Milestone 4 — Chiado Drills & Pause/Resume SOP (weeks 7–9) — $10,000

Deliverables: scripts to simulate missed epochs/shallow reorgs; a concise SOP (thresholds, pause/resume criteria, comms template).
Acceptance: one public drill completed on Chiado; alerts fire; at least two teams report using the SOP; post‑mortem published.

Milestone 5 — Operator Snippets (weeks 9–10) — $4,000

Deliverables: small PRs (or ready gists) that add one‑line imports/snippets for common stacks (e.g., Sedge/DappNode); instructions to import bundle identically if merges lag.
Acceptance: PRs opened; bundle provides identical functionality without merges.

Milestone 6 — Cross‑Client Sampling & SLO Calculator (weeks 11–12) — $4,000

Deliverables: optional heuristics to compare two endpoints (classify node‑fault vs network‑event); an SLO calculator that outputs red/amber/green presets based on observed cadence.
Acceptance: classification reduces false positives in local tests; generated presets integrate cleanly as optional rules.

Milestone 7 — Workshop, Mini‑Audit & 30‑Day Soak (weeks 13–14) — $3,000

Deliverables: recorded workshop; focused review of rules/adapter; 30‑day observation of alerts in drills.
Acceptance: workshop published; review notes resolved; soak report shows ≤1 false positive/month and <60s mean‑time‑to‑alert in drills.


Evaluation (success metrics, 90 days)

  • Adoption: ≥10 operators import rules/snippets; ≥3 dApps use finality-adapter.
  • Signal quality: ≤1 false positive/month; <60s alert time in drills.
  • Readiness: one completed Chiado drill with post‑mortem; ≥2 teams confirm SOP usefulness.

Team / Org

Team & Relevant Experience

Dapps over Apps is a collective that ships open-source developer tooling and documentation. Our work typically focuses on scoped utilities (CLIs, adapters, config/rule packs) and clear guides that developers can use on day one.

Selected prior work :

  • Hardhat/Foundry (Anvil) local testing patch — added Arbitrum precompile addresses (ArbSys at 0x64, ArbGasInfo at 0x6c) and support for tx type 0x7e (deposits) for local workflows.
    Notes: Ox-rollup project · https://www.ox-rollup.com

  • Retrieval Utility for Filecoin — a measurement tool that tests CID retrieval across public gateways (experience with automated checks, reporting, and CLI UX).

  • VoxEdit → Unity/Roblox Asset Converter (open source) — a practical asset pipeline tool with docs and examples.

  • Arbitrum Stylus VS Code extension — IDE support for an emerging EVM/WASM stack (packaging, release process, and developer-helping ergonomics).

  • Avatar-Everywhere CLI — a portable identity toolkit that converts Sandbox avatars to VRM for use in other platforms, including simple on-chain ownership checks.

Project team

  • Abdulkareem Oyeneye — Project Lead
    Works on developer tooling and project coordination; has led multiple open-source utility efforts from scoping to docs and release.

  • Gospel Ifeadi — Smart Contract Engineer
    Experience across Rust/TypeScript/JS/Python and dApp/tooling projects; contributes backend automation and integration scripts.

  • Emmanuel Charles — Blockchain Developer & QA
    Focus on Solidity/Rust/TypeScript and test/QA practices; helps define acceptance criteria and automated checks.

  • Musa Abdulkareem — Engineer
    Contributes core engineering support and protocol-level integrations as needed.

Why this team fits this project

  • We regularly ship small, composable tools (CLIs, IDE extensions, adapters) and configuration-driven assets (patches, presets) with clear usage docs.
  • We’ve built measurement and verification utilities (Retrieval Utility) and local dev/test integrations (Hardhat/Anvil patch), which are directly analogous to producing Alertmanager/Grafana rule packs, a finality adapter, and drill scripts with acceptance tests.

Hi @DappsoverApps - If you update your GIP title to a question and fix the poll so that it’s 5 days from the date of publishing, we will assign your proposal a number and it will be live.

Please ping me here if and when you do that. More info here → Gnosis DAO | Gnosis DAO Docs

Thanks for your proposal @DappsoverApps. Can you confirm if this is entirely your own initiative, or if you’re working alongside others in the ecosystem (e.g. the teams working on Gnosis Chain within Gnosis Ltd) already?

We appreciate the clarity of your proposal, particularly the structure of milestones, the background on the team/previous work, and the summary of key aspects of your proposed work. However, without personal technical experience in this area, we’re having a hard time assessing the likely impact and desirability of this service package. Any supporting commentary/references from others in the ecosystem would help us to gauge that these are indeed useful additions, and not simply work for work’s sake.

Thanks again

2 Likes

Hi @john_szczepaniak , thank you for your comment. The forum does not give us option to make edit to the proposal. Can you help us out? Thank you.

Hi @staworth, thank you so much for taking time to review our proposal.

This is our own initiative. We don’t have a formal arrangement with Gnosis Ltd or NodeSentinel. We’ll open RFCs/PRs in public and, if merges take time, ship the same artifacts as a drop-in bundle so value doesn’t depend on upstream acceptance.
Where this would live: Gnosis’ monitoring hub (ethstats, forkmon, beacon, Blockscout).

Why the service is useful (signals from the ecosystem)

  • Observability exists; standardized alert rules/SOP don’t.
    Gnosis already points operators to forkmon/ethstats/beacon/Blockscout for visibility. Our pack adds importable Alertmanager rules (stalled-finality / fork-suspicion) and a short, shared pause/resume SOP to sit alongside those tools (not replace them).
    For reference → (https:/ /docs.gnosischain.com/node/management/monitoring-node

  • There’s precedent for incidents worth drilling.
    The Chiado testnet “entered a forked state” and was relaunched; exactly the scenario a 30–45-minute drill + SOP prepares teams for.
    More context → Chiado (testnet) fork note
    Ethereum also had brief non-finality events in May 2023; these incidents motivated finalized/safe-aware app behavior industry-wide.
    For more context → ETH finality incident – context

  • Client divergence risk on Gnosis is acknowledged.
    GnosisDAO recorded GIP-132 (Nethermind↔Erigon consensus discrepancy) and a one-time bounty whihc is aclear signal that fork-aware alerting is useful.

  • SLOs should be Gnosis-specific, not generic Ethereum.
    Gnosis documents 5-second slots, 16-slot epochs (~80 s) and ~2.7-minute finalization , so thresholds should derive from CL/EL at runtime, not be hard-coded.
    For more contetx → Mainnet parameters https: // docs. gnosischain .com/about/networks/mainnet?)
    Gnosis also operates post-Dencun/EIP-4844, which adds chain-specific considerations for operations and monitoring.
    More context → [Dencun on Gnosis( https :// docs.gnosischain. com/about/specs/hard-forks/dencun?)*

  • DAO priority on reliability tooling is visible.
    The community has discussed/advanced validator-monitoring funding (e.g., NodeSentinel under GIP-138), showing a need for chain-reliability investments; our work complements, not duplicates, per-validator monitoring.

How we will make impact easy to judge (quick, verifiable steps)

  • Post an RFC + first rule/dashboard PR so you can try it immediately (install steps included).

  • Run a short Chiado drill (missed-epochs + shallow reorg) with a brief post-mortem, since Chiado previously forked.

  • Report concrete quality metrics: ≤ 1 false-positive/month; < 60 s alert time in drills; adoption counts (rule imports / adapter usage).

  • Keep scope non-invasive: configs + a tiny adapter + docs only—no new long-running service (this complements forkmon/ethstats/beacon rather than replacing them).

We hope the above answers clarifies your concerns. Please kindly let us know if you need further clarifications. We are happy to answer.
Thank you.

Hi @john_szczepaniak , we hope you are doping good? We are following up on our last comment . Thank you.

1 Like

All set. Apologies for the delay it was a crazy week.

1 Like

Ah, no worries, thank you!

Hi @staworth , we hope you are doing great! We wanted to follow up and ping youi just in case you missed our response to your questions. Thank you!