Read the docs

OFFPEAK JOURNAL

What your receipt actually proves.

OFFPEAK

Billing · Product preview

A checkable billing record is useful because a team can retain it and verify that it was included in a published commitment. Its value depends on being precise about what is checked and what remains a matter of trust.

The private record

The proposed receipt includes request and model identity, measured token counts, and charge information. OFFPEAK signs that record. The prompt is not meant to be published with the receipt batch.

Illustrative product workflow. Paid inference is in development.

The public commitment

Receipts are grouped into a Merkle batch whose root is anchored to the intended registry. A proof bundle allows a verifier to check inclusion after the batch has reached the required finality.

Publication is a separate state

Pending, published, and finalized describe different stages. A returned model response does not mean its batch is already finalized. The console should show that distinction rather than presenting every receipt as verified.

Illustrative product workflow. Paid inference is in development.

What verification cannot decide

A valid signature and inclusion proof do not independently establish that a GPU did the work, that usage counts were truthful, or that the answer was correct. Stronger execution attestations belong to future research.

The privacy boundary

Registry payloads are designed to exclude customer content and wallet addresses. Token transfers still expose wallet addresses, amounts, and timing. These are not anonymity or confidential-computing guarantees.

Keep the full bundle

The planned verifier checks the supplied record, signature, proof path, configured registry, and finalized commitment. Preserve the complete bundle for independent checking. All receipt data in the current console is illustrative.

Based on the supplied OFFPEAK version 1.0 product and build briefs. Read the overview ↗

← All articles