Lead Engineer — TypeScript/Postgres, Audit-Grade Evidence Platform

Independent Review — Signing, Hash-Chain and Offline Verification (TypeScript / Postgres) Fixed price · One-off · ~10–15 hours · Remote What we need We run a platform that issues signed evidence receipts. Each receipt is Ed25519-signed, hash-chained to the one before it, and designed to be verified offline by a third party using a public CLI — someone who trusts neither our customer nor us. We are about to put those claims in front of buyers who will test them. Before we do, we want someone from outside the team to check whether the implementation actually supports what we say about it. This is not a penetration test and not a full security audit. It is a focused review of one thing: do the cryptographic claims hold? The questions we want answered Each of these has a yes/no answer that we can act on. We'd like each one answered with reference to the code, not in the abstract. 1 · Which receipt types carry a real signature? Our CLI reports a sha256-legacy check on one receipt type and an Ed25519 signature on another. We need to know exactly which types carry a public-key signature, which carry only a hash, and whether any hash is keyed. If a receipt type carries only a plain hash over the canonical form, then "independently verifiable by a third party" is not true for it, and we need to say so publicly. 2 · Is the chain binding cryptographic or only a database relationship? Each receipt stores the hash of the previous one. What we need to know is whether that prior_hash sits inside the signed payload. If it doesn't, someone with direct database access could rewrite downstream records, recompute the hashes, and every signature would still verify — which makes the chain a foreign key, not a tamper-evident structure. We have one indication it may not be bound and would like it confirmed either way. 3 · What does the timestamp actually prove? Our central claim is that receipts are sealed at the moment an event occurs rather than reconstructed later. As far as we can tell, that rests on a self-asserted timestamp — signature verification proves content integrity and key authority, never time. We want that assessed, and if it holds, a short recommendation on the cheapest credible remedy (published chain heads, RFC 3161, a transparency log). 4 · Does the offline verifier genuinely agree with the server? There is a canonical serialisation and a CI check asserting agreement between implementations. We want to know whether that check tests the real production path or a reconstruction of it, and whether a receipt issued under an older format version still verifies today. 5 · Key custody. Signing keys live in a managed KMS. We want a straightforward assessment of custody, rotation, and what happens to historical verification when a key is retired. 6 · A claims-to-implementation map. We will give you the short list of public claims we make. For each: supported, partially supported, or not supported — with a one-line reason. This is the most valuable deliverable. We would rather be told to weaken a sentence now than find out from a customer's security architect. Deliverable One written document, however plain — findings against each question, evidence for each finding, and the claims map. A short call at the end if useful. We are not looking for a polished report. We are looking for correct answers, including uncomfortable ones. If a claim doesn't hold, saying so clearly is exactly the outcome we're paying for. What you'd get from us Read-only access to the relevant repository, the receipt format spec, the public verifier CLI, sample receipts of each type, and the list of claims. Everything under NDA. No production data is involved — there are no customers yet. Who this suits Someone comfortable reading TypeScript and Postgres, who has worked with applied signing and hashing in ordinary web systems — Ed25519, SHA-256, HMAC, canonical JSON, key custody in a managed KMS. Not blockchain and not primitive design. If you have implemented or audited webhook signature verification, receipt or audit-log signing, or anything in the transparency-log family, that's the relevant experience. To apply Two things, briefly: The closest thing you've reviewed or built to this — signed logs, receipts, verifiable exports, signature verification. Given questions 1–3 above, where would you look first? A couple of sentences is plenty. We're interested in how you'd approach it, not a free answer. Please include your fixed price and rough turnaround.