TECHNICAL NOTES

How GemGunner works

← Back to demo

In brief

GemGunner groups recently deployed Ethereum contracts into projects and surfaces unusual ABI functions and events. This frozen demo stores historical observations; it is not a security audit or safety guarantee.

Data flow

The frozen pipeline is deployment rows → per-deployer projects → cached ABI enrichment → signature scoring → manifest/index/detail JSON. The browser reads only those immutable JSON files; it does not call Dune, Elastic, Etherscan or Sourcify.

Grouping

Deployment rows are partitioned by deployer, ordered chronologically, and joined into one project while successive deployments are less than six hours apart. The demo records chain, deployer, block, timestamp, transaction hash and transaction count when available. The release contains 93,333 deployment rows grouped into 32,177 projects.

ABI rarity

For each verified ABI, functions and events are normalized to canonical signatures (including nested tuple types). A finding receives 1 / (contracts with that signature deployed at or before this block + 1); the contract score is the sum of its function and event scores. The frozen release has 20 ABI observations across 93,333 deployments, and 534 stored function findings. This is a limited observed ABI corpus, not a complete verification set. Sourcify verification timestamps are post-cutoff observations, not historical proof. Missing ABI/source remains unknown and is shown as unavailable. A rarity score is an analysis signal, never an audit or safety judgment.

Frozen provenance

The requested cutoff is 2026-09-16T00:00:00Z, with snapshot ID ethereum-eoa-60d-20260915. Extraction caches retain the SQL hash, execution ID, cache hash, snapshot ID, source list and observation times. The browser release includes per-file hashes; post-cutoff source retrieval is labelled rather than presented as cutoff evidence.

Engineering limits