Detailed Technical White c paper Version June 2018

Transcription

1 Detailed Tehnial White paper Version June 2018 HAVE YOUR CRYPTO AND SPEND IT TOO A blokhain platform that enables UK liened lenders to provide loans seured against rypto assets to borrowers all over the world! Copyright () 2018 Lendo Platform PTE Ltd 1

2 Legal Dislaimer Please read the following notie arefully before proeeding to read this white paper doument issued by Lendo Platform PTE Ltd, an exempted ompany inorporated and existing under the laws of Singapore (hereinafter Distributor ). This notie applies to all persons who read this doument. Please note this notie may be altered or updated. The white paper does not onstitute any relationship (ontratual or otherwise) between you (hereinafter you or Holder ) and the Distributor. Aquisition of the Lendo tokens is available only after aepting the terms of the token sale (hereinafter T&C ). Aquisition of Lendo tokens does not represent an exhange of rypto urrenies for any form of ordinary shares of the Distributor and a Holder of Lendo tokens is not entitled to any guaranteed form of dividend. Holders of Lendo tokens are only entitled to ertain rights as laid out within the Terms and Conditions. Lendo tokens are not intended to onstitute seurities in any jurisdition. This whitepaper does not onstitute a prospetus or offer doument of any sort and is not intended to onstitute an offer of seurities or a soliitation for investments in seurities in any jurisdition. This whitepaper is for information purposes only. The ontents of this white paper are not a finanial promotion. Therefore, none of the ontents of this white paper serves as an invitation or induement to engage in any sort of investment ativity. Prospetive buyers of Lendo tokens should arefully onsider and evaluate all risks and unertainties assoiated with the rypto urrenies, Lendo and their respetive businesses and operations, the Lendo tokens and the Lendo Initial Coin Offering. Familiarize yourself with all the information set out in this white paper, Risk Notie and the T&C prior to any purhase of Lendo tokens. Ensure that you are aware of all of the potential risks prior to obtaining Lendo tokens. The Risk Statement details some of the potential risks that you should onsider. We reommend that you seek out independent finanial advie before engaging in any sort of business endeavour.

3 Legal Dislaimer Abstrat Value Proposition For Borrowers For Lenders For Merhants For ELT and Other Crypto-Curreny Holders Introdution to the Detailed Tehnial Whitepaper Tehnial Problem Desription Crypto Exhange and Payment Exhange/Payment Proessor Integration ELT as an aepted rypto urreny Crypto as Collateral Collateral Smart Contrat Collateral Seurity Lendo Aounts Lendo urrent aounts Lendo ELT savings aounts Lendo safety deposit Lendo rypto-baked loan aounts Lendo redit ard aounts General Payment Systems Lendo redit ard Lendo debit ard Coin for payment of Lendo Platform fees Ethereum Lendo Token (ELT) Lendo loyalty program Requirements Solution map Roadmap Lendo Solution Solution Overview Lendo Core Servies urreny exhange servie loan manager ard servies manager redit ard manager debit ard manager ard proessing gateway aount manager data analytis servie sheduler bath proessor doument manager loyalty program manager... 23

4 4.3. Lendo Smart Contrats Multi-signature ontrats Lendo ELT Coin Lendo Ie-Cold Storage Overview of the Lendo Vault System Lendo Admin Site Lendo Client Web Portal Lendo Lender Portal lender servie lender registration servie lender aount management servie Lendo Seure Merhant Portal Lendo Merhant Payment Gateway Lendo Card Issuer Software Development Proess Change management Continuous integration Design Priniples Software engineering priniples to adhere to Software engineering design patterns to be employed GDPR and Privay Appendix: Lendo Platform Arhiteture Components Gateways, Sites and Portals Card Management and Proessing System Loan Management System Components System Components Smart Contrat Code Ethereum Lendo Token Use Case Borrower/Lender Use Case Credit Card Holder/Lender Use Case Safety Deposit Use Case High level sequene diagrams Loan appliation Loan operation Credit ard appliation Credit ard authorization Credit ard operation Debit ard appliation Debit ard authorization Lendo Data Model Payment Proessing Networks List Appendix 1. The Loan Management System Interfae Loan appliation proess Loan management Repayments and Invoie Management Invoie arhive

5 1. Abstrat Lendo brings together the worlds of rypto and fiat urrenies to provide value for rypto holders and new markets for lenders and merhants. Lendo is powered by the Lendo Token, whih is known as the Ethereum Lendo Token (ELT). The ICO will reate this ELT rypto urreny and subsribers will own the initial supply Value Proposition Lendo is a lending platform whih will allow liensed and regulated lenders to lend fiat urreny against rypto ollateral The platform will provide loans, rypto asset trading, redit and debit ards and servies, and merhant servies. It will provide a omplete banking eosystem for rypto asset holders For Borrowers Many people who own rypto urreny want to hold on to it as a long-term investment. They don t always want to sell it when a short-term need for ash arises, suh as paying bills, buying a new omputer or a ar, beause they feel they will lose out on the potential gains of holding on to the rypto urreny. In addition, borrowing against a rypto asset arries potential tax benefits as ompared to selling it. Lendo rypto-baked Loans With Lendo these potential borrowers will be able to get an instant loan using their rypto urreny as ollateral while ontinuing to benefit from holding on to the rypto urreny. Lendo Credit and Debit Cards But it does not stop there! Lendo will also offer redit and debit ards for their aount holders so that they will be able to leverage their rypto urreny balane to either, bak a redit ard, or spend it in real time with the debit ard. The redit and debit ards will be usable in any ATM, or merhant aepting major redit ards For Lenders Loan ompanies urrently lend money to lients within their loal regulatory jurisdition. They an t provide loans to borrowers outside this area beause of the legal problems assoiated with making good on any defaults in loan repayments. Lendo will offer lenders the mehanisms to aept rypto ollateral and to reover value in the ase of loan default ompletely outside of any ourt and regulatory jurisdition. With Lendo they will be freed from geographial restritions and will be able to offer rypto baked loans worldwide 1.4. For Merhants There are a few solutions that allow merhants to aept rypto diretly. Lendo will offer merhants a Software as a Servie (SaaS) solution that an be aessed diretly via the web or with optional Point of Sale (POS) hardware, whih will allow them to aept rypto urreny for purhases in real time. This will allow merhants to aept rypto urreny from anyone who holds any of the rypto urrenies to be listed in our exhange, inluding ELT For ELT and Other Crypto-Curreny Holders Lendo Vault The Lendo Vault is one of the world s most seure ie-old storage vaults and Lendo lients will be able to store large amounts of rypto there seurely in Safety Deposit Aounts. Furthermore, the whole sum deposited is insured against loss. Lendo harges fees for the use of the vault payable in ELT. 5

6 Lendo ELT Token Saving Aount Lendo will inentivise ELT holders to keep their oins out of irulation by providing a token savings aount that pays for the ELT to be loked in the vault for lengthy periods. The holders gain two ways: - they get a steady monthly bonus of ELT and if the prie of ELT inreases the value of their ELT token savings inreases. Lendo Loyalty Program In order to pay fees, all users of the Lendo platform use ELT. Eah quarter Lendo will distribute 30% of all the ELT fees olleted, bak to ELT holders in proportion to how muh and how long they have held the ELT that quarter. The benefits are twofold: Firstly, holders get token bonuses eah quarter Seondly the loyalty program provides downwards pressure on token sales, pinhing the market at the supply side to drive up token value 6

7 2. Introdution to the Detailed Tehnial Whitepaper This doument fouses on the detailed tehnial aspets of the Lendo Platform inluding tehnial speifiations of the produts and features, the proposed development approah, the tehnologies, and tehnology partners seleted, and design hoies that have been made. We ll look in detail at how we will ensure that our systems are seure and your rypto is safe. This doument is aimed at a tehnially savvy audiene (engineers and senior tehnology analysts) and is provided in the interests of transpareny and so that they an properly evaluate our approah. For a ommerial, business development or investor fous please see the ommerial white paper. That paper goes into more detail about the business problem Lendo is solving as well as how we plan to establish our market position. Important note: At this stage it is inevitable that some of the assumptions we make now will be hallenged during or after implementation. We may find better tehnologies, better solutions and better tehnology partners. This doument represents our urrent thinking, but we reserve the right to ontinue to improve on our development plans. 7

