Privacy
Last updated: 2026-10-15
This page lists what AttestPage keeps about calls to https://s2h6qt73jtzlgbgnnfacln2poq.srv.us and for how long.
Access log
For each request we log the time, method, path, status, duration, payment rail and its network, price, a coarse user-agent class (for example "ai_agent", "browser" or "crawler"), a short product token from the user agent, such as "gptbot" or "curl" (never the full string), the referrer's host name, a caller id, on a refused request (429 or 503) the reason as a short code (for example "trial_exhausted"), on MCP requests a mark ("mcp") with the MCP method and tool name only, never the arguments, and marks that separate our own checks from customer requests: a yes/no mark ("own") that says whether the request came from our own checks, on paid routes a mark ("body") that says whether a paid request's body was exactly one of the examples we publish ("probe") or not ("other"), and, on our own checks only, whether they came from the public or the loopback address, and a yes/no mark ("direct") that says whether the request came straight to the service's local port rather than through the front end. The log also holds a few short labels for which version of a page, price, payment offer or error message a caller was shown, and whether it was the caller's first call. The caller id is a keyed hash of your IP address under a random key replaced every UTC day. The key is kept only on the server, in a file only the service's own account can read, stored apart from the logs, so a restart does not change it, and it is deleted with the first request of the next UTC day. While a day's key exists, someone holding both the key and the logs could work out which address a caller id came from; after the key is deleted, that day's caller ids can no longer be matched to an address. A new key each day means caller ids cannot be linked across days. We do not log request bodies, query strings, target URLs, IP addresses or full user-agent strings. Log files are deleted after 14 days.
When a request to /v1/sample/:name gets a 404, the log also keeps the requested sample name for 14 days, only when it is 1-24 lowercase letters or hyphens; otherwise the name is dropped.
For a request to a path we do not serve, the path is logged as its first segment only, when it is 1-32 lowercase letters or hyphens, otherwise as "/other", and kept 14 days. When such a request gets a 404, the log also keeps the requested path itself for 14 days, without its query string, with control characters removed and cut to 80 characters, so we can see which missing pages callers look for.
Rate limits
To apply per-address rate limits and trial limits, we hold a keyed hash of your IP address in memory. The key is separate from the caller-id key, random, replaced every UTC day and held in memory only, never written to disk. When a request is refused by a rate limit, we log its time, path, caller id, bucket key and reason in data/ratelimit.jsonl for 14 days.
Payments
- For each settled payment we keep the time, route, network, amount, transaction hash and payment id.
- A paid receipt contains the payment details, including the paying wallet address. You hold the receipt; see Attestations below for receipts we keep.
- When a paying address is refused because it is on a sanctions list, we keep the time, route, network and that address.
- Paid requests log a hash of the payer address under the same daily key as the caller id (see Access log), and a short user-agent name; raw addresses are not stored in the access log.
- To answer a retried payment with the same response, we keep the paid response in memory for one hour.
- When a call's work is done but its payment fails to settle, we keep the time, route, payment id, signature nonce, paying address and, if reported, the failure reason and transaction hash, so the charge can be checked against the chain. If the payment had a payment id, the withheld response is also kept in memory for at least one hour, until the payment can no longer go through.
- Where Lightning (L402) is on, we keep the payment hash of each used token and its expiry time until the token expires, so it cannot be used twice, and the paid response in memory until a restart, so the same request with that token gets it again.
Attestations
For POST /v1/attest we keep a sequence number, the time, a SHA-256 of your idempotency key and the paying address if you sent a key, the SHA-256 you sent, the SHA-256 of your note, and the signed receipt (which includes the paying address). We keep these so that a retry gets the same receipt. The note text itself is never stored. These records are kept with no set end date.
Pages we fetch
Pages fetched for you are not stored. We keep only what goes into the receipt you receive. That receipt records the IP address of the site we fetched (never yours), its TLS certificate details and a few of its response headers. robots.txt files are cached in memory for up to one hour.
Sharing
Payments go through an x402 facilitator and are recorded on a public blockchain, as all such payments are. When a verify/citations call cites a page with a DOI, that DOI (only the DOI) is sent to Crossref (api.crossref.org) to read its public metadata. We do not sell or share the data above with anyone else.
Contact
no contact address is set on this server; the robots.txt opt-out works without one.