[WIP] "Just in time liquidity" AKA "splits" vault #1

wilsoncusack · 2022-05-20T00:36:42Z

A "vault" which does not hold lenders funds but rather pulls the liquidity from lenders "just in time" to lend to a loan. Requires borrowers to pass in a set of lenders and lend amounts to use to fulfill the loan, and so assume there is off chain calculation done, tracking which lenders have approvals and enough funds to fill the loan. Also allows for reusing funds that have been paid back to a lender but not withdrawn.

This has a similar spirit to the Lend Offers PR - with-backed/backed-protocol#80 - but has a couple key differences

Multiple lenders can match to a single loan
There is a separate "terms" contract which provides lending and liquidation terms. Lenders approve terms contracts. This can also be thought of as lending strategies. E.g. you might approve a "Nouns terms contract" which lends to Nouns or a terms contract that uses oracle messages (passed in "data") to lend to nearly any NFT.

Concerns, some of these suggest changes to the core protocol:

I dislike the approvals calls required: approving facilitator to move NFT, approving facilitator to spend ERC20
In general lots of storage and checks and some loops. Feels like gas will be very high.

Roughly correct diagram of the case when the loan is created in the same transaction as the lend.

wilsoncusack · 2022-05-20T00:49:05Z

src/LendController.sol

