Blockchain technology as a remedy to the problems of electronic LCs; Limitations and proposals. (part 2)

Limitations and proposals

            Even though blockchain is already used by a lot of firms, many barriers could be stated regarding its implementation into the realm of trade. These problems vary in nature and are particularly related with operational and technical risks as much as legal and regulatory issues. Specific solutions have already been purposed, nonetheless the situation is still in precarious state.

Technical/Operational limitations and proposals

The present paper sought to prove that Blockchain technology is capable of replacing the fragmented paper-based procedures that eLCs did not manage to successfully do, mitigating the related risks and costs. Nonetheless, as anyone might think, this technological breakthrough will have to deal with the hurdles that any common software is facing in today’s modern world, i.e. various kind of errors like malfunctions and bugs. On the one hand, “platform logic” errors refer to those which disrupt the completion of a verified transaction in a multiple user platform upon which smart LCs will be hosted, while on the other hand, “internal coding” errors, being related with the “formation stage” of the contract or alternatively the time frame when rights and duties are being specifically converted into code. Furthermore, smart contrasts bugs could be considered as a new level of blockchain security effect. On the contrary to what is known until today, where the traditional software’s bugs could be fixed with a simple use of a patch; everything now seems much more complicated. This is justified by the fact that a smart contract blockchain-enabled transaction resembles with a rocket launching and subsequently it cannot be stopped. However, notwhistanding the fact that they cannot be patched, they may be upgraded by utilizing further smart contracts to interact with them, operating as a sufficient failover mechanism. What is more, as LabCTFC states in its report “humans make mi$taak3s when k0diNg”, while unintended software vulnerabilities is not unlikely to exist too.

Technical disruption and manipulation constitute “external integration” errors which complex the situation even more, deriving from a wrongful information process or puzzling provisions. Despite the fact that IoT and oracles will interact with the underlying sales contract, without breaching the independence and strict compliance principle, any potential manipulation by insiders who may have “backdoors” to the code, or a better understanding of technical know-how will react to particular inputs or events that will possibly trigger unlawful enforcements. For example, a failing, or malicious oracle may transmit or accept wrong information that do not reflect the LC parties’ intention, triggering a wrong payment or falsely attributing property rights, without the smart contract conditions’ fulfillment. Βlockchain enabled devices like IoT may also lose their interconnection with the blockchain execution environment, the device operating system, and hardware, failing contrarily to trigger enforcement where all the terms and conditions have been sufficiently met. Despite that all these aforementioned technological challenges are likely to bring disastrous effects in multiple stages of any smart contract automated process; core infrastructure and basic technical standards are still a “work in progress”.

Another cornerstone is related with the consensus mechanisms, i.e. one of the key blockchain’s attribute, whose contribution reassures the validation of the transactions, upgrading the security levels in contrast with eLCs’ paucity in this regard. Unfortunately, these mechanisms are proved not to be indestructible. Particularly, should the hacker, in case of a 51% attack on the network, gain the mining’s majority power, he could defraud others, by sending payments, while he will be able to create ex post facto a different version of the blockchain in which nothing did actually paid off (fork). After all, who would be responsible in case the platform collapse, and how could this be prevented in order the ongoing usage of the blockchain to be allowed, given that the community in the permissioned network that will be used for the smart LC transaction is going to be probably small?

These calamitous effects could be possibly prevented by proactive mechanisms or alternatively through the usage of a second ledger which would operate as a “backup” plan, containing all the lost accounts and data in real time, being capable of bringing the situation back to its original stage. Mitigants would be able to remedy these eventualities, placing specific duties upon the platform provider in order the LC services’ continuity to be reassured, despite the central administrator’s possible failure. Alternatively, a financing facility, capable of manually operating in case of the same event could be put in place. However, this is not a straightforward exercise, since both importer and exporter would prefer such contribution to be regarded as the continuance of the facility which the blockchain platform had already provided. In other words, all the amounts that have advanced before that time to be taken into amount.

It could be stated that, even if interoperability can be seen, the fact that there are not enough workers, having the required competencies in regard to blockchain technology in order to collaborate not only between them, since multiple parties are involved in a smart LC transaction but with an associated custom software solution as well, coordinating in order to effectively intervene in semi-automated procedures, will possibly affect harmonization numbers, following the low eLCs’ adoption rate. Finally, despite that blockchain technology may be faster than eLCs, due to its KYC/AML application that assists the LCs’ issuance, it is plagued by the problem of scalability which, nonetheless in case of a permissioned blockchain is merely approachable as these are compromising the freedom of trust for it.

