Transparency Report: How Every Feature Works Under the Hood

Someone recently suggested that EF-Map might be hiding or obscuring specific players' or tribes' activity. This couldn't be further from the truth—and it made me realize we should explain exactly how everything works.

This post is a complete breakdown of every major feature in EF-Map: what runs in your browser (client-side), what data we access, what requires login, and what we collect (spoiler: only anonymous aggregate stats that you can view publicly).

The core philosophy: EF-Map is a privacy-first mapping tool. We don't track users, we don't filter data by player or tribe, and nearly everything runs entirely in your browser. You don't even need to log in for most features.

The TL;DR: What Runs Where

Feature-by-Feature Breakdown

🗺️ Routing (Point-to-Point, Scout Optimizer, Reachability)

What it does: Calculates optimal paths between star systems using A* or Dijkstra algorithms. The Scout Optimizer finds the best order to visit multiple waypoints. Reachability shows which systems you can reach with a given jump range.

How it works:

• 100% client-side – All pathfinding runs in Web Workers inside your browser
• The star system graph (24,000+ systems, stargates, distances) is loaded once when you open the map
• Route calculations never leave your device
• No server calls during calculation

What we track: Anonymous aggregate counters only – "X routes calculated" (not who, not which systems, not when).

Login required: No.

🏗️ Smart Assemblies

What it does: Shows player-built structures on the map with their status, owners, and locations. Structure types include: Network Nodes, Smart Gates, Smart Turrets, Smart Storage Units (SSUs), Smart Hangars, Manufacturers (Printers, Refineries, Shipyards, Assemblers), Portable Structures, and Decorative Structures.

How it works:

• Data comes from public blockchain events – the EVE Frontier blockchain emits events when structures are deployed, modified, or destroyed
• Our PostgreSQL indexer listens to these blockchain events and stores them
• The map fetches snapshots from our API and displays them
• No filtering by owner or tribe – every structure visible on-chain is visible in the tool

What we track: Nothing about which structures you view.

Login required: No.

🚪 Smart Gates

What it does: Shows player-built jump gates and optionally includes them in route calculations.

How it works:

• Smart Gate deployment/linking events come from the public blockchain
• Our indexer captures all gate data – origin system, destination, owner, access settings
• Three routing modes:
  • None: Don't use Smart Gates (no login needed)
  • Unrestricted only: Use public gates anyone can transit (no login needed)
  • Unrestricted + restricted you can use: Includes gates you personally have access to (requires login)

Why login for restricted gates: To check if YOU can transit a restricted gate, we need to know your character ID to query the blockchain access list. Without login, we can only show unrestricted (public) gates.

What we track: Aggregate counter of Smart Gate route calculations (not which gates, not who).

📡 Live Event Tracker

What it does: Shows real-time blockchain events (kills, structure changes, gate activations) as they happen in the universe.

How it works:

• WebSocket connection to our event server
• Server broadcasts all blockchain events as they're indexed – no filtering
• Events are stored in your browser's IndexedDB (not on our servers) for 72-hour history
• No user-specific filtering – everyone receives the same events

Searching your events: When you search in the Live Event Tracker, it queries your local browser database (IndexedDB) – not our servers. This means:

• We don't see your search queries
• We can't filter results by player or tribe (we never see the query)
• If an event isn't in your history, it's either because the blockchain didn't emit it or you weren't connected when it was broadcast

What we track: Connection count only (how many maps are connected, not who).

Login required: No.

💀 Killboard

What it does: Tracks PvP kills across EVE Frontier – who killed whom, where, with what ship.

How it works:

• Kill mail data comes from blockchain events
• Our indexer processes these events into structured kill records
• Data is exported as snapshots that the frontend fetches
• No filtering – all kills visible on-chain are in the killboard

What we track: Nothing about killboard views.

Login required: No.

🔍 SSU Finder (Premium Feature)

What it does: Searches for Smart Storage Units (SSUs) across the universe with advanced filtering.

How it works:

• SSU data comes from blockchain events
• Advanced search runs server-side (queries are complex)
• Subscription-based – requires wallet connection for Stripe payment
• Search results are not filtered by owner/tribe – you see all SSUs matching your criteria