+            (,,, uint40 lastAccumulatedTimestamp,,,,,,,) = loanFacilitator.loanInfo(loanId);
+
+            if(lastAccumulatedTimestamp != 0) {
+                require(terms.allowBuyouts);


need to think if this is really the best way to do this / what we want to do. Alternatively could

require(terms.amount >= loanFacilitator.totalOwed(loanId))

or just not do any check? If the terms contract is willing to lend to this asset, it should be willing to buyout? Expecting to get buyout amount back on repayment. (Off chain will have to ensure that terms include a 10% improvement over existing).

i think cool to not do any check. borrow ticket holder could then use UI to see if theres any way they could get better terms on their loan

well but this issue is, if you're a lender, are you OK more than X of your funds moving because you need to payback the previous lender, in addition to lending?

wilsoncusack · 2022-05-20T00:49:34Z

src/LendController.sol

+
+    event SetTermsApproval(address indexed from, address indexed termsContract, bool approved);
+
+    function setTermsApproval(address termsContract, bool approved) external {


we'll probably want to have an amount based allowance and decrementing against it as funds go out.

wilsoncusack · 2022-05-20T00:54:15Z

src/LendController.sol

+    }
+
+    // used to create loan and lend to it in one transaction
+    function onERC721Received(


using this onReceived hook allows us to prevent needing a multi call where users first createsLoan and then calls lend here. Although worse gas than multi call because NFT needs to go user -> LendController -> Loan Facilitator rather than user -> loan facilitator. But loan facilitator doesn't support multicall, anyway

I think it would be cool if the core backed contract, on loanCreate allowed the borrower to send the lend ticket somewhere via a safeTransferFrom, counting on an immediate loan fulfillment as the result of that transfer. So the LendController would receive the lend ticket, instead, check terms and just return loan payment.

Would also be nice if we used like a fulfillLend hook to allow the lender to provide the liquidity by any means. Not necessarily a transfer from msg.sender.

wilsoncusack · 2022-05-20T01:30:06Z

src/LendController.sol

+            terms.interestRate,
+            terms.amount,
+            terms.durationSeconds,
+            address(this)


this actually isn't quite right: we do not want to transfer the lend ticket to this contract. Because Backed has eager transfers for loan repayments, and we need to track whose funds are whose in the LendController, we will need to deploy a contract solely for the purpose of holding the lend ticket and receiving repayment. We will need one such contract for every lend ticket

Non-eager payouts are better for composability but worse for gas in the EOA case: eats into lender returns to have to come back and withdraw payback

with regards to collateral seizure, are any of the lenders able to call seizeCollateral? does this newly deployed contract need to then know about liquidation strategy?

I think the newly deployed contract would just allow the parent to make seize calls and send the collateral to itself/somewhere. parent (i.e. LendController) would control auction.

And yeah I think possibly anyone could call seizeCollateral, so long as what happens next (e.g. what kind of auction) is pre-agreed on

moodysalem

just some somewhat higher level comments

moodysalem · 2022-05-20T16:46:57Z

src/LendController.sol

+    uint16 interestRate;
+    uint128 amount;
+    uint32 durationSeconds;
+    address loanAsset;


why is this part of loan terms? it's included in the call

we need on L147

moodysalem · 2022-05-20T16:53:58Z

src/LendController.sol

+
+        for(uint i = 0; i < request.lendersSpecs.length; i++) {
+            LenderSpec memory info = request.lendersSpecs[i];
+            require(termsApprovals[info.lender][request.termsSource], 'lender has not approved terms source');


you could potentially borrow from lenders with different terms contracts, where the total lent must be less than the min

yeah, but then need to do extra accounting on the way out? Can't assume everyone had the same rate, etc. But is interesting idea.

moodysalem · 2022-05-20T16:57:47Z

src/LendController.sol

+            lenderLoanShares[loanId][info.lender] = info.amount * ONE / terms.amount;
+        }
+
+        loanAsset.approve(address(loanFacilitator), type(uint256).max);


ick from core

agree, as I said below

Would also be nice if we used like a fulfillLend hook to allow the lender to provide the liquidity by any means. Not necessarily a transfer from msg.sender.

moodysalem · 2022-05-20T17:02:10Z

src/LendController.sol

+    struct BorrowRequest {
+        LenderSpec[] lendersSpecs;
+        address termsSource;
+        LoanTerms terms;


surprised the borrow request specifies the terms rather than it being derived from the terms source, but makes sense so the terms returned from the source can be validated. think these likely should be diff structs though

yeah was concerned about a race condition where terms contract is changed while borrow request tx is in the mempool. Agree could be different structs.

adamgobes · 2022-05-20T19:18:22Z

src/LendController.sol

+        bool skipIsBuyoutCheck,
+        bytes calldata data
+    ) internal {
+        LoanTerms memory terms = NFTLoanTermsSource(request.termsSource).terms(tokenId, msg.sender, request.terms.loanAsset, '');


should this method make some checks as to whether terms from terms source match up with request.terms? ideally they're the same yes, but someone could maliciously pass mismatching?

will get checked in NFTLoanFacilitator, right? Must meet or beat.

joshieDo · 2022-05-23T10:37:59Z

src/LendController.sol

+            }
+            lenderTotal += info.amount;
+
+            lenderLoanShares[loanId][info.lender] = info.amount * ONE / terms.amount;


lenderLoanShares[loanId] can be moved out of the loop for some gas savings for loops > 1 (example, example

mapping(address => uint256) storage loan = lenderLoanShares[loanId] for(...) { ... loan[info.lender] = info.amount * ONE / terms.amount; }

and even accessing the fields on request might be better cached if used more than once, but i'm not 100% sure of that

wilsoncusack · 2022-06-22T12:00:16Z

will come back to this with v2 done 😈

wilsoncusack added 5 commits May 19, 2022 16:13

forge install: forge-std

ff5922d

forge install: backed-protocol

b299ad6

forge install: solmate

7239ccb

WIP but enough progress to get feedback

9286ffe

comments

857f61c

wilsoncusack commented May 20, 2022

View reviewed changes

moodysalem reviewed May 20, 2022

View reviewed changes

adamgobes reviewed May 20, 2022

View reviewed changes

joshieDo reviewed May 23, 2022

View reviewed changes

wilsoncusack closed this Jun 22, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] "Just in time liquidity" AKA "splits" vault #1

[WIP] "Just in time liquidity" AKA "splits" vault #1

wilsoncusack commented May 20, 2022 •

edited

Loading

wilsoncusack May 20, 2022

adamgobes May 20, 2022

wilsoncusack May 20, 2022

wilsoncusack May 20, 2022

wilsoncusack May 20, 2022

wilsoncusack May 20, 2022 •

edited

Loading

wilsoncusack May 20, 2022

wilsoncusack May 20, 2022

wilsoncusack May 20, 2022 •

edited

Loading

adamgobes May 20, 2022

wilsoncusack May 20, 2022

moodysalem left a comment

moodysalem May 20, 2022

wilsoncusack May 20, 2022

moodysalem May 20, 2022

wilsoncusack May 20, 2022

moodysalem May 20, 2022

wilsoncusack May 20, 2022

moodysalem May 20, 2022

wilsoncusack May 20, 2022

adamgobes May 20, 2022

wilsoncusack May 20, 2022

joshieDo May 23, 2022 •

edited

Loading

wilsoncusack commented Jun 22, 2022


		event SetTermsApproval(address indexed from, address indexed termsContract, bool approved);

		function setTermsApproval(address termsContract, bool approved) external {

[WIP] "Just in time liquidity" AKA "splits" vault #1

[WIP] "Just in time liquidity" AKA "splits" vault #1

Conversation

wilsoncusack commented May 20, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wilsoncusack May 20, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wilsoncusack May 20, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

moodysalem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joshieDo May 23, 2022 • edited Loading

Choose a reason for hiding this comment

wilsoncusack commented Jun 22, 2022

wilsoncusack commented May 20, 2022 •

edited

Loading

wilsoncusack May 20, 2022 •

edited

Loading

wilsoncusack May 20, 2022 •

edited

Loading

joshieDo May 23, 2022 •

edited

Loading