Privacy & data

Who is responsible, and who this is for

The person who runs this site is the data controller for everything described here, and the only contact point published is the mailbox on the contact page (info@periodictable.lol) — no company, postal address or telephone number is published anywhere, deliberately. One thing does not depend on that: the payment partner is the merchant of record for every charge, so the transaction, its records and the tax position are theirs, and what is held here is the minimum described below.

This service is for adults: the rules require you to be 18 or over, or the age of majority where you live, and the checkout asks you to confirm it. A stake made by a child is reversed and the payment returned on request — write to info@periodictable.lol.

What is collected, and why

Nothing below is inferred or enriched. There is no advertising network, no cross-site tracking and no data broker, and personal data is not sold or rented to anyone.

The listing you bought

• • Your email address, so the receipt can reach you and a holder can be told when someone outbids them. Kept until the listing ends — do not stake with an address you would mind losing access to.
• • The listing itself: the title, the one-line pitch, the domain shown on the row, and the destination a click is sent to. Public by design — it is the product — and kept while the listing is on the board.
• • Clicks, counted into a total on the row, with no IP address or user agent stored next to one and no per-visitor history to build a profile from.

Payment facts shared by the payment partner

• • The payment reference, the amount, the currency, the card brand and the last four digits, the outcome and the time of the charge. Kept with the payment as the record of a sale — it is what answers "what is this charge?" and what a dispute is decided on.
• • A withdrawal, reversal or refund is recorded against the same row rather than deleting it, which is why the row survives after a listing is replaced.

Safety, abuse and operations

• • The site's own security check records the hash of an address for a short window, never the address itself, so repeated checkout attempts can be rate-limited without keeping a list of who visited.
• • Reports you send, and the mail log used to send them: the address a message was sent to and whether it went out. Kept for 30 days after sending, then dropped.
• • The operator's audit trail — a listing removed, a report actioned, a stake reversed — kept as long as needed to explain a decision if it is challenged, and deliberately free of unnecessary personal data.

What is published

Published, and public the moment a stake settles: the element, the title and pitch, the domain on the row, the destination of the link, the total staked on that element, and how many times the row has been clicked.

Never published: an email address, a payment reference, card details, a report, or the hash behind a rate limit. Row-level click logs are visible to the operator and are not published, and the totals carry no identity — no per-visitor history, and one click cannot be tied to another.

Cookies and analytics

No page of this site sets a cookie of its own, and there is no advertising or profiling cookie anywhere — including behind analytics, which is off in production unless the operator switches it on.

The events: tile_click, drawer_open, search_submit, checkout_start, checkout_paid, reclaim_click, go_click, plus an aggregate pageview count. They record that something happened and the shape of the page — not who did it. No analytics script is loaded before consent, and it does not load until you say yes. A visitor who never answers makes no request to Plausible at all, because the gate is the script rather than a flag inside it.

When analytics is on it is Plausible: cookieless, IP-anonymising, limited to the events above, and the switch is held in the deployment configuration and never changes at runtime. Analytics is off in production, and that is not a figure of speech: NEXT_PUBLIC_PLAUSIBLE_DOMAIN is left unset in the deployment, so no request reaches Plausible from this site.

What your browser talks to

On a normal page view: none. Every icon is fetched by our own server, at the proxy route /api/favicon, and served from this domain, so the icon service sees our request rather than the browser's and learns nothing about which pages are read. Listing screenshots are captured by our servers the same way, so a third party is not reached while a page is browsed.

Three exceptions, all on a step a visitor chooses to take: checkout mounts the payment partner's form, so Stripe sees that page and, when the anti-bot check is enabled, Cloudflare too; and analytics, if it is enabled and consented to, as above. Nothing else is fetched — no font service, no tag manager, no chat widget, no tracking pixel and no advertising script is loaded by this site, on any page.

Companies that process data for us

Each of these acts on instruction, and none of them may use the data for advertising of its own. This list is the whole set: nothing is added to it without appearing here.

• • Stripe — processor, and seller of record for the charge. Payments, receipts and reversals. Stripe is the merchant of record: it sees your email address, the charge and your payment instrument, decides the tax position and remits the tax. We see the amount and the reference it gives us.
• • Resend — processor. Sends transactional email from our own domain — the receipt, an outbid notice, a confirmation link, a report notification — processing the recipient address and the message body to deliver it.
• • Neon — processor. Hosts the database that holds every row described above.
• • Vercel — processor. Hosts the site and runs the scheduled jobs, so it processes requests — including IP addresses in its own logs — on our behalf.
• • Cloudflare — processor. Turnstile, the anti-bot check on checkout when it is enabled: it sees the checkout request and a browser fingerprint, and it is mounted nowhere else.
• • Google — processor, for site icons only. Its favicon service was once called by the browser directly on every page carrying a listing. Not any more: our own server fetches the icon and serves it from this site through a proxy, so Google sees our request rather than the browser speaking for a visitor.
• • Microlink — processor, for listing screenshots only. Turns a listed page into the preview image stored with that listing, called once per listing by our servers and never by the browser, so a visitor's IP address never reaches a third party.
• • Plausible — processor, for analytics only. Product analytics for the operator, off in production unless the operator switches it on: cookieless and IP-anonymising, reporting counts rather than people, holding one device's history for 24 hours at most, and not loaded unless a visitor says yes.

Retention, and deletion

Payment rows are kept while the listing exists and afterwards for as long as tax, accounting and dispute handling require, because a deleted row cannot answer a chargeback. Reports and their mail log are kept for 30 days after sending. Rate-limit hashes expire on a short window and are never joined to anything else.

A deletion request is honoured by taking the row off the board and dropping the personal part of every row that can be dropped without breaking one of those obligations — an email address attached to a payment that is later disputed is kept until the dispute window passes, and then it goes. Every deployment also runs a scheduled erasure sweep: finished rows older than the retention window are deleted by a job, not by hand.

In the UK, the EEA or Switzerland you also have the right to object to processing, to ask for a portable copy of what is held and to complain to your national supervisory authority; the controller is not established there, so a request goes to the mailbox above and is answered within 30 days.

Security

Passwords are not used and not stored: there is no account to log into, and card details never reach this site — they are entered into the payment partner's own form, and only their reference and the outcome come back.

Transport is encrypted end to end and the database is not reachable from the open internet. No system is perfect: if a breach ever affects personal data, affected people are told without undue delay, with what is known and what to do about it.