A search you could actually verify

There are 16⁴⁰ possible Ethereum addresses. Impossibly many. We go deep on that number on The Space. This page is about the search itself: how it would actually run, and how you could actually join it.

Nothing below is running yet. We’d rather tell you it’s coming than pretend it already works. This is the design, written down first, so the client can be held to it once it ships.

Here’s the method. Generate a candidate private key. Derive its address the same way any Ethereum wallet does: an elliptic-curve public key, hashed with Keccak-256. Compare it against the 31 known Dead Ringers addresses. Discard it. Repeat.

There’s no cleverer way to do it. That’s not a limitation. It’s the whole reason Ethereum addresses are safe in the first place. If there were a shortcut, this wouldn’t be a tribute to hopelessness. It would be a security incident. The only real lever is how many candidates you can generate and check per second, on perfectly ordinary hardware. No special chips. No wasted energy chasing a shortcut that doesn’t exist.

And none of it ever touches Ethereum. Generating a key and deriving an address is the same local math your wallet software already does every time it makes you a new address. Nothing broadcast, nothing signed, nothing costs gas. Checking a candidate against 31 known addresses is a string comparison. No transaction is ever sent. No contract is ever called. Ethereum has no way to know this search is happening, because nothing about it ever reaches the network.

Here’s how you’ll be able to join, once it’s real. An open-source client, small enough to read in an afternoon, running entirely on your machine. It generates and checks candidates locally. Your private keys are never written to disk, never transmitted, never seen by anything but your own device, not even by us. The only thing that ever leaves your machine is a number: how many candidates you’ve checked, and how fast.

We will never ask you to download something that reports back the addresses or keys it generates. If a future version of this page ever asks for that, treat it as a bug, or worse, and don’t run it.

And here’s what actually gets published. Not a list of generated addresses. That would just be noise: uniformly random strings that tell a researcher nothing, cost real money to host at the scale this would reach, and look, to anyone skimming, uncomfortably like the output of a tool built to drain real wallets instead of check 31 specific ones. Instead: a coverage ledger, timestamped and cryptographically verifiable, proving which ranges of the keyspace have been swept without ever revealing a single key. A leaderboard, showing how much verified work each contributor has done. The method itself, open-source, so anyone, including cryptography researchers, can read exactly how it works instead of trusting a description of it. And a coverage map: the swept fraction of the keyspace, visualized as it grows. Negligible next to 16⁴⁰ for a very long time. Also, quietly, a second generative artwork this project produces without meaning to.

This is Phase 2. Not started. Not funded. Not scheduled. What’s above is the commitment, not a changelog.