API based Hash-Link Contract for DvP – Could we also do more on-chain?

In the following article we summarize and discuss a proposal by Banca d’Italia to secure Delivery versus Payment (DvP) on DLT-based infrastructures. The corresponding publication proposes an interoperability model to connect a DLT infrastructure to a (central bank) payment system over a functional design called the “API-based DvP with Hash-Link Contract”. The authors explore the potential of this model in view of the Target Instant Payment Settlement (TIPS) and emphasize the low functional coupling of the concept with respect to the specific asset-managing DLT. We provide a rough overview of the concept and some own thoughts at the end.

What is a Hash-Link Contract?

Hash-Linked Contract (HLC) is a smart contract-based mechanism used in Distributed Ledger Technology (DLT) to ensure the safety and reliability of transactions between buyers and sellers in a functional manner. In view of DvP a seller may lock the asset-leg of the transaction in a smart contract, which is linked to a hash value. After successful cash transfer, which gets communicated to the HLC contract, the buyer is able to initiate the asset transfer to his account by providing the obtained preimage of the hash value, which unlocks the asset-leg and allows the transaction to be finalized. This functional approach ensures that the buyer possesses sufficient funds for transaction completion and assures payment for the seller.

How does the proposed HLC based DvP work?

The proposed API-based DvP Hash-Link Contract involves an off-chain based oracle API. The on-chain HLC contract communicates with this oracle, which in turn also establishes a connection to the payment system (PS). An execution preimage and a cancellation preimage are exclusively generated by that oracle and are shared with parties upon conditions are met. The following sequence diagram roughly depicts the interaction, for more detailed information we refer to the diagrams in the paper. The seller initiates the DvP transaction via the „DvP-Oracle“ which generates the preimages and corresponding hashes. After successful transfer the buyer can retrieve the preimage to access the locked assets and trigger the final asset transfer. In case of a payment failure the seller can transfer assets back by using the cancellation image.

Discussion

The publication highlights that outside the DLT infrastructure the HLC contract can loosely connect to a payment system via the proposed standardized API gateway. Therefore, the contract itself might need a minimal dependency to this API such that variety of contract designs could be created by market participants against that interface. The approach also shows a high level of interaction of the transacting parties whereas the role of DLT based HLC contract plays a rather minor role. However, this might be wanted to offer a cooperative way for DvP with minimal contract functionality used. In turn it might be questioned whether the DvP functionality should be split between on- an off-chain instances. Beyond that the concept relies on separate communication channels besides the DLT infrastructure where hashes and preimages get transferred.

Can we get less interactive and do more on-chain?

The low function coupling several DLT based contract designs against one standardized interface seems to be a very charming feature of the concept. A question arises: Could we achieve this low coupling also via an on-chain based contract design? And second, looking at the level of interactivity it could also be interesting to have a standardized on-chain based solution which offer a higher degree of automation – a hypothetical on-chain „DvP-Contract“ could manage the entire DvP process on its own.

Think of the following sequence diagram in direct comparison which in addition makes use of a token-based asset-managing contract. Think of such a „DvP-Contract“ which also might be connected directly to the payment system and on the other hand provides the handling of payment and asset transfer side entirely on-chain. A well designed DvP-Contract design might might make use of some proven token standard although ERC-20 might not be sufficient in this case. Surely this approach might only be suited to transfer assets across one DLT Infrastructure but in this case the proposed design enables a very low level of interactivity because DvP is handed over to contract functionality.

Conclusion

Our rather complementary on-chain idea might offer a higher level of automation and less participant interaction on the DLT infrastructure itself. It would avoid an additional off-chain oracle and would tie the entire DvP process together into a smart-contract-based structure. Still both approaches seem to have their benefits as they target different needs of interaction. Several functional designs might coexist in the future and the decision in terms of usage will be left to market participants and their specific needs regarding on-chain functionality, level of interaction and degree of automation possibility.

Disclaimer: The opinions and statements expressed in this article are those of the author and do not necessarily represent the views of the company or organization.