Why subscription: This feature has ongoing infrastructure costs (indexing, storage, API). Subscription helps cover those costs.

What we track: Subscription status only (no search queries logged).

Login required: Yes (for subscription verification).

🖥️ EF-Map Overlay (Desktop Helper)

What it does: Native Windows application that overlays route information on your game client.

How it works:

• Helper runs 100% locally on your PC
• Communicates with the EF-Map web app via local HTTP (127.0.0.1) – data never leaves your machine
• Displays route waypoints, tracks visited systems, and shows your current location
• Your live location and visited systems stay on your device – we never receive this data
• No login required to download or use basic features

Why login is optional: You can use the helper without logging in – follow mode, route overlay, and visit tracking all work without authentication. Login is only required if you want to save bookmarks directly to your Tribe folder, because the app needs to know which tribe folder to write to.

What we track: Helper connection status (aggregate count only – not who, not which systems you visit).

📝 User Overlay (Tribe Folder)

What it does: Encrypted annotations that only you (or your tribe) can see on the map.

How it works:

• Notes are encrypted client-side before storage
• Encryption key derived from your wallet signature
• Server stores ciphertext – we literally cannot read your notes
• Login required to derive encryption key

Why login: Without your wallet signature, we can't decrypt your notes – and that's the point. Only you (or tribe members with shared keys) can see them.

