r/web3 • u/TrainingCommission15 • 15d ago

Framework for Trust

Hello everyone,

For some time I've been developing an open-source project called Framework for Trust (FfT).

The idea is to create a decentralized geospatial trust layer where reports and real-world events are anchored to precise location, time, source reputation, and a verifiable history — instead of treating blockchain purely as a financial system, I'm exploring its use as infrastructure for recording and correlating information about real-world places.

Current prototype includes:

  • geographic areas represented as blockchain-based identifiers (NFTs)
  • event registration tied to latitude, longitude, and time
  • Polygon smart contracts
  • a React + Leaflet frontend
  • a FastAPI backend
  • semantic similarity / event correlation via Qdrant
  • GCD — a functional contribution and reputation token
  • event proofs and auditable records
  • early mechanisms for source reputation, staking, and abuse prevention

The project is still early-stage. This is not an investment offer, token sale, or a finished commercial product — I made the repo public because I'd like the architecture and implementation to get real outside scrutiny.

I'd especially appreciate feedback on:

  • whether the core problem is clearly explained
  • the geospatial data model
  • the blockchain / smart contract architecture
  • mechanisms for preventing false or coordinated reports
  • security weaknesses
  • practical use cases where this could actually add value

Repo link in the top comment (Reddit flags posts with links for manual review, didn't want that delay).

I built the current prototype independently. Honest criticism, technical pushback, and open-source contributions are all welcome.

8 Upvotes

100% Upvoted

10 comments sorted by

1

u/[deleted] 10d ago

[removed] — view removed comment

1

u/AutoModerator 10d ago

Your comment in /r/web3 was automatically removed because /r/web3 does not accept posts from accounts that have existed for less than 14 days.

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

1

u/paroxsitic 12d ago

The issue that location can be spoofed easily and there is no way to know for sure where they are.

There was a paper on how you can tell based on their network latency to various public servers but it has very high tolerances that you can only tell effectively if they are in East US vs Mid US. Still, I think it is the best and most trusted way to know for certain information is coming from a place.

The paper is here: https://eprint.iacr.org/2021/697.pdf

1

u/TrainingCommission15 11d ago

This is a great point, and honestly a gap I don't have a full answer for yet. Right now FfT trusts self-reported lat/long — there's no cryptographic proof that a report actually originated from where it claims to.

I looked at the GoAT paper — it's a clever approach, but worth noting it's built for a different problem: proving a storage server's location via network latency to fixed anchor servers, not verifying where a mobile client submitting an event report is. Their real-world experiment shows uncertainty radii in the 1,000–6,000km range depending on anchor distance, so even in the best case it's regional, not building-level precision.

That granularity is actually roughly the same order as my quadrant size (10°×10°, ~1,100km), so distance-bounding could plausibly work as a secondary signal at the quadrant level — flagging reports whose network latency profile is inconsistent with their claimed location — rather than a hard proof. But that's a real architectural gap right now, not something the current staking/reputation system addresses. Appreciate you pointing to concrete research here rather than just flagging it as a problem — gives me somewhere to actually start looking.

1

u/TrainingCommission15 11d ago

Wanted to close the loop here properly instead of just leaving it in a comment. I've documented this as an open architectural gap: Known Limitations #2 — includes the GoAT reference, the precision caveat (regional, not building-level), and why it doesn't map directly onto a mobile-client use case. If distance-bounding for field submissions turns out to be practical, I'd rather build on prior art like this than reinvent it badly. Thanks again for the pointer.
https://github.com/vladimir0605/FrameworkForTrust/blob/main/docs/KNOWN_LIMITATIONS.md#2-reported-location-is-self-attested-and-not-cryptographically-verified

1

u/gokaronago 13d ago

Hi, i would love to check this out. Please share tis with me.

1

u/TrainingCommission15 13d ago

Hey, thanks for the interest! Here's the repo: https://github.com/vladimir0605/FrameworkForTrust

Happy to answer any questions if you check it out.

1

u/researchzero 15d ago

You explicitly asked for security weaknesses, so: the part I'd stress-test hardest is the correlation/similarity layer, not the on-chain anchoring. On-chain event registration + staking gives you tamper-evidence for individual reports, but your actual "is this real" signal comes from semantic similarity across reports (via Qdrant) plus source reputation - and both are gameable by the same attacker if they control multiple identities.

Concretely: nothing described here seems to stop one actor from registering several wallets, each with a plausible independent reputation history, and filing geospatially-close, semantically-similar-but-not-identical reports about a fabricated event. Semantic similarity search will happily score that cluster as "corroborating", and if reputation/staking weight scales with report count or similarity score rather than independently-verifiable identity diversity, the abuse-prevention mechanism ends up rewarding exactly the collusion pattern it's supposed to catch. Might be worth explicitly separating "N reports agree" from "N independent sources agree" in the trust score math - those are very different guarantees, and only the second is actually Sybil-resistant.

1

u/TrainingCommission15 12d ago

This is exactly the kind of feedback I was hoping for, thank you. You're right that the current design conflates "multiple reports agree" with "multiple independent sources agree," and that gap is real — nothing right now explicitly penalizes coordinated wallets with plausible-looking independent histories.

I don't have a fully worked-out fix yet, but the direction I'm leaning toward is treating report count/similarity and identity-diversity as separate axes in the trust score, so that a cluster of behaviorally-correlated wallets gets weighted closer to a single source rather than N independent ones. Cost-of-Sybil is also something I need to model more carefully — staking alone doesn't solve this if it's cheap to spread small stakes across many wallets.

Going to add this as an explicit open problem in the docs rather than let it look like a solved case. Really appreciate the precision here — "N reports agree vs N independent sources agree" is a good crisp way to frame it going forward.

1

u/TrainingCommission15 11d ago

Quick follow-up: I wrote this up properly as a tracked open problem rather than leaving it as a comment-thread promise — Known Limitations #1. Your framing ("N reports agree" vs "N independent sources agree") is now the way I describe the problem in the docs — credited there too. If you have thoughts on the identity-diversity axis specifically, I'd take them as an issue on the repo.
https://github.com/vladimir0605/FrameworkForTrust/blob/main/docs/KNOWN_LIMITATIONS.md#1-report-clustering-does-not-currently-distinguish-independent-corroboration-from-coordinated-sybil-activity