Getline Whitepaper Article Series:
Loan Contract Design
We’re pleased to introduce the sixth and last of a series of articles based on our whitepaper. The purpose of this article series is to run through the whitepaper in layman’s terms, and make it as simple as possible to read and understand the details of what the Getline Network is, how we’ll function, how we’re structured, and how we plan to move ahead. These articles will be shortened & simplified versions of the whitepaper content. See the whitepaper for the full content.
Note, this final article is on an entirely technical subject, so it is not in as easy to read language as the other articles.
Just as a short intro, Getline is disrupting a $1 trillion market through blockchain technology.
The Getline Network is a peer-to-peer lending market on the Ethereum blockchain. The platform will allow for instant and direct lending in cryptocurrencies. Getline will initiate a unique architecture for a credit risk prediction market to make lending safer for lenders and more accessible for borrowers. We aim to revolutionize the peer-to-peer lending market and fully decentralize it, making it easily accessible, safe, and compliant to serve as an infrastructure for a new kind of global financial system. For those of you who don’t know, peer-to-peer (or P2P) refers to the ability of two individuals or entities, to exchange value with each other directly, without the need of a middleman.
All Articles:
1st Article — Introduction, Aim, & Our Idea
2nd Article — Credit Risk Management & Loan Lifecycles
3rd Article — Competition & Challenges
4th Article — GET Tokens And Their Distribution & Crowdsale
5th Article — Roadmap
6th Article — Loan Contract Design (Last)
In this sixth and last article of the series, we’ll cover section 11, which is:
*11 Loan contract design
*11.1 Modularization
*11.2 Attestation interface
*11.3 Loan contract
*11.4 Investment split
NOTE: This last section is on an entirely technical subject, so it will not be in as simple language as the previous articles.
Let’s get started…
11 Loan contract design
The loan contract is the most sensitive part of the architecture, linking everything together, handling both collateral and the loan’s capital. Thus, it was designed and written to mitigate damages in case of a security breach. To decrease deployment costs and to make code modifications easier, it’s also modularized.
11.1 Modularization
To decrease costs of the deploying loan contracts, and to increase security, the code has been modularized. The main code for managing money has been abstracted to a Ledger Library contract whose goal is to manage money transfers and investors for a loan, without managing any time-dependence or state machines. The Ledger Library is deployed only once for each loan contract version, and each loan then communicates with the same library code. It allows for the code to be deployed beforehand, making each loan contract a mere shell which manages memory without duplication of the read-only memory that holds most of the code. It significantly reduces gas costs for all loans in the network.
Loan contracts still have separate code for state management, handling fundraising, payback, etc. for improved code clarity.
Every loan is a separate contract, so bugs in one cannot influence the others. Damages from breaches are minimized thanks to the granular architecture. It also makes every loan immutable and guarantees both the lender and the borrower that the contract can only be performed according to the terms previously agreed upon. Once the loan is deployed, third parties cannot influence it.
The loan is split into two main modules and an attestation interface.
See “Figure 5: Loan” in the whitepaper.
11.2 Attestation interface
Passed and verified during construction of the loan contract, the side of attestation (or proving) in the Loan itself is very simple.
For more information and technical formulas, please see the whitepaper.
If the loan is a private one, an always-true-attestator can be passed, but for public and shortlisted loans on Getline, specific Ethereum addresses will be white-listed as legal and working attestators. The addresses will be checked in the centralized part of the ecosystem and not on the blockchain.
11.3 Loan contract
The loan contract acts as an entry point for both parties. Acting as an API and containing business logic concerning timing and the loan’s state, the loan’s code itself does not manage tokens nor collateral, and passes all such operations to the Ledger Library, which is described in more details below.
The contract is designed as a state machine using an enum and modifiers written as a common pattern, as seen in the Solidity documentation, and has the following states:
Collateral Collection,
Fundraising,
Payback,
Finished
See exact formula and “Figure 6: Collateral collection” in the whitepaper.
After the deployment of a loan, it waits in the collateral collection state indefinitely. The borrower has to create an allowance in GET tokens according to the ERC20 token specifications (see formula in the whitepaper), which transfers the whole allowance into the loans’ escrow (using the Ledger Library), simultaneously entering the first timed state — fundraising.
During fundraising the loan awaits input from potential investors. Should the goal not be reached, the collateral is returned to the borrower and the loan is finished, going directly to the finished state. Otherwise, for each investor a percentage of collateral, directly proportional to their investment value, is reserved in case of a loan default. That reserved collateral shall be freed to the investor only if the goal is reached and the borrower fails to pay back during the payback period. After the goal is reached, the loan is freed for the borrower and the payback state begins.
During that state the borrower can withdraw the loan from the contract and is expected to pay it back with interest. It is not possible to pay the loan back in multiple instalments, one and final pay back allowance is required with the full amount. If the loan is paid back during that period, the funds are released to the investors and can be withdrawn, and collateral is sent back to the borrower. Otherwise the loan defaults, and the collateral is released to the investors.
For more info, and to see “Figure 7: Fully paid back flow of the loan contract”, “Figure 8: Changed flow in case of default”, and “Figure 9: System layers”, see the whitepaper.
11.4 Investment split
Each investor has reserved collateral tokens and revenue share proportional to the amount of the investment. If the loan is paid back, the amount received back works as expected, with interest rates bringing a higher return. Otherwise, if the loan has defaulted, each investor gets a number of collateral tokens that is a weighted average of the amount invested compared to the total loan amount. There is a possibility that a small amount of collateral (in a range of the least significant digits) is left due to division flooring and constant precision of uint256 numbers. That amount does not belong to any investor, but it would be sent back to the borrower.
See Figure 10: GetLine network ontology
We hope you enjoyed this last article of the whitepaper article series,
Have a great day!
The Getline Network team.
If you enjoy our articles, please like and follow us on Facebook and Twitter.
Also, join our Rocket chat if you’re interested in contributing to our platform.
