top of page

Portal Focus - May/June 2021


A Smart Contract for Trustless Payments in the Moving Industry

By Alvaro Stein, Director, Decapack

Best Practices (and Pitfalls) in Tech Adoption

The term “Smart Contract” was first coined by Nick Szabo, an American computer scientist, more than 2 decades ago. Later he regretted using those words because they don’t reflect the nature of this type of software. There is nothing particularly smart about them, and the word “contract” predisposes people to think in legal terms. A Smart Contract can be any software or algorithm involving digital transactions between parties (“if this happens, then that transaction between A and B occurs”). They deserve a memorable name because they “run” on the same transformative technology that runs Bitcoin: blockchain.

Like Bitcoin, Smart Contracts run synchronically in a global and open network of computers from people like you and me. You don’t need to understand blockchain technology to believe in its wonders, just like you probably don’t know how the Internet works but can’t live without it. Bitcoin is the best demonstration of the technology features:

  • Owned by no one (no central authority).

  • Indestructible.

  • Un-hackable (try stealing a Bitcoin).

Just as it is impossible to steal a Bitcoin, it is impossible to stop a Smart Contract from executing when the conditions are met. A Smart Contract is, therefore, like an unbreakable promise. The parties don’t need to trust each other when signing one because it can’t be broken. It is trustless.

Does the concept of trust in our industry—or the lack of it—sound familiar? Do you trust that all your clients and agents will pay you on the agreed terms? Can you give 30 days’ credit to an unknown or untrusted agent or client? How much time and money you spend on disputes?

Let’s say we write a simple program to automate the following payment agreement between a client (or booker) and an agent: “The Client will have 5 days to approve or dispute an invoice from the Agent. If the Client does not make a decision to the contrary, then the invoice is automatically approved, and funds will be transferred from the Client’s bank account to the Agent’s bank account in 30 days.”

It sounds simple, but there are some challenges that any typical software cannot overcome. In traditional architectures, you would need a technology vendor, in-house or third-party, to develop and support it. This vendor will hold the single key, or the “big red button,” to shut it down. Like any software, it will be as secure as the expertise of the development team. You’d need access to the bank accounts, which adds to the security challenge and introduces other parties in the process (banks). The trust factor is not eliminated; it just shifts away from the counterparty to the technology vendor.

If that payment agreement is built and stored on a blockchain, it would be called a Smart Contract. It’s not owned nor controlled by a single entity. There is no “big red button.” It cannot be stopped, hacked, or destroyed.

If you and your client sign that “Payment Smart Contract,” you will receive the money 30 days after approval of the invoice, no matter what.

Would your client or agent agree to sign it? If they do, then trust is not necessary because you know the software will execute. If they don’t, you definitively can’t trust they will fulfill their promise to pay in 30 days.


bottom of page