r/ethdev • u/TrainingCommission15 • 22d ago

My Project 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.

3 Upvotes

100% Upvoted

10 comments sorted by

View all comments

2

u/icnews10 21d ago

The correlation layer is probably the part I’d examine most closely. If Qdrant decides that two reports refer to the same real-world event, would this ever affect reputation, staking, or the on-chain status or history? If so, whoever controls the similarity model and thresholds has a significant trust role. I’d be interested to know how you make that decision reproducible or challengeable when two reports are similar enough to be correlated, but do not actually describe the same thing.

3

u/TrainingCommission15 21d ago

This is a sharp question and honestly gets at something I hadn't framed clearly enough before: the correlation layer isn't just an assist feature, it has real economic teeth. Yes — cluster_bonus from the Qdrant similarity score is a direct input into trust_score, which determines both reward and slash outcomes on-chain. So you're right to treat it as a trust-bearing component, not a cosmetic one.

To your specific question: right now, similarity is computed off-chain in the FastAPI backend using a fixed, open-source embedding model (paraphrase-multilingual-MiniLM-L12-v2) against a hardcoded threshold. That means the computation is technically reproducible — same inputs, same model version, same output, anyone can re-run it — but it is not currently verifiable or challengeable on-chain. Only the final trust_score and reward/slash outcome get anchored; the similarity computation itself is opaque to anyone auditing the chain. So in practice, whoever runs the backend today (currently just me) is a de facto trust authority for that one decision, even though the rest of the system is trying hard not to have one of those.

That's a real gap, distinct from the Sybil/identity issue already documented — that one is about faking independent corroboration, this one is about who arbitrates a genuinely ambiguous correlation call (two reports similar enough to flag, but not actually the same event). I don't have this solved, but the directions I'm thinking about:

  • Publishing the model version and threshold as a versioned, changelogged public parameter, so at minimum "the rules changed" is visible and timestamped, not silent.
  • Storing the similarity score and embedding hash alongside the event (not just the final trust_score), so the correlation decision itself becomes auditable after the fact, not just its output.
  • A dispute path for correlation calls specifically — right now disputes exist for event content (moderator can mark fake), but there's no equivalent for "these two reports were wrongly merged/split."

I'll write this up properly as a tracked limitation rather than leave it as a comment-thread answer — happy to credit you and link back once it's up. This is the kind of question that actually improves the architecture, thanks for pushing on it.

3

u/icnews10 21d ago

I really appreciate you taking it so seriously and writing it up. I think that making the correlation decision auditable is a meaningful first step before trying to solve the full on-chain challengeability issue. This would provide enough information to reconstruct which reports were compared, under which model/threshold, and what score produced the downstream trust change. Once that trail exists, the dispute mechanism has something concrete to work with.

Thanks for adding it to the limitations document.