[PROPOSAL] [DRAFT] SnapGuard - Verifiable State Sync & Snapshot Pre-flight (Validator-Grade)

Hub Proposals Proposal Ideas
1

Category: Critical validator tooling / AEZ reliability
Request: $35,000
Timeline: 10–12 weeks build + 12-months Maintenance Commitment
License: Apache-2.0
Deliverables: Open-source CLI, GitHub Action, ops runbook PRs, evidence pack

1) Executive summary

SnapGuard is a small, offline CLI that fail-fast verifies Cosmos state sync and snapshot restores before an operator touches a live data directory. It:

  • Derives trusted state-sync parameters from chain-registry with multi-RPC header witnesses and optional CometBFT light client verification.

  • Verifies snapshot integrity (checksums and, where supported, metadata) from any provider (Quicksync, Polkachu, or self-hosted).

  • Runs an ephemeral restore and confirms AppHash/height match the trusted header.

  • Emits a single Go/No-Go report plus a paste-ready config.toml stanza.

Today, operators often discover failures after long downloads/restarts. SnapGuard makes bootstrap predictable, auditable, and fast. Demand across validators and relayers is broad and immediate (no LOIs required).

2) Problem & urgency

  • Trust params are fragile. Operators manually copy trust_height/trust_hash under time pressure → frequent mismatches.

  • Snapshot integrity lacks a standard pre-flight. Providers publish tarballs and checksums; CometBFT only validates AppHash after restore.

  • Nearly all validators and many relayers perform state sync or snapshot restores during upgrades/incidents. Failed syncs waste hours, extend incidents, and stall interchain flows.

image
image1536×1024 156 KB

3) What we’re building

CLI commands

  1. sg plan - Trust & config planner

    • Pull chain-registry; fetch headers from N RPCs (default 2; auto-escalate to 3 if snapshot metadata is absent).

    • Emit paste-ready config.toml state-sync stanza + rationale.

  2. sg lc-verify - Optional light client header verification

    • Verify the trusted header commit against ≥2 RPC peers; cache proof bundle.

  3. sg fetch - Snapshot fetch + manifest

    • Download from any URL; record provider checksums; build a content-addressed local manifest.

  4. sg verify - Pre-restore verification

    • Check declared height vs witnessed headers; validate checksums; if metadata exists, verify it; if metadata is not supported, require 3-of-N header witnesses (light client verification strongly preferred).

  5. sg dryrun — Ephemeral restore & AppHash check

    • Restore to a scratch dir; query ABCI Info; compare AppHash/height to the trusted header; tear down scratch.

  6. sg compat — Pruning/indexer compatibility checks

    • Detect known-bad snapshot vs node flag combos; warn (YELLOW) or fail (RED).

  7. sg go-no-go — One-page final report

    • RED / YELLOW / GREEN gates + paste-ready config.

Hard gates

  • RED if: headers disagree, checksums fail, light client verification or metadata proof fails, or AppHash/height mismatch.

  • YELLOW if: metadata is not supported but 3-of-N headers agree (and light client verification unavailable); or if compat risks detected.

  • GREEN only if all gates pass, including light client verification or metadata proof on chains that support one of these signals.

Out of scope v1: hosting snapshots, running any network server, full light client sync, GUI.

image
image1024×1536 131 KB

4) Why it’s not duplicative

  • Not a snapshot host - source-agnostic verifier; works with any provider.

  • Not “CometBFT already checks” – runtime checks happen after restore; SnapGuard fail-fasts before you commit time/data.

  • Not a dev framework/halt debugger/linter - an ops pre-flight that drops into validator SOPs.

5) Deliverables, timeline & budget (10–12 weeks) - $35,000

# Milestone Acceptance Budget
M1 Planner & registry (wks 1–2) sg plan (2-of-N headers), config generator, docs & tests. $6,000
M2 Fetch & verify (wks 3–5) sg fetch (manifests/sha) + sg verify (height/header/metadata), friendly errors. $7,000
M3 LC verify & dry-run (wks 5–7) sg lc-verify (proof cache) + sg dryrun (scratch restore + ABCI Info); GREEN on Cosmos Hub + 1 consumer (transcripts). $7,000
M4 Providers & compat (wks 7–9) Adapters: Quicksync & Polkachu + schema sniffer; sg compat; red-team demo (corrupted chunk → RED). $6,000
M5 Evidence & upstream (wks 9–10) 4 public transcripts (Hub + 3 consumers) GREEN; 2 docs PRs (Hub + consumer); GitHub Action; Homebrew/Nix; 10-min screencast. $5,000
M6 Maintenance 12 months Monthly smoke tests (Hub + consumer), provider schema probes, patch bumps & issue triage; org-graduation plan. $4,000

