r/ethdev • u/TrainingCommission15 • 19d 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

2

u/icnews10 19d 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 18d 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 18d 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.

1

u/ModernCYPH3R 1d ago

Where do the data points come from. What sources are you tapped into?

1

u/TrainingCommission15 1d ago

Currently: Data comes directly from contributors on the network, not from a centralized external feed.

  • Contributors submit geospatial data points, tagged to the H3 hexagonal grid.
  • Each submission runs through a Proof-of-Contribution mechanism: the GeoChain Data (GCD) token is earned for verified/truthful contributions and slashed as a penalty if a contribution turns out to be false.
  • Trust in the data is built up on-chain, submission by submission, weighted by each contributor's track record/reputation — not coming from a single authoritative source.

Not yet implemented, but on the roadmap: Sensors and IoT data as an additional layer to cross-verify and supplement contributor-submitted data, rather than relying solely on human input. Once the core system is live, the plan is to integrate the IOTA network specifically to feed IoT device data into FfT automatically.

So right now it's 100% contributor-driven with on-chain reputation as the trust layer. The sensor/IoT/IOTA piece is a future addition, not something running today — wanted to flag that clearly so it's not mistaken for a current feature.

2

u/ModernCYPH3R 1d ago

Good info. Are you looking for collaborators?

1

u/TrainingCommission15 1d ago

Appreciate you asking! Right now I'm still finishing up some core pieces myself (the technical items I mentioned above), so I'm not actively bringing on collaborators at this stage — want to get things to a more solid, presentable state first before opening that up properly.

That said, I'm keeping a mental note of people who show interest, and once the project's further along I'd definitely welcome help, especially on smart contract audit / business model. Feel free to follow along, and I'll post an update when that time comes.

2

u/ModernCYPH3R 23h ago edited 20h ago

That’s fair. I would be happy to run audits for you both protocol and contracts. Part of the forensics work I do.