8 3. Tehnial Problem Desription 3.1. Crypto Exhange and Payment In order to provide a platform in whih rypto and fiat urrenies an exhange value for loans and payments we need to provide seamless aess to a marketplae where owners of a urreny an sell to buyers of that urreny. So, one of the first requirements is a rypto exhange Exhange/Payment Proessor Integration Lendo needs to be able to quote real-time pries for: Lendo rypto-loan ollateral amounts Lendo redit ard ollateral amounts during redit ard appliation Lendo debit ard purhases at the point of sale Merhant transations made on Lendo merhant terminals or the Lendo merhant web portal Furthermore, Lendo will need to onvert and transfer urreny at the quoted rate: During a Lendo debit ard purhase operation During purhases made on a Lendo merhant terminal During ad-ho urreny exhange operations by lients on the Lendo lient portal The Lendo Platform will therefore need to integrate with a servie provider that an: Provide real-time prie information for urreny pairs, e.g. $ETH/BTC meaning that to buy one ETH you d have to pay BTC Exeute the transation one it is approved, transferring the purhased urreny diretly to our Lendo aount for our subsequent disbursement ELT as an aepted rypto urreny In order to use ELT in transations in all of the above ways (rypto-loans, redit and debit ards, and merhant payments) ELT must be listed on at least one exhange. It is a high priority requirement that Lendo will seek the introdution of ELT into various rypto exhanges. Lendo has begun initial disussions with the Gibraltar Blokhain Exhange (GBX) and are atively pursuing other opportunities Crypto as Collateral Aepting rypto as ollateral is a relatively new onept. The main requirements here are that the whole agreement is tied up in a Smart Contrat and that the ollateral is kept very safely during the term of the ontrat Collateral Smart Contrat In order to be able to use rypto as ollateral the Lendo Platform needs to be able to sequestrate the rypto, tying it up with a ontrat that will: release enough rypto to the lender to over the remaining loan balane and returning the remainder to the borrower in ase of default or return the rypto to the borrower in ase of full loan repayment Lendo will use Ethereum Smart Contrats to lok up any type of rypto urreny and will program rules ontrolling how the funds are to be subsequently disbursed. The rypto is not transferred to the smart ontrat diretly but aess to the private key ontrolling any disbursement of the rypto from the vault an only be gained via outputs of the smart ontrat funtions that implement the rules. 8

9 Lendo rypto-baked Loans In the ase of ollateral being used for rypto-baked loans we need to take into onsideration the ases where: The lender and borrower agree that the loan has been paid bak so they agree to release funds to the borrower The lender and borrower agree that the loan has been defaulted on and agree to release partial funds to the lender to over the remaining balane and any agreed early termination ondition and the remainder of the funds to the borrower The lender believes the loan has been defaulted on, but the borrower does not. After a pre-agreed period, and arbitration from Lendo if Lendo now agrees that the loan is in default, partial funds release is authorised to the lender to over the remaining balane and any agreed early termination ondition and the remainder of the funds are released to the borrower The lender will also have the ability to unilaterally hoose to derease the amount of ollateral held if ertain onditions arise, suh as the prie of the rypto used for ollateral going up, or a signifiant amount of the loan being repaid. In this ase Lendo will o-sign the transation For some other reason the borrower requests Lendo to terminate the agreement, and Lendo, after reviewing the request agrees, partial funds release is authorised to the lender to over the remaining balane and any agreed early termination ondition, and the remainder of the funds are released to the borrower All these onditions will need to be implemented in a Smart Contrat that overs the ollateral assoiated with a loan. This will require multiple signatures to release the funds and onditions around the aeptane of the multiple signatures. Lendo rypto-baked redit ards In the ase of ollateral being used for rypto-baked redit ards there is no loan, just redit! So, the borrower will pay no interest eah month. This means that the ontrat ontrolling these loans will need to take the following into onsideration: Lendo and ard-holder agree that the ard balane has been paid bak so they agree to release ollateral to the ard-holder Lendo and ard-holder agree that the redit ard agreement has been defaulted on in some way and that the ard-holder is not able, or refuses, to pay bak the ard balane, so they agree to release partial ollateral to Lendo to over the remaining balane and the remainder of the ollateral to the borrower. Externally to the Smart Contrat they will have agreed to lose the redit ard aount. Lendo believes the redit ard agreement has been defaulted on, but the ard-holder does not. After a pre-agreed period, and independent arbitration if it is indeed determined that the redit ard agreement is in default, partial ollateral release is authorised to Lendo to over the remaining balane and the remainder of the ollateral is released to the ard-holder The lender will also have the ability to unilaterally hoose to derease the amount of ollateral held if ertain onditions arise, suh as the prie of the rypto used for ollateral going up. In this ase Lendo will o-sign the transation. For any reason the ard-holder requests Lendo to terminate the agreement, Lendo, will authorise partial ollateral release to Lendo to over the remaining balane sending the remainder of the ollateral to the borrower. All these onditions will need to be implemented in a Smart Contrat that overs the ollateral assoiated with a redit ard loan. 9

10 Lendo ELT savings aounts Lendo will also offer ELT savings aounts. These differ from the urrent aounts it offers in that they are for ELT urreny only but an t be aessed until the end of the term they are being saved for. Eah month the savings aount holder will be remunerated in ELT for having kept the ELT tokens out of irulation that month. The rypto is stored in Lendo s old storage vault. This means that the ontrat ontrolling the rypto in these aounts will need to take the following into onsideration: At the end of the ontrat term the funds are released to the aount holder. All these onditions will need to be implemented in a Smart Contrat that overs the ollateral assoiated with an ELT savings aount. Lendo safety deposit aounts Lendo will also offer safety deposit aounts, enabling anyone to make use of our high seurity vault, and will harge vault fees in ELT. They are intended for storing relatively large amounts of rypto urreny, but the urreny does not need to be ELT. Though it an t be aessed immediately, it an be aessed with a short notie period used to retrieve the aess keys from ie-old storage. The rypto is stored in Lendo s old storage vault. This means that the ontrat ontrolling the rypto in these aounts will need to take the following into onsideration: The aount holder unilaterally agrees to withdraw some or all of the funds so some or all of the funds are released to the aount holder If, for any reason, Lendo deems it neessary to lose the aount the funds are released to the aount holder. All these onditions will need to be implemented in a Smart Contrat that overs the ollateral assoiated with a safety deposit aount Collateral Seurity The sequestered rypto needs to be kept seure while it is in our ustody, so we need to employ the stritest levels of seurity. We must keep eah user s rypto in separate wallets to eliminate the possibility of one stolen key being able to drain all aounts. These wallets must not be onneted to the Internet to prevent the keys they ontain from being aessible and open to haking attempts. This type of wallet is known as Cold Storage. We must physially restrit aess to the air-gapped omputer system (Cold Storage) with biometri as well as ryptographi ontrols We must enrypt data in flight, and at rest both in Cold Storage as well as while in transit to it on sneakernet Bakups of the Cold Storage database must be enrypted and proteted with further seurity measures to ensure that anyone obtaining aess to the bakup media will not be able to reonstrut the keys Bakups must be held in separate geographial regions to the Cold Storage system to prevent against loss due to loal or regional disasters One the bakups are stored in the remote loations the original data must be removed from the air-gapped system Aess to off-site bakups loations must be ontrolled by biometri means All aess must be audited 1. Sneakernet is an informal term for the transfer of eletroni information by physially moving media suh as magneti tape, floppy disks, ompat diss, USB flash drives or external hard drives from one omputer to another; rather than transmitting the information over a omputer network 10

11 The terminology here may be a bit onfusing here so to larify here is a definition of a ryptowallet: Cryptourreny wallets are software programs that store your publi and private keys and interfae with various blokhains so users an monitor their balane, send money and ondut other operations. When a person sends you bitoins or any other type of digital urreny, they are essentially signing off ownership of the oins to your wallet s address. In order for a purhase transation you make to be able to spend those oins and unlok the funds, the private key stored in your wallet (and used to sign the transation) must math the publi address the urreny is assigned to in the blokhain. If publi and private keys math, the balane in your digital wallet will derease, and the reipient s address (from the transation) will inrease aordingly. There is no atual exhange of real oins. The transation is signified merely by a transation reord on the blokhain and a hange in balane in your ryptourreny wallet. In our ase the wallet is something we re going to be referring to as the Lendo Cold Storage Vault. But we need to also make sure that it is only aessible under the onditions speified in the assoiated Smart Contrat (see Collateral Smart Contrat). This means the addition of a few more requirements The wallet in whih the rypto will be sequestered must be aessible only when the onditions in the assoiated smart ontrat are met. This means that the sequestered rypto urreny must be sent to the Smart Contrat and that only the Smart ontrat must be able to transfer the funds anywhere aording to the programmed rules Finally, this means that the Lendo Cold Storage wallet will need to hold the private key that allows ontrol of the Smart Contrat, thus ensuring that only those with aess to that wallet s ontents an transfer funds This will mean that any sequestered funds will be assoiated with a smart ontrat that is visible and available for inquiry publily. It will also be registered, that the funds have been transferred to the smart ontrat, in the publily aessible blokhain of the rypto urreny onerned. It is important to note that private key for aess to this Smart Contrat will have been reated in Lendo s old storage vault and will have never been on any system onneted to the internet Lendo Aounts Lendo will provide five main types of aounts Current aounts ELT Savings aounts Safety Deposit aounts Loan aounts Credit ard aounts Lendo urrent aounts Lendo urrent aounts are wallets that an ontain various types of urreny, rypto or fiat. These aounts are for day to day use and so transations will need to be made immediately whenever the user requires it. The type of wallet used here is a hot wallet. This is the least seure type of wallet, but it allows for transations to be made immediately. Users will be urged not to store large amounts of rypto in urrent aounts. 11

