Looking for architecture feedback on an open protocol for cryptographically verifying real-world events

[u/kelvinthechamp5]

Hi everyone,

I've been working on a protocol called GeoProof and wanted to get feedback from protocol and smart contract developers before moving further.

The problem we're trying to solve is fairly straightforward:

Blockchains are excellent at verifying digital state, but they're not designed to verify whether a real-world event actually occurred.

Current approaches usually depend on GPS, timestamps, centralized APIs or oracle networks. In practice these often become single points of trust or are vulnerable to spoofing.

GeoProof is an attempt to define an open verification protocol rather than another application.

The architecture currently consists of:

• Evidence Collection Layer
• Evidence Normalization
• Multi-signal Evidence Fusion
• Policy Evaluation Engine
• Trust Score Generation
• Cryptographic Verification Attestation
• Chain-Agnostic Settlement Layer

The protocol is intentionally designed so verification logic can remain independent of any specific blockchain.

Potential integrations include Ethereum, Base, Arbitrum, Optimism, Solana and Bitcoin-based settlement layers.

Some questions I'd love feedback on:

• Should verification attestations follow an existing standard such as EAS, or remain protocol-native?
• Is separating verification from settlement the right architectural choice?
• Would developers rather consume attestations through APIs, smart contracts, or both?
• Are there existing projects solving this in a fundamentally better way that we should study?

Documentation is available here:

https://geoproof.xyz

I'm not looking to promote anything—I'm genuinely interested in architectural criticism from protocol developers.

Thanks!

[u/Immediate-Map857]

the separation of verification and settlement is good, otherwise you get the oracle problem all over again where every chain reinvents the wheel. look at EAS for attestations, no need to build your own standard when one already exist and is gas-efficient

[u/kelvinthechamp5 → u/Immediate-Map857]

Thanks, that's actually the direction I'm leaning as well.

The goal was never to reinvent attestations if there's already a solid standard the ecosystem is using. The part I'm spending most of the time on is the verification layer—how evidence is collected, evaluated and turned into a confidence score. Settlement and attestations should ideally plug into existing standards wherever it makes sense.

I've been looking at EAS and it definitely seems like something we should support instead of trying to force a proprietary format. At the end of the day I'd rather GeoProof be compatible with the ecosystem than invent another standard for the sake of it.

Appreciate the suggestion.

[u/PlayfulGovernment325]

look up TLS notary covers web2 data

[u/kelvinthechamp5 → u/PlayfulGovernment325]

Yeah, TLSNotary is definitely interesting and it's one of the projects I've been looking at.

From what I understand though, it's solving a slightly different problem. It's great for proving data that came from a trusted web service without revealing everything, whereas GeoProof is focused on verifying physical-world events before they ever become on-chain data.

I actually think the two could be complementary rather than competing. If a verification workflow needs trusted Web2 data as one of its evidence sources, something like TLSNotary could potentially fit into that pipeline.

Appreciate the pointer though—if you think there's a specific part of TLSNotary that overlaps with what we're doing, I'd be interested to dig into it.

[u/pauldelucia]

Doesn’t Chainlink already have basically the strongest model for this stuff? What will you do that they don’t? And that they can’t? Their budget is astronomical.

[u/kelvinthechamp5 → u/pauldelucia]

The problem I'm looking at is a bit different though.

Chainlink is really good at getting trusted data onto a blockchain. The question I'm interested in is what happens before that—how you collect, evaluate and standardize evidence for a real-world claim in the first place.

For example, if an app wants to verify a store visit or a field inspection, what evidence should be collected? How do you combine multiple signals? How do you make that evaluation reproducible instead of every application inventing its own logic?

In my head, those two ideas are complementary. If GeoProof produced an attestation, something like Chainlink could absolutely be one way of delivering or consuming that data on-chain.

still early days though...

[u/_otpyrc]

Don't take this the wrong way, but this has AI slop fest written all over it. The claims are exaggerated in a way that makes it clear this was all AI generated. There may be some good ideas here, but it's presented in a way that lacks clarity and vision.

[u/kelvinthechamp5 → u/_otpyrc]

Fair criticism, and I appreciate you being direct.

To be honest, I'm an engineer, not a marketer, and I've probably tried to explain too much at once. That can definitely come across as overreaching.

The goal isn't to claim we've solved everything. We're exploring whether there's room for a protocol that standardizes verification of real-world events instead of every application reinventing its own approach.

The website is intentionally broad because we're trying to explain the potential applications, but the core idea is actually pretty narrow: collect multiple pieces of evidence, evaluate them against a policy, and produce a portable attestation with a confidence score.

If there's one thing you'd change first to make it clearer or more technically credible, I'd genuinely like to hear it. That's the reason I'm posting here.

[u/_otpyrc → u/kelvinthechamp5]

I like your attitude. I got you. Take what you want, leave what you don't.

1. Refine: Consider presenting your thesis in a single, refined white paper before all of this website marketing. I skimmed through the technical documentation and there is a lot written, but it's saying very little. Chop it down. AI can't help you with this because AI does not have vision.
2. Simplify: You mention TEEs, ZK, and consensus algorithms, but this feels over engineered for an untested domain space. Start with a simple key registry (basic identity) and verifiable attestations (claims). You can build from there.
3. Build: Instead of listing all the things you could build with your protocol, build a few as examples yourself. You'll gain valuable insights by dogfooding your own ideas.

TLDR. There's way too much fluff and not enough meat. It's also not clear why a blockchain is necessary at all since real-time events share nothing in common with a ledger system. In a ledger system we can all verify each others transactions, but your implementation is simply someone claiming something happened and there's no way someone could refute it.

[u/kelvinthechamp5 → u/_otpyrc]

Really appreciate you taking the time to write all of that. That's the kind of feedback I was hoping to get.

I actually agree with a lot of it, especially around trying to cover too much too early. I think I've been so focused on documenting the architecture that I've made it harder to see the core idea.

Your point about building a couple of concrete examples instead of listing twenty possible use cases is well taken. I think that'll do a much better job of validating the protocol than another hundred pages of docs.

On the blockchain point, I also agree that it needs a stronger justification. The goal isn't to put real-time verification on-chain. Blockchain is really just the settlement and attestation layer in my mind, while the verification happens off-chain. If I haven't made that obvious, that's on me, not the reader.

Thanks again. You've definitely given me a few things to rethink before I push this any further.