The Problem of Proof of Delivery

A Checkmark Is Not Proof

Every day, millions of deliveries change their status to "Completed" or "Delivered". The courier clicks a button. The customer gets a notification. The system closes the task. Formally, that's it. The package is delivered, the service is rendered, the work is done.

But behind this checkmark lies a fundamental problem: in most systems, proof of delivery is just a database record, not actual evidence of the fact.

A record can be made from anywhere. From a warm office, from a car two blocks away, from home. It can be made an hour early or a day late. It can be made for a delivery no one has ever seen. And as long as everyone is happy, no one notices. Problems only begin when a dispute arises.

The Essence of the Problem

True proof of delivery must answer four questions:

• What was delivered or completed?
• Where exactly did it happen?
• When did it happen?
• Who recorded it, and can they be trusted?

Most existing systems only answer the last question—and only formally. "Employee #4572 clicked the button." But who clicked it? From where? What was actually in their hands? In what condition?

The problem is compounded by the fact that there are always at least three parties in the chain: the field worker (executor), the company (or intermediary service), and the end recipient. Each has their own interests. The recipient wants to ensure they received what they ordered. The company wants to ensure the employee actually did the work. The field worker wants to protect themselves from false claims.

And none of the parties have a tool that provides objective, verifiable, and immutable proof.

Who Suffers

The Field Worker. The courier, installer, sales rep, or service engineer. The person who physically goes to the address. When a claim arises—"not delivered," "went to the wrong place," "package was opened"—they are left alone facing the accusation. Their word against the customer's. And in most systems, priority is given to the customer because the customer pays.

The Company. Logistics operators, service departments, retailers. Every dispute means time spent investigating, paying compensations, and losing trust. Without objective records, it's impossible to tell a genuine mistake from fraud. Decisions have to be made based on indirect data and intuition.

The Recipient. The person waiting for the package or service. They cannot prove they didn't receive the delivery if the system says "Delivered." They cannot prove the packaging was damaged if there was no record at the moment of handover.

Existing Approaches

The industry has tried many ways to capture proof of delivery. Let's look at the main ones.

Paper Signature / Tablet Signature

The classic method. The recipient signs a paper manifest or the courier's device screen.

What it provides: a formal autograph.

What it fails to solve: doesn't record the exact location and time. Doesn't confirm the condition of the package. Isn't tied to the specific contents of the delivery. Paper manifests can be lost. An electronic finger signature on a screen lacks legal weight without additional infrastructure. The signature can be disputed: "That wasn't me."

SMS Code / PIN

The recipient tells the courier a code sent to their phone.

What it provides: confirms that the person with the recipient's phone was present during the handover.

What it fails to solve: the code can be dictated to anyone. Doesn't record the location. Doesn't confirm the package's condition. Doesn't protect against "I gave the code, but the wrong item was inside." Fails if the phone is dead or has no signal.

Photo in a Messenger

The courier photographs the package at the door and sends it to a chat or the app.

What it provides: visual confirmation that the package was at some location.

What it fails to solve: the photo can be taken anywhere and anytime. There's no tie to GPS coordinates. No tie to the specific delivery. No guarantee the photo wasn't taken earlier or elsewhere. The file can be swapped. There's no protection against retroactive editing.

CRM Checkmark / App Checklist

The employee fills out a form: "Delivered," "Customer accepted," "No issues."

What it provides: a structured record in the system.

What it fails to solve: it's a self-declaration. An employee can mark a delivery as done without ever visiting the address. The data is stored in the company's system and controlled by them. The recipient has no access to it and cannot verify it. A database record can be altered by an administrator.

GPS Tracking Without Photo Verification

The system tracks the courier's movement and records that they were in the vicinity of the delivery address.

What it provides: indirect confirmation of presence.

What it fails to solve: "being in the area" doesn't mean "delivered." It doesn't confirm the actual handover. It doesn't record the package's condition. GPS accuracy in urban environments can be off by dozens of meters. It doesn't protect against situations where the courier was nearby but never went inside.

Video Call / Video Confirmation

The courier video calls the recipient and shows the package.

What it provides: live visual contact.

What it fails to solve: the video recording is rarely saved. There's no tie to coordinates or the specific delivery. It doesn't generate structured data. It's hard to scale to hundreds of deliveries a day.

What Unites All These Approaches

Despite their variety, they share common weaknesses:

Dependence on the system. The data lives inside someone else's app or database. The user cannot extract it and verify it independently.

Lack of connection to reality. Most methods don't simultaneously record the location, time, and object. You either get a photo without coordinates, coordinates without a photo, or a checkmark with neither.