12 Current aounts will be used for general trading, paying fees and as the soure for Lendo debit ards Lendo ELT savings aounts ELT Savings aounts allow lients to lok up ELT for extended periods. The ELT is loked in the Lendo time vault and annot be withdrawn for any reason before the term. They are paid a fee in ELT by Lendo eah month. These aounts, in effet, earn interest eah month although it is not ompound interest as the new ELT is not added to the prinipal Lendo safety deposit Lendo safety deposit aounts are for storing lient s rypto. They will be stored in the most seure wallets on the planet, but these wallets won t allow immediate aess. The funds will be sent into Lendo s old storage vault. Lendo will harge a fee for this servie Lendo rypto-baked loan aounts Lendo s main business will be to provide rypto-baked loans. For this Lendo will provide loan aounts that ontain the rypto-ollateral and its urrent value in the market. This will also be stored in Lendo s old storage vault. Aess to these funds will be ontrolled via a smart ontrat that will restrit withdrawal of funds to onditions speified in the loan agreement Lendo redit ard aounts Finally, Lendo will provide redit ard aounts linked to their lient s Lendo redit ards. The funds in this aount will not be aessible diretly, but will instead be ontrolled by the smart ontrat that restrits withdrawal of funds to onditions speified in the redit ard agreements General Payment Systems Lendo plans to leverage the basi platform features above to provide payment solutions for its users and for merhants wishing to aept any rypto for payment Lendo redit ard Lendo will leverage the loan platform to provide a guarantee deposit with our ard issuer to enable them to issue of redit ards on our behalf. Lendo will partner with a major redit ard issuer to deliver this servie seamlessly to its lients. Lendo will need to provide programmati aount aess for real-time authorizations as well as integrations for ard aount provisioning and setup. Lendo will also need to work with the partner to reate a robust settlement system. Lendo will maintain a large balane in an operating aount with the partner so that authorisations and settlement will not have to wait until funds are transferred. This will allow Lendo lients to apply for redit ards by submitting an amount of rypto urreny that will be held as ollateral against the ard limit. From here on the ard aount will funtion exatly like any other redit ard Lendo debit ard Lendo will also offer its lients the possibility of applying for Lendo debit ards. These ards will be linked to their Lendo urrent aounts. They will selet whih aounts are to be used and in whih priority order. When they want to make a purhase with their ard rypto from these aounts will be exhanged for fiat urreny to over the harge in real time. Behind the senes Lendo will get a quote for the rypto that needs to be sold to determine how muh to sell. This amount is sent to the terminal for onfirmation. This amount inluding any fees and an amount to hedge against exhange rate hanges during settlement, will then be debited from the ard holder s Lendo urrent aount and be redited to Lendo s operating aount. Lendo will authorise the transation. 12

13 Lendo will maintain a large balane in an operating aount with the partner so that authorisations and settlement will not have to wait until funds are transferred. Lendo will leverage the exhange platform s quotation servie to be able to determine the ask prie for the urreny pair required for the purhase. Lendo will partner with a major redit ard proessor/provider to provide this servie seamlessly to Lendo lients. Lendo will need to provide programmati aount aess for realtime authorizations as well as integrations for ard aount provisioning and setup. During settlement Lendo will need to make the urreny trade whih will use the agreed amount of rypto from the lient s aount. Note that rypto stored in the user s urrent aount will be stored in Lendo s hot wallet. Users are generally autioned not to store large amounts of rypto in any hot wallet in ase the wallet provider is haked, and they lose their rypto. By ontrast the Lendo redit ard will be able to be used for large redit limits as the rypto will be stored in Lendo s old storage vault for omplete peae of mind Coin for payment of Lendo Platform fees Use of the platform will require payment of fees. Fees will be harged for aess to our old storage vault. Fees will also be harged for urreny exhange and ard purhases. To enable these fees to be paid without requiring learing banks (and related fees) our own token needs to be reated and aepted. This token needs to be tradeable for other tokens in the Lendo exhange. Fees an only be paid using ELT Ethereum Lendo Token (ELT) For this reason, Lendo will reate a rypto urreny to be alled the Ethereum Lendo Token. It will live on the Ethereum blokhain and must be a standard ERC20 oin that implements the ERC223 protool. It must be enhaned to provide the ability to add features over time and be resilient to as yet unknown rypto attaks Lendo loyalty program Eah quarter Lendo will distribute 30% of all the fees olleted, bak to ELT holders in proportion to how muh and how long they have held the ELT that quarter. The platform needs to alulate this amount on a quarterly basis and automatially transfer oins to over the bonus to the ELT holder s aounts. This requires that the platform keep trak of all holders of ELT oin so that it will know who held them in the last period and for how long. 13

14 3.6 Requirements - Solution map Multi Curreny Wallet Fiat Crypto Lendo Exhange Fiat & Crypto Quotations trades Crypto Curreny Exhange Crypto as Collateral Lendo Vault Warm Wallet Cold Storage Vault Deep Cold Storage Vault Loan System ELT Coin Loyalty Program General Payment System Credit ard system Credit Card Debit ard System Debit Card Merhant Payment System 14

15 3.7 Roadmap OCT 2016 Lendo ommenes strategy and onept planning FEB 2017 Leno founders appoint management and feasibility team Q Lendo forms UK ompany & hires full operational & teh team. Q Preliminary approah to GBX Q PRE ICO Start ICO Q Lendo website goes live Q Lendo establishes Singapore ompany through whih future operations will be onduted, in order to benefit from the ICO-Friendly environment BTC wallets offered to Lendo ustomers Q ICO end Q Credit and Debit ards available to Lendo ustomers ELT to be listed on exhanges IBAN aounts available to lendo ustomers Q Merhant system to be offered to Lendo ustomers Q UK Pilot lending operations ommene Q Beta version of Lendo Vault to be launhed Q Global lending Operations to Commene Vault fully operational 15

16 4. Lendo Solution The following sub-setions desribe the tehnial solution being developed by Lendo as part of its platform solution 4.1 Solution Overview Lendo will be implemented as a set of miro-servies that will together provide the Lendo platform servies. Eah individual servie will be designed to be deoupled mono-funtional entities so that they an be saled, proteted and loated appropriately to their funtion. Eah servie will typially maintain its own database for information for whih it is the authority and will ommuniate with other servies via internal APIs and message busses where it is not. The following sub-setions desribe in detail the various parts of the Lendo solution. 4.2 Lendo Core Servies The Lendo ore servies provide the servie API for the majority of the Lendo servies. All of the publi faing servies integrate with the ore servies. The ore servies inlude the following miro-servies. urreny exhange servie quotation servie hedge management loan manager ollateral manager ard servies manager redit ard manager debit ard manager 16

17 ard proessing gateway aount manager data analytis servie sheduler bath proessor doument manager loyalty program manager urreny exhange servie To provide urreny exhange servies between 300+ rypto and fiat urrenies. To provide information about whih urrenies are available and to provide quotations for individual urreny pairs. To interfae with rypto urreny hedge providers to offer Lendo and its lender partners the possibility of purhasing hedging failities for short and long-term positions they take respetively. In our initial implementation we will partner with CoinPayments, the leading rypto payments proessor. CoinPayments API will allow us to make transfers from users or internal aounts to any other user, aount, lender or merhant, with or without urreny onversion, instantly! quotation servie CoinPayments offer an API that allows us to quote pries for any of 300+ urrenies (fiat and rypto) and their over 100k ombinations. We will store historial values for these urreny ombinations so that we an provide aggregated values to the ollateral alulator hedge management We will identify partners who will be able to offer us hedging failities based on short and longterm positions and various other parameters loan manager The loan manager will handle all aspets of loan proessing. Loan appliation (aount reation, approval, onfiguration) Loan information requests (statements, transations, balane, payments) Loan disbursement (sending loan amount to borrower) Loan aount management (request aount losure, request loan inrease, request to partially disenumber ollateral) ollateral alulator The amount of ollateral for a given loan amount The loan amount offered for a given ollateral amount The amount of ollateral required for a loan or to bak a redit ard is alulated by the ollateral alulator. The alulator also omputes the amount of loan that will be offered for a given amount of ollateral. This little servie ommuniates with the quotation servie to determine the urrent and historial values. The alulator will take the lowest of the average quotation over the last 3 months and the urrent prie and uses that as the base value. Eah approved lender in the Lendo Platform onfigures values for their loan alulation. The 17