Liability

Various legal issues will have to be also addressed, should blockchain technology replace eLCs. Even though some statutory provisions are merely fair in regard to technical disruption, manipulation or errors what is going to happen if an indirect form of error take place in a sophisticated encoded environment? How would the judges allocate liability, if neither party would not be at fault; Who would be responsible, if an LC transaction fails because of a fault of the platform or the smart contract?

Currently, smart contracts execute what they are programmed to do, not providing reasoned analysis based on independent thinking or addressing “grey zones” like tribunals traditionally do, referring to caselaw and statutes.The most extreme option in case they “go wrong” states that no one will be liable, independently of the nature of the problem, since anyone use the platform at its own risk. However, this is not a realistic point of view, assuming that regulators, policy makers, judges and other interested parties will not be comfortable with this explanation. On the other hand, Commodity Futures Trading Commission invokes that the individual who designed, developed and maintained the code or the platform should be held liable in case for example the code does not have features that prevent illegal activities. I tend to agree with a third much more mediocre option, supporting that given the circumstances each case should be investigated separately. Finally, one might look into the group of individuals that could cause or remedy the injury.

Given the misconception that only one type of smart contract exists as much as their irreversibility, contractual provisions would have to be supplementary agreed. Between the two extreme views, i.e. that “code is contract”, envisaging the terms’ codification into a separate digitalized automated contract that operates through “smart logic” and an advanced digitalization of the traditional contract enriched with an encoded payment mechanism, an intermediate choice might be preferable.More specifically, a second transaction that would incorporate remedial premises, also improving risk allocation and bringing in line potential inconsistencies e.g. a cap of liability clause for specific errors, liquidated damages provisions or in case of civil procedures the commonly arise question concerning the “burden of proof” in fulfilling the requirements for a claim or under what conditions may any alleviations mitigate the damages. Both of them together would constitute a coherent agreement which would offer flexibility, since every possible circumstance cannot be easily adapted into the “strict logic of code” such “force majeure” a commonly used term which is particularly provided in article 36 UCP 600 and representations and warranties as well, minimizing vagueness which would possibly lead to lower monitoring services and higher negotiation costs. These proposals may walk in line with EDI agreements , since a limited number of dealings will rely on code as a part of the broader LC transaction. In conclusion, the financial regulators must take the view that blockchain and its relevant applications are relatively new technologies which still evolve. For this reason, they must not keep in mind to regulate the technologies, delivering the LCs “cure” but the financial activities alone, whether these services are provided via an electronic platform or through paper based conventional contracts.

Further questions arise concerning the choice of law and jurisdiction matters, recalling, nonetheless that this still constitutes an LC pain point too. The fact that the smart LC transaction would operate in a decentralized manner renders this aspect quite vexing, because the law will probably refer to the location where damage occurs. It must be stated that there are no courts or regulatory bodies known yet, albeit number of theories are already sitting on the table. Jurisdiction could relate with the place of organization of any enmeshed entity, the place where the substantial activities that caused the injury took place or eventually the place where a substantial impact on the case has been made (the “effect test”). In terms of the law applicable, a “choice of law” clause cannot be incorporated in the programming language, although the manner that the smart contract or the platform deploys may help a lot this problematic aspect.

Enforceability

Smart contracts are typically not legal contracts. Their automaticity as much as the mechanic way in which their computer code operates, leads to the conclusion that there is no need for a party to resort to the law, aiming to enforce a promise by the counterparty. In principle, they are able to be “identified, interpreted and enforced”, utilizing well established and ordinary legal principles.Besides, there is no reasoning why normal rules should not carefully apply subject to practical and theoretical difficulties, because the relevant contract is a smart one. As anyone might think, legal uncertainty in relation to their enforceability arises, since it is quite challenging to interpret a smart contract under the aegis of traditional contract law. Given the diversity of the Civil and Common law jurisdictions, specific minimum stipulations should be definitely determined, e.g. offer, acceptance and consideration , having as a common ground the “meeting of the minds” which can be seen in most jurisdictions that use legally binding contracts, ensuring normality, giving at the same time rise to legal consequences that the relevant circumstances and legislation provides. Thus, some believe that the question whether consideration was intended may be assessed by reference to the traditional principles for less conventional contractual models too. Some experts do contrarily indicate that since performance will in all probability be far less of a problem, conventional contract law in its present form is implausible to be the most efficient solution of adjudicating any relevant controversy. This argument is based on the fact that although securing performance will be far less of a problem, the results may not always accord to the parties’ expectations, leading to disputes after the transaction’s completion. Thus, automation will have to shed the weight to restorative nor enforcement remedies, especially for cases that refer to mutually agreed ongoing performances.

