Introducing the MVP of our Syndicate Loan dApp
About six weeks ago, Lition held a meetup at the SAP Dataspace, where we celebrated the launch of our first testnet. Towards the end of the event, I took the chance to introduce our finance use case, which is bound to expand our ecosystem. You can see the recorded video of the meetup here.
Lition recently signed a partnership with two German banks that led to an agreement over the execution of a syndicate loan on our very own infrastructure. This MVP was designed to facilitate the discussions in preparation for a trial run with live data for a real estate project valued at 20 million Euros in Munich.
First, let me quickly give you a brief overview on what syndicate loans are:
- In a syndicate loan, multiple lenders (mostly banks) collectively provide the loan amount and thereby form a syndicate
- The loan is then provided to a single borrower, which could be the government, an individual or a large investment project
- This reduces the default risk for the lending parties and enables huge loan amounts
- Unfortunately, the manual processes behind these loans rely on intermediaries, phone calls and fax machines and thus are anything but 21st century.
As a matter of fact, digitalization of the process to close a syndicate loan is critical to enhance security and cut cost. Since the aforementioned presentation, we have committed to work on the syndicate loan dApp. The application is built on a responsive front-end user interface, which seamlessly connects to the blockchain via web3.js.
Today we are releasing the minimum viable product (MVP) of our syndicated loan blockchain application.
The dApp allows multiple parties to apply for, manage and approve loans decentrally.
The dApp we at Lition have been developing has some basic functionality to create loans in the browser-based web interface and let’s you store the loans on the blockchain, currently in a self-developed smart contract.
One of the core features is multi-user functionality, meaning a loan creator can add other banks as lenders which can then propose changes to the loan agreement. If a party agrees with the current state, it can approve the loan. Once every single party has agreed to the same revision, the loan will be approved and can then be enforced.
Use of the Lition Blockchain with its privacy and deletability features
In a loan application, the most private data is provided: credit history, payment details, collateral like salary levels or property. In order to test and evaluate our dApp, we decided to deploy the smart contract on an EVM-compatible public blockchain, namely the Ethereum-based Kovan network. However, before commercial deployment in our partner bank, we will require a legal solution for privacy.
This is where the Lition blockchain comes into play, which we will use for deployment in a future version. The loans then are processed on a privileged sidechain, with selective data visibility to ensure private data is only shared among the nodes that are trustworthy — similar to our running Energy dApp described here.
Further, the private data of a loan needs to be deleted when it is fully paid off, goes into default or the application is declined. This functionality is paramount, as no large business can afford to openly violate laws. Lition’s data deletion functionality will allow the banks to solve this issue and be compliant with legislation.
Try it out yourself
To test the dApp, I invite you to play around by creating some loans and adding users by their addresses. To do that, it’s best if you install the MetaMask plugin, with which you can easily create multiple addresses. Then you can play around and see that you can retrieve loans, even when another user (e.g. another bank) added you to them. The dApp also allows you to propose changes to the loan data. To simply interact with the smart contract, you can also use the remix IDE (https://remix.ethereum.org/), which lets you for example create loans quickly. Afterwards you can open the front-end website and directly see the loans you’ve created.
Want to try it out yourself? Follow these steps:
1.) Install Metamask or just start your web3 browser.
2.) Select the Kovan network and get some Testnet ETH at https://faucet.kovan.network/ or just post your address in this chatroom: https://gitter.im/kovan-testnet/faucet
3.) Navigate to https://scripts.lition.de/syndicated-loan/ where you can sign up on the smart contract, or navigate directly to the main interface: https://scripts.lition.de/syndicated-loan/main.html
4.) Start with “Propose New Loan” and write it to the blockchain.
If you like, you can check out the source code on our github repository. This might be especially useful when reading the next chapter.
You can share your comments and feedback with us on our Telegram Channel at https://t.me/LitionEnergy
Tech Stack
The lean design for the front-end was crafted by our UI designer, Chris and implemented in bootstrap and Vanilla JS. We plan to redevelop later versions in a framework like React.js, however, a final decision for the specific framework has yet to be made. Thanks to bootstrap, the website is generally responsive, even though, extensive testing has not yet been undertaken. So please, get your android smartphone out and install Opera, which has an integrated wallet and web3 functionality and test if the dApp works! If you are using iOS, unfortunately you need to wait a little bit.
The front-end application connects to the blockchain via web3.js, specifically the version 1.x which is a complete refactoring of the old version. The new version for example, permits the use of asynchronous functions and promises. Through your provider (e.g. Infura, in the case of MetaMask), the smart contract calls are then propagated to the blockchain network and executed on the virtual machine.
The html forms of the application are the core piece to exchange data between the user and the smart contract. After retrieving data from the blockchain, it is stored in objects in browser storage and from there loaded into the form fields. Next to loan data, the data of registered users is also locally stored, from where it fills dropdown menus. Thereby, a user can search for registered users and the form automatically pre-fills the specific field when a new user shall be added to a loan.
Regarding the user registration, after opening the modal need to specify the user name, their role and their account address. When clicking “Register on blockchain”, following code gets executed. Next to the smart contract function call (userRegistration(…).send), the function refreshes the UI and retrieves the current user list from the smart contract retrieveUsers().
function userRegistration(_name, _role, _account) {
_name = $('#modal_add_userName').val();
_role = $('input[name=radios_role]:checked').val();
_account = $('#modal_add_userAddr').val();
if (devMode) console.log(Registering User: name=${_name},
role=${_role}, address=${_account});
txNotifyUI('send', 'register');
storeContract.methods.userRegistration(_name, _role, _account)
.send({from: userAccount})
.on("receipt", function(receipt) {
txNotifyUI('conf', 'register', activeLoanId, _address);
sessionStorage.removeItem(activeLoanId);
deleteFromSidePanel(activeLoanId);
retrieveUsers();
})
.on("error", function(error) {
console.log(error);
console.log(typof(error));
// $("tx-status").text(error);
});
}Now, let us dive a little bit into the core logic of our dApp, the smart contract. You can look at the code on etherscan.io right here.
pragma solidity ^0.5.2;
pragma experimental ABIEncoderV2;
contract SynLoanData {
uint public loanId;
LoanData[] public loans;
struct LoanData {
uint id;
string name;
uint revisionNumber;
address registeringParty;
string dataString;
uint regTime;
mapping (address => uint) userToId;
uint[] loanAmounts;
bool[] approvalStatus;
address[] userList;
uint8 numOfUsers;
}
struct userData {
string name;
string role;
address account;
}
...
The core oft the syndicate loan app, are structs named LoanData. Here is where we store the critical information about the loan, which can be evaluated on-chain. Next to a unique id (uint public loanId) which gets passed to every newly created loan, we have the revisionNumber, important to specify the current version. If updates are made by one party, the revisionNumber increments.
The dataString is a stringified JSON object, that after creation in the UI, also sits in the browser’s session storage and stores the values from the html form.
The approvalStatus array logs the current status specific to the users registered in the loan. Each user has their own local id in the loan (represented by the mapping userToId). As an example: loans[_loanId]approvalStatususerToId[msg.sender] gets you either true or false, for the sender of the transaction. The loanAmounts array similarly stores the loan amounts specific to a user in a single loan.
Future Outlook
As stated, the dApp is an alpha version to give our community a status update on where we are heading in development. Regarding the functionality, we want to implement event emitters and streamline automated updates (e.g. if another user updates a loan). Furthermore, lenders should be able to search each other in order to form loans and avoid the agency chaos that banks are facing today. In the long run, the app should support tokenization of loans, so they can be transferred to new accounts or traded on secondary markets — actions that are not impossible, but almost always infeasible in the real world.