18 most important is the Loan to Value (LTV). This figure is typially around 60% meaning that the lender will offer the borrower a loan of 60% of the base value alulated above. The ollateral alulator will ommuniate with the lender servie (see lender servie) to determine the LTV for a partiular lender and ombine it with the base value to return the amount of ollateral required ard servies manager Lendo will offer redit and debit ards. These redit ards will be from a major redit ard network and will therefore work anywhere major redit are aepted. This servie will handle the following general requests onerning all ards: New ard appliation List ards Closing the ard aount In order to get a Lendo redit ard a lient will need to deposit rypto as ollateral in the Lendo old storage vault. All Lendo lients will be approved for this type of ard as long as they meet the minimum ollateral requirements Credit Card Appliation Proess The ard servies manager will inlude a workflow to apply for a redit ard. To apply for the redit ard the Lendo lient simply selets either the amount of redit required on the ard or the amount of rypto to use as ollateral. The system will use the ollateral alulator to selet an amount of ollateral that orresponds to the redit limit entered by the user if this is the user s hoie will do the reverse to alulate the redit limit if ollateral amount was hosen (see ollateral alulator). The offer will then be displayed. The offer will inlude the amount of ollateral, the proposed ard limit and any Lendo redit ard terms. The appliant will have to agree to the terms before ontinuing. One that is done, the system will wait until the appliant transfers the ollateral to the Lendo old storage vault, and then the ard will be approved. The ollateral stays in the vault until the ard aount is losed at whih time a request is made to reover the rypto and return it to the ard holder. Lendo will pre-authorise the redit ard aount to the redit limit. This redit ard an then be used throughout the month for purhases up to the redit limit. Settlement will be from a Lendo operating aount designated for redit ards. It is topped up at the end of eah month paying bak the balane to the Lendo operating aount. The amount of the top up an be as little or as muh as the ard holder hooses when paying the monthly ard payment. See the Appendix Credit ard appliation for more detail on the appliation proess. Note that the ard holder will ontinue to own the rypto used for ollateral and will make money on that ollateral when it is finally returned (assuming the ollateral has risen in value at that time). 18

19 Debit Card Appliation Proess The ard servies manager will inlude a workflow to apply for a debit ard. To apply for the redit ard the Lendo lient simply sets up the priority of the aounts to be used for debit ard. See the Appendix Debit ard appliation for more detail on the appliation proess Closing a redit ard aount The ard servies manager will inlude a workflow to lose a redit ard aount. To lose a redit ard aount, the ollateral will need to be returned to the ard holder. To do this the system marks the ard as losed to avoid any new purhases. The system will alulate the final ard balane inluding any mandatory fees that have already arued in the urrent month but have not yet been billed. The ollateral will need to be retrieved from old-storage so during that time the value of the ollateral may hange, so the final alulation is deferred until the ollateral is in warm storage. The system then alulates the differene between the ard balane and the value of the ollateral at that time. The differene is sent to the ard holder and whatever remains is taken by Lendo to over the defiit. If there is insuffiient ollateral to over the ard balane amount, then all of the ollateral is sent to the Lendo aount and then the hedge option is exerised to return the value of the hedge to Lendo as well Closing a debit ard aount To lose a debit ard aount the proess is very simple. There is no ollateral to return, so the system will simply mark the aount as losed and from then on, all authorization requests on the ard will be delined redit ard manager The redit ard manager will be responsible for: Providing statements Listing transations Requesting harge baks Monthly usage and payments Eah month the ardholder will be able to spend up to the pre-determined limit. Fees harged will over the old storage osts and other expenses. 19

20 As with other redit ards the ardholder will reeive monthly statements detailing the ard usage. Bill payment will be able to be set up to: Automatially pay off the balane Automatially pay a minimum payment or Manual the ardholder will need to transfer money eah month to make at least the minimum payment Credit Card multi-signature ontrat To protet the ollateral, it will be transferred to Lendo s old storage vault, whih will be a multi signature wallet, that will regulate how funds an be withdrawn. See 4.3. Lendo Smart Contrats for more information Credit ard purhase authorization using the ard Holders of this ard will have the exat same experiene using the ard as they would have with any other redit ard. Imagine the following senario where Sam wants to buy 100 of books from Dave s bookstore using his pre-paid Lendo redit ard: 1 The whole proess starts when Sam uses his Lendo Credit Card to purhase 100 worth of books at Dave s bookstore. Dave has a regular redit ard terminal that takes major redit ards. 2 Dave s terminal onnets to his payment proessor. His aount is onfigured with a Merhant aount that is to be redited one the payment has been approved. 3 Dave s payment proessor sends the request to the proessing network for approval. The major redit ard network operator reeives this request and determines the institution that it needs to ontat for approval 4 In this ase it s a Lendo Credit Card so the major redit ard proessing network will ontat Lendo Card Issuer. This servie is provided by a third-party ard proessor. 5 The Lendo Card Issuer will first hek that Lendo has enough money on deposit with them and will then ontat Lendo to attempt to get authorization for the 100 purhase. Lendo will hek Sam s Lendo Card Aount available redit balane to may see if its greater than 100. If it is it will authorize the transation and debit the aount. 6 From this point on the transation is authorised. The Lendo Card Issuer reeives the authorization and passes it bak to the major redit ard proessing network. It also debits Lendo s holding aount with Dave s Bookstore 3 Proessing Network 5 Sam s Lendo Card Aount 10 $100 payment $100 Goods Dave s Proessor & Merhant Aount 8 Lendo Credit Card Proessor 6 20

21 7 The major redit ard proessing network notifies Dave s Merhant Payment Proessor 8 The Proessor redits the Merhant Aount 9 Finally, Dave s Terminal will show the transation approved 10 Sam Gets his books happy that he s paid with his Lendo redit ard! debit ard manager For debit ards we ll use a payment proessor CoinPayments.net. This is the largest proessor of oin payments in the world. We will link this diretly to the ardholder s debit ard aount and make API alls to the payment interfae on the fly Debit ard purhase authorization using the ard Imagine a similar senario but this time Sam uses his Lendo debit ard: 1 The whole proess starts when Sam uses his Lendo Debit Card to purhase 100 worth of books at Dave s bookstore. Dave has a regular redit ard terminal that takes major redit ards. 2 Dave s terminal onnets to his payment proessor. His aount is onfigured with a Merhant aount that is to be redited one the payment has been approved. 3 Dave s payment proessor sends the request to the proessing network for approval. The major redit ard proessing network reeives this request and determines the institution that it needs to ontat for approval 4 In this ase it s a Lendo Debit Card so the major redit ard proessing network will ontat our Lendo Card Issuer. This servie is provided by a third-party ard proessor. 5 The Lendo Card Issuer will first hek that Lendo has enough money on deposit with them and will then ontat Lendo to attempt to get authorization for the 100 purhase. Lendo will hek Sam s Lendo Card Aount urrent aount balanes in priority order to see any amount if onverted to fiat urreny is greater than 100. If it is it will authorize the transation and then debit the aount and onvert rypto the on the fly using CoinPayments. The fiat urreny will be sent to Lendo s debit ard proessor s bank aount during the settlement proess. 1 Dave s Bookstore 3 Proessing Network 5 Sam s Lendo Card Aount 10 $100 payment $100 Goods Dave s Proessor & Merhant Aount 8 Lendo Debit Card Proessor 6 21

22 6 From this point on the transation is authorised. The Lendo Card Issuer reeives the authorization and passes it bak to the major ard proessing network. It also debits Lendo s holding aount with The major ard proessing network notifies Dave s Merhant Payment Proessor 8 The Proessor redits the Merhant Aount 9 Finally, Dave s Terminal will show the transation approved 10 Sam Gets his books happy that he s paid with his Lendo debit ard! ard proessing gateway The ard proessing gateway is the system omponent through whih all ommuniation from the third-party Lendo ard issuer will pass when it wants to ommuniate with Lendo. It is used solely during the purhase authorization proess as desribed above (See Credit ard purhase authorization using the ard and Debit ard purhase authorization using the ard ) aount manager The aount manager will provide aess to lient aounts (wallets). These aounts will be able to store a variety of urrenies and are of one of six different types: Current Aount ELT Savings Aount Safety Deposit Aount Loan Aount Credit Card Aount Debit Card Aount This servie will provide the following APIs: Create Aount (name, type, urreny) only for reation of urrent aounts List aounts Show Balane, Show onverted balane (in terms of fiat) List Transations data analytis servie The data analytis servie will be used to analyse and data mine the vast amount of operational data that the platform will produe. It will power administrative funtions like searh and will enable seurity systems to monitor for intrusion and anomalous behaviour. It will also be key to our finanial reporting enabling online analytial proessing for management information systems and driving regulatory ompliane sheduler The sheduler will trigger jobs that need to be arried out on a shedule. We will use a quartz sheduler bath proessor The bath proessor will be used to exeute funtions on bathes of entities at a time. We will use SpringBath. 22

