Check a solution's seal. Short form, which needs only what is short: request is the solve request as it was sent (the answer's inputs), and solution_seal is the seal its answer gave. The request is solved again, under a physics permit and the limits and refusals of solve, and the answer is holds, cause ("solution_seal" when the seal given is not the seal the request solves to), recomputed_solution_seal and recomputed_receipt_sha256 when it holds (when it does not, no seal is returned: solve gives the true one), a sentence of what was checked, and text_not_compared: the short form compares no answer text you hold, so a copy with a decimal changed still holds; verify_receipt checks a copy against the receipt that copy carries, and the check is complete only when that receipt equals recomputed_receipt_sha256 here. Nothing is stored, so the short form answers the same on every connection. Worked example: {"request":{"solver":"atom_dft","parameters":{"atomic_number":10}},"solution_seal":"<the solution_seal of its solve answer, 64 lowercase hex digits>"}. Long form: the whole solve answer sent back, without request; it takes no physics permit, recomputes the solution seal and names the part that fails, and checks only the exact hex values and the seals, not the decimal copies of the values and not the receipt, as its answer says; verify_receipt checks a copy's bytes against the receipt it carries. Same bytes as POST /verify_solution. On this open connection one address holds at most 1 physics permit at a time, and a solve, a dataset job and a run of more than 10000 steps are long work, of which 1 runs at a time: a call that finds no permit or no place is answered "Too many concurrent physics tasks." and is sent again; nothing waits. An answer is waited for 60 seconds.