Mutability. Database records, files in messengers, screenshots—all of these can be edited, deleted, or swapped. And proving that a forgery happened after the fact is impossible.

One-sided control. The confirmation is recorded by the executor's system. The recipient receives no artifact they could use in a dispute.

Where the Solution is Heading

It's clear that proof of delivery shouldn't just be a record in a system, but a self-contained, verifiable, and immutable artifact that exists independently of the platform and can be checked by any party.

This requires three components:

Visual recording. A photo of the object at the moment of handover. Not just a "pic in a chat," but a snapshot tied to a specific delivery.

Context. Coordinates, time, delivery details. Everything that ties the snapshot to reality. Not separate, scattered data points, but a single package.

Integrity guarantee. A mechanism that makes it impossible to secretly alter the data after it's recorded. Such a mechanism exists: the cryptographic signature.

The approach where a photo, metadata, and a cryptographic signature are combined into a single exportable package is the next step in the evolution of proof of delivery. It shifts the focus from "the system says it's delivered" to "here is the proof, check it yourself."

Conclusion

The problem of proof of delivery is not a minor technical detail. It is the foundation of trust between the field worker, the company, and the recipient. As long as delivery confirmation is just a checkmark in someone else's database, any dispute turns into a conflict where the winner is whoever shouts the loudest or controls the system.

The solution lies in transitioning from records to proofs. From checkmarks to signed data packages. From "trust the system" to "verify it yourself."

This isn't a question for the future. The technology for this already exists. The question is who will start using it.

The Cryptographic Signature as Proof of Delivery

From Records to Proofs

In the previous article, we explored why traditional delivery confirmation methods fail as actual proof. Checkmarks in an app, signatures on a screen, SMS codes, and photos in messengers are merely records. They can be disputed, forged, or deleted. They are controlled by a single party and live inside someone else's system.

But if these methods don't work, what does?

The answer already exists in the legal and financial worlds. It is the electronic signature—a mechanism that turns digital data into irrefutable evidence. And it can be applied directly to the moment of physical delivery.

Why Cryptography?

For a record to become proof, it must possess three properties:

Immutability. Once created, the data cannot be altered unnoticed.

Verifiability. Anyone can confirm its authenticity without having to trust the creator.

Contextual Binding. The data must be tied to a specific location, time, and object.

Traditional databases do not provide these properties. A database record can be edited by an administrator. A screenshot can be faked. A file in a messenger can be deleted. Anything stored "by someone" is controlled by that "someone."

Cryptography shifts control from human hands to mathematics. An electronic signature is not just a checkmark. It is a mathematical operation after which the data becomes immutable. And anyone with basic cryptographic tools can verify this.

How It Works

At its core lies asymmetric cryptography. The system uses two keys:

The Private Key is secret and stored only by the signing party. It is used to create the signature.

The Public Key is open and available to everyone. It is used to verify the signature.

When data is signed with a private key, a unique cryptographic mark is created. This mark can be verified using the public key. If the data has changed by even a single bit, the verification will fail. If the signature is forged, it will fail. If the signature was created with a different key, it will fail.

Forging a signature knowing only the public key is impossible. It is not just a matter of complexity—it is mathematically impossible with modern algorithms.

What is Needed for Proof of Delivery

Proof of delivery consists of three components:

1. Visual Record. A photograph of the object at the moment of handover. This answers the question: "What exactly was delivered, and in what condition?"

2. Contextual Metadata. A set of data tying the photograph to reality:

• GPS coordinates of the point where the photo was taken
• A timestamp
• Order information (number, address, contents)
• The photo's hash (SHA-256)—a digital fingerprint of the file

Metadata answers the questions: "Where," "When," and "Which order does this belong to?"

3. Cryptographic Signature. A signature covering the entire metadata package. It answers the question: "Can this data be trusted?"

All three components together form a self-contained package. A photo without metadata is just a picture. Metadata without a signature is just text. A signature without data is meaningless. Together, they are proof.

Why the Photo Hash is Needed

The SHA-256 hash is a unique, fixed-length string computed from the file's contents. Even the slightest change to the file (a single pixel, a single byte) results in a completely different hash.

The photo's hash is included in the metadata before it is signed. This creates a chain: the signature covers the metadata, and the metadata contains the photo's hash. If someone replaces the photo file, the hash will change, and verification will immediately show a mismatch.

This prevents anyone from swapping the photo after signing while leaving the metadata intact.

What the Signed Package Guarantees

Data Immutability. After signing, it is impossible to change the coordinates, time, order number, or any other information in the metadata. Any alteration will invalidate the signature.

