Commitments and timestamps

Commit binds report digests and batches to independently verifiable Bitcoin timestamps through an OpenTimestamps-compatible profile. It is an optional, asynchronous part of the evidence lifecycle.

Commitment lifecycle

NOT_REQUESTED → PENDING → VERIFIED with explicit FAILED or expired handling.

Commitment state and evaluation findings are independent. A valid payment report can have a pending timestamp; a verified timestamp can commit to a report whose evaluation failed.

Evidence required

A verified commitment must establish the relationship between the report digest, any batch membership proof, the timestamp proof, and the accepted Bitcoin evidence. Simply writing a known block hash in a report is not Bitcoin anchoring.

A timestamp supports a claim of prior existence under its verification assumptions. It does not prove the report true, establish universal event ordering, or guarantee that the underlying data will remain available.

Privacy and cost

Keep confidential evidence off public chains. A bare hash of predictable content can be guessed; consider appropriate privacy-preserving commitment design and access controls. Retain enough private evidence for authorized consumers to reproduce the checks.

Batching reduces commitment overhead but not storage or availability obligations. Public calendar access is not a contractual SLA. Track failures and allow independent verification of completed proofs.

Source: OpenTimestamps.