Repayment Tracking & Allocation Implementation

[tspoff]

Issue

Tracking what lenders are entitled to withdraw what repayments at what time requires overhead. We want to minimize cost and keep interfaces as familiar as possible.

Solutions

MiniMe Style ERC-20 link

[+] Can handle ERC-20 payment tokens if sent though a function, like repay()

[-] O(logn) loops on transfer and withdraw [-] Large storage overhead

Conclusion: Likely won't use due to gas costs

ERC-721

[+] Can handle ERC-20 payment tokens if sent though a function, like repay() [+] No loops, withdraws simple to calculate

[-] Can't split or combine stake without extra logic [-] Can't withdraw multiple stakes at once without a batch function (which we could totally do)

ERC-1843: Claims Token Standard link

[+] Can keep ERC-20 ownership tokens, looks efficient (still evaluating)

[-] Requires payment token to be ERC-223 compatible for the tokenFallback hook.

• We could potentially "wrap" the payment token before sending, it'd be the same number of calls as approve() + function() anyways.

ERC-1726: Dividend-Paying Token Standard link

[-] Only supports Ether payments

Conclusion: Won't use as ERC-20 payments are critical. Can learn from though.

[adibas03]

Looking at the ERC-1843 claim standard implemetation, We need to maintain a balance of each address, that ever has the tokens, in a bid to maintain the balance. This means a typical O(logn) storage consumption to each address. This would than be exaggerated when we add computation of fees, interest, penalties. I still prefer the ERC721 implementation over this, at least for the MVP, and if divisibility becomes a priority, we might re-consider.

Note: I still very much like the claim standard, and I think we should build on that.

[adibas03]

We could add our implementation as the ERC 721 implementation for the standard