Do you have something up on the puzzle side already? I love puzzles, and I'm curious to find those "hidden randomly between specific hex bits" and learn more about cryptography.
What drives my interest is the fact that I've recently participated in a very similar activity — during the November airdrop round in stellar.public#spacedrop channel on keybase user @erayd published a few educational puzzles where users could get an XLM reward if they can figure out how to extract it. You can find all the currently active challenges, as well as a description for the solved ones, on this page: https://erayd.keybase.pub/puzzles.html. I liked the idea of 'earn by learning' so I later contributed a few puzzles based on the less known features and quirks of Stellar.
I look forward to seeing the new challenges you've come up with, and in the meantime, I'd like to share a few thoughts about the current state of stellarkeys.space.
First of all, it's a bit misleading that you use the term "leaked keys" for the list, which you generate on the fly by going sequentially through all possible Ed25519 private keys. Probability of finding the existing account is about 0.0000000000000000000000000000000000000000000000000000000000000000000007, which I guess many orders of magnitude smaller than any reasonable "probability of coming to life" estimation, no matter how you define it.
For sure, a lot of folks will enjoy jumping through random pages just for fun, which brings us to the next issue — on every page load by every user results in 25 separate requests to the public Horizon server to load the balances. During the next spacedrop round, it could be a few thousand users constantly navigating through pages, trying to catch the winds of luck, and that will put unnecessary load on SDF's Horizon instances, affect other projects, and might even work as a DDoS attack. That's not in the best interests of the community, so please don't do this. You can use your own Horizon deployment or switch to a more effective algorithm.
My last comment is about the burn address generator, which is also an incorrect and misleading naming for the tool, given what it does. For the "real" burn address used by SDF, they had a secret key, and they used it to properly lock the account (set the master weight to zero). This setup guarantees that the funds will never escape this account and get into the circulation, which is what "burned" implies. Your tool generates a valid public address but doesn't have the corresponding secret key to lock the account. The funds are not really "burned" and can get back to circulation if the account's secret key is found in the future (for example, by some lucky user of your tool).
