Summary
I run an open-source monitor that reads the deployed bytecode and upgrade config of a protocol’s contracts straight from the chain, records a known-good baseline, and alerts the moment an implementation, an admin, or a critical parameter moves. It already covers Gnosis Chain’s bridge and consensus surface. I would like to turn it into a maintained public good for Gnosis, funded retroactively for the work done so far plus a modest ongoing amount to keep it running. This is a Phase-1 discussion to get feedback on scope and budget before drafting a formal GIP.
The problem
The contracts that secure Gnosis are upgradeable: the OmniBridge and AMB mediators (home and foreign) that carry value between Ethereum and Gnosis Chain, and the GBC deposit contract that secures consensus staking. An upgrade to any of those is a high-impact event, and on a less-watched contract a silent or unexpected implementation swap, or an admin change, can go unnoticed. Behavioural monitors watch transactions; they do not continuously prove that each deployed implementation is still the audited one and that its upgrade key has not changed.
What I have already built
An open-source monitor: https://github.com/emilhuseyn/drift-monitor . It reads each contract over public RPC (no API key) and records the bytecode hash, the EIP-1967 / EternalStorageProxy implementation and admin slots, and the owner. A failed read is never compared, so an RPC outage cannot raise a false alert.
It already runs against 9 Gnosis-governed contracts across Ethereum and Gnosis Chain: the OmniBridge foreign and home mediators, the AMB foreign and home bridges, the GBC deposit contract, and bridged assets (WXDAI, GNO, USDC.e). The first sweep surfaced one thing worth a standing watch: the GBC deposit contract and the bridged USDC.e share a single upgrade admin (0x7a48dac6…) - one key over both the consensus deposit contract and a bridged stablecoin. A monitor that proves that key and those implementations have not moved is a direct consensus- and bridge-integrity check.
(The same engine also runs against Lido and Uniswap deployments, so the Gnosis coverage is an application of a working tool, not a prototype.)
What a grant would fund
-
Harden and expand the Gnosis coverage: every governed bridge, consensus and system contract on both chains, with a maintained canonical manifest in the repo.
-
A live alert feed into a channel GnosisDAO chooses (Discord, Telegram, or a public dashboard) that fires on any implementation, admin or critical-parameter change.
-
A short written report of anything the first full sweep surfaces.
-
Keep it running and maintained for the grant period.
Benefit to Gnosis
-
GNO holders and Gnosis Chain users: independent, public proof that the bridge and consensus contracts are still the audited ones and their upgrade keys are unchanged.
-
Validators and bridge users: early warning of any upgrade or config change on the contracts their funds and stake depend on.
-
It is a public good: open-source, free to all, not a product with a fee.
Indicative budget (open to feedback)
Modeled on the GIP-138 node-sentinel precedent, scaled for a first proposal:
-
Retroactive, for the monitor built so far plus the initial Gnosis coverage and sweep: a one-time amount in DAI (I would suggest the 5,000-8,000 DAI range, open to what the community thinks is fair).
-
Ongoing, to run and maintain the live monitor and alert feed: a modest quarterly amount in DAI or GNO.
Paid to a plain recipient address. I am flexible on the split and the numbers; this thread is to find what GnosisDAO considers reasonable before I draft the GIP.
Open source
All work is and stays open-source; the repo is public now.
Conflict of interest
None. I am an independent security researcher with no paid relationship to GnosisDAO or any Gnosis-ecosystem entity.
About me
Independent smart-contract security researcher and backend developer. Confirmed, paid High-severity finding in an Immunefi audit competition, a confirmed finding on ENS, triage-confirmed findings on HackenProof, and several GitHub security advisories. I also do peer-reviewed research on software supply-chain security and provenance. The monitor in the repo is my project.