teaconf

For some time now, you know that I have been reading and researching Ricardian Contracts. I have discovered a definition of trade that I had never really thought about before—and, as far as I remember, it is not something that is taught in schools either. In Ian Grigg’s (@iang_fc) approach, the rights and obligations underlying commercial and, in particular, financial assets are essentially defined by a contract. If we broaden this perspective a little, a very large part of economic life, from opening a business to the employment contracts of workers, operates through contracts. If we take this a little further, we can even consider everyday commercial documents, such as a retail receipt, as part of a contractual relationship. In the final part of this article, I will try to explain the Ricardian approach through the example of a retail receipt. Contracts are easy to apply in everyday life. Digital assets, however, are not so straightforward. Digital assets can be represented using different names, symbols, and technical definitions. Therefore, what exactly the buyer is purchasing needs to be documented through a contract in a legally appropriate manner. Ricardian Contracts aim to address this problem. A Ricardian Contract is a contract that clearly defines what a digitally traded asset is, what rights it gives to its owner, and what conditions it is subject to. It is readable by humans and verifiable by machines. Dr. Wright (@Dr_CSWright) has been trying to instill three important ideas in us for years: Code is not law. Possession of a key does not prove ownership. Governments will always exist, and courts will continue to issue judicial decisions. If we take Ian Grigg’s approach together with what Dr. Wright has taught us, then the real issue in digital commerce is not merely recording an asset on a blockchain or controlling it through a key. The real issue is to clearly define which legal rights and obligations that asset represents and to establish a reliable record that courts can evaluate when assessing those rights and obligations in the event of a dispute. Whether you are a developer, a buyer, or a seller, if you are creating, issuing, or purchasing a digital asset, you first need to clearly define what that asset represents and conduct the transaction according to that definition. As long as governments exist and courts continue to operate, this legal dimension of digital commerce will not disappear. Ultimately, digital assets are not an area where we can simply do whatever we want, disregard the law, and assume that we will never be held accountable before a court. Let’s move on to retail receipts. In a broad sense, a sales receipt can be evidence of a contractual relationship, but it would not be correct to say that the receipt itself is the contract. Let’s continue with the supermarket example. A sales relationship arises between the buyer and the supermarket. The supermarket offers a particular product at a particular price. The customer purchases the product and makes the payment. The sales receipt can show what was purchased and how much was paid, but it cannot by itself contain the entire legal and commercial meaning of the sales relationship, including the product’s warranty terms, return conditions, the buyer’s rights, and so on. So, if we approach this product from a Ricardian perspective, can we establish a verifiable contractual relationship between the sales receipt, the product sold, and the rights and obligations arising from that sale? Yes, we can. In fact, there are many working applications that already do this. The existence of working applications does not prevent us from working in this area as well. On the contrary, existing applications can be seen as evidence that there is a need and a market for such solutions. We can modify them, transform them, and, if necessary, compete with them... We can design a model in which the idea of a Ricardian Contract is applied at the product level. There could be a product information document containing details such as the product name, manufacturer, product code, production date, etc., together with a contract specifying the warranty, return conditions, the buyer’s rights, and other terms. A hash of this contract could then be generated. A QR code could direct the user to a link where the contract terms and the blockchain record could be displayed. Anyone who wishes could verify the record. The sales receipt could then state that, for XXX USD, a product or products identified by a specific identity and subject to a specific contract were sold. In this way, a verifiable cryptographic bridge could be established between the physical piece of paper and the cryptographic contract. The hash or record on the blockchain alone does not guarantee that “this document is legally valid,” but it can form part of a strong chain of evidence showing that the contract existed with a specific content at a specific point in time and that the parties carried out a transaction associated with that contract. A chain of evidence consisting of product + contract + sale + history could be established. “For those who say, ‘This is not enough for me; I want more,’ I can theoretically offer an even longer chain.🙂 Product Lifecycle: raw material + source of the raw material and production conditions + manufacturing + quality control and certifications + supply chain + storage and logistics + sale + warranty + maintenance and repair + resale + recycling or disposal. In short, there seem to be many opportunities in the field of contracts. It is an area worth experimenting with and, if necessary, worth failing in. If you primarily target small and medium-sized businesses and freelancers, your chances of success may increase. Large companies can afford the high costs of such services, whereas small businesses and freelancers may struggle to access them.