Verify a file and its receipt
Check who issued the receipt, whether the bytes match, and which publication assurance was recorded.
On this page
Keep the file and receipt together
A received file has a .vot-receipt sidecar, for example Final cut.mov.vot-receipt. Delivery pages offer receipts separately from the payload files. Keep the receipt with the corresponding file if you need later verification or a retained handoff record.
The receipt includes the object’s cryptographic root and length, publication assurance, commit profile, session information, and observation time. It is signed with the deployment’s Ed25519 receipt key.
Check the receipt and the file
- Open
/verifyon the deployment that issued the receipt. - Select or drop the receipt and its corresponding file.
- Start the check and wait for the file to finish hashing.
- Read both the signature result and the file-match result.
The receipt is sent to the deployment for signature checking. The file is read and hashed locally in your browser; its contents are not uploaded. Large files take time to read from disk, particularly from network storage or a removable drive.
You can check a receipt on its own. That establishes whether the server issued it, but does not establish that a file on your disk matches it. Include the file for that second check.
Interpret the result
| Result | Meaning and next step |
|---|---|
| Receipt is genuine and file matches | The issuing key validates the receipt and the current bytes have the recorded identity. Retain both if the result is part of your handoff. |
| Receipt is genuine, no file selected | The signature checked. Select the file to establish its contents match. |
| File does not match | You selected different, incomplete, or altered bytes. Check the pairing, then obtain a fresh verified copy if needed. |
| Receipt was not issued by this server | Check that you used the original deployment. A different or rotated signing key will not validate the receipt here. |
| Receipt cannot be checked | Confirm it is the complete original sidecar. Keep the error details for the issuing team. |
A filename alone is not evidence of a match. A receipt proves one exact content identity, even if another file happens to have the same name.
Read evidence from an automated delivery
The automation API and MCP tools expose each delivery file’s content identity, size, and receipt_b64 (a base64-encoded CBOR receipt). Retain these records with the operation ID when your workflow needs traceable handoffs.
An outbound-library receipt attests to the source object. Download counters report starts, not confirmation that a recipient finished or verified a local copy. Project job evidence separately exposes signed recipient verification and explicit acceptance for the exact package.
Confirm recipient verification and acceptance
VOTPort records three different kinds of evidence:
| Record | What it establishes |
|---|---|
| File receipt | The signing deployment's recorded object identity and publication assurance. |
Recipient verified statement |
The device attests that it verified the exact ordered package. |
Recipient accepted statement |
The device explicitly accepts that same package. Verification alone never implies acceptance. |
The ordered manifest commits to every filename, VOT hash suite, object root, byte length, and position. The server signs an authorization binding that digest to the grant, server origin, recipient device key, nonce, and validity window. The recipient signs verification and acceptance separately. Changing the manifest or statement kind invalidates the signature.
Native recipients
After a native HTTP or QUIC receive verifies and publishes the local files, it queues a signed verification report. In Workflows, review Recipient verification and acceptance, then choose Accept verified delivery and confirm the manifest when you intend to accept it.
Reporting uses a durable outbox separate from the transfer journal. A temporary reporting failure does not require downloading the files again. The running client submits batches of up to 16 every minute and removes a queued statement only when the server acknowledges its exact ID. Use Retry pending reports or the client CLI to flush a batch:
votport evidence device-key
votport evidence list
votport evidence retry
votport evidence accept VERIFICATION_ID
A short CLI transfer may exit before its background report finishes. Inspect the evidence status and retry if needed. The acceptance command is an explicit recipient action, not an MCP tool that an agent performs implicitly.
Browser recipients
A download click cannot establish which bytes were saved. On the delivery page, open Verify saved files and accept this delivery, choose the saved payload files, and let VOTPort hash every expected file. If you downloaded a ZIP, extract it first and select the payloads. Acceptance becomes available after verification succeeds; confirm it separately.
The browser keeps a nonextractable device key and queued evidence in IndexedDB. Clearing site data removes that identity and local history. Browser and native keys are separate; use the device enrolled by the project administrator for recipient-restricted deliveries.
Retain and interpret the record
Inspect signed evidence in the workflow's browser history or export it as JSON. The automation API exposes it at GET /api/workflows/jobs/{id}/evidence, and MCP provides get_job_evidence.
Authorizations last seven days. A new signed report can arrive after share expiry or revocation while its authorization is still valid. An already-recorded statement can be acknowledged again after authorization expiry; a new expired statement is rejected. Duplicate submissions do not produce duplicate verification or acceptance events.
These are statements made by a device. The administrator's enrollment maps its key to an email address; the signature alone does not prove a person's identity or prevent a modified client from making a false statement. Retain the trusted issuer key, signed records, and enrollment context with the project.
Follow custody between VOTPort deployments
A signed trade route records the source manifest and the destination port's signed custody receipt. Forwarding retains verified ancestry. Export these records from the job's destination entry or the receiving port's Trade route controls.
Custody confirms a signed deployment-to-deployment handoff. It is separate from a recipient's explicit acceptance and does not strengthen the file receipt's storage profile. Preserve the trusted issuer keys and original signed records when the history must remain verifiable later.
Trust the issuing key
The deployment exposes its public receipt key at /api/receipt-key and in the operator interface. Obtain it over a trusted connection or directly from the deployment owner.
For records that must outlive a deployment or key rotation, preserve the verifying public key alongside the receipt and document how you obtained it. A signature proves possession of the corresponding private key; an unfamiliar key does not establish the issuer’s identity by itself.
Understand publication assurance
The receipt records the actual commit profile. Supported local receive filesystems use Balanced. Qualified Linux SMB3/CIFS and NFSv4 receive mounts use Balanced with provider POSIX_NAS (0x0005). This records server-acknowledged durability under the administrator-confirmed storage contract, not physical-media readback or appliance power-loss certification. Unqualified or replaced NAS mounts stop receiving. See direct NAS receiving.
An outbound-library receipt uses Fast for existing files and does not attest to a newly durable write. Read the recorded profile instead of assuming every receipt has identical storage guarantees.
VOTPort’s service and storage handle readable file contents; it is not an end-to-end encrypted vault. Configure encryption at rest on the underlying infrastructure.
Cryptographic verification does not inspect a file for malware. Projects can separately require media checks and malware scanning. Verification does not prevent future storage damage. It lets you detect whether the bytes still match when you check them again. Keep file backups, access controls, and any required content scanning in your operating policy.