Every promise Dossier makes — tracked, dated, and held publicly. Every miss recorded. Nothing here is ever deleted. If we change course, the original commitment stays; the correction is appended below.
This page exists for the same reason the parent Federation's corrections log exists: the easiest way to build trust is to make it expensive to lie.
Dossier's full pipeline — Helius WebSocket capture, token enrichment, convergence detection, and Telegram alert dispatch — will be operational and serving the beta cohort by May 19, 2026. The detector is already running in production; this commitment is about the public launch to operatives on the waitlist.
The beta launch cohort will surveil 40 curated wallets, expanded from the original 8 used for system validation. Selection methodology: Kolscan daily + weekly leaderboards, filtered for memecoin specialization, 30-day positive PnL, and absence of obvious insider or wash patterns. The full wallet list and selection rationale will be published as a public document before paid tiers activate (see #004).
Paid tiers (Operative at $29/mo, Handler at $99/mo) will be live and accepting payment within 30 days of the May 19 beta launch — target on or before June 18, 2026. The free Operative-Beta tier (6 months free for the first 50 verified operators) remains active regardless. No card collection during the beta intake — all access at the beta tier is genuinely free until conversion windows open.
Before any operator pays for Dossier, the full wallet selection and scoring methodology will be published as a public document at dossiertrack.co/methodology. The document will cover: data sources, candidate filtering criteria, scoring formula, removal triggers, governance process for cohort expansion, and the exact wallet addresses currently being surveilled. This mirrors the Federation's lending-spec pattern — design before code, methodology before payment.
Dossier is the intelligence arm of the Galactic Federation of Finance. Methodology is developed under Admiral Zoran Voss and the Federation research desk. Dossier is an independent product (own pricing, own roadmap, own brand), but every commitment made by Dossier operates under the same transparency principles as the parent — public specs before code, append-only corrections log, no inflated stats, no hidden authorities.
If Dossier ever departs from Federation doctrine, that departure will be logged here as a numbered correction. The relationship is not marketing; it is operational structure.
Dossier exists inside the Galactic Federation. So does its revenue. A staged, public, on-chain percentage of Dossier's net revenue is committed permanently to $GFOF liquidity on Raydium — not to marketing, not to a side wallet, not to anyone's pocket. The percentage scales with Dossier's ability to sustain itself.
Phase 1 · Beta (now through ~Aug 2026). Dossier is free. No revenue, no contribution. Focus is product-market fit.
Phase 2 · Paid launch through first $5K MRR. 25% of net revenue deployed quarterly into $GFOF/SOL liquidity on Raydium. "Net revenue" is defined as gross subscription revenue minus Stripe fees, refunds/chargebacks, and direct infrastructure costs (Railway, Helius API, domain). The math is published every quarter alongside the on-chain transaction.
Phase 3 · $5K MRR sustained for two consecutive quarters. Contribution steps up to 50% of net revenue, same quarterly cadence, same LP-injection mechanism. The "two consecutive quarters" trigger exists so that a single lucky month doesn't lock Dossier into a higher commitment than the business can sustain.
Mechanism. Dossier Stripe payouts → dedicated on-chain treasury wallet → quarterly conversion to $GFOF → addition to Raydium $GFOF/SOL liquidity pool. LP receipt held permanently by the Dossier Treasury — not burned, not withdrawn, not redirected. Every quarterly injection is reported here as an appended note to this entry with the transaction signature.
Dossier Treasury Wallet: G1MLNThNPE8hcZQfNTcjZGEDaSx1otutcNScLazBc92Y
Publicly auditable on Solscan. Stripe payouts swept here at the end of each calendar month. Zero outflows except quarterly LP injections to Raydium and direct infrastructure reimbursement.
Why this commitment exists. Most token projects can't answer the question "where does real revenue go?" because there is no real revenue. Dossier has a real product with real subscribers. Making the answer public, mechanical, and on-chain removes ambiguity. If the Federation ever wants to know whether the intelligence arm is paying its share, the answer is a Solscan link.
Dossier launched on schedule on May 19, 2026 (see #001). Alerts fired correctly for roughly 36 hours after launch. Then a Postgres connection bug in the wallet monitor caused it to crash and restart in a loop. Because the process kept restarting, the service appeared "online" on the Railway dashboard, but it was not actually capturing wallet activity. No new convergences entered the database, and therefore no Telegram alerts fired.
The system was effectively dead from approximately May 19, 11:00 PM CT through May 26, 5:43 PM CT — roughly seven days. During that window, the live ticker on this site continued to scroll older entries, and the 24-hour counter eventually fell to zero. Both were accurate. Neither was investigated quickly enough.
Root cause. The four backend services that talk to Postgres were using a single persistent connection per service, with no automatic reconnect when that connection was dropped. Railway's internal networking closes idle TCP connections after a period of inactivity, which surfaced as ECONNRESET errors that the services were not handling. Each service exited on the unhandled error and was restarted by Railway, only to fail the same way again. The wallet monitor was the visible symptom; the other services were silently vulnerable to the same failure.
Fix. All four services (wallet monitor, main detector, Handler detector, public API) were rewritten on May 28, 2026 to use a connection pool with built-in reconnect, TCP keepalive on the underlying socket, and a non-fatal error handler that logs and recovers rather than exiting the process. The change is a connection-handling fix only — no detection rules, wallet cohort, or alert formats were modified.
What is in place to prevent recurrence. The connection pool will transparently replace a dropped connection rather than crashing. Pool-level error events are logged but do not exit the process. The probe-on-boot pattern surfaces any database reachability issue immediately in the deploy logs rather than at the first user-visible failure. A separate follow-up will add automatic reconnect logic on the Helius WebSocket as well, addressing the other class of silent-death failure that this incident exposed.
What this correction does not cover. Dossier's monitoring was not strong enough to detect that the alert pipeline had stopped producing output for a week. That is a separate failure of operational diligence, and the lack of proactive uptime alerting is the underlying reason this took seven days to surface. Strengthening that is on the internal workplan, but no specific commitment is being made here — when one is, it will be logged as its own entry.
The Dossier alert pipeline went silent again from approximately the evening of May 30 (CT) through the morning of June 5. Both Telegram channels — Dossier Signals and Dossier Handler Signals — received no alerts during that window. This is the second multi-day outage in two weeks, following the May 19–26 outage logged in #007.
What happened. The wallet monitor's connection to our data provider (a long-lived WebSocket feed delivering Solana transaction events) stopped receiving data and never recovered. The Node process stayed alive, the Railway dashboard kept showing the service as "online," but no new trades were being recorded. Telegram alerts cannot fire on data that was never captured.
Root cause. Infrastructure log retention on the current tier had rolled over by the time the issue was discovered, so there is no definitive log from the moment the connection dropped. The failure pattern matches a class of issue commonly called "silent connection death" — the underlying network connection drops, the local process keeps believing it is still connected, but no data flows. The wallet monitor service had no logic to detect this state or to automatically reconnect when it occurred.
This is a different bug from #007. The May 19 outage was a database connection issue, which was fixed on May 28 with auto-reconnecting database pooling. The May 30 outage was a WebSocket connection issue, which that fix did not address. Two parallel failure modes in the same service. The first fix did what it was designed to do; it just was not enough on its own.
Fix. The wallet monitor was restarted on June 5 to recover the system. That brought it back online but did not fix the underlying cause. On June 6, an auto-reconnecting WebSocket layer was deployed with a heartbeat-based detector for silent connection death. The service now automatically reconnects on any disconnect (with exponential backoff), re-subscribes to all watched wallets on reconnect, and forces a fresh connection if it receives no data or heartbeat response within a configured window. The structural failure mode behind both #007 and #008 — silent connection failure with no auto-recovery — is now closed.
What this means in plain terms. The product was effectively offline for a substantial portion of the post-beta-launch period. Subscribers received no alerts during that time. The site dashboard continued to display historical data, which made "live" framing misleading. No promise is being made here that no other outages will occur — there are other ways a service can fail. The commitment is narrower and verifiable: every connection-class failure that produces silent downtime will get a corrections entry with root cause and fix, on the same week it is discovered.
Dossier's site previously used a fictional narrator — Admiral Zoran Voss (see #005). With the v0.5 site, the product no longer speaks through an in-character persona. Doctrine and research are attributed to the Galactic Federation of Finance as an institution; the methodology, status, and homepage state things plainly, in the product's own operational voice.
Why. Dossier's credibility rests on plain, verifiable claims about real on-chain activity — a public corrections log, no committed numbers without a spec, no hype. An in-character narrator voicing the product sits in tension with that.
Boundary. A fictional character may still appear in Dossier's marketing and social channels as clearly-labeled flavor. It does not represent the product's leadership, and it does not voice performance claims — those live only in the corrections log and forecast record, with verifiable backing.
In #002 we projected a beta cohort of 40 curated wallets. The grid shipped at 38. This entry reconciles that number rather than leaving #002's projection unaddressed.
Why. During curation, two of the projected wallets failed verification — on closer inspection they were dead or suspect (no genuine recent on-chain activity, or patterns that didn't survive scrutiny). Rather than pad the roster back to a round 40 with entries that didn't clear the bar, the beta launched with the 38 that did. The count reflects what passed verification, not a target we forced.
We launched the Scored Forecast Record — a public, append-only log where Dossier states falsifiable predictions in advance and scores its own accuracy after the fact. The first logging session is complete. The point is plain: a smart-money detector should be willing to be graded, on the record, before the outcome is known.
The baseline. We established a qualified-holder baseline for $GFOF of 42 organic wallets, measured at a 0.01% supply floor, excluding five structural wallets — the Moonshot bonding curve and four Streamflow dev-lock contracts — that are not organic demand. This is the measurement basis the first forecasts resolve against, stated up front so the resolution criteria can't be moved later.
The first two forecasts. FCST-S-00001-H7 and FCST-S-00001-H30, made 2026-06-17, resolving on or about 2026-06-24 and 2026-07-17. They are explicitly labeled SELF-BOOTSTRAP: they exist to seed the scoring methodology and are not convergence signals, trade calls, or product claims. Probability is hard-pinned at p=0.50 by design in this phase (so the Brier score sits at 0.25 until there is enough resolved history); the model only earns a calibrated probability later, once forecasts have actually resolved.
Honest gap. The two forecast hashes are recorded in the append-only event log, but their OpenTimestamps Bitcoin anchoring — and the public commit of the event-log file itself — is still pending; that step needs the build environment and will be completed and noted here. Until then the integrity guarantee rests on the published hashes, not yet on the Bitcoin anchor.
This log previously used five overlapping status labels (IN PROGRESS, SCHEDULED, ACTIVE, SHIPPED, MISSED). They have been consolidated to the same disciplined vocabulary the Federation corrections log uses: ON TRACK (a commitment in force or in flight), KEPT (delivered), and MISSED (failed). Two accountability logs speaking different status languages is a small credibility seam; closing it while the log is still short was the cheap, honest fix.
What changed, precisely. Only status labels were normalized — IN PROGRESS / SCHEDULED / ACTIVE became ON TRACK, and SHIPPED became KEPT. No entry text, date, id, or outcome was altered. This entry exists because changing a visible label on a past public entry is itself a change the log should record, even when the underlying facts are untouched.
Also added. A keep-rate summary, total/ON TRACK/KEPT/MISSED tallies, live search, and status filters — all computed from the entries on this page at load time, so the figures cannot drift from the log.
STATUS · Taxonomy aligned to parent log · stats auto-calculated · no entry content changed
The calibration plan for Dossier signal forecasts is now locked and published as a public spec at dossiertrack.co/forecast-spec. Three parameters are fixed, each as method + provisional value + recalibration trigger: the qualifying floor F = 0.01% of circulating supply, the broadening threshold of +15% at the H7 and H30 horizons, and a mechanically-selected control universe of eligible-but-no-signal tokens. None is a final number; each is provisional under the no-committed-numbers rule until the data supports it.
The disclosure that matters. Convergence signals often fire on tokens already in motion, so a Phase 1 control that compares signal tokens against all eligible tokens cannot separate predictive skill from pre-existing momentum. Phase 1 results are therefore labeled suggestive, not isolated skill — stated plainly on the spec page rather than left for someone else to point out.
The commitment. We commit, in advance, to a Phase 2 control matched on holder velocity (which holds momentum roughly constant), and to publishing that matched result on the record regardless of how it breaks — including if it shrinks or eliminates the measured edge. This entry exists so that pre-commitment is on the record and cannot be quietly dropped later.
STATUS · Calibration spec published · confound disclosed · matched-control result pre-committed to publish either way
During a security audit of the Dossier backend we found a Helius API key hardcoded in plaintext in a leftover file (an early learning script that was never part of the running service). All production code correctly reads credentials from environment variables; this one file predated that discipline and was missed. The repository’s secret-ignore rules were otherwise correct, so no environment file or other credential was exposed.
Impact. The exposed key was a Helius RPC key (read access to public Solana chain data). It could not move funds, access user data, or touch any wallet — Dossier holds no custody and stores no user secrets. The realistic worst case was consumption of our request quota by a third party. We have no evidence the key was used by anyone else.
What we did. Rotated the key immediately (the exposed key is now dead), re-applied access settings to the replacement, and deleted the leftover scripts from the repository. We log this even though it was low-impact and caught before any known misuse — which is exactly the kind of event a project is tempted not to disclose. That temptation is the reason to disclose it.
STATUS · Key rotated · leftover files deleted · no evidence of misuse
The key rotated in #014 turned out to also be the live credential the production wallet monitor was using. Rotating it killed the monitor’s authentication: its WebSocket to Helius began returning 401 (unauthorized) on every reconnect attempt, and new trades stopped being ingested. The interruption lasted roughly one day, until we identified the cause.
How it was caught. Our own status telemetry. The status page flipped to DEGRADED and stated plainly that the pipeline was online but the data feed was interrupted — new trades were not being ingested until it reconnected. This is the instrumentation we built after #007 and #008 specifically so a running process can never mask a stalled feed. It worked as designed: the failure was visible and honestly labeled, not hidden behind a green light.
Impact. Convergence detection paused during the interruption — the monitor could not see new trades, so no new signals could fire for that window. No user funds, custody, or data were involved. The gap is in ingestion coverage for the affected period, which we disclose here rather than pretend continuity we did not have.
What we did, and the process change. Updated the monitor to the current live key; ingestion resumed and status returned to LIVE. We then swept all backend services and confirmed every one is on the same live key. Going forward, a key rotation includes updating the credential everywhere it is used — code, deployment variables, and any local files — as a single checklist. #014 and this entry are the same event from two sides: rotating an exposed key without updating the service that depended on it.
STATUS · Resolved · all services on live key · rotation checklist adopted