Hard questions

The objections we don't dodge.

Five questions a serious reviewer asks in the first meeting. Two could kill the idea if we got them wrong — so we answer those in full, then the three that are harder than they look.

Q1 · the one that kills the project if we get it wrong

"Doesn't publishing receipts leak everyone's private data?"

What's public is never the decision — it's a commitment: cryptographic proof that a specific, unaltered decision was sealed at a specific time by a registered key. The decision itself is revealed only to a party with legal standing to see it, who then checks it against that commitment.

Commit, don't expose

The register stores a salted hash of the payload — enough to prove integrity, useless for reconstructing the data.

Reveal on legal basis

A subject, regulator or court receives cleartext and verifies it hashes to the commitment.

Aggregate, not individual

Outcome rates are published as windowed statistics. The public sees patterns; never a person.

Q2 · we publish the attack surface and pay you to break it

"What stops someone from faking the whole thing?"

A trust system that can't say how it fails isn't trustworthy. Here's the attack surface, and what stops each one.

Forge a receipt from nothing

The signature must resolve to a registered Ed25519 key in the registry. No key, no provenance.

Residual: a stolen key — out of scope here, handled by rotation + revocation.

Backdate a decision

Append-only log + chain position. A receipt can't be quietly inserted into the past.

Residual: timestamp accuracy depends on the TSA you bind.

Only publish flattering decisions

The Coverage metric divides verifying receipts by declared scope volume — the denominator is public and spot-checked.

Residual: a wildly under-declared scope is itself a visible signal.

Collude with the scorer

Scoring is reproducible from public artifacts — anyone can recompute it. No trust in the scorer required.

Residual: none cryptographic; the artifacts are the audit.

Alter the payload after sealing

The content hash commitment self-invalidates. One changed byte fails verification.

Residual: none — this is the core property.

Replay an old receipt

Unique ID + chain position make a replayed receipt detectable as out of place.

Residual: depends on consumers checking chain position.

Disclosure loop: report → triage → fix → disclose → credit. Good-faith research is never met with legal threats.

Read the full security policy →

Q3–5 · the harder ones

Three that are harder than they look.

Who decides what's 'official'?

A governed registry and authorization process — never payment. We say so in plain text: payment never grants official status, and the registry is a pilot.

Isn't this just a fancy log?

A log you control proves nothing to a second party. The difference is independent verification: anyone re-runs the math against a published key and gets the same answer.

What if the spec is wrong?

The spec, fixtures and verifier cores are open. Independent verifier agreement across runtimes is the trust anchor — and the standing challenge pays you to break it.

Where a claim isn't proven yet, we say so.

This is a pilot. None of the above is settled law or a ratified standard — it's the protocol's current, testable position. Where a claim isn't yet proven, we've said so in plain text rather than rounded it up. If your hardest question isn't here, send it — the gaps are the roadmap.