23 doument manager The doument manager is the servie that manages the KYC douments and other douments that are ingested into the platform. The servie will need to take speial are about the seurity of these douments as they ontain extremely important PII data. They must be enrypted at rest, and aess to administrative and support sreens where these files an be viewed must be restrited by role and eah aess must be audited. GDPR requirements will apply espeially strongly to these douments. The doument manager will be responsible for implementing the GDPR requirements and Lendo s Data Protetion Offier (DPO) will be responsible for making sure it does. The solution must be high availability at least five nines. Additionally, the solution must inlude protetion for its douments by providing at least one out-of-region replia. The doument manager will allow for the following APIs: CRUD for douments Setting ACLs for douments by user and group Tagging and enrihing Doument organization We will try to identify the best online doument management servie or ommerial doument management software that we an integrate to provide the required features loyalty program manager Holders of ELT oin will be rewarded eah quarter. In order to do this, we need to determine what the aounts of all of the holders of ELT are. We also need to determine the total amount of fees that have been olleted. The formula is as follows: Determine the total tokens (TTIC) in irulation this period Calulate total fees paid (TFP) in ELT this period Perentage of fees paid reserved for loyalty program (LP) = 30% Determine the loyalty inentive per token (LIPT) amount = (TFP x LP ) / TTIC For eah token owner: (to determine list of token owners we will subsribe to Transfer events from ERC223 token and will keep trak of all oin movements and store the addresses and balanes of eah address. We an use these addresses to know where to transfer the arued ELT after alulation) Prorate the token ownership (TO) for period on a per token owner basis Calulate ELT oin seonds as number of seonds oin is held during the period Aggregate all ELT oins to give total oin seonds this period Divide by number of seonds in this period to give ownership per period Calulate loyalty inentive = TO x LIPT Transfer to token owner address alulated loyalty inentive worth of ELT 4.3. Lendo Smart Contrats The Lendo smart ontrats are written for Ethereum in Solidity For transpareny they will all be published on github (see vault-aggreement) and the ontrat ode will be verified so that the ode will be visible on Ethersan. Lendo will produe one smart ontrat that will be parameterised for the following purposes: 23

24 Lendo rypto-baked loan smart ontrat Lendo rypto-baked redit ard ontrat Lendo ELT savings aount ontrat Lendo safety deposit aount ontrat Multi-signature ontrats The ontrats will be multi-signature ontrats but will use a very simple algorithm to avoid the risk of haking Lendo ELT Coin The Lendo ELT oin is an Ethereum smart ontrat that implements the ERC223 token protool. For transpareny it is published on github (see and the ontrat ode is verified so that the ode is visible on Ethersan. The token is upgradeable using the proxy method and employs assembler to aess return values from the proxy funtions. When the version is updated an event will be triggered to alert any interested parties to the hange. The total supply is set to 1.2 billion and the deimal preision is Lendo Ie-Cold Storage The Lendo old storage vault is an ie-old storage vault. In this doument and in ommerial literature we refer to it simply as the Lendo Vault for short, but in this setion where we need to explain its operation we need to desribe its omponents Lendo ie-old storage vault Lendo old storage vault Lendo warm wallet Getting rypto into and out of the ie-old storage vault involves passing through these three separate vaults. Lendo ie-old storage vault This means that the keys are enrypted, split into three parts, dupliated and then distributed two at a time to three geographially distint loations, where they are physially and biometrially proteted. Two of the three loations will need to be aessed in order to reonstrut the enrypted key and then a password will be required to deode the key. This reonstrution an only be done in our old storage vault. Lendo old storage vault Our old storage vault is a server that is air-gapped not physially onneted to the Internet. The only aess is by physially sitting at the terminal of the vault omputer system. Lendo warm wallet The warm wallet is in fat online but the keys that ontrol the wallets there are in ie-old storage, so it s alled a warm wallet. One an transfer rypto into the wallet but an t get it out exept by going to the ie-old storage vault. 24

25 Overview of the Lendo Vault System Lendo has designed a very seure vault system inluding a warm wallet, a old storage vault and an ie-old storage vault where funds an be deposited in real time into ie-old storage using the warm wallet but annot be withdrawn exept by making a request that will take over a day to fulfil. Furthermore, all funds going into the vault system are ontrolled, either diretly or indiretly, by smart ontrats on the Ethereum blok hain. Cold storage defines a storage loation for ryptographi keys that is not onneted to the internet. Ie-old storage is a loation that adds physial seurity around aess to these loations suh as biometri ontrols and physial seurity measures like an atual metal vault! For obvious seurity reasons the atual loations of the vaults (the vault omprises multiple loations) will never be made publi, eah loation however will be subjet to military grade physial seurity in addition to the digital seurity measures devised by Lendo. Before we get into explaining the shemati above and show how rypto-urrenies (oins, alt-oins, and tokens), an be plaed in the Lendo vault, let s take a moment to see why oldstorage is so important Overview Why is old-storage important? Aess to the value in any rypto urreny is ontrolled through the owner of an address. An address is the standardised representation of all, or part, of the publi key part of a ryptographi key pair. Though address generation and format differ depending on the type of oin, or token, ownership of the address is proved by demonstrating aess to the private part of the key pair. Key pairs have two parts a publi and a private part and they work beause when something is enoded with either of the parts it an be deoded ONLY with the other key part. The number of permutations of possible values for a key is so great that it would take an impossible amount of time to try to guess the other key. So, if we an keep the private key really private, then we an prove that we are the owner of the aount by simply signing (enrypting) something using this private key, and everyone an verify that its true by deoding it with the publi key. On the other hand, now we need to be really areful to keep that private key really private, beause one anyone has it, they will be able to prove, irrefutably, that they are the owner of the aount ontrolled by that key. So, that s why it s so important to have a very seure wallet to store your rypto. When you store rypto in a wallet in fat you re just storing the private key there. Some ompanies hold billions of euros worth of rypto urreny on behalf of their lients. If a haker were to attak 2 Assuming total hashing power of the whole of the bitoin network as of 2017 = 2^ keys per seond for a 256-bit key we d need 2^256 / 2^ That s x 10^58 seonds. Or x10^54 hours. Or, x 10^50 years! Or written another way, 733,659,730,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years. The age of the universe, for omparison, is 12,799,000,000 years old! 25

26 the ompany and gain aess to the keys of their lients, they ould transfer all of the funds to their own aount and no one would know who they were or be able to reover the rypto. This has happened a number of times, and now it s no longer good enough to believe that a ompany will employ good seurity praties to protet the keys! It s just too tempting for hakers! So now the tendeny for large amounts of rypto is to not even keep the keys in a omputer that is onneted to the internet at all, so that it is simply impossible to get to it through the net! This is known as old storage - when keys are kept in a plae that is not onneted to the internet. They an be printed on paper, or on USB stiks or even embossed on ingots of gold! But then the problem beomes - how to protet those offline storage loations? Paper an burn in a fire, USB stiks an beome orrupted or lost, and gold an be stolen. And if you lose the key, you won t be able to aess the funds! In the following subsetions we ll look at the solution Lendo will use for the most seure ieold storage vault on the planet! Lendo Warm Wallet Lendo will implement a warm wallet that allows rypto to be transferred to it immediately, online, but to withdraw funds, aess must be made to the ie-old storage vault. The Lendo warm wallet aepts any supported oin, alt-oin or token. It is a truly multiurreny ie-old vault. 1 Getting a new wallet Eah time the system needs a new wallet the newcontrat() funtion is alled. This will go to the internal list inside the warm wallet to pull out a pre-reated ontrat. This ontrat simply needs to be initialised with the ontrat type that this request referenes. 26

27 This means that Only the vault will be able to transfer funds and only under ertain approved onditions The borrower will transfer the funds to this ontrat address and so the funds will immediately be in the old storage vault The funds pass diretly from the user s ontrol to old storage vault 2 Presenting transations for signing This ours when some ontrat provision regarding transfer of funds out of ie old storage is triggered. If the borrower has paid off the loan or has defaulted, the funds have to be withdrawn and distributed. In order to do this a transation for the disbursement of the funds has to be prepared and will be sent to the old-storage omputer to be signed and sent bak. 1) All rypto going into the Lendo Vault is assoiated with a smart ontrat (see 4.3. Lendo Smart Contrats). The newcontrat() funtion is alled to reate a new ontrat of the desired type and transfer the rypto to it. The implementation uses an internal list of previously reated ie-old storage vaults to set as the vault property in these ontrats. The vault is the only address that an transfer funds out of the ontrat so the funds are effetively in ie-old storage immediately 2) When it omes time to transfer funds based on some ontrat onditions being met the appropriate funtions are alled (with any required approval for multiple signatures), and the transation is reated and submitted to the warm vault system for subsequent signing by the ie-old vault. 3) After the proess of retrieving and reonstruting the keys from ie-old storage has taken plae an event will be emitted by the warm wallet to announe the availability of the signed transations. The event subsriber will submit the signed transation to the blokhain and the transation will be exeuted. 4) Mark all ontrats in the list available for use when reeiving a reeipt that the orresponding private key for an enrypted publi key is now in ie-old storage. 3 Piking up transations that have been signed One the transations have been signed on the oldstorage omputer they are added to the USB stik for the next synhronisation event. When they are piked up here two things happen. 1) The signed transation is submitted to the blokhain using a method appropriate to the type of urreny and blokhain, 2) an event is triggered to notify other parts of the Lendo system that the transation has been proessed and funds will soon be available. 27

