Nothing to
collect.

These pages are static. They set no cookies, load no analytics, no tag manager, no third-party scripts and no third-party fonts — the typefaces are served from this domain. Nothing here follows you anywhere.

The application log records, per request:

• a random request id, the method, the path, the user-agent
• the response status and how long it took

Not the request body, not the response, not your IP. The web server keeps a separate access log in the conventional format — client IP, timestamp, request line, status, bytes, referer, user-agent. It is used for abuse handling and for seeing which machines actually find us, and it is rotated under a fixed size cap rather than kept indefinitely.

The daily free allowance is per client IP, which means something has to be remembered. What is stored is a salted SHA-256 hash of the address — never the address itself — with a random salt generated once on this deployment.

The salt is the part that matters: IPv4 is only 2³² addresses, so an unsalted hash of one is trivially reversible and would be privacy theatre. Only the current day’s rows are kept; earlier days are deleted on the first call of a new day.

For each paid call we record the payer address, the amount, which endpoint or model was bought, the network and scheme, timestamps, the settlement status and the transaction hash. This is what makes reputation unfakeable, and it is the same data anyone can already read from the chain.

On-chain settlement is public and permanent. Nobody can delete it — not us, not you. That is a property of the payment rail you chose, and it is worth knowing before you pay from an address you care about.

Request bodies — the URL you want audited, the token address you want checked, the prompt you want answered — are used to produce your response and are not written to the logs or the ledger.

Some of what you send does leave our machines, and it matters which. The complete list of outbound flows, and why each one exists:

• the on-chain checks read the chain through an RPC endpoint — and deployer-check through a block-explorer API — so whoever serves those sees the address you asked about
• the endpoints that fetch a URL contact that site, which sees the request
• chat requests are forwarded to the upstream model provider you selected, under that provider’s own terms
• backlinks, keyword-volume, ranked-keywords and keyword-ideas send your target domain or keyword list to a third-party SEO data provider. Link graphs and Google Ads banded volume estimates cannot be derived from a page fetch, so the question has to be asked somewhere — and here the query is the sensitive part: a keyword list says what you are working on
• prediction-markets sends your search term to the venues it quotes (Polymarket, Limitless, Manifold), and defi-yields sends your filters to the public DeFi data source it names in the response (DefiLlama)
• a paid call’s signed authorization goes to the facilitator that verifies and submits it — payer address and amount, the same data that lands on-chain moments later

Nothing else goes out, and none of it is a profile: each of those parties sees one query, with no account or history behind it. Send neither secrets nor other people’s personal data.

No data is sold, rented, or handed to advertisers, brokers or analytics vendors. The only outbound flows are the operational ones listed in §05: the RPC and explorer reads behind an on-chain check, the site you asked us to fetch, the model provider for a chat call, the third-party SEO data provider behind the search-and-SEO endpoints, the public market and DeFi sources, and the facilitator that settles a payment. Each is a working request needed to answer your call, and each of those parties handles what it receives under its own terms rather than ours.

contact@true402.dev. Note the shape of the problem: with no account, a request to “delete my data” has nothing to key on — there is no record tied to you to find. The trading rules are on the terms page.

Last updated 2026-08-23.