Intro
I’ve been thinking about GeoTAG, especially after my article on Africa on the MEV Map. The idea is pretty neat: validators can say, “Hey, I’m in Africa,” without revealing their exact city or coordinates. The challenge, of course, is making sure these claims are actually true, without exposing anyone’s precise location.
GeoTAG works together with Hirami to collect MEV data, linking regional validator information to MEV analysis while maintaining privacy.
While there are many possible privacy techniques so as to not leak validator data, my focus is on three that are most relevant to GeoTAG’s evolution: the original design based on pure zero-knowledge proofs, hybrid approaches that combine ZK with TEEs for stronger authenticity, and the current short-term direction of using TEEs, which are already supported and trusted within the Flashbots ecosystem.
- Hardware enclaves (TEEs, like Intel SGX) → trust the hardware to verify location data without leaking it.
- Hybrid approaches (TEE + ZK, etc.) → combine hardware attestation and ZK proofs for stronger security.
- Pure ZK proofs → the method GeoTAG currently uses; validators prove they’re in the region without revealing coordinates.
Each approach has its own trade-offs. Following Sir Vivek’s of Kernel suggestion to explore this and identify the most effective technique.
Let’s dive in…
Trusted Execution Environments (TEEs)
Trusted Execution Environments (TEEs), such as Intel SGX, AMD SEV, and ARM TrustZone, are hardware-isolated enclaves that protect computation from the rest of the system. Code and data inside a TEE remain confidential and tamper-resistant, even in the presence of a compromised host operating system. This provides strong guarantees around integrity, confidentiality, and correct execution.
TEEs are particularly relevant for GeoTAG because they allow validators to securely handle sensitive inputs such as hardware-derived location signals, network latency measurements, or system environment properties without exposing raw data publicly. This fits squarely with GeoTAG’s goal of enabling validators to prove regional presence without revealing precise location details. Using remote attestation, a TEE can produce cryptographically signed statements confirming that approved code ran correctly and processed valid environment inputs.
In a high-level GeoTAG flow, a validator runs a GeoTAG module inside a TEE. The module collects trusted location-related signals such as GPS readings, latency measurements to known reference points, or clock offsets. The TEE then generates a signed attestation asserting that the validator operates within a specific region without disclosing exact coordinates. This attestation is submitted to an on-chain smart contract, which verifies it using the TEE’s cryptographic keys, ensuring both authenticity and integrity.
This approach offers several advantages. Exact coordinates remain private, with only regional membership revealed. The attestation guarantees that the validator executed approved code and relied on genuine environment data. On-chain verification also creates a public, tamper-resistant record of regional commitments.
That said, TEEs introduce meaningful complexity. Running validator or Ethereum-related logic inside an enclave can be resource-intensive, and securely supplying real-time environment inputs such as GPS or network signals to the enclave requires careful design. Side-channel attacks and firmware vulnerabilities remain known risks, though when properly managed, they do not undermine the core privacy guarantees.
Overall, while TEEs do not directly prove geographic location on their own, they can serve as a strong foundation for GeoTAG when combined with trusted environment inputs. In this role, they offer a practical, privacy-preserving, and verifiable mechanism for validators to commit to operating within a given region.
Hybrid Approaches (TEE + ZK)
Hybrid approaches combine Trusted Execution Environments (TEEs) with zero-knowledge proofs (ZK) to balance credibility and privacy. In this setup, TEEs are used to securely collect and authenticate sensitive inputs such as location signals, while ZK proofs ensure that only a minimal claim, like regional membership, is revealed.
This works well for GeoTAG because it fixes the weaknesses of using either technique alone. TEEs can attest that trusted code ran and gathered real environment data, but they do not naturally limit information disclosure. Pure ZK proofs preserve privacy, but they struggle to guarantee that the private input is truthful. A hybrid approach combines both strengths: the TEE vouches for the authenticity of the input, and the ZK proof restricts what is revealed. This fits closely with Flashbots’ philosophy of pragmatic trust minimization.
At a high level, a validator runs a GeoTAG module inside a TEE, which collects and signs location-related signals. A ZK circuit then proves that this signed input lies within a predefined region, such as Africa, without revealing exact coordinates. The validator submits both the enclave attestation and the ZK proof on-chain, where the contract verifies authenticity and regional membership together.
The result is strong privacy, higher credibility than pure ZK, and good composability with Flashbots’ existing TEE-based infrastructure. The main tradeoff is complexity. Hybrid systems are costly to build and maintain and introduce additional performance overhead. As a result, they are better suited as a long-term, high-assurance direction for GeoTAG rather than a minimal first implementation.
Which Fits GeoTAG Best?
Which approach fits GeoTAG best is still very much an open question. Initially, the proposal was to use zero-knowledge proofs as the core mechanism for GeoTAG. ZK aligns cleanly with GeoTAG’s vision: validators can prove that their private location lies within a given region without revealing any coordinates, and the approach fits well with Ethereum’s on-chain constraints. For these reasons, ZK was the natural first choice.
However, after careful discussions and iterations, especially through interactions with Sir Vivek of Kernel, we decided to pivot, at least in the short term. While ZK remains a strong long-term direction, the surrounding questions of input authenticity and real-world deployability are still being actively explored. In contrast, TEEs offer a more immediately practical foundation. They are increasingly becoming an industry standard for trusted execution, are already used extensively within the Flashbots ecosystem, and allow us to experiment with verifiable claims grounded in real execution environments today.
As a result, the current direction is to use TEEs as the initial building block for GeoTAG, while continuing to explore ZK and hybrid TEE plus ZK approaches in parallel. This keeps the system deployable in the near term, while leaving room to evolve toward a more robust and privacy-maximal design as the research matures.
Open to Feedback
This work is very much a starting point, not a finished position. GeoTAG touches a wide surface area, spanning cryptography, trusted hardware, validator incentives, and real-world deployability, and it is not something that should be designed in isolation. I am intentionally keeping this exploration open-ended and would really value feedback from the broader MEV and Flashbots community, especially from people who have worked directly on TEEs, zero-knowledge systems, or validator infrastructure.
A major goal here is to stress-test the assumptions, threat models, and design trade-offs with specialists who have seen these systems fail or succeed in production. Questions around input authenticity, hardware trust, regional definitions, and incentive alignment all benefit from collective scrutiny, and community discussion is likely to surface edge cases that are easy to miss in a single-author analysis.
I also see this work as something that could evolve into a real, production-grade research project. GeoTAG has clear potential if geographic decentralization becomes a first-class metric with economic or policy implications, and I am interested in developing this further through deeper collaboration, prototyping, and formal analysis. In that direction, I plan to pursue research support and grants, including applying for the Flashbots Research Grant, to dedicate focused time and resources toward refining the design, validating assumptions, and exploring implementations.
Overall, this is an open invitation to critique, collaborate, and iterate. If you have thoughts, objections, alternative approaches, or relevant prior work, I would love to hear them. The goal is not to defend a fixed design, but to move toward the strongest possible version of GeoTAG through open research and shared insight.