GIP-126: Should the GnosisDAO Renew its Long-Term Partnership With Nethermind for Gnosis Chain Maintenance?

Governance GIPs
8

Nethermind × GnosisDAO: Year 1 Grant Update

Reporting period: June 2025 – May 2026

This update reports progress against the commitments made in GIP-126, which renewed GnosisDAO’s long-term partnership with Nethermind for Gnosis Chain maintenance in June 2025.

Alongside the Balancer recovery fork and the Fusaka rollout, the bulk of our sustained effort went into the execution client itself: performance, reliability, and storage. RPC reliability has been the headline focus this year and remains our top priority going forward.

Summary

  • Client improvements across the year’s releases: RPC reliability and standardisation, transaction-processing and pruning performance, Flat DB, history pruning, EraE, and Nethermind UI.

  • Balancer recovery fork delivered as a custom Gnosis-specific release, activated December 2025.

  • Fusaka shipped and activated on Gnosis mainnet in April 2026, with shadow-fork and devnet infrastructure throughout the test cycle.

  • Amsterdam (Glamsterdam) implementation underway.

  • Testing knowledge from QA and DevOps shared with the Gnosis testing team to collaborate in this area going forward.

Client improvements

This is where the majority of the year’s engineering went, and where the partnership delivers its day-to-day value to Gnosis operators.

RPC reliability & standardisation

Our two headline goals here are reliability and standardisation, ensuring Nethermind’s RPC responses match the de-facto reference implementation so dApps, indexers, and infrastructure on Gnosis behave identically regardless of client.

  • Reliability fixes addressing edge cases in subscription handling, healthchecks, and archive-node block validation under heavy load. These are the failure modes most likely to hit operators in production.

  • Standardisation. Aligning response shapes, error codes, and edge-case semantics across the eth, trace, and debug namespaces with the reference implementation, reducing client-specific surprises for Gnosis tooling and providers.

RPC remains the top priority for Year 2: continued reliability and standardisation, plus request throughput, latency under load, and eth_getLogs/filter performance. These are the most common sources of operator pain on busy endpoints.

State, storage & sync

  • Flat DB. New storage backend holding state as flat account/storage records instead of walking the Merkle-Patricia trie. Opt-in while we gather operator data.

  • History pruning. Configurable, reducing storage requirements for non-archive operators.

  • EraE. Support for the EraE archival format, extending Era1 tooling to post-Merge execution-layer history and enabling lighter sync-and-restore.

Performance & maintenance

Steady gains in transaction processing, pruning, sync speed, and memory footprint, keeping Nethermind lean and dependable for Gnosis operators across the full range of hardware.

Network & protocol work

  • Balancer recovery fork. Contributed to the November 2025 soft fork that froze the attacker’s accounts, then shipped a custom Gnosis fork that rewrote the affected token contract to move frozen balances to the DAO recovery address.

  • Fusaka. Full feature set implemented and activated on mainnet April 2026 with no client incidents.

  • Amsterdam (Glamsterdam). Implementation in progress, tracking Ethereum mainnet timelines.

  • Testing. Continued EEST and Hive development through the Fusaka cycle, with QA and DevOps knowledge shared with the Gnosis testing team to collaborate in this area going forward. Nethermind continues to operate the public Hive instance with daily cross-client runs.

Scope of Work: Year 2

Year 2 organises around three themes:

  1. Client hardening. Keep Nethermind a reliable, efficient client through Amsterdam/Gloas and the forks that follow, with continued investment in testing and operational resilience.

  2. Scaling execution and storage. Improve execution throughput, state read/write handling, and database efficiency; stabilise Flat DB and history pruning toward default-on configurations; continue work on pruning, archive access, and state/history management.

  3. Data access, indexing, and trustless RPC. Continue RPC reliability and standardisation work, targeting response-format parity with the reference implementation alongside throughput and eth_getLogs/filter performance. Strengthen indexing and low-latency canonical state access for the workloads Gnosis tooling and providers depend on. Extend verifiable responses for selected state, receipt, log, and history queries.

4 Likes