Blockchain And Smart Contracts In Retail

Introduction

Blockchain has recently celebrated its tenth anniversary, but for many in the retail sector, it is still seen as "something for the future". However, many retailers and tech companies are actively looking at ways to deploy blockchain technology (and its close relation, smart contracts) in their business. A recent report by the UCL Centre for Blockchain Technologies analysed 105 different projects across the US, EMEA and Asia using blockchain in some form in the supply chain (of which 15% are already in production)[1].

Two of the key use cases that are being widely discussed in the retail sector - and the focus of this article - relate to product provenance and supply chain management. However, retailers are exploring other use cases, from revolutionising loyalty programmes and digitising product warranties to potentially allowing for the development of peer-to-peer marketplaces that could compete with the likes of eBay, Uber or Airbnb.

What is blockchain?

Before discussing what blockchain might offer to the retail sector, it is worth understanding some of the key features of blockchain technology and smart contracts.

There isn't space in this article to discuss these topics in detail but if you are interested, here is a good video (and report) to start with.

For our purposes, it is enough to say that blockchain offers a different way of storing and sharing data between multiple participants in a network (like a retailer's supply chain).

Figure 1: Decentralised ledger

One of the key challenges with sharing any data within a big network is knowing that you can trust the data to be accurate and up-to-date (and that no-one has tried to falsify the data for their own purposes).

This trust is traditionally achieved by the data being held in a centralised database hosted by one participant that acts as a "single version of the truth" (i.e. just like our bank balances are determined by the "ledger" maintained by the bank).

Blockchain looks to create trust within a network in a different way. Rather than there just being a single master copy of the database, each participant in the network holds their own copy of the same database (see figure 1). That is why blockchain is referred to as being distributed or decentralised.

As everyone in the blockchain network has an identical copy of the database, each participant knows with confidence that "what I see is what you see".
One of the other key aspects of this "distributed database" system is that once a new entry in the database has been agreed by the network (through a consensus model that I won't go into here), it is very difficult to edit or erase that data. The database can be updated with new entries, but the full history of all transactions in the database is, in effect, etched in stone and can (in principle) always be viewed by the participants in the network at all times.

(Incidentally, this is where the name "blockchain" comes from. Each transaction forms a "block" in an unbroken "chain" of other transactions. If someone tried to fraudulently tamper with the data on the blockchain, the "chain" would be broken and the fraud would be discovered).
The key implications of this are:

• all participants in the network know that they can trust that the data held on the blockchain can't be erased or changed by any one participant for their own benefit; and

• as details of all transactions are retained on the blockchain, a full audit trail of all transactions is retained at all times.

Blockchain networks can either be "permissionless", which means they are open to any member of the public that wants to use them (like Bitcoin) or "permissioned". Permissioned blockchains are hosted on private computer networks and access is limited to a closed circle of participants (like members of a specific supply chain).

How is blockchain relevant to the retail sector?

Use case 1: Product provenance

Many retailers are currently being pulled in two competing directions – their supply chains are becoming ever more complex and globalised in an effort to keep pace with the "everything now " demands of the modern consumer, while they are also faced with an ever-increasing pressure to provide more detail and transparency over the provenance of their products. Examples of the latter include:

• consumers demanding more information on issues such as potential allergens and specific dietary requirements;

• the desire to provide greater information on fair trade and environmental initiatives;

• the ability to respond more effectively to product recall situations (such as the 2018-9 concerns in the US regarding the risk of e-coli being present in romaine lettuces grown in certain parts of California);

• the ongoing battle to prevent the sale of counterfeit goods; and

• the need to comply with legislation such as the UK Modern Slavery Act 2016 (which requires companies to protect against the risk of slavery or human
trafficking in its supply chains).

Blockchain proponents argue that this technology can help retailers to rise to these challenges.

Use case 2: Supply chain management

Another use case relates to the management of retail supply chains generally. As noted above, many retailers' supply chains are becoming more complex. And yet, many supply chains are still based around paper documents (e.g. many port authorities will require a physical bill of lading).

As described in a recent article by Wired [2] :

Shipping a container of avocados from India to the Netherlands, say, involves dozens of people and businesses. Farmers need to drop off the avocados, boats need to pick them up, regulators need to sign off on the container's contents, and someone needs to make sure that the fruits haven't gone bad. Most of these handoffs and communications are still done via analog technology.

A 2018 report by the Economist identified some of the problems that this is causing, including:

• delayed deliveries – over 65% of US importers surveyed said that more than a quarter of their deliveries from abroad arrive late;

• excessive paperwork – 42% said that they spent more than 2 hours on paperwork to arrange a shipment; and

• lack of visibility - 83% said they struggle to track items as they move across the world.

The same report noted that putting all of the Asia-Pacific region's trade-related paperwork online could:

• slash the time it takes to export goods by up to 44%;

• cut the cost of doing so by up to 31%; and

• boost exports by as much as $257bn a year.

A further problem is that, even when supply chain data is held in digital form, each participant in the supply chain may be working off its own data system. This fragmented approach makes it very difficult for a retailer to have a clear overall view of its supply chain and often makes it impossible to accurately track products from the factory to the store.

As above, proponents of blockchain technology argue that it may be key to this problem.

How it works in a nutshell

Many supply chain blockchain solutions are in an evolutionary state. The UCL report mentioned above notes that nearly half of all the projects they surveyed are in a pilot or proof of concept phase. However, some outlines of how blockchain could work in a supply chain context can be identified – see figure 2 below:

Figure 2 – An example of blockchain being used in the supply chain

Three fundamental issues

In our view, there are three fundamental issues that will impact on how successfully blockchain technology will address the use cases identified above:

How to ensure that the data originally entered on the blockchain is accurate

As noted above, one of the key attractions of blockchain is that it is very difficult for data held within it to be edited or erased. However, as discussed in an article by the Financial Times on the shortcomings of blockchain: "The integrity of data on a public blockchain can be trusted not to change, but that says nothing about whether the data is right in the first place"[3].

In other words, blockchain technology can do little to stop a supplier who is willing to create (for example) falsified data about whether a bluefin tuna is from a sustainable source or whether a consignment of cocoa beans has been purchased in accordance with fair trade requirements.

But this simply reflects the reality that in any transaction that relies on human beings, it is unlikely that any technology will be able to completely eliminate the risk of human error (or deviousness).

In some circumstances, a blockchain system may be able to eliminate scope for human error or fraud by taking data directly from a reliable, objective source. For example, if a shipment of avocados needs to be transported in a chilled environment, it may be possible to combine a blockchain system with the so-called "Internet of Things" technology so that an internet-enabled temperature sensor is able to monitor the temperature of the shipping container. This data can be recorded securely on the blockchain without the need for human intervention. This would then provide an objective and auditable record of the condition of the shipment throughout its transit.

How do you link a physical product with data recorded on a blockchain?

While digitisation is an increasing trend in the retail sector, there is obviously a limit to this where the retailer is selling physical products to their customers.
Accordingly, a key challenge for any blockchain system is how to ensure there is a stable "match" between a physical product and the data relating to it on the blockchain. There is much talk of the record of a physical product on the blockchain being a "digital twin" of the product itself, but how do you ensure this?

Some blockchain solutions propose using a QR code (see figure 3) which would be physically attached to the relevant product (e.g. in the inside pocket of a luxury handbag). Other solutions have proposed using a RFID chip - similar to the chips used in marathons to track the pace of runners.

Figure 3: QR code

In practice, this raises two separate questions:

• how do you ensure that the "tag" on the physical product (whether it is a QR code, a RFID chip or something else) is not tampered with or itself counterfeited? This is not just a hypothetical question – if a counterfeiter is sufficiently skilled to be able to copy a luxury handbag, they will likely be able to copy a QR code. If a counterfeiter is able to copy the "tag", then it is unlikely that the blockchain solution will be able to distinguish between the real product and the fake one as they will both have identical "tags" in them.

• how do you effectively "tag" a physical product that will change during the supply chain? In their report, the UCL Centre for Blockchain Technologies used the following examples to illustrate this point: 

One answer to these difficulties may be in the emerging field of nanotechnology. For example, IBM is developing a range of technologies called "crypto-anchors" – tiny computers or other technology which can be physically embedded into products [4].

How to build a blockchain ecosystem?

If you have decided to investigate a blockchain supply chain solution, another question quickly presents itself: do you build your own solution or do you partner with others (perhaps your competitors) to build a shared ecosystem? There are obvious risks inherent in both approaches.

If you build your own solution, you are gambling that you will be able to persuade the other participants in your supply chain (which may be dozens of different companies) to use your new supply chain platform. This may not be straightforward – there may be substantial costs involved, and the relevant suppliers may also be facing pressure to prioritise competing solutions from other retailers. While some retailers (such as Walmart [5]) have had success in requiring their suppliers to implement their nominated blockchain solution, not many retailers will have enough leverage over their suppliers to mandate this. Clearly, the more "gaps" you have, the less likely that you will have end-to-end traceability of your products (and therefore, the business case for the blockchain solution may erode).

On the other hand, establishing a consortium to build a common blockchain solution is not likely to be straightforward either. Libra (Facebook's cryptocurrency) is a case in point – several of the original participants, including PayPal, Visa, Mastercard, Stripe and eBay have pulled out of the project since its inception.

One of the core problems relates to how governance of the consortium will work in practice. Some practical questions include:

• How will decision-making between the consortium work?

• What contractual relationships will exist between the participants?

• How are new participants incorporated into the consortium?

• Who owns the IP in the blockchain technology (see further below)?

• How will individual data be managed? Who gets to see what data? What can they do with it? Who can they share it with?

All of these issues can be difficult to agree, particularly between potential competitors. There have been recent news stories regarding blockchain consortiums where later participants feel like they are not on an equal footing to the founding members of the consortium due to the way in which the governance rules are structured.

Some other legal issues

Data protection

The interface between blockchain technology and data protection legislation is going to be complex on any blockchain project.
The problem is neatly summed-up by Michèle Finck, Oxford EU law lecturer and senior researcher at the Max Planck Institute (as referenced in the Financial Times)[6] :

The GDPR was created for a world in which we have centralised data silos that collect, store and process data. Blockchains essentially decentralise all of those processes. So you certainly can’t deny there’s a tension between GDPR and blockchain, because they represent different visions of what the database is. As a result, it’s very hard to figure out what a GDPR-compliant blockchain would be.

The GDPR makes no specific reference to blockchains and, as at the date of publication, no EU member state has yet enacted any data protection legislation that makes any specific reference to blockchain technologies.

Some of the data protection-related issues that are relevant to blockchain are:

• how do you determine who the data controllers are in a decentralised system?

• similarly, how do you regulate cross-border transfers of data in a system where data is decentralised and cannot be "controlled" in the same manner as traditional IT systems?

• how do you reconcile the "right to be forgotten" principle within the GDPR against the foundational principle of blockchain that all data is stored immutably?

One obvious solution is not to store any personal data on the blockchain itself, with any personal data being stored "off ledger". Another option, proposed by CNIL, the French data protection authority, is to try to use encryption technologies to make the underlying personal data practically inaccessible. However, such a proposal does not necessarily solve the conflict but merely mitigates its impact. For now (and until further guidance on this point is published by regulators), the law and technology are in conflict with no regulation in force to determine how to solve this conflict.

Please see our blockchain report for further information on these issues.

IP issues

A key question in most use cases will be who owns the IP in the blockchain technology?

The blockchain platform will likely comprise two key elements:

• the back-end blockchain software that determines how data is recorded on the distributed database; and

• the user-facing app.

The back-end blockchain software will often be pre-existing software that is used by the blockchain developer to service multiple clients. The user-facing app will often be bespoke software developed for the particular use case.

The user-facing app is what each participant accesses to send transactions for recording onto the blockchain (the recording of the transaction on the blockchain is undertaken by the back-end blockchain software). The user-facing app will interoperate with the back-end blockchain software via APIs. One of the key IP battlegrounds is who owns the IP in the user-facing app.

In short:

• will the IP be retained by the blockchain developer (as it has been built specifically to be compatible with its back-end solution)?

• should it be owned by the customer (who has paid for the work specific to its use case)?

• where there is a consortium, should the IP be owned by the "lead" member of the consortium (who may have borne the bulk of the risk and cost of establishing the consortium and the development of the relevant IP) or should it be owned collectively by the consortium members (likely via a special purpose vehicle)?

Regardless of who owns the IP in the user-facing app, it should, where possible, be developed in such a way that it can be possible (with minor changes) for it to interoperate with other blockchain solutions, otherwise you have the risk of "lock-in" to the blockchain developer’s solution.

Competition

A blockchain consortium may also raise competition issues. For example:

• A key principle of competition law is that competitors must not exchange competitive sensitive information about prices, customers etc. and must make their commercial decisions independently of each other, without sharing information that might reduce competition. Accordingly, the blockchain platform would need to be carefully designed to avoid any concerns about potential collusion, particularly about the extent to which participants will have visibility of the entire blockchain data (and therefore potentially of each other's transactions).

• Another possible risk is whether the rules of a particular blockchain platform could restrict competition (e.g. if only certain market participants were permitted to join or if discriminatory rules were imposed on members). In such cases, the blockchain platform (particularly if it is successful) could act as a barrier to market entry or an impediment to competing effectively in a particular market. Again, the rules of the blockchain platform would need to be devised with care, in order to create a level playing field for all competitors.

Competition authorities are already focusing their attention on competition in digital markets, and the UK authorities recently fined a company that provided a platform for two competitors to share customers and markets.

Smart contracts

As discussed above, the typical supply chain involves lots of paperwork and management time to operate and execute the various contractual arrangements and arrange each of the payments involved. Can blockchain technology solve this too?

Many people think that "smart contracts" are a key part of the solution to this problem.

In essence, a smart contract is a way for a legal contract to be executed automatically without human intervention. To achieve this, the terms of the legal contract (e.g. for the shipping of products from A to B) are reduced to their simplest form, typically based on a formula of "if X happens, then do Y". (For example, "If the products are delivered by X date, then pay the supplier £Y").

This simple formula can then be translated into computer code and stored on the blockchain platform. The blockchain platform will be updated as the products are delivered and accepted and payments will be made automatically on the performance of these contractual triggers. In theory, the fact that there is an immutable copy of the contract stored on the blockchain, as well as a record of when contractual milestones are achieved, means that there is likely to be less scope for disputes about the terms of the contract and whether they have been performed.

However, there are a number of practical and legal issues relating to smart contracts.

Are smart contracts limited to simple situations?

As mentioned above, in order to be reduced to code, the terms of smart contracts need to be capable of being articulated in a precise way (i.e. the "if X happens, then do Y" formula). This is likely to mean that the smart contract framework will struggle to cope with more complex contracts, including where there is an element of human judgement required.

In a retail supply chain, complex or bespoke supply contracts may not be capable of being reduced to smart contract code. Smart contracts may also be better suited to situations that will be fulfilled over a short timeframe, as most smart contract frameworks will not be flexible enough to accommodate the inevitable changes in external events or laws that will occur over a longer duration. However, for many retailers, this still leaves a potentially large number of straightforward "repeat business" supply contracts that may be capable of being streamlined through the use of blockchain technology and smart contracts.

As an aside, some commentators have noted that traditional contracts contain a number of concepts – such as "good faith" or "reasonable endeavours" – that will be difficult to translate into a smart contract framework. While these concepts can serve a useful purpose in long-term, relational contracts, I suspect not many readers will shed a tear if these are a casualty of the development of smart contracts. It is also worth noting that, in the slightly longer term, it is conceivable that AI may develop to a stage which it is able to provide the necessary "intelligent judgement" to fill in the gaps here.

How will the parties ensure that the contract says what they want?

Many businesses rely on their legal teams to explain and confirm what their contracts "mean". However, current "analogue" contracts are at least still written in something approaching normal language (most of the time anyway!). With smart contracts, how will the parties be able to get comfortable that the final version accurately reflects their intentions?

I suspect that most businesses will want to have a natural language "translation" of the smart contract code. The question that then arises is if the smart contract code and the natural language version don't match, which version prevails?
Strictly speaking, the smart contract code will logically be the controlling document (as these are terms that will actually be executed). On this, it is interesting to note that the Terms of Service of an infamous smart contracting project called The DAO explicitly stated that any human-readable documents were "merely offered for educational purposes and do not supersede or modify the express terms of the DAO's code set forth on the blockchain".

However, it is an interesting point to consider whether, if the courts had to consider this, would they actually decide that the natural language version of the contract is the document that actually best represents the intentions of the parties, particularly if this is the document that has been used by the parties during their negotiations?

What if there is a mistake in the contract?

Mistakes are often made in contracts. For example, let's say a fashion chain wants to order 10,000 tonnes of cotton but instead orders 100,000 tonnes in error. For traditional contracts, there is the legal doctrine of mistake that will determine whether or not such an error will be rectified by the courts (and of course, the parties can always agree to change a traditional contract before it has been performed).

With smart contracts, this area is more difficult. Once a smart contract is agreed, it is effectively set in stone on the blockchain and is intended to execute automatically, leaving the parties with little scope to amend the contract at a later stage. However, this may be resolved more easily where a small-scale, permissioned blockchain is used which sets out a specific procedure to resolve disputes. With these new types of contracts combining law and code, there may also be need for new type of due diligence that ensures that both legal and technical risks are planned for and mitigated against.

A sceptical view

It is always a good idea to apply a degree of healthy scepticism to any new technology, and there is certainly no shortage of this in relation to blockchain. One element of this criticism relates to the increasing emphasis on private, permissioned blockchains (driven by concerns around security and scalability). Many are asking whether these solutions are really blockchain in any meaningful sense [7]:

A number of blockchain technology providers such as Digital Asset Holdings and R3 have implemented a shared ledger model, rather than a distributed ledger. In this infrastructure, market participants’ nodes only keep a record of the transactions to which they are a counterparty, and that they upload from a central ledger that keeps a record of all transactions.

With this approach, participants cannot query data for which they are not a stakeholder. This is quite an evolution from the initial blockchain model, as the infrastructure becomes a semi-distributed environment in which a partial ledger co-exists with a central ledger. With this development, the infrastructure is becoming closer to a traditional utility model that holds a golden copy of information.

Or, as another commentator put it (rather more bluntly) [8]:

Private blockchains are completely uninteresting … In general, they have some external limitation on who can interact with the blockchain and its features. These are not anything new; they’re distributed append-only data structures with a list of individuals authorized to add to it. Consensus protocols have been studied in distributed systems for more than 60 years. Append-only data structures have been similarly well covered. They’re blockchains in name only, and—as far as I can tell—the only reason to operate one is to ride on the blockchain hype.

Conclusion

It is currently difficult to assess the extent to which blockchain technology will end up materially affecting retail supply chains. However, given the competitive environment in which most retailers are operating, it is likely that many of them should at least be considering whether blockchain technology can offer it an opportunity to reduce costs, improve efficiency and/or provide a better service to its customers.

If you would like to discuss the issues in this article further, please contact Ian Edwards or Esme Strathcole.

[1] http://blockchain.cs.ucl.ac.uk/wp-content/uploads/2019/08/DLT-in-the-Supply-Chain_UCL-CBT.pdf

[2] https://www.wired.com/story/following-a-tuna-from-fiji-to-brooklynon-the-blockchain/

[3] https://ftalphaville.ft.com/2018/04/13/1523592006000/Sell-all-crypto-and-abandon-all-blockchain/

[4] https://www.research.ibm.com/5-in-5/crypto-anchors-and-blockchain/

[5] https://cointelegraph.com/news/walmart-requires-certain-produce-suppliers-to-deploy-blockchain-technology

[6] https://ftalphaville.ft.com/2018/04/12/1523503800000/Immutable-ledgers-meet-European-data-protection-/?tagToFollow=

[7] https://ftalphaville.ft.com/2017/11/22/2196054/taking-the-block-out-of-blockchain/

[8]https://www.wired.com/story/theres-no-good-reason-to-trust-blockchain-technology/