Hey Wisdom — this is really strong work. The geographic blindness in Ethereum’s validator set is a real problem, and Hirami + GeoTAG tackle it from a practical angle.
On prior work: There is some interesting history here worth exploring. Lido’s Borderless Ethereum initiative tried something similar — getting validators to self-report location via graffiti tags in beacon blocks. The discussion thread there surfaced questions about what “validator location” means when components can be distributed, how to handle privacy concerns, and whether self-attestation is sufficient. Your ZK-based approach seems like a natural evolution. It would be worth digging into what worked and what friction points emerged from that effort. (I haven’t spoken to anyone at Lido with direct knowledge, it’d be very useful to learn from that effort and how it might be improved.)
There is also recent work on ZK circuits for location verification from some collaborators of ours at zkmaps. They built circuits implementing point-in-polygon algorithms that could be relevant to GeoTAG’s verification layer, and there’s been some more recent work on the project since development paused. It may not be relevant (in-country verification might use a different technique), but it’s worth mentioning.
On verification approaches: This connects to work we are doing on composable location verification. The purpose of this work is to raise the cost of falsifying location claims, so we can make more credible decisions about where things are happening, and potentially tie incentives to that information. The core insight is that combining multiple independent sources of evidence raises the cost of forgery more than any independent proof-of-location technique. No single source gives you certainty, but stacking several independent ones makes spoofing more and more expensive. For GeoTAG, this might mean designing it with an optional verification layer where validators can provide corroborating evidence beyond self-attestation.
On what is being verified: The definitional question feels important here. When we say a validator is “in Africa,” what do we actually mean? Where the validator node hardware is running? (The likely answer.) It also might be where the legal entity that owns the private keys is based? Where the infrastructure operator is incorporated? These can all diverge. A validator might be African in ownership but route through European relays for latency.
These measurement questions are exactly what we have been exploring at GEOBEAT.xyz. We are building a geographic decentralization index that treats physical distribution, jurisdictional diversity, and infrastructure heterogeneity as distinct dimensions rather than collapsing them into a single metric. The index is live now if you want to take a look.
For GEOBEAT we forked Armiarma crawlers to map physical node distribution at the network layer. Hirami’s focus on MEV activity and validator behavior is complementary - it operates at the application layer. Combining these approaches could help quantify how geographic location affects MEV capture, which would make the structural disadvantages you are documenting more measurable. (We think there are a lot more data sources to integrate into a more robust index measuring geographic decentralization, but we had to start somewhere …)
The measurement work there pairs naturally with the verification framework we have been developing — one quantifies what geographic decentralization looks like, the other provides tools to verify the location claims that make measurement possible.
Building measurement infrastructure for Africa’s participation in Ethereum’s MEV ecosystem is essential groundwork. You are creating visibility where there was none. Would be interested in exploring how GeoTAG’s on-chain commitments could integrate with multi-signal verification as you develop the FRP.