Photo Authenticity. The hash in the metadata matches the hash of the actual file. This means it is the exact photo that existed at the moment of signing.

Binding to Place and Time. Coordinates and timestamps are embedded in the signed data. They cannot be "tweaked" retroactively without breaking the signature.

Independent Verifiability. Verification requires only the package itself and the public key. No access to the system that created the proof is needed. No account is required. There is no need to trust the creator. The verification is mathematical, not based on trust.

How Verification Works

The verification algorithm consists of four steps:

Step 1: Verify the signature. The signature file and the metadata file are taken. The public key (embedded in the signature or obtained separately) is used for verification. If the signature is valid, the metadata has not been altered.

Step 2: Decode the metadata. The metadata file is decoded into a readable format. Inside are structured fields: the photo hash, coordinates, time, and order details.

Step 3: Verify the context. The metadata fields are checked. The coordinates must match the delivery address. The time must fall within a reasonable window. The order number must match the task.

Step 4: Verify the photo. The hash of the actual photo file is computed and compared to the hash in the metadata. A match confirms the photo's authenticity.

If all steps pass, the proof is valid. The delivery took place at the specified location, at the specified time, for the specified order, with the specified photo. And this can be proven to anyone.

What This Changes for All Parties

For the Courier. The "word against word" situation disappears. When a claim arises, there is no need to make excuses or look for witnesses. There is a signed package. It can be presented, and the dispute is closed. The courier is protected from false accusations.

For the Company. An objective tool for resolving disputes appears. There is no need to guess who is right. The package is either valid or it isn't. This reduces the number of unjustified compensations and protects against fraud from both clients and employees.

For the Recipient. A guarantee appears that delivery data will not be altered retroactively. If the package is damaged, it is captured in the photo and protected by the signature. If the delivery did not take place, the package simply does not exist. No checkmark in the system will say "delivered" if there is no physical proof.

Why This Works Where Databases Fail

One might ask: why use cryptography? Why not just store photos and data in a secure database?

Because a database is controlled by its owner. An administrator with access rights can change a record. A company can delete data. A service can shut down, and all records will vanish. In any centralized system, whoever controls the system controls the data.

A cryptographic signature shifts trust from the system to mathematics. A signature cannot be "asked" to say something else. You cannot call it, pressure it, or fire it. It either matches, or it doesn't. And this does not depend on who stores the files, who owns the servers, or who controls the app.

The package can be copied, transferred, and archived. It works exactly the same way a day, a year, or ten years later. It does not depend on the existence of the company that created it.

Where This is Applied

This approach is already used in industries where irrefutable proof is critical:

Insurance. When documenting claims, photos with metadata and signatures are accepted as evidence without additional expert review.

High-Value Logistics. When transporting valuable goods, every stage is recorded with signed packages to eliminate disputes over damages.

Field Service. When performing warranty work, a signature confirms the fact and scope of the work completed.

Legal Proceedings. Signed electronic documents are accepted by courts as evidence.

Applying the same approach to standard delivery is not inventing something new, but using a proven mechanism in a new domain.

Technical Implementation

In practice, it looks like this:

A field worker takes a photo via the app. The app automatically collects metadata: GPS coordinates, time, task information, and computes the photo's hash. All of this is sent to the server.

The server signs the metadata with its private key. The signature and public key are added to the package. The finished set (photo + metadata + signature) is returned to the app and can be exported.

The entire process takes seconds. To the field worker, it looks like taking a normal photo. All the cryptography works in the background, automatically.

Limitations

It is important to understand that a signed package does not solve every problem:

It does not confirm the contents. If the photo shows a closed box, the package does not prove what is inside. It only proves the fact that this specific box was handed over at this place at this time.

It does not replace inspection. The recipient still needs to check the goods. The package records the moment of handover, not whether the contents match the order.

It requires file storage. If the package is deleted, the proof is lost. Like any digital artifact, it requires storage.

But what it does do—turn a record into proof—it does flawlessly.

Conclusion

The problem of delivery confirmation is fundamentally a problem of trust. As long as confirmation exists only as a record in someone else's system, trust is based on the honesty of the system's owner. And honesty is an unreliable foundation for business.

The cryptographic signature changes this model. It shifts trust from human hands to mathematics. A package containing a photo, metadata, and a signature is not a record of delivery. It is proof of delivery. Self-contained, verifiable, and immutable.

The technology for this has existed for a long time. The algorithms have been proven by decades of use in the banking sector and government systems. The question is not whether this is possible. The question is when the delivery industry will transition from records to proofs.

And that transition has already begun.