Since our last update, we’ve begun working on our mobile application Minimum Viable Product (MVP), and progressed through the development of the lending smart contracts. We’ve discussed and solved several engineering challenges we faced with these contracts.
This week, we decided to examine linking each app installation to only one Ethereum address. If one address is assigned to every user of the app, and that single address is allowed to lend and borrow to/from many addresses, it is possible that a single address can be in various stages of multiple loans at a time. It is also possible that a given address that lends to many people may have more than one loan engaged in a holding period at any given time — holding periods are the duration in which a loan has completed and a reward has started to accumulate. Therefore, every address has an amount engaged in a holding period equal to or less than its current balance. This amount engaged in holding can be split into smaller amounts that represent each loan amount in holding.
The complexity arises when you look at how the contracts should treat users who try to break holding periods. In some cases, a lender who has a loan in holding may decide to forfeit their reward because they need money right away.
But what if a lender has multiple loans in holding, and decides to withdraw an amount of money from their address greater than the amount they have not engaged in holding? Which loan holding periods does the contract cancel, and in what order?
To maximize the reward for that lender, the contract should end the loans that most recently went into holding, and progressively move backward in time. This is because an amount of tokens that have been in holding for a longer time period have generated greater reward than an equal amount that only recently went into holding. You could also expand the contract to pay out partial rewards when a lender breaks a holding period, where the partial reward is proportional to the time they waited.
For our early alpha MVP, we are currently favoring prohibiting lenders from breaking holding periods. This simplifies our programming and allows us to move forward quickly. Later on, we plan to build a more complicated version that cancels newer loan holding periods first and allows older loans to continue accumulating rewards, while giving partial rewards for loans that had their holding period canceled.
As we move forward with our MVP, we will be providing more examples and discussions of the engineering progress we’ve made. Within the next few days, we’ll display our progress on the development of the mobile application.
Be sure to checkout our website as well as connect to our social media on Reddit, Twitter, Discord, and Telegram. If you have any questions, let us know and we’d be glad to help clear things up!
