Three different responsibilities
The public website and API are coordinators. They know the puzzle definition, assignment ledger, leases, recent progress and aggregate coverage. They do not need to run BitCrack or KeyHunt to perform that role. A participant’s client asks for work, prepares a local workspace, launches a compatible engine and reports non-secret progress.
The engine is the component doing the expensive cryptographic search. CUDA and OpenCL backends use compatible GPUs; the CPU backend provides a slower but portable execution path. Keeping these layers separate avoids turning the central service into a custodian of participant hardware or discovered secrets.
The trust boundary around a solution
The most sensitive possible output is a matching private key. OpenPuzzle’s design rule is that this value remains local. The client can preserve a protected local record and stop automatic execution, while the coordination service receives only assignment metadata needed for review. Raw engine output is also kept local.
This is a narrower interface than uploading complete logs to a central server. It reduces the amount of sensitive material crossing the network and makes the client’s network behavior easier to audit from source.
Anonymous does not mean stateless
The service still needs a way to associate progress with the correct assignment. Each installation uses a random client UUID rather than a user account. Progress reports carry the assignment identifier, counters, checkpoint and measured speed. These operational identifiers are sufficient for lease renewal and completion handling without requiring a participant profile.
Why the client is open source
The client decides which commands are launched locally and which fields are sent to the API. Publishing that code allows participants to inspect these behaviors. It also makes release changes reviewable: recovery, safe stop, updater verification and backend handling can be compared between tags rather than treated as an opaque binary.