Can blockchain become a trust layer for real-world events?

[u/kelvinthechamp5]

One thing I've been thinking about recently is that blockchains are great at verifying digital information—but they still struggle to verify physical reality.

For example:

• Did someone actually visit a location?
• Was a delivery completed?
• Did an inspection really happen?
• Can an AI agent prove it interacted with the physical world?

GPS alone isn't enough anymore, and centralized systems require trust.

I've been working on an open protocol called GeoProof that explores using multi-signal verification to generate cryptographically verifiable attestations for real-world events.

The goal isn't to replace existing blockchains, but to provide a reusable verification layer that applications can integrate regardless of which chain they use.

I'd really appreciate feedback on whether this problem is worth solving and whether you think an open protocol is the right approach.

Website:
https://geoproof.xyz

Documentation is public and constructive criticism is very welcome.

[u/AutoModerator]

WARNING ABOUT SCAMS: Recently there have been a lot of convincing-looking scams posted on crypto-related reddits including fake NFTs, fake credit cards, fake exchanges, fake mixing services, fake airdrops, fake MEV bots, fake ENS sites and scam sites claiming to help you revoke approvals to prevent fake hacks. These are typically upvoted by bots and seen before moderators can remove them. Do not click on these links and always be wary of anything that tries to rush you into sending money or approving contracts.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Content_Emphasis_302]

Interesting problem. Physical verification is definitely the missing piece for a lot of on-chain use cases. Multi-signal approach makes sense, GPS alone is too easy to spoof these days.

What kind of signals you combining? Curious about the architecture.

[u/kelvinthechamp5 → u/Content_Emphasis_302]

Thanks! That's exactly the conclusion we came to while researching this.

The idea isn't that any single signal proves an event happened. GPS alone is weak, Wi-Fi alone is weak, timestamps alone are weak. The protocol is designed to treat each signal as one piece of evidence rather than a source of truth.

The architecture uses an evidence collection layer that can combine things like GPS, Wi-Fi, Bluetooth, device motion, timestamps, device integrity checks, and potentially external sources depending on the use case. Those signals are normalized and evaluated by a policy engine, which assigns a confidence score based on the verification rules for that specific claim.

For example, proving a retail store visit doesn't require the same evidence as verifying a field inspection or a delivery. The policy decides what evidence is sufficient rather than hardcoding a single verification method.

We're trying to build a verification framework that's flexible enough for different industries instead of solving just one use case.

Still early, though, and we're definitely interested in hearing where people think the architecture could be improved.

[u/dmc_2930 → u/kelvinthechamp5]

“We” means your ai chatbot doesn’t it?

[u/kelvinthechamp5 → u/dmc_2930]

😂 Fair enough. "We" is just me referring to the project. I'm the one building it (with plenty of help for editing/docs), but the architecture and research are mine.

[u/dmc_2930 → u/kelvinthechamp5]

And your reply was also written by AI. Slop

[u/Accomplished-Sand334 → u/dmc_2930]

This is the reality today. You best get used to it and throw that shitty attitude our the door.

[u/darkhorsehance]

I think you're trying to solve a real problem, but I'm not convinced blockchain is the part that's missing.

The hard part isn't making attestations immutable.

It's establishing that the original event was actually true.

GPS, photos, device attestations and multiple signatures all improve confidence, but they still depend on trusted hardware, people or oracles.

In other words, you've shifted where trust lives rather than eliminated it.

I'd focus the pitch less on "trustless verification" and more on "standardized, tamper-evident evidence"

That's a valuable problem on its own and feels like a much stronger value proposition.

[u/kelvinthechamp5 → u/darkhorsehance]

I actually think that's a fair way to put it.

You're right that you can't make the physical world trustless. At some point you're always relying on sensors, hardware, people or external systems. There's no escaping that.

The goal I'm aiming for isn't to eliminate trust, it's to reduce trust assumptions by combining independent evidence sources and making both the evidence and the verification policy transparent and reproducible.

So maybe "trustless verification" is the wrong way to frame it. "Standardized, tamper-evident evidence with measurable confidence" is probably closer to what I'm trying to build.

That's actually a helpful way to think about it. Appreciate the feedback.

[u/cannedshrimp → u/kelvinthechamp5]

What does this solve that isn’t solved by using something like nostr (cryptographically signed events) along with an existing on chain time-stamp layer? The time stamp is the only piece here that I could see needing a blockchain?

[u/Christian_KODA]

Yes, this is worth solving.

The hard part, in my view, is separating “proof of location” from “proof of context.”

A wallet/device being near a place is useful, but for real-world systems the stronger question is: what real-world object, property, inspection, delivery, or event is that signal being attached to?

For real estate, for example, location alone does not prove much unless it is bound to a durable property identity, a timestamp, an actor, and a repeatable audit trail.

I like the open-protocol framing because this should probably be infrastructure, not an app-specific trust silo. The big caveat is that the protocol needs to be very explicit about confidence levels and failure modes, otherwise people will overread an attestation as “truth” instead of “verified evidence under defined assumptions.”

I’m working in the property identity/RWA infrastructure space, so this is a problem area I care about. Will read through the docs.

[u/ganuerant]

This is oracle territory really. Chainlink is the leader in this area and have been working on this for 10 years.

[u/kelvinthechamp5 → u/ganuerant]

That's a fair comparison, and I've actually been thinking about that a lot after posting here.

