Phantom Receipt | Free, checkable with only a public key

What a receipt is

A Phantom Receipt is a plain text file. It carries the record that was sealed, the place of that record in an append-only ledger, a digital signature over that place, and the signer's public key. A record can be any bytes. When we seal a file for you, the record is the file's SHA-256 fingerprint, so the receipt does not contain your file.

There are two forms. A chain receipt carries the few ledger entries around the sealed one and a signed ledger tip. A batch receipt carries a short Merkle proof and a signed Merkle root, so one signature can cover many records and each receipt stays small.

PHANTOM-RECEIPT v1
issued 2026-09-30 04:51:42.002
signer-fpr 184609a2b571a6d6...
record-index 3
anchor-tip 6:08b09d0b4c026254...
anchor-sig MEQCIDuITRkBg2xLOPqt26D...
pubkey LS0tLS1CRUdJTiBQVUJMSUMg...
segment W0JMT0NLXzAwMDAwM10g...

Shortened. This sample was made with a throwaway test key. You can check the full version on the verify page.

Inside a receipt, line by line

Every line has one job. The lines outside the signature are each tied to something the signature or the proof covers, so a receipt whose header lies fails the check even if its signature is genuine. A check ends in one of three answers, each with a stated reason: VALID, INVALID or MALFORMED.

Line	What it says
`PHANTOM-RECEIPT v1` or `v2-merkle`	Which form this is. See the two forms below.
`issued`	The time on the issuer's own clock. On its own, it is the issuer's word. An outside timestamp token is what makes the time independent.
`signer-fpr`	The SHA-256 fingerprint of the signer's public key. It must match the key embedded in the receipt, or the check fails.
`record-index`, `anchor-tip` (v1)	Where the sealed record sits in the ledger, and the count and hash of the signed ledger tip it is linked to.
`leaf-index`, `leaf-count`, `merkle-root` (v2)	Which record this is in a batch, how large the batch is, and the signed root the record's short proof must rebuild exactly.
`anchor-sig`	The signature over the tip or the root.
`pubkey`	The signer's public key, so the receipt can be checked with nothing else. You still decide whether to trust that key.
`segment` (v1) or the audit path (v2)	The few ledger entries around the record, or a short list of hashes. Together with the record, they let anyone recompute the tip or the root.

Two forms of receipt

Chain receipt (v1). For one matter's files, sealed one after another. Each record is linked to the one before it, and the receipt carries the entries around the sealed record plus a signed ledger tip. Change one entry and every link after it breaks. One signature per receipt. The receipt grows as the ledger grows, because it carries every entry from the record up to the signed tip, which is why the batch form exists.

Batch receipt (v2, Merkle). For many records at once. All the records are hashed into a tree and one signature covers the root. Each record gets its own small receipt, a short proof of about log2(N) hashes, so receipts stay small however large the batch is. One signature per batch.

What we can seal for you

The receipt does not care what is inside a record. It seals whatever record it is given, and for files that record is a fingerprint. Here are the kinds of record we offer, each with its real status. The labels are the same as on the tools page.

A single file

In pilot

A text-message export, an email, a photo, a PDF or a spreadsheet. We seal its SHA-256 fingerprint and issue a chain receipt. Anyone holding the same file can check it against the receipt.

A set of files for one matter

In pilot

All the exhibits for a matter, sealed together, with one receipt per file and a plain-English report that lists them. Right for a client file you want to freeze on the day it arrives.

A large batch of records

In pilot

Hundreds or thousands of records sealed in one step with a batch receipt. One signature covers all of them, and each record can still be proven by itself. A batch receipt stays about a kilobyte plus the record, however large the batch is. Useful for logs, exports and recurring records.

A receipt with an independent timestamp

In pilot

A receipt plus an RFC 3161 token from an outside time authority, so the time does not rest on our clock. A second proof, anchored in Bitcoin, is in progress and not live.

A captured web page

In pilot

A public page saved as a screenshot, the page's HTML, a PDF and the raw response headers, each fingerprinted and sealed with a receipt. It shows what our software fetched at that moment. It does not show what anyone else saw, and it handles public pages only. In this pilot form, the receipt in a capture is signed with a software key, and the report says so.

A decision or event record from your own software

In pilot

For software teams: any record your system produces, such as an approval, a payment decision or a settings change, sealed without the receipt layer needing to understand it. The record is yours. The proof that it was not altered afterward is ours. Offered by arrangement. The receipt carries the record itself, so for anything sensitive we seal a fingerprint of it instead.

Typed message records, such as payment messages

In progress

For payment and software teams: records of a defined message type, such as an instruction, a status report, a return or an end-of-day statement, each marked so that one type cannot be passed off as another. The proof for a third party is still the signed receipt. Not offered yet.

A ledger summary report

In pilot

A single self-contained page that says whether the whole ledger is intact, lists each timestamp and re-checks it, and spells out what the result does not prove. See the sample report, which uses made-up data.

A draft certification to accompany an exhibit

In progress

A draft, for a qualified person and counsel to review, edit and sign. It is not offered yet and will not be until a Texas-licensed attorney has reviewed the wording. Best Pay does not sign it or testify.

What every kind has in common: we seal what you give us and cannot tell you what it means. For files we seal a fingerprint, not the file. Sealing shows a record is unchanged since the seal. It does not show the record is true.

What a valid receipt proves

The sealed record is exactly as it was when it was sealed. Change any part and the check fails.
The record is covered by the signed ledger tip or Merkle root in the receipt.
The signature verifies under the public key shown in the receipt.
If you pinned the signer's public key, obtained from us by a separate route, the signer is the holder of that key.
With a timestamp token, the receipt existed no later than the time an outside authority signed.

What it does NOT prove

That the sealed file is true or genuine.
That the file was not altered before it was sealed.
Who made, wrote or sent the file.
Who the signer is, unless you pinned a key you trust. The checker says so every time you have not.
How the signing key was stored. A receipt alone does not show whether a key was held in hardware, so we state that in writing for your matter.
That a court will accept it. The court decides, and your lawyer decides how to use it.

Seal early. The most useful thing you can do is seal material as soon as it reaches you and write down where it came from.

Checking a receipt: only a public key

Three things are needed: the receipt, the signer's public key (an ECDSA P-256 key) and a browser. The check recomputes the hashes, follows the chain or Merkle proof, and verifies the signature. It does not call us, look anything up, or need our servers to be running.

In a browser: the verify page. Save the page and it works offline. Its content policy forbids network requests.
In your own software: a C++ header kit that verifies receipts using only a pinned public key. It checks only. It cannot issue receipts. Email to ask for it.

Two more honest points

The browser checker accepts ECDSA P-256 keys only. If it meets a format or algorithm it does not handle, it says UNSUPPORTED. It never says VALID for something it could not check.

A receipt on its own shows the time on the issuer's own clock. For an independent time, add a timestamp token from an outside authority. See the WORM ledger page.

Check a receipt Free pilot for Texas lawyers