A proof-of-work random number generation system for Pokémon (The original question that was here was considered too confusing, unclear, and rambling. You can still view it in the edit history, but the content is no longer useful by itself, and cannot be reasonably reconstructed into a question suitable for this site. The question object is still here by decision of a moderator, as a placeholder to preserve any reputation gained by the answerers of this question while it was still active, as well as to preserve the original question content in case any new questions are built upon this one.)
It is hard to tell from this question, but I suspect that you may have managed to confuse yourself about what problem you have: i.e., that you've gotten caught up in a particular mechanism, and would benefit from taking a moment to step back and look at the actual requirements.  I found it hard to extract the actual requirements from your question.

In these situations, it's always a good idea to ask yourself the question: What is my threat model?  What kinds of threats do you need to defend against?  What kinds of attack vectors are possible for an attacker?

For instance, a crucial question is: do you trust the game software that is running the game?  It sounds like you want to say that you don't trust the software, but that leads you to an unsolvable problem.

Or, to put it another way, it seems like there's a simple solution to your problem.  Your game software can generate truly random numbers using a suitable random number source (e.g., /dev/urandom or CryptGenRandom).  There doesn't seem to be any reason to use a deterministic PRNG, and no reason for the random numbers to be derived from untrusted user inputs.  Doesn't this solve all your problems?  Why are you going into such complicated stuff, when there's a much simpler way to generate random numbers that also happens to eliminate the issues you're worried about?  Is there some requirement that I'm missing?

If you're about to say "but the user could modify the game software's RNG to bias its output", my response will be "yes, that's always possible, and nothing you will ever do will ever be able to stop that".  Realistically, you can't prevent reverse-engineering of your software.  The user who is running your software could always run a modified version of your software that gives them better stats, and no amount of cryptography is ever to make that impossible.
But in any case, these are the kinds of questions you should be working out when you think through your threat model.

I confess I had a hard time understanding what proof-of-work has to do with trusting that the random numbers you generate are trustworthy.