Conclusively, the fact that the well-known deviations between the two judicial systems will bring into the surface a lot of regulatory and legitimacy concerns, referring to Intellectual Property rights, consumer protection law and property rights, should they apply globally, must not be neglected.Another relevant concern is related with the legislation of public/private key cryptographic technology (PKI), being a specific type of electronic signature that cannot be frequently met in every developing country in order strong authentication and advanced data encryption to be legally secured.

Smart legal contracts

In contradiction to the above, “smart legal contracts” differ in being specifically designed to operate on a blockchain, representing a legally binding and enforceable legal contract in court. Smart contracts with legal implications must be reverse engineered, having a “back-to-front legal contractual analysis, in which enforcement yields to correction”. Those arguments’ underlying logic is transformed via computation empower softer connectivity, automation and dynamic transactional arrangements. More specifically, natural language contracts combined with self-executing code, operating in a DLT network that contains a hashed reference to the natural language provisions constitutes the “Ricardian contracts”. This mechanism could facilitate the incorporation of governing law, jurisdiction and dispute resolution clauses, being regarded as the main trend upon which some IT companies rely upon, aiming to “deliver” enforceability. This type of contract was originally suggested for the issuance of bond instruments , being readable by both humans and machines. It has to be stated that in case of lack of an express statement, demonstrating the parties’ intention to be legally binding, the relevant contract will not be precluded from being legally recognized. Contrariwise, the Judges will look into the entirety of the parties’ relationship and intention.

 For example, a similar software uses a smart contract which operates based on three components, i.e. firstly its template’s grammar, consisting of natural language contract text which identifies information like date and price, secondly through a data model that offers a framework that categorizes the variables and the components of the business context that operationalize smart contracts and thirdly the template’s operational logic which execute the contract , when business context and the legal contract’s elements are categorized , using data- oriented modeling language.

Smart Dispute Resolution mechanism

The geographically dispersed nature of cross border transactions like LCs raises various questions in relation to the enforceability of different foreign courts’ judgements that will possibly lead to conflicting outcomes. Despite the ‘’Online Dispute Resolution’’ regulation and particularly the specially designed platform whose aim was to improve the chaotic conflicting management, the lack of formal international instruments which would enhance and accommodate the situation is visible to the naked eye. For this reason, alternative solutions must be provided, keeping in mind that the parties were always afraid to litigate in foreign lands. For instance, some major smart contracts’ features like immutability or their programmable nature combined with the multisignatory mechanism could construct an “internal smart dispute resolution mechanism into the smart contract itself”, addressing any related with jurisdictional variations and enforceability concerns. This Smart Dispute Resolution mechanism would be able to take the form of a formal arbitration or informal mediation. The mechanism will be linked with a digital pre-designated arbitrator who will assist both parties by the time breaches or other errors like encrypted bugs occur. Conclusively, the arbitrator is going to operate as a third-party oracle , saving money and time, since the smart contract would be able to be ceased, restarted or continued upon some alterations’ fulfillment that are going to be carried out after the online hearing process. This mechanism will hopefully reduce litigation costs, providing at the same time some smart contract’s functionality which responds to today’s modern trade finance needs. An incorporated clause will render dispute resolution as a part of the DLT procedure rather than independently imposed upon it. In case the smart LC participants will not incorporate any arbitration clause like the following one: “Any dispute, controversy or claim arising out of or relating to this contract, or the breach, termination or invalidity thereof, shall be settled by arbitration in accordance with the Blockchain Arbitration Rules", the tribunals will still have jurisdiction over the legal effects of this modern contractual type, interpreting the code applying traditional contract law principles.

Fraud and forgery in relation to Data Privacy concerns

            Blockchain is merely the safest way to ensure that any inserted data will not be corrupted as it is unfortunately happening in LCs transactions, provoking that way fraudulent behaviors and forgery. However, any information, either maintained in the utilized network or being spread over multiple nodes, is considered proprietary and confidential, violating data protection laws. Thus, regulatory data privacy obligations will have to prevent or restrict their disclosure, since once data is stored on the ledger it cannot be erased, probably provoking devastating consequences for the entity or individual.[60] The same problem exists pertaining to agreed contractual terms that must not be widely shared.

