A user may care about thirty companies. They may own five of them, be considering three, and merely follow the rest. A conventional market product can easily turn that preference set into a server-side profile: watchlist, holdings, positions, alerts, browsing behavior, and eventually inferred intent.
Ticker Watch does not need that profile to answer a much narrower question: “What changed around NVDA?” The public market gateway needs the selected ticker. It does not need the user’s entire watchlist, brokerage balance, cost basis, or position size to retrieve recent public evidence about NVIDIA.
The request boundary
The core single-ticker flow is intentionally simple:
This is not anonymity. The request still reaches a service, and ordinary network metadata still exists. The architectural claim is narrower: the market research request does not require the application to attach a detailed investor profile to that ticker request.
Why keep the watchlist local?
A watchlist is deceptively sensitive. A list of public ticker symbols can reveal employer relationships, acquisition speculation, investment interests, sector concentration, or a user’s research priorities. None of those inferences are required to render a single-company research page.
Ticker Watch therefore treats the watchlist as preference state, not as a prerequisite for the public evidence pipeline. The browser stores the local experience. When optional trusted-device synchronization is enabled, the design sends an AES-GCM encrypted payload to the sync relay rather than a readable ticker list.
| Data | Needed for single-ticker research? | Primary boundary |
|---|---|---|
| Selected ticker | Yes | Browser → market gateway |
| Full watchlist | No | Local device / optional ciphertext sync |
| Portfolio holdings | No | Not required by Ticker Watch |
| Position size / cost basis | No | Not required by the research request |
| Public news and filings | Yes | Market evidence pipeline |
Encryption is the second boundary, not the first
Local-first does not mean “never synchronize.” People use multiple devices. The useful question is whether synchronization can happen without turning the relay into a readable preference database.
The current design encrypts the watchlist with AES-GCM before optional sync. Trusted-device pairing transfers the necessary secret through a one-time capability flow. The relay is designed to persist ciphertext and technical synchronization metadata rather than ticker symbols in plaintext.
That design still has a threat model. A compromised browser can read state while the page has decrypted it. Malware or a malicious extension can observe what the user sees. Encryption at rest does not protect data from a hostile endpoint that is actively using the key.
What the gateway should do—and not do
The market gateway has a useful responsibility: isolate external provider differences from the browser. News and filing providers have different schemas, identifiers, timestamps, and availability rules. The gateway normalizes the result so the client can consistently render evidence and attach research context.
But normalization should not become an excuse to grow the request envelope. For a single-company refresh, the gateway should not need:
- the rest of the watchlist;
- the user’s portfolio value;
- a brokerage credential;
- the size of the user’s position;
- the user’s financial vault.
Keeping that boundary small also makes the system easier to explain and audit. A privacy promise becomes more credible when the network request can be described in one sentence.
What we give up
Minimum-data architecture creates constraints. Without holdings, Ticker Watch cannot truthfully say, “This event affects 18% of your net worth.” Without cost basis, it cannot calculate personalized tax consequences. Without portfolio composition, it cannot perform true portfolio-level risk analysis.
Those may be useful products, but they are different products with different data requirements. The architectural mistake would be collecting all of that data “just in case” while delivering only ticker research.
What this means for investors
For the user, the practical benefit is not a cryptographic slogan. It is a smaller trust requirement. You can research a company without first uploading the composition of your portfolio. You can keep a preferred ticker list on your own device. And when the product presents an interpretation, you can move back to the public evidence rather than being asked to trust a hidden profile-driven score.
Where we go next
Once preference state is separated from the public research request, another problem becomes interesting: repeated checking. A user does not want the same five stories every time. The next article explains how Ticker Watch creates an encrypted device-local research checkpoint and turns a refresh into “Since I last checked.”