28 If the transation requires multiple signatures, then the other parties are ontated so that they an sign the transation as well. 1 Synhronisation USB insert in warm-storage Shown to the right is the proess that takes plae eah time the administrator inserts his USB to synhronise data from the air-gapped old vault omputer. Periodially the system administrator will put his USB key in a speial terminal onneted to the warm vault and it will launh a synhronization job automatially, The synhronization job will: Transfer any new ie-old storage vault addresses to the warm wallet to be used in new ontrats Transfer any signed transations from the USB to warm storage to be announed in the next publishing event Clear all data from the USB stik Pik up any transations that require signing and transfer them to the USB stik for transfer to the air-gapped old storage system Add a ount of how many unused ie-old storage vaults remain in the warm vault. An internal proess inside the warm wallet system keeps a list of unused ie-old storage vaults, in the form of smart ontrats, ready for any requests that may ome in. Eah ontrat in this list ontains an address, in one of various formats. Coin addresses like bitoin and Ethereum, and supported alt-oin addresses as well. Note: Tokens are stored in addresses of their underlying oin or alt-oin implementation. The ontrats in the list ontain only the address derived from the ryptographi key-pair used to reate the address. The private key remains safely loked away in the ie-old vault and will have never resided in any omputer system that was onneted to the internet. Furthermore, the address in the ontrat in the list is enrypted using the publi key of the ontrat, so that it an only be read by the ontrat itself. This ensures that even if the private key for this vault were ever disovered, it would be useless beause the publi key would be loked inside the ontrat. The ontrat list is replenished eah time a key-synhronisation event happens between the old storage and warm storage. See Cold Storage Vault for information about the reation of the ie-old storage vault ontrats. The ontrats in the list will able be parameterised for use in: Loan ollateral aounts, redit ard aounts, ELT savings aount, or safety deposit aounts. 28

29 In eah ase the ontrat will have been initialised, in a two-step proess 1) Create the ontrat template, with default onfiguration. Pre-reate a large number of these to over antiipated demand. 2) Enrypt the address of an unused old vault using the publi key of the newly reated ontrat and pass the enrypted ypher text bak to the old storage omputer in the next synhronisation event. Don t yet mark the ontrat available for use! Cold Storage Vault Periodially the system administrator will take the same USB stik and plug it into the old storage vault. At that time the system will launh a synhronisation job automatially. 1 Synhronisation USB insert in old-storage The synhronisation job will: Transfer any new transations that need signing to the old vault omputer. Sign all transations that are in the old storage vault whose keys have been reonstruted from ie-old storage and add those signed transations to the USB stik. Delete the keys for these vaults from old-storage Send as many ie-old vault addresses to the USB stik as are required or as have been reated. Ie old vaults are reated in the old vault, but they are not used until the keys have been enrypted, split and then stored in the remote offsite storage loations. Only then are the vaults ie-old. As soon as the addresses are opied to the USB stiks, delete them from the old storage omputer. Send notifiations about whih keys have arrived at ie-old storage safely, bak to warm wallet via the USB stik 29

30 Lendo Ie- Cold Storage Vault Periodially any one of three authorised ouriers ome to the old vault. Eah one has password-ontrolled aess to a part of the set of keys that have been reated automatially by the old-storage system. The keys will have eah been split into three parts (1, 2, and 3), and then eah part dupliated (4, 5, and 6) and enrypted with eah of the ourier s passwords as follows: Bundle 1: Parts 1 and 2 are enrypted with ourier 1 s password Bundle 2: Parts 3 and 4 are enrypted with ourier 2 s password Bundle 3: Parts 5 and 6 are enrypted with ourier 3 s password This ensures that: Only two bundles are required to reonstrut the key set No one ourier an reonstrut the key set 1 On insert of USB stik in old-storage omputer Courier inserts eah USB stik into the old-storage omputer Load list of keys from ie-old storage Load list of reeipts from ie-old storage Courier piks up a blank USB stik and inserts it Courier types password to enrypt his bundle Copy appropriate bundle to USB stik Shipping notes: Also inluded for eah ourier is a printout of a list of USB stiks identifiers to reover from ie-old storage. Eah ourier takes his own bundle, and the list and transports it to the offsite ie-old storage loation that he is assigned to. 30

31 2 On arrival at the deep old-storage vault loation Eah ourier is assigned to a distint loation. Eah ourier will only be able to gain aess to the loation by passing biometrial ontrols as well as formidable physial seurity ontrols. Only when the enrypted key parts all are transferred to separate geographial loations and proteted with physial and biometri ontrols they are deemed to be in the ie-old storage vault. In this doument and ommerially we refer to ie-old storage as the Lendo old storage vault for simpliity. Using the list of USB stik identifiers, the ourier will selet the orret stiks and bring them bak to the old storage room. Eah time the ourier visits the room he will insert any keys he has brought bak from old storage and will enter his password to derypt them in the old-storage system Lendo Admin Site Various admin funtions inl. Verify KYC Add Lender Support for transfers to/from the old storage vault 4.7. Lendo Client Web Portal This is the site where lients go to: Register See history and onsult information Manage wallet Apply for and manage loans Apply for and manage ards See amount to derease loan ollateral and make request 4.8. Lendo Lender Portal lender servie Make and manage offers Administer loans Consult loan information for lenders lender registration servie Register new lenders Initial aount reation and onfiguration lender aount management servie Update aount details CRUD Loan offers Update default Loan to Value (LTV) amount 31

32 4.9. Lendo Seure Merhant Portal Merhant sign up Merhant aount management and aess Rebrand and resell CoinPayments solution in a web-based POS solution Lendo Merhant Payment Gateway Servie API for Merhant POS system to ommuniate with Lendo Integrates on the bak end with CoinPayments for fulfilment Lendo Card Issuer Lendo will partner with a white-label ard provider to provide our redit and debit ards. This provider is authorised and regulated by the Finanial Condut Authority in the UK as an Eletroni Money Institution and as a Consumer Credit lender. The ards will be branded as Lendo ards with the style, and logo under our ontrol. We will provide ontatless ards for more onveniene for the end user. Partnering with a third-party ard provider with expertise and experiene in this area provides us with a robust and seure integration platform whih we will leverage to maintain high levels of seurity while proessing ard payments. 32

33 4.9. Software Development 5.1. Proess - Change Management 5.2. Continuous Integration With the miro-servies arhiteture we will implement ontinuous integration where development spikes are small and are ontinuously integrated. Automation of the proess will be high, and fous will be on quality. TeamCity Cuumber Junit Mokito Selenium Loadrunner JProfiler SonarQube 33

34 6. Design Priniples 6.1. Software engineering priniples to adhere to We will adhere to the SOLID SRP Single Responsibility Priniple. A lass should have one and only one reason to hange, meaning that a lass should only have one job OCP Open/Closed Priniple Objets or entities should be open for extension, but losed for modifiation LSP Liskov Substitution Priniple. Every sublass/derived lass should be substitutable for their base/parent lass ISP Interfae Segregation Priniple. A lient should never be fored to implement an interfae that it doesn t use or lients shouldn t be fored to depend on methods they do not use DIP Dependeny Inversion Priniple Entities must depend on abstrations not on onretions. It states that the high level module must not depend on the low level module, but they should depend on abstrations 6.2. Software engineering design patterns to be employed MVC Clearly separate model, view and ontroller IoC and DI Inversion of Control Dependeny Injetion Miro Servies arhiteture Struture appliation as a set of loosely oupled servies that are very fine grained. Use ontainerization where possible GDPR and Privay Lendo will employ a fulltime Data Privay Offier (DPO) as presribed by GDPR regulations. This offier will ensure that: Software is built with privay and data protetion built in Proedures for data protetion and privay are adhered to All opt-in rules and opt-out failities are properly implemented Any data breah is reported in a timely manner 34

35 7. Appendix: Lendo Platform Arhiteture 7.1. Components Gateways, Sites and Portals merhant payment gateway lender servie IMerhant ILender lient portal admin site ard proessing gateway merhant portal lender portal ICardPaymentGateway ard payment proessor IVisaPaymentProessor 35

36 Card Management and Proessing System aount manager redit ard ontrat debit ard ontrat IAount lendo old vault lendo warm vault IWallet ard servies manager ICardOperations IExhange IHedge hedge management servie exhange servie ard proessing gateway IQuotation ICardPaymentGateway ICollateral quotation servie ard payment proessor ollateral manager IVisaPaymentproesso 36