What we track: Nothing about note contents (we can't even see them).

📊 Static Data Tools (Compare Regions, Blueprint Calc, Star Colouring, Module Mission)

What they do: Multiple features use static files extracted from the game client:

• Compare Regions – Compare structural and navigational statistics across EVE Frontier's regions
• Blueprint Calculator – Calculate crafting materials and production chains
• Star Colouring / Planet Counts – Visualize stars by planet count, class, or other metrics
• Module Mission – Checklist of all modules in the game for tracking your collection

How they work:

• Compare Regions uses the smaller universe map database (system positions, gates, regions)
• Star Colouring / Planet Counts uses the solar system database (detailed celestial data)
• Blueprint Calculator and Module Mission use JSON files generated from static game data
• All calculations are performed client-side in your browser
• Same data for everyone – computed from the same static dataset
• Databases and JSONs are downloaded once and cached locally

What we track: Nothing.

Login required: No.

📈 Activity Tracker

What it does: Visualize game, tribe, and player activity over time – structure deployments, state changes, and other on-chain events displayed as time-series charts.

How it works:

• Data comes directly from the blockchain – we read on-chain events from the Primordium indexer
• An aggregation job runs on our server, summarizing events into hourly buckets for fast visualization
• Charts show: structure online/offline state changes, activity by player or tribe, drill-down from Game → Tribe → Player
• No filtering or editorializing – we display exactly what the blockchain contains
• Anyone can verify the source data by querying the same on-chain tables

What we track: Nothing about who views activity data. The activity itself is public blockchain data.

Login required: No.

What We Collect (And What We Don't)

We Collect: Anonymous Aggregate Statistics

As detailed in our Privacy-First Analytics post, we track:

• Feature counters: "Cinematic mode was toggled X times" (total, all users)
• Session buckets: "Y% of sessions lasted 5-15 minutes" (no user identity)
• Time sums: "Users spent Z total hours in cinematic mode" (aggregate)

You can view these stats yourself: Visit the Usage Stats page – it shows the exact same data we see.

We Don't Collect

• ❌ User IDs or wallet addresses (in analytics)
• ❌ Session IDs or browsing paths
• ❌ IP addresses for tracking
• ❌ Which systems you route between
• ❌ What structures you click on
• ❌ Search queries
• ❌ Device fingerprints
• ❌ Your location or visited systems (helper data stays on your device)

Where Does the Data Come From?

This is important: we don't generate player activity data – the blockchain does.

We don't control what the blockchain emits. If an event exists on-chain, our indexer captures it. If it doesn't exist, we don't have it. There's no manual curation or filtering step where we decide "show this, hide that."

Why Client-Side Matters

When we say "client-side," we mean the code runs in your browser, on your device:

• Route calculations: Your browser does the pathfinding. Our servers never see your start/end systems.
• Map rendering: Three.js renders 24,000+ stars locally. No server-side rendering.
• Search: Fuzzy matching runs in-browser against locally-loaded data.
• Settings persistence: Stored in your browser's localStorage, not our database.

The benefit: we literally can't see what you're doing because the computation happens on your machine.

Web Analytics: What We Do Track

In the interest of full transparency: We use industry-standard web analytics to understand how the site is used. Here's exactly what that means:

📊 Google Analytics 4

We use Google Analytics 4 (GA4) to understand aggregate site usage. Here's what GA4 collects by default:

What GA4 does NOT collect (and we don't send):

• ❌ Your wallet address
• ❌ Your character name or ID
• ❌ Which systems you search for or route to
• ❌ Which structures you view
• ❌ Your in-game activities or tribe affiliation

What you'll see in DevTools: Requests to google-analytics.com and googletagmanager.com. These are standard analytics pings, not behavioral tracking.

📈 Our Custom Usage Stats

In addition to GA4, we collect our own aggregate-only usage statistics (visible at /stats):

• What we track: Event type counters ("10,000 routes calculated today") and duration sums ("users spent X hours in cinematic mode")
• What we don't track: Who calculated those routes, which systems, or when
• How it works: Your browser batches events and sends them to /api/usage-event every few seconds

Inspect the payload yourself: In DevTools Network tab, filter for "usage-event" and click the request. The payload looks like:

{"events":[{"type":"route_calculated"},{"type":"cinematic_enter"}]}

No user ID, no system names, no identifying information.

Why We Use Analytics

We use analytics to answer questions like:

• How many people use the Scout Optimizer vs basic routing?
• Is the new Solar System View feature being used?
• What's the typical session length?
• Which countries have the most users?

This helps us prioritize development. We don't use it to track individual behavior or target advertising.

Verify It Yourself: A DevTools Guide

Don't take our word for it. You can verify every claim in this post using your browser's Developer Tools. Here's how to fact-check us:

Opening DevTools

In Chrome, Edge, or Firefox: Press F12 or right-click anywhere and select "Inspect". Then use the tabs described below.

1. Network Tab: See Every Request We Make

Open the Network tab, then use EF-Map normally. You'll see every HTTP request the page makes.

2. WebSocket Tab: Watch Live Events

Filter the Network tab by "WS" (WebSocket). You'll see the connection to our universe events server.

Click on it and view the "Messages" tab. You'll see:

• Incoming events only – The server broadcasts events; your browser doesn't send user-specific data back
• Event content – Each message contains blockchain event data (kills, structure changes) with no user tracking

3. Application Tab: See Your Local Data

Open the Application tab (Chrome/Edge) or Storage tab (Firefox).

4. Helper Traffic: Confirm It's Local-Only

If you use the EF-Map Overlay Helper, filter the Network tab for 127.0.0.1 or localhost.

All helper traffic stays on your machine. You'll see requests to http://127.0.0.1:38765/... – this is your local helper, not an external server. Your current system, visited systems, and follow mode state never leave your PC.

5. What You Won't Find

• ❌ Requests to Facebook, Mixpanel, Amplitude, or other behavioral analytics
• ❌ Your wallet address being transmitted to us (exceptions: SSU Finder subscription check goes to our server; Smart Gate access checks and profile picture/character name lookups go directly to CCP's chain RPC and APIs – not stored by us)
• ❌ Route start/end systems being sent anywhere
• ❌ Your search queries leaving the browser
• ❌ Device fingerprinting scripts
• ❌ Your in-game activities being tracked individually

If you find something that contradicts our claims, please let us know. We're committed to transparency, and we'd rather fix a problem than hide it.

The Transparency Commitment

If you ever notice something that seems inconsistent with these principles, please reach out. We're committed to building a tool the EVE Frontier community can trust.

Summary Table: Login Requirements

Related Posts

• Privacy-First Analytics: Learning Without Tracking – Deep dive into our anonymous stats system
• Web Workers: Background Computation – How route calculations run client-side
• Database Architecture: Blockchain Indexing – How we index on-chain data
• Smart Gate Authorization – How gate access checking works

Questions about how something works? Ask in our Discord. We're happy to explain any aspect of the system in detail.