The Problem
Temporary traffic cameras are a mess. Mobile speed cameras, construction zone cameras, temporary enforcement units — they appear, disappear, and nobody has reliable real-time data on where they are.
Waze tries. It's volunteer reporting, noisy, easily gamed, and owned by Google. OSM has highway=speed_camera tags but no verification layer and no incentive for accuracy. Governments obviously don't publish this data (that's the point).
The core issue is information aggregation: hundreds of drivers pass a camera every day, but that knowledge stays trapped in their heads. No single authority has it. No market exists to surface it.
The Idea
A staking-based reporting system for temporary traffic cameras, built on Nostr and ecash.
Not a prediction market (liquidity problems, legal complexity). Something simpler: reporters put skin in the game, bad reporters lose their stake, good reporters earn rewards.
Think of it as a decentralized oracle for traffic enforcement data.
Architecture
Reporter → Nostr event (camera sighting) + ecash stake ↓ Nostr relay network (geohash-filtered propagation) ↓ Confirmers / Challengers → counter-events with their own stakes ↓ Resolution → ecash payout to correct reporters ↓ Consumers → subscribe to relay, pay ecash for real-time feed
Nostr Layer
Custom event kinds:
30100— parameterized replaceable camera report (geohash, coords, camera type, expiry timestamp, stake commitment hash)10100— ephemeral sighting (quick "I see one right now" without stake, lower confidence)10101— challenge event (references original event ID, stakes against it)10102— confirmation event (references original, adds stake in support)
Geographic filtering via geohash-encoded relay subscriptions. A driver on a route subscribes to relevant geohash prefixes and gets only camera events along their path.
Nostr npubs give reporters persistent reputation without KYC. Disposable npubs for privacy-sensitive jurisdictions. NIP-05 for optional reputation anchoring.
Dashcam evidence attached via NIP-94 or IPFS/blossom references.
Ecash Staking Layer
Cashu ecash for private value transfer. Three approaches I'm considering:
Option A: Burn-and-Reward
- Reporter burns ecash tokens to a null key when creating their Nostr event
- Burn proof included in the event (spent token nullifiers visible)
- If report confirmed correct by expiry, reporter receives stake back plus reward from protocol pool
- If challenged and proven false, reporter loses stake (already burned)
- Reward pool funded by consumer subscriptions and token issuance
Option B: Trusted Mint as Escrow
- Purpose-built Cashu mint or Fedimint federation with custom logic
- Reporter sends tokens to internal "staking wallet"
- Mint locks funds until resolution, issues new tokens to winners
- Cleaner UX but mint operator is trusted party
Option C: Lightning Hold Invoice Hybrid
- Ecash on the user-facing side for privacy
- Staking side converts to Lightning hold invoices (HTLCs that lock without settling)
- Hold invoices resolve when oracle signs outcome
- Winner receives settled Lightning payment, converts back to ecash
- No trusted mint needed but more moving parts
Currently leaning toward Option A for MVP. Most aligned with Nostr's trustless philosophy. Can layer Option C later for larger stakes.
Resolution Mechanism
The hardest part. Current thinking:
- Time-based default: Report stands if no challenge within window (48 hours or until camera expiry). Simple but vulnerable to coordinated false reports.
- Stake-weighted consensus: Multiple reporters stake on same location. Majority stake wins. Sybil-resistant if minimum stake or reputation thresholds required.
- Evidence-based: Photo/video in Nostr event. Manual review or jury system where random staked participants vote.
- Dashcam oracle: The holy grail. Frame + GPS + timestamp from dashcam apps = automated verification. Requires dashcam app integration.
Practical hybrid: time-based default for low-value reports, evidence-based for challenged reports, optional dashcam oracle for high-confidence automated verification.
Consumer Side
Nostr client that:
- Subscribes to geohash-filtered relays
- Displays active camera reports with confidence scores (stake-weighted)
- Optionally pays ecash for premium features (real-time push alerts, historical data, route analysis)
Confidence scoring per report based on:
- Total stake supporting it
- Number of independent confirmations
- Reporter reputation (historical accuracy)
- Time since last confirmation
- Whether challenges exist
Why This Combo
Nostr = free decentralized infrastructure. No servers to run. Relays operated by community. Geographic filtering native to subscription model. Censorship-resistant (anyone can run a relay).
Ecash = reporter privacy. Critical in jurisdictions like France where publishing camera locations is criminal. Tokens aren't linked to identity. Disposable npubs per report. Ecash not linked to main wallet.
Staking = data quality. Financial skin in the game separates this from Waze's noisy volunteer reporting. Bad actors lose money. Good reporters build reputation and earn rewards.
No blockchain needed. No smart contracts, no gas fees, no L1/L2 complexity. Nostr + Cashu + Lightning covers everything.
Open Questions
-
Resolution mechanism: Is time-based default good enough for MVP, or do we need evidence-based from day one? How do we prevent coordinated false reporting without making the system too heavy?
-
Ecash staking model: Burn-and-reward is simplest but requires a funded reward pool. Who seeds it? Token issuance? Consumer subscriptions? Is the trusted mint approach (Option B) actually more practical despite the trust tradeoff?
-
Legal exposure: France actively prosecutes camera location publishers. Germany is relatively permissive. Switzerland varies by canton. How much does this matter if the system is fully decentralized and anonymous? Does Nostr + ecash provide enough plausible deniability for relay operators and mint operators?
-
Liquidity / cold start: How do you bootstrap enough reporters and stakes to make the data useful? Is geographic focus (start with one country/region) the right approach?
-
Dashcam integration: Is there an open-source dashcam app that could be extended to automatically emit Nostr events with evidence? This would solve the resolution problem almost entirely.
-
OSM integration: Should this be a separate layer that reads from OSM, or should confirmed reports eventually write back to OSM? The OSM community may resist gambling-adjacent overlays.
-
Relay economics: Who runs geohash-filtered relays long-term? Is there a natural funding mechanism (ecash micropayments for relay access, stake fees, etc.)?
What I Want Feedback On
- Does the burn-and-reward staking model make sense, or am I missing something about how ecash works that makes this impractical?
- Is there an existing Nostr event schema I should align with instead of inventing custom kinds?
- Anyone built dashcam + Nostr integrations before?
- Thoughts on the legal question — does full decentralization actually protect operators, or is that naive?
- Is there a simpler version of this that gets 80% of the value with 20% of the complexity?
Thinking about building this as a side project. No token, no VC, just open-source infrastructure for a real problem. If you're interested in contributing or have feedback, drop a reply.
#nostr #ecash #cashu #bitcoin #decentralization #opensource #traffic #osm