This new technology, as a new way of registering and storing data should be considered in the light of the relevant data legislation like the General Data Protection Regulation 2016/679 which was drafted before the rise of blockchain, being conceived with more centralized, “traditional data-processing paradigms in mind”. Questions such as who the “data controller” will be or who is going to process the data will be difficult to be answered mainly in regard to open decentralized blockchain networks. Miners cannot be regarded as data controllers, given that they simply validate the submitted transactions, not involving in their objective. Contrarily though, they could be considered as “data processors”, because they follow the controller’s instructions. Algorithm developers could play this role too, while the smart LC’s participants have also the capability to designate a data controller or alternatively be considered as “joint controllers” themselves, as they define the objectives as much as the data format or uses pursued by the processing. This could be done by contract or through the establishment of a legal entity or association. Several principles like the “right to be forgotten”, the controller’s obligation in regard to the data’s accuracy and storage as much as the data subjects’ right to request alteration of its data are opposed to blockchain’s immutability. Thus, it is extremely dubious, given that this database is simultaneously maintained in thousands of copies, whether these concerns could be efficiently fully satisfied, in accordance with the guidelines that the GDPR provides. The CNLI oppositely invokes though that the inserted information could be made inaccessible e.g. by the Smart LC’s data controller, possibly sacrificing some GDPR’s prerequisites, aiming to compromise with DLT. Thus, the data subject would unquestionably move closer to an effective exercise of its right in accordance with article 17 GDPR, should a proper crypto logical method is used for its data storage; Furthermore, when smart contracts are involved, the data subject ought to have the right to obtain human intervention, at least to express its concerns, even after the smart contract’s performance is recorded on the blockchain network.

Assignment

A further legal constraint that might render blockchain technology’s impact on the LCs’ use incremental rather than revolutionary is related with possession. On the contrary to UCP’s 600 provisions which entitle the beneficiary to assign the LC proceeds, regardless the credit’s transferability , there is no similar provision in the purposed ecosystem yet. Particularly, it is known that the market capitalism’s rise evolved a series of exceptions to the old common rule which prohibited the assignments of claims for policy reasons , allowing the exception of tangibles negotiable instruments, although the equation of a private key to a DLT token with a negotiable instrument will definitely require to be legislated despite its acknowledgement in case law. It could be stated that this idea constitutes another promising direction towards LCs’ remedy, minimizing possible related with this solution adoption risks.

Conclusion

Despite the purposed mechanism’s limitations, the current manual, not affordable and slow financial instrument could be effectively replaced by the utilization of Blockchain technology along with the use of smart contracts combined with oracles and IoT as well. Human intervention will be no longer necessary and as Mr. Antonopoulos remarkably states “Blockchain will represent a shift from trusting people to trusting math’’. Due to real-time data means, the LCs will no longer constitute a stand-alone mechanism, because the underlying sales contract will be effectuated without breaching the strict compliance and autonomy principle. Blockchain advantages such as the decentralized contract execution alongside the real-time documents’ review, the smart payment automation and trade asset tokenization will definitely provide sufficient ground for market reshape, offering trust, legitimacy and cost efficiency. However, the law will also have to successfully adapt to this kind of change, either by applying the existing regulatory regimes with minor adjustments or drafting new legislative models. What is more, better accessibility throughout the regime will be achieved as well. Small and medium enterprises, would be able to transact securely on a peer-to-peer basis with individuals or legal entities from all over the world, should the law that will govern peer-to-peer interactions prevail against the ethos, underlying this innovative technology.The emerging markets may be also extremely benefit, especially, when similar ecosystems are combined with cryptocurrencies, self-starting that way all the relevant procedures, consequently lowering the networking costs.

 In conclusion, the traditional LCs regime is ripe for decentralization and automation. Thus, a common natural language between computer developers and lawyers must be established, aiming to hopefully welcome this opportunity. These technologies must be embraced by the financial industry so as to harmonize the LC regime with supply chain practices. However, I am inclined to believe that, when blockchain technology is to be applied in the economic sector, a hybrid form which would preserve a specific degree of centralization, encompassing both philosophies’ advantages should prevail.This enormous innovative potential has to be adequately regulated, pondering the interaction between innovation, law and technology. In any other case, blockchain could be either used for advantageous but even for malicious ends as well just like any other type of technology.

Stavros Zoumpoulidis | Lawyer

Legal & Compliance Division , Intralot S.A