It would be great to serve a negative consequence to the account address which does not repay a loan. I have not figured out a way to achieve this as yet.
I have been thinking that the contract could maintain a state of “niceness” whereby the contract has the ability to increase or decrease the ratio of:
- plain borrowers (new borrowers / borrowers who are not purchasing cheaper interest rates)
- decorated borrowers (borrowers who have purchased or earned
LB tokens and are prepared to deposit them to earn the cheaper rate)
Are the plain borrower’s actions a foregone conclusion?
Whilst it may be inevitable that plain borrowers will run off with the money 100% of the time, it may just be the case that, during a given round of loans, some (or perhaps all) of them will repay; in which case the contract will increase “niceness” and offer a slightly larger amount of plain borrower positions (per round).
If the plain borrowers repeatedly run off with the money then the contract will reduce those plain borrower positions (and perhaps even the borrowable amount) to an absolute minimum for as many rounds as required (i.e. until a plain borrower actually pays back their loan).
LB Token supply (the right balance of minting and burning)
The trick is to find the correct way to control the LB token supply. A clever design of minting and burning based on borrower actions (honest vs dishonest) should suffice. The LB token is the economic driver (incentive) for lenders to participate and for borrowers to be honest. LB tokens must be rare enough to have value and there must always be enough liquidity in the DAI/LB pool so that borrowers can buy LB and lenders can sell LB.
Per account risk
I think it is safe to say that dishonest users will just come to the platform with a newly generated account address each time (posing as a new honest user). Definitely open to the per account risk approach and also Know Your Customer (KYC), however this does lean away from the permissionless and censorship resistance attributes of a decentralised network such as Ethereum. Instead, if there is a combination of maths, game theory and tokenomics which would work, then I would be inclined to choose the later over the former.
Default risk awareness
I really like your idea of making other parties aware that they are accepting value from a borrowed loan agreement.
There would definitely be types of transactions where this unsecured lending would be better suited i.e. a business selling food would not use this because they can’t re-coupe the food after the customer has eaten and left.
However, a business selling/renting a fixed asset (renting a house) or an ongoing asset like a gym membership would be a good use case i.e. in the case of the fixed asset, the authorities could accept evidence that the house/rent payment was not legitimate. In the case of membership, the gym would simply cancel the ongoing membership etc.
B2C and B2B applications
Basically this new thinking takes the challenges of KYC, reputation, loan-guarantors, collateral, trust and “the long con” etc. and solves them by making this a 3-way interaction (as apposed to a 2-way interaction).
In a 2-way interaction on the blockchain the borrower can just run off with the money. This is like receiving cash in the hand. However, in a 3-way interaction there is an organic and natural relationship between two of the entities; the B2C or B2B relationship takes care of the anonymity element. Whilst the customer is now still able to lean on a lender from time to time, they are not in a position to re-sign up to the same Gym again and again under different IDs.
On the business side, businesses can register themselves as accepting this method of payment. This way the business is fully aware of the arrangement (the fact that their income from their client is via the unsecured loan DApp). These centralised “buy now, pay later” service like zip and/or afterpay are quite common these days. However, this Ethereum implementation would be decentralised whereby the decentralised lenders are earning the interest.
Thanks so much for your valuable input.