Coordination requires metadata
The server must know which puzzle is being worked, which assignment was issued, whether progress is recent and whether the assignment reached a terminal state. It also needs enough counters to maintain coverage and enough timing information to manage leases. Those are coordination facts.
The client therefore sends identifiers and operational measurements such as assignment ID, checkpoint, keys checked and measured throughput. These values help the coordinator prevent overlap, estimate progress and decide when abandoned work can be recycled.
Cryptographic execution stays local
BitCrack, KeyHunt and other supported engines execute on the participant machine. The server does not remotely operate the GPU instruction stream and does not need a copy of raw engine output to allocate ranges. The workspace used to launch and supervise an engine is local client state.
This separation is especially important for the most sensitive possible result: a matching private key. OpenPuzzle’s rule is that the key is preserved locally rather than automatically transmitted as ordinary progress telemetry.
Why raw logs are not the default API
Uploading complete logs would expose more machine information than the coordinator needs and would make the protocol harder to reason about. A narrow structured API is easier to audit: each endpoint has a specific purpose, and the client source shows which fields are assembled for those requests.
Local logs still matter for troubleshooting. They simply do not have to become central project data by default.
Anonymous participation still needs identifiers
OpenPuzzle does not need a social profile to coordinate work. A random client UUID is enough to associate a machine installation with assignments and recent progress. An assignment UUID identifies a specific unit of work. These identifiers are operational, not a claim of real-world identity.
That distinction lets the service maintain consistency without requiring participants to create an account just to contribute compute time.
Open source narrows the trust gap
A participant can inspect the client code that performs claims, heartbeats, completion reports, updater downloads and process control. Release tags make changes comparable over time. This does not magically remove all software risk, but it converts important behavior from an undocumented promise into code that can be reviewed.
The server still has responsibilities
A narrow client protocol is only one part of security. The public service must also validate requests, enforce assignment state transitions, protect database credentials, avoid exposing private configuration and keep administrative interfaces separate from public APIs. Client-side privacy does not excuse weak server-side controls.