6) KPIs:

  • Trust model: GREEN requires light client verification or metadata proof on ≥3 chains that support it; otherwise YELLOW with 3-of-N witnesses.

  • Evidence: 4 public transcripts + 1 red-team demo (corrupted chunk flagged RED pre-restore).

  • Adoption: 2 docs PRs opened (Hub + consumer) + ≥3 Action installs (warning-only) or maintainers’ public ACK.

  • Performance: sg plan + sg verify < 60s; sg dryrun < 15 min on demo snapshots (documented).

  • Compat: sg compat flags ≥2 known-bad pruning/indexer combos in the demo matrix.

7) Maintenance & ownership

  • 12-month maintenance: monthly smoke tests on Hub + one consumer; provider schema probes; minor patches; issue triage.

  • Long-term Stewardship: We intend to transition SnapGuard to a community-governed home (such as the cosmos org) after 12 months, subject to maintainer interest, or continue under our org with named co-maintainer.

8) Governance fit (Cosmos Hub / Atom Economic Zone)

  • Direct AEZ reliability ROI: safer, faster bootstrap across provider/consumer chains; less downtime during halts/upgrades.

  • Small spend, wide impact: chain-agnostic, immediate utility across SDK chains.

  • Upstream-friendly: ready docs PRs + a GitHub Action so projects can enable in warning-only mode on day one.

9) Risks & mitigations

  • “Not trustless everywhere.” → GREEN requires light client verification or metadata proof; otherwise YELLOW with 3-of-N witnesses and explicit caution text.

  • Provider heterogeneity. → adapters + schema sniffer + monthly CI probes to catch layout drift early.

  • Edge-case restores. → sg compat surfaces pruning/indexer pitfalls; RED on known-bad pairs; never silent failure.

10) Differentiation:

  • Quicksync / Polkachu → snapshot providers; SnapGuard verifies/pre-flights any source.
  • CometBFT state sync → protocol checks after restore; SnapGuard fail-fasts before restore.
  • Chain-registry → metadata source; SnapGuard consumes it to plan trust/config.

Team:

Dapps over Apps is a collective advancing Web3 through developer tooling and education. We create tools that enhance the developer experience and lead initiatives that onboard new builders into blockchain ecosystems.

Some of our notable contributions include:

Abdulkareem Oyeneye – Project Lead
Experienced developer tool engineer and project manager with a strong background in Web3 growth and technical product execution. He has led multiple ecosystem tooling initiatives and is skilled at identifying developer pain points and protocol infrastructure needs.https://www.linkedin.com/in/abdulkareem-oyeneye-82a6aa277

Gospel Ifeadi – Smart Contract Engineer
Proficient in Rust, C++, JavaScript, and Python, Gospel has worked on multiple dApps and developer tooling projects. He brings deep experience in backend development, smart contract automation, and R&D.https://x.com/gospel70800

Emmanuel Charles – Blockchain Developer & QA Engineer
Experienced in Rust, TypeScript, and C++, Emmanuel brings a dual focus on smart contract development and quality assurance for blockchain systems.https://www.linkedin.com/in/emmanuel-charles-0b0023250

Musa Abdulkareem – ZK Engineer
Focused on building robust blockchain toolkits and applications, Musa contributes core engineering support for protocol-level integrations.https://www.linkedin.com/in/wisemrmusa

Bolaji Ahmad – Full Stack Engineer
Bolaji has worked on foundational tooling within the Polkadot ecosystem and contributes full stack and infrastructure expertise across multiple blockchain frameworks.https://linkedin.com/in/bolajahmad

2

Hi community, we are tagging @Govmos, @Life_and_Crypto, @Salim, @Harry_Hal @Teslagrinder, @calabi.yau, and everyone for visibility on this proposal.

Thank you for your time and attention.