37 Loan Management System Components aount manager IAount lendo old vault lendo warm vault loan ontrat lender servie IWallet IExhange hedge management servie IHedge loan manager exhange servie ILender ICollateral IQuotation loan ontrat ollateral manager quotation servie lender portal Loan Management System Components bath proessor IBathProessor analytis servie IAnalytis sheduler ISheduler IDoument doument manager 37

38 7.2. Smart Contrat Code Ethereum Lendo Token This is an ERC223 token build on the Ethereum blokhain. It is written in Solidity ELTToken ontrat ELTToken is VersionedToken, ELTTokenType { string publi name; string publi symbol; funtion ELTToken(address _tokenowner, string _tokenname, string _tokensymbol, uint _totalsupply, uint _deimals, uint _globaltimevaultopeningtime, address _initialimplementation) VersionedToken(_ initialimplementation) publi { name = _tokenname; symbol = _tokensymbol; totalsupply = _totalsupply * 10**uint(deimals); deimals = _deimals; balanes[_tokenowner] = _totalsupply; Transfer(address(0), owner, _totalsupply); globaltimevault = _globaltimevaultopeningtime; released = false; ELTTokenImpl ontrat ELTTokenImpl is StandardTokenExt { event UpdatedTokenInformation(string newname, string newsymbol); string publi name; string publi symbol; funtion ELTTokenImpl() publi { funtion () publi payable { revert(); funtion releasetokentransfer(bool _value) onlyowner publi { released = _value; funtion setglobaltimevault(uint _globaltimevaultopeningtime) onlyowner publi { globaltimevault = _globaltimevaultopeningtime; funtion admin(string funtionname, string p1, string p2, string p3) onlyowner publi pure returns (string result) { return funtionname; funtion settokeninformation(string _tokenname, string _tokensymbol) onlyowner publi { name = _tokenname; symbol = _tokensymbol; emit UpdatedTokenInformation(name, symbol); VersionedToken ontrat VersionedToken is owned { address publi upgradablecontrataddress; 38

39 funtion VersionedToken(address initialimplementation) publi { upgradablecontrataddress = initialimplementation; funtion upgradetoken(address newimplementation) onlyowner publi { upgradablecontrataddress = newimplementation; funtion() publi { address upgradablecontratmem = upgradablecontrataddress; bytes memory funtioncall = msg.data; assembly { let funtioncallsize := mload(funtioncall) let funtioncalldataaddress := add(funtioncall, 0x20) let funtioncallresult := delegateall(gas, upgradablecontratmem, funtioncalldataaddress, funtioncallsize, 0, 0) let freememaddress := mload(0x40) swith funtioncallresult ase 0 { revert(freememaddress, 0) default { returndataopy(freememaddress, 0x0, returndatasize) return (freememaddress, returndatasize) Owned ontrat owned { address publi owner; event OwnershipTransferred(address indexed _from, address indexed _to); funtion owned() publi { owner = msg.sender; modifier onlyowner { require(msg.sender == owner); _; funtion transferownership(address newowner) onlyowner publi { owner = newowner; OwnershipTransferred(msg.sender, newowner); ELTTokenType ontrat ELTTokenType { uint publi deimals; uint publi totalsupply; mapping(address => uint) balanes; mapping(address => uint) timevault; mapping(address => mapping(address => uint)) allowed; bool publi released; uint publi globaltimevault; StandardTokenExt ontrat StandardTokenExt is StandardToken { funtion istoken() publi pure returns (bool weare) { return true; 39

40 StandardToken ontrat StandardToken is TimeVaultToken { funtion inreaseapproval(address _spender, uint _addedvalue) publi returns (bool suess) { allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedvalue); emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]); return true; funtion dereaseapproval(address _spender, uint _subtratedvalue) publi returns (bool suess) { uint oldvalue = allowed[msg.sender][_spender]; if (_subtratedvalue > oldvalue) { allowed[msg.sender][_spender] = 0; else { allowed[msg.sender][_spender] = oldvalue.sub(_subtratedvalue); emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]); return true; TimeVaultToken ontrat TimeVaultToken is owned, ERC20Token, TimeVaultInterfae { funtion transferbyowner(address to, uint value, uint earliestretransfertime) onlyowner publi returns (bool) { TimeVaultInterfae transfer(to, value); timevault[to] = earliestretransfertime; return true; funtion timevault(address owner) publi onstant returns (uint earliesttransfertime) { return timevault[owner]; funtion getnow() publi onstant returns (uint blokhaintimenow) { return now; ontrat TimeVaultInterfae is ERC20Interfae, ERC223Interfae { funtion timevault(address who) publi onstant returns (uint); funtion getnow() publi onstant returns (uint); funtion transferbyowner(address to, uint _value, uint timevault) publi returns (bool); ERC20Token ontrat ERC20Token is ERC20Interfae, ERC223Interfae, ELTTokenType { using SafeMath for uint; funtion totalsupply() publi onstant returns (uint) { return _totalsupply - balanes[address(0)]; funtion transfer(address _to, uint _value) publi returns (bool suess) { bytes memory empty; return transfer(_to, _value, empty); funtion transfer(address _to, uint _value, bytes _data) publi returns (bool suess) { if (iscontrat(_to)) { return transfertocontrat(_to, _value, _data, false); else { return transfertoaddress(_to, _value, _data, false); 40

41 funtion approve(address _spender, uint _value) publi returns (bool) { allowed[msg.sender][_spender] = _value; emit Approval(msg.sender, _spender, _value); return true; funtion allowane(address _owner, address _spender) publi onstant returns (uint remaining) { return allowed[_owner][_spender]; funtion balaneof(address _owner) publi onstant returns (uint balane) { return balanes[_owner]; funtion iscontrat(address _addr) private view returns (bool is_ontrat) { uint length; assembly { length := extodesize(_addr) return (length > 0); funtion transfertoaddress(address _to, uint _value, bytes _data, bool withallowane) private returns (bool suess) { transferifrequirementsmet(msg.sender, _to, _value, withallowane); emit Transfer(msg.sender, _to, _value, _data); return true; funtion transfertocontrat(address _to, uint _value, bytes _data, bool withallowane) private returns (bool suess) { transferifrequirementsmet(msg.sender, _to, _value, withallowane); ContratReeiver reeiver = ContratReeiver(_to); reeiver.tokenfallbak(msg.sender, _value, _data); emit Transfer(msg.sender, _to, _value, _data); return true; funtion hektransferrequirements(address _from, address _to, uint _value) private view { require(_to!= address(0)); require(released == true); require(now > globaltimevault); if (timevault[msg.sender]!= 0) { require(now > timevault[msg.sender]); require(balaneof(msg.sender) >= _value); funtion transferifrequirementsmet(address _from, address _to, uint _value, bool withallowanes) private { hektransferrequirements(_from, _to, _value); if ( withallowanes) { require (_value <= allowed[_from][msg.sender]); balanes[_from] = balanes[msg.sender].sub(_value); balanes[_to] = balanes[_to].add(_value); funtion transferfrom(address from, address to, uint value) publi returns (bool) { bytes memory empty; if (iscontrat(to)) { return transfertocontrat(to, value, empty, true); else { return transfertoaddress(to, value, empty, true); allowed[from][msg.sender] = allowed[from][msg.sender].sub(value); return true; 41

42 ERC20Interfae ontrat ERC20Interfae { funtion totalsupply() publi onstant returns (uint); funtion balaneof(address tokenowner) publi onstant returns (uint balane); funtion allowane(address tokenowner, address spender) publi onstant returns (uint remaining); funtion transfer(address to, uint tokens) publi returns (bool suess); funtion approve(address spender, uint tokens) publi returns (bool suess); funtion transferfrom(address from, address to, uint256 _value) publi returns (bool); ERC223Interfae event Transfer(address indexed from, address indexed to, uint tokens); event Approval(address indexed tokenowner, address indexed spender, uint tokens); ontrat ERC223Interfae { uint publi totalsupply; funtion balaneof(address who) onstant publi returns (uint); funtion transfer(address to, uint value, bytes data) publi returns (bool suess); event Transfer(address indexed from, address indexed to, uint value, bytes data); ContratReeiver ontrat ContratReeiver { strut TKN { address sender; uint value; bytes data; bytes4 sig; funtion tokenfallbak(address _from, uint _value, bytes _data) publi pure { TKN memory tkn; tkn.sender = _from; tkn.value = _value; tkn.data = _data; uint32 u = uint32(_data[3]) + (uint32(_data[2]) << 8) + (uint32(_data[1]) << 16) + (uint32(_data[0]) << 24); tkn.sig = bytes4(u); SafeMath Library library SafeMath { funtion mul(uint a, uint b) internal pure returns (uint) { uint = a * b; assert(a == 0 / a == b); return ; funtion div(uint a, uint b) internal pure returns (uint) { uint = a / b; return ; funtion sub(uint a, uint b) internal pure returns (uint) { assert(b <= a); return a - b; funtion add(uint a, uint b) internal pure returns (uint) { uint = a + b; assert( >= a); return ; 42

43 ELTTokenType ontrat ELTTokenType { uint publi deimals; uint publi totalsupply; mapping(address => uint) balanes; mapping(address => uint) timevault; mapping(address => mapping(address => uint)) allowed; bool publi released; uint publi releasefinalizationdate; 43

44 7.3. Use Case Borrower/Lender Use Case The following use ase shows how borrowers, and lenders interat with Lendo and its Vault Lendo Admin Register Create, View update or delete Lendo Aount Loan Appliation Lendo System <<extend>> Create, View update or delete Loan Offers <<inlude>> View Loan & Crypto Status Deposit Crypto View Browser Details Borrower Lender Default on Loan Early repay or loan Term Complete <<inlude>> View Loan Reports <<inlude>> Full Crypto Return Partial Crypto Return View Browser Reports Lendo Vault 44

45 Credit Card Holder/Lender Use Case Lendo Admin Register Lendo System Credit ard Appliation <<inlude>> View Credit ard & Crypto Status & details Deposit Crypto Credit Card Holder Close Credit ard with balane Close Credit ard with zero balane <<inlude>> <<inlude>> Partial Crypto Return Full Crypto Return Lendo Vault 45

46 Safety Deposit Use Case Lendo Admin Register Lendo System Create Safety Deposit Aount <<inlude>> View Safety Deposit Aount & Crypto Status & details Deposit Crypto Safety Deposit Holder Close Safety Deposit Aount <<inlude>> Crypto Return Lendo Vault 46

47 7.4. High level sequene diagrams Loan appliation 47

48 Loan operation 48

49 Credit ard appliation Credit ard authorization Credit ard operation Debit ard appliation 49

50 Debit ard authorization 50

51 7.5. Lendo Data Model In a miro-servies arhiteture a single database shema does not make sense. However, to help larify the relationships between the logial entities within the system an integrated data model an help. Here we ve presented suh a model, whih fouses on the most important entities, but leaves out muh of the detail that will be needed for implementation. It fouses on the business aspets of the plan rather than the operational ones, for example it does not inlude entities for managing roles and permissions, but does inlude users and their relationships to lenders, loan offers, and loans. 51

52 7.6. Payment Proessing Networks List We will hoose a payment proessor based on their reah and brand Visa: Visa remains the king of the mountain in the ard network industry. The ompany had billion debit and redit ards in irulation in the 12-month period ended September 30, 2015 and proessed $7.354 trillion in total volume. MasterCard: MasterCard is no slouh, as it has seured the No. 2 spot among ard networks. In the nine-month period ended September 30, 2016, MasterCard had issued billion ards in its redit, debit, and harge program and had proessed $3.591 trillion in gross dollar volume. Amerian Express: Amerian Express remains a fore among its peer ard networks even though it doesn t have the sheer numbers of Visa or MasterCard. The ompany had issued million ards and proessed $1.04 trillion in ard billed business in Disover: Disover remains in fourth plae behind Visa, MasterCard, and Amex. The ompany proessed $312.4 million in total network transation volume in 2015 aross million transations. UnionPay: UnionPay is the only interbank network in China that onnets all of the ATMs of all banking ompanies throughout the world s most populous nation. Merhants in more than 141 ountries aept UnionPay ards, whih makes it the third largest payment network by value of transations proessed, behind only Visa and MasterCard. JCB: Japan Credit Bureau operates primarily in Asia. Maestro: This international debit ard servie was founded in 1992, and MasterCard owns it. Approximately 15 million points of sale aept Maestro. Interlink: Interlink is the eletroni funds transfer division of Visa and it operates primarily within the U.S. But unlike a standard Visa hek ard purhase, and Interlink purhase uses a PIN and an provide ash bak from the merhant. STAR: STAR was one of the first networks to fous on PIN debit, and First Data bought the ompany in The ompany prides itself on its innovation, suh as the first proessing of an envelope-less deposit at an ATM and the first real-time diret eletroni hek debit. SHAZAM: Shazam is a U.S. interbank network that operates primarily in the Midwest. The not-for-profit ompany provides eletroni funds transfers to hundreds of finanial institutions. NYCE: The New York Curreny Exhange is an interbank network that now serves as the primary network for more than 300,000 ATMs and 89 million users in the U.S. and Canada. Ael: The Ael interbank network links more than 400,000 ATMs throughout all 50 states, along with a few U.S. Air Fore bases around the globe. Plus: Plus overs all of Visa s redit, debit, and prepaid ards, along with a plethora of other ATM ards from other issuing banks. The network laims more than one million ATMs in more than 170 ountries. Intera: Intera is the primary Canadian debit ard system and flourishes there beause other traditional providers, suh as Visa and MasterCard, hardly provide ards in the nation. As of 2010, Intera laimed 80 member organizations, 59,000 ATMs, and 450,000 merhants. Visa ReadyLink: This servie allows Visa ardholders to quikly add ash to their prepaid aounts. Retailers suh as Safeway and 7-Eleven make ReadyLink available to ustomers Pulse: Disover owns Pulse, whih operates an interbank network for more than 4,400 finanial institutions and 380,000 ATMs in the U.S. 52

53 Appendix 1. The Loan Management System Interfae The Loan Management System is under development and we hope to have a working demonstration on the website quite soon. In the meantime, we present a guide to how the system will work. Stage 1 is to apply for a loan, obviously. Loan appliation proess The loan appliation sreen will appear as above. (Note that this a design layout only, so numbers are not orret). The top slider display shows the maximum loan available for the borrower s urrent holdings of the aepted Crypto ollateral. The bottom of the sreen shows the urrent available ollateral. In the entre left of the sreen is the loan alulator, where loan value and loan duration an be varied within the lender s pre-set parameters. The interest rate and required ollateral are displayed here, and the borrower an selet whih ollateral to use. On the entre right of the sreen, the monthly repayments are alulated and displayed. Assuming that there are suffiient non-ollateralised holdings in the borrower s aount, the apply for a loan button will beome likable. One a loan has been applied for the request is sent to the lender for approval (in reality this will likely be an automated approval sine the loan will only be advaned one the ollateral is in plae so no redit heks are required) and one approved the borrower s ollateral will be transferred to the ollateral vault, and the appropriate amount of fiat urreny will be transferred to the borrower s fiat aount. When applying for a loan the borrow an hoose the type of urreny wanted to use for the loan, the user an also hoose the duration of the loan. 53

54 Loan management One a loan has been made, the borrower an trak the loan re-payment and loan to value history, and selet automati or manual repayments. The values are also represented graphially. The graph an also be swithed to show a bar representing the original and the urrent ollateral value The page displays loan statistis and loan to value statistis in real time and offers aess to the invoie arhive and loan agreement and offers the ability to inrease the loan under suitable onditions if the LTV has redued over time. The historial loan data traks the remaining loan amount in from start to end, the urrent loan to value in % and the value of the ollateral in. The loan management system is also set up so that the borrower easily an trak and monitor his loans and ollateral. 54

55 Repayments and Invoie Management Pro-forma invoies and payments are managed within the system. There is aess to assets suh as the loan agreement, additional borrowing and repayment adjustment tools, and an arhive of invoies. The lendo system will allow the user to pay the invoie diretly from the available funds inside Lendo, or to hoose to pay using several available urrenies. In ase the borrower wishes to pay with rypto urreny from outside the Lendo system a one time wallet address will be generated for the lender and this one time wallet address will be valid for 2 hours. It will also be possible to make a bank to bank wire transfer from an online bank. In ase the user hooses the wire option a proforma pdf file will be reated with all the neessary payment details and instrutions. Borrowers have the possibility to apply for a postponement of the loan prinipal and only pay the interest for the atual invoie they are about to pay. Applying for suh a postponement aries a fee to be paid in ELT. The lendo system will make a hek on the urrent LTV and if it is within the set parameters the system will automatially approve suh a postponement and the lendo loan management system will then realulate the remaining loan so that the aount is orreted aordingly. 55

56 Invoie Arhive Invoies are issued as requested by the user via in PDF format. Depending upon requirements a pro-forma invoie or reeipt an be issued. The next invoie will appear to the user one after the payment due date for the previous invoie. In the invoie arhive the user has the possibility to apply for postponement of prinipal payments and only pay interest due. It will also be possible to hange the invoie frequeny between monthly and quarterly. The borrower an also set up the autopayments from this page and hoose whih lendo aounts should be used to make the automati loan payments. There is a possibility to set up to 3 aounts to draw from and whih aount to set as priority to draw from. Finally, the borrower an apply for a loan extension. The loan extension will mean that the loan alulations will be different. The Lendo system will make a alulation based on the urrent loan to value for the atual loan and then instantly aept or rejet suh appliation based on pre-set parameters. All settings hanges and appliations arry different fees to be paid in ELT tokens. 56