What this site knows about you.
Reading this site requires no account and sets no cookies. Some pages fetch published research records as you read them; mining sends more. This page describes exactly what goes where and when, taken from the code rather than from a template.
Last updated 24 July 2026
Just browsing
There are no cookies, no analytics, no tag managers, no fingerprinting and no third-party scripts of any kind. Nothing follows you between pages, and nothing about you is recorded for its own sake.
The site is a static export, but it is not inert. The home page and /finds read the published collection from our database at Supabase as they load, and opening /mine reads the current challenge from a public Solana RPC. You did not ask for those requests, so: the servers on the other end see your IP address and the ordinary metadata of a web request, exactly as any site you visit does. Nothing identifying you is attached. The database reads carry this site’s own public read key, which says which project is asking and nothing about who is asking.
Pages in the address space itself — anything you reach by navigating or searching from /explore, or by giving a page address — really are computed in your own browser, and reading them fetches nothing from anyone. Three kinds of record are the exception and are built from stored bytes rather than derived from an address: the generator-family pages and the quantum-sampled pages on Finds, which exist because they were measured rather than addressed, and the landmarks in Explore, whose text is written into the site and placed at the address it happens to occupy. Landmarks still travel nowhere — their text ships with the page — but they were put there rather than found.
If you mine
The search itself runs entirely in your browser; page derivation and the lenses never leave your machine. What does leave is reporting, and it is automatic rather than something you press a button for. While the miner runs it sends a signed report roughly once a minute — whether or not anything has cleared a threshold, because the coverage counters are the point of the report. Not every clearing page is sent: a report carries the counters plus at most eight of the strongest nonces, and separately the single strongest unclaimed find is submitted every couple of minutes. Everything else that cleared is represented only as a number in the tally.
Neither edge of that is where the word “mining” would put it. Opening the page is already enough: it generates and stores your claimant key and identity, reads the challenge from a public Solana RPC, and, if you have mined here before, restores your saved session and can within seconds send a report and claim a find left waiting from last time — all without your pressing Start. At the other end, Stop halts the search but not the reporting loops: while the miner remains on screen a final report can still go out and unclaimed finds can still be submitted. What ends it is the miner going away — switching to another tab there, navigating elsewhere, or closing the page.
Mining for the record publishes — that is what it is for — but how much is not all-or-nothing. The Everything mode, which is the one that sends whole mined ranges, has a switch on it and sends nothing while that switch is off. The single-lens modes have no such switch: they report coverage about once a minute whenever they run. If you want to search while sending nothing at all, the “Explore freely” tab does exactly that: it runs locally, submits nothing, and nothing it finds can be claimed. The following is what reaches our own database:
Used as a rate-limit key so one sender cannot flood the endpoints. It is written to a rate-limit table as your address behind a short prefix naming the endpoint — ip:your-address when you submit a find, rip:your-address when you report coverage, rrip:your-address when you send a mined range — alongside a counter and a window timestamp. Your claimant key gets its own counter in the same table. None of it is attached to your find, and none of it is used to profile you.
Its coordinates — the challenge, the wallet and destination values, the nonce — plus which lens matched and at what version, the metrics that made it notable, the signature proving you claimed it, the challenge descriptor it was derived against, a row id, and the bookkeeping: whether it verified, why if it did not, whether the challenge was confirmed on chain, its archive number and event id once assigned, and the time it arrived. Despite the name, wallet and destination are not accounts: they are two random 32-byte values your browser mints for itself, no private key is ever generated for them, and nothing here treats them as anything but part of the page coordinate. Most of this is public and anyone can read it — that is the point of the collection. Three columns are stored but withheld from public reads: the signature and the descriptor, so the record cannot be replayed by a stranger, and the internal row id, which is of no use to anyone outside the database.
A random Ed25519 public key your browser generates the first time you open the mining page — not when you first mine, so it exists whether or not you ever start. It is how one miner's finds are attributed consistently. It is not derived from anything about you: no name, no email, no device identifier. If you clear your browser storage you become a new, unlinked claimant.
Sent automatically about once a minute while the miner runs in single-lens mode, with no find required: the running count of pages your browser examined and cleared, filed against the same coordinates and claimant key. These are the denominators the site publishes; they are self-reported, and the site says so wherever they appear. The Everything mode does not send these — the range below already carries the same pages, and counting them twice would inflate exactly the numbers that are supposed to be conservative.
This is the largest thing the site sends, and it is new. A range is the stretch of the space your browser searched plus EVERY find it made in that stretch — not a selection of the best ones. Stored: the coordinates and the window (challenge, wallet, destination, first nonce, how many), your claimant key as the signer, the lens versions used, the challenge descriptor, the full block of find records as text with its SHA-256, how many records and how many pages, the notable and winner counts and the highest score, the two signatures (one made before the stretch was searched, one after), the two timestamps, whether the challenge was confirmed on chain, and the bookkeeping for whether the indexer has taken it: a state, an error if it was refused, and an archive number and event id if it was accepted. The block of records is capped at about a megabyte and a half. Unlike finds and coverage, this table is NOT publicly readable — it is a staging area the indexer drains, and what becomes public is what survives that audit, which then appears on Finds like any other find.
No name, email address, account, password or payment detail is ever requested or stored, because the site has no concept of any of them. The three endpoints your browser can reach are rate limited to 30 find submissions, 120 coverage reports and 360 mined ranges per hour, counted separately against your address and against your claimant key.
What is kept in your browser
Most of what is here stays here, and one item is a genuine secret: your private signing key, which never leaves under any circumstances. Being stored locally is not the same as being private, though. Three of these values — your public claimant key, your wallet and your destination — travel with every claim and report, because they are what a find is filed under. Clearing your browser’s site data erases all of it immediately and completely, and makes you a new participant.
Persistent (local storage — survives until you clear it)
- lob_claimant_key_v1 — your claimant signing key, private half and public half. The private half is never transmitted; anyone who obtains it can sign as you, so treat it like a password, and losing it simply means a new identity.
- lob_identities_v1 — the wallet and destination pair this browser mints for itself. Both are transmitted with every claim and report; they are part of the page coordinate, not an account.
- lob_browser_finds — the seed miner’s twenty best word finds, ranked by score and deduplicated, so the history panel can show them. Only finds of two or more words qualify, and only from that miner; the coordinate miner keeps its own finds in the session entry below.
- lob_report_session_v3:… — one entry per challenge and lens you have mined, holding how far the scan reached, the counters, and the best finds it is holding — including any not yet submitted. The rest of the key is your challenge, lens and a prefix of your identity, so a new identity starts clean rather than inheriting the last one’s progress.
Temporary (session storage — discarded when you close the tab)
- lib_stored_address, lib_stored_bytes, lib_stored_mark, lib_stored_origin — the page you are currently viewing, so a reload does not lose it. These are never transmitted.
Who else is involved
The site is hosted on Cloudflare, and its database and endpoints run on Supabase; both process requests on our behalf. The home page and Finds read from Supabase as they load, so a visit reaches it whether or not you mine.
One third party is not ours at all. Opening the mining page reads the current challenge from api.devnet.solana.com, the public Solana development-network endpoint. It is a free public service run by others, not a processor acting on our instructions, and it sees your IP address like any server you contact. If you would rather it did not, do not open that page.
IBM Quantum is not currently in the picture. A stateless Cloudflare Worker exists to relay a browser request to IBM using a token you would supply, and it is written to keep no copy of the token or the response, but nothing on this site calls it yet — the quantum panel is an explainer and says so. If that changes, this section changes first.
Links out to GitHub are ordinary links; following one puts you on GitHub’s terms, not ours.
Removing something
Local data is yours to clear directly, as above. For a published find, write to support@libraryofbinary.com with the claimant key or the find in question and it will be removed from the live collection — the database this site reads, which is what anyone browsing here will see.
Three honest limits sit behind that, and none of them can be engineered away. Copies others have already downloaded cannot be recalled. Anything already anchored to a public chain is beyond anyone’s reach, including ours. And a verified claim is also appended to the project’s hash-chained archive, which is the canonical record: it is append-only by construction, so entries cannot be edited or dropped without breaking the chain that makes the archive worth anything. Removal clears the live dataset, not history. If that is not acceptable to you, the moment to decide is before you submit.
About this project
The Library of Binary is an independent research project, run pseudonymously; correspondence goes to support@libraryofbinary.com. If this policy changes, the date at the top of this page changes with it.