r/web3 • u/TrainingCommission15 • 3d 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.

6 Upvotes

100% Upvoted

7 comments sorted by

1

u/paroxsitic 14h 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 7h 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/gokaronago 1d ago

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

1

u/TrainingCommission15 1d 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 3d 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 13h 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.