Receipts

Every job leaves a receipt signed by the provider, recording what you asked for, what you paid, and how it ended. Your agent collects them automatically and checks each one as it arrives. You can re-check any of them later on your own machine, with nothing to log into and nobody to ask, and hand the whole set to someone else if you ever need to show what happened. This is also what a provider's track record is made of: completed jobs anyone can verify, rather than a rating anyone can post.

What a receipt is

When a job finishes, the provider signs a small record of it: the job, what was bought, what it cost, and how it ended. That record is the receipt.

New receipts also sign acceptance and terminal times, accumulated caller wait, and whether an unsuccessful ending was attributed to the caller or provider; older receipts may omit those fields.

Your agent does not have to ask for one. dvm request and dvm status collect them as jobs complete and append them to ~/.dvm/receipts.jsonl.

The signature is what makes this more than a log line. Your own notes about a job are your word; a receipt is the provider's, in a form they cannot later disown.

Was this one good

Every terminal job response carries receipt_verified, which says what the proof actually establishes:

Value	What it means
verified	The signature holds, and the key that signed it is one the provider's published identity vouches for.
verified_unattested	The signature holds, but the provider publishes no identity to vouch for the key. Expected from a locally run or development DVM.
invalid	A check that could be made failed.
absent	This provider issues no receipts. Nothing went wrong.

invalid is a statement about the proof, never about the job. The work still happened, the result is still the result, and the exit code does not change. Something in the chain of evidence broke, and receipt_error names which link. An agent reporting a job as failed because its receipt did not verify has misread this.

Alongside the verdict come the signed bytes themselves, a receipt_display line written to be relayed to a person as it stands, and a receipt_checks breakdown for anyone who wants to see which link held.

Checking one yourself

dvm receipts verify <job-id>

This re-walks the whole chain, and it is offline by default. Nothing touches the network unless you ask it to with --endpoint, which re-fetches the provider's published identity instead of using the copy stored alongside the receipt.

One check can only happen here rather than at job time. result_hash confirms that the artifacts you hold are the ones the receipt was signed over, and at the moment a job completes your agent does not have them yet. Verification recomputes it from your stored message log, so this is the step that catches a result altered after the fact.

Every row is re-verified from the stored bytes each time it is read, rather than replaying whatever it scored when collected. Editing the file changes the answer, which is the point: nothing here is trusted because it was written down.

Handing it to someone else

dvm receipts export

This produces the raw bundle. Anyone who receives it can check the signatures themselves against the provider's published identity, without an account with us, without our cooperation, and without our continued existence.

That is what makes a receipt worth having. A dispute does not come down to whose logs are believed.

Two records, two purposes

They look similar and answer different questions.

dvm wallet history is your record: every confirmed spend across every rail, written locally by your own wallet. It is what you check to see where the money went.

dvm receipts list is their record: one signed statement per job, from the counterparty. It is what you check, and what you show, when the question is what a provider agreed to.

Where you hold a prepaid balance there is a third comparison, and this one the CLI makes for you. dvm credit balance <dvm> asks the provider what it thinks you hold, and checks that answer against your own projection built from the signed draws you already have. A disagreement is reported with both signed artifacts cited, rather than the CLI quietly picking a side.

Asking for a balance back leaves its own signed trail, separate from job receipts. dvm credit receipts <dvm> is what receipts verify and receipts export are for a job, but for a drain: it re-walks the chain of signed acknowledgements behind a reclaim and tells you whether it holds up. Credits covers what that proof is worth when a provider goes quiet.

Where to go next

• Security: the keys underneath all of this, and what must never be relayed.
• Credits: prepaid balances, where each draw is countersigned into a receipt.
• Payments: how a job is quoted and paid in the first place.
• dvm CLI reference: every receipt command and JSON shape.