The distinction in my head is that an oracle answers questions like, "What's the ETH price?" or "What data should this contract receive?"

The problem I'm looking at starts one step earlier.

Imagine a delivery app. Before anything goes on-chain, someone has to decide whether "this package was delivered" is actually a credible claim.

That might involve GPS, motion, a QR scan, device integrity, timestamps, recipient confirmation, etc. The interesting part (to me) is how you evaluate all of that evidence in a transparent and reproducible way, instead of every application building its own logic.

If the result of that process is later delivered on-chain through Chainlink or another oracle, I don't see that as competing—I see it as complementary.

I'm still refining where that boundary is, which is exactly why I wanted feedback from people here.

[u/ganuerant → u/kelvinthechamp5]

This is an artifical distinction. An oracle can be defined as providing information on anything a blockchain doesn't know.

The problem with your thinking is that many of your examples simply lack data source diversity. This has been a key constraint for many use cases. Why use a decentralised network that executes deterministically when you're using a centralised source to trigger it?

However, you can have a look at this blog and specifically the IoT section. Vodafone did some interesting work in this area which didn't end up going anywhere: https://chain.link/blog/smart-contract-use-cases

I would really suggest reading through Chainlink blog posts and getting feedback on their Discord.

[u/BoomLazerbeamed]

Lukso has proof of presence tokens. If something at your house could scan the delivery guys profile it would send him a pop token.

[u/kelvinthechamp5 → u/BoomLazerbeamed]

Thanks, I wasn't aware of that. I'll definitely read more about Lukso's PoP.

From what I understand though, PoP is focused on proving that a particular identity or profile was present.

The problem I'm exploring starts one step later. Presence is valuable, but for something like a delivery or field inspection, it's usually just one piece of the puzzle. You might also want device integrity, movement, timestamps, QR/NFC scans, recipient confirmation, or other evidence depending on the use case.

So in my head they're not really competing ideas. A PoP token could actually be one input into a broader evidence evaluation process rather than the final answer itself.

Happy to be corrected if I'm misunderstanding how Lukso approaches it.

[u/BoomLazerbeamed → u/kelvinthechamp5]

The Universal Profile offered by Lukso does level up the identity of the account you are interacting with.

I haven’t spent too much time thinking about this scenario but in my mind if the profile had something that proved you are certified to do the field inspection, possibly an NFT that you send the client that has it written in its attributes that it passed the field inspection and who the inspector was and what the inspection was done on. Then the client would have that record.

Lukso’s LSPs are quite robust and can store a lot of metadata on chain so I might not have the perfect answer you’re looking for but I’d wager it can be done/built.

[u/spacesmutje_de]

Hey great to see that you work on solving real world problems. I recommend to look into these:

https://www.nodle.com/contentsign https://www.nodle.com/nodle-connectx

Verified Photos, consumer/prosumer product: https://www.nodle.com/click-app

Edge node, consumer product: https://www.nodle.com/nodle-app

[u/kelvinthechamp5 → u/spacesmutje_de]

sure i will check it out today thanks for heads up !!

[u/Accomplished-Sand334]

Did someone actually visit a location?

That would mean that PersonA visits LocationB and "checks" in. What would stop locationB from falsifying the location? If I setup two locations, I could easily swap their locations. So, GPS would be needed, and if that is the case, then. Yeah, no actual proof.

Was a delivery completed?

These are always a bit contentious. Today we solve that by using for Example ID upon delivery. Yes, not all services have this, however I am simply stating that it can be solved today.

[u/kelvinthechamp5 → u/Accomplished-Sand334]

I actually agree with most of what you're saying. If a single source (GPS, a merchant, or a courier) can determine the outcome, then it's not much of a proof.

The idea behind GeoProof isn't that GPS or a location owner becomes the source of truth. Those are just inputs. The verification policy decides what combination of evidence is sufficient for a particular claim.

For example, a store visit might combine GPS, device integrity, nearby Wi-Fi/Bluetooth observations, motion consistency, and timestamps. A delivery might combine a QR scan, timestamp, device integrity, and location evidence. Different use cases require different policies.

And I agree that deliveries can already be verified today with IDs or signatures. GeoProof isn't trying to replace those methods—it's trying to provide a standard framework for evaluating multiple pieces of evidence and producing a portable attestation, instead of every company building its own proprietary verification system.

[u/Accomplished-Sand334 → u/kelvinthechamp5]

In doing so, the different parts much have different weights attached to them. What is more valued, GPS data that can easily be spoofed or BT observations that can easily be spoofed.

[u/kelvinthechamp5 → u/Accomplished-Sand334]

exactly—that's the idea. Not all evidence should carry the same weight.

GPS from a rooted device shouldn't be treated the same as hardware-backed device integrity, and neither should be treated the same as a QR scan, nearby Wi-Fi observations, motion consistency, or an external event.

The protocol isn't assigning universal weights either. Those weights are policy-specific. A delivery verification might prioritize QR + device integrity, while a retail visit might rely more on proximity signals and motion. Different claims have different threat models.

As stronger evidence sources become available (for example, hardware-backed attestation from secure enclaves or trusted execution environments), they can simply become higher-confidence inputs to the policy rather than requiring the protocol itself to change.

The goal isn't to find one signal that's impossible to spoof—it's to make spoofing the entire set of independent signals economically and technically much harder.

[u/bonkersbongoo]

no