Lending pool patterns + protocol primitives required to enable them

[raulk]

We’re workshopping a bit with the FVM DX team on lending patterns, and we think that undercollateralized loans with dripping patterns might be a popular one.

1. Borrower shows up to the contract and declares rate of power onboarding.
2. Contract calculates required collateral. Borrower posts collateral.
3. Loan contract instantiates the loan with a dripping pull pattern.
4. When the borrower needs to pull funds, it calls a method on the contract, which calculates the exact pledge needed to onboard the amount of power pending since the last withdrawal, based on current CE conditions.

To make this work, the protocol would need to provide some primitives:

1. Ability to easily calculate pledge needed to onboard X amount of power today.
2. Ability to earmark funds as only deployable as pledge collateral (otherwise the lender could withdraw the funds immediately)
3. Sector ACL. Ability to identify which sectors were onboarded with the loan. If the contract reserves the right to terminate sectors when the terms of the loan are breached, it should only be authorised to terminate the sectors enabled by the loan. This also enables a miner to draw loans from various sources (or from the same source as terms evolve) without cross-interference.
4. Likely more, let's brainstorm in this thread.

[raulk]

cc @trruckerfling @hammertoe @aashidham @ychiaoli18 @arajasek

[anorth]

Did you mean borrower (i.e. storage provider) rather than lender above? I'm a bit confused otherwise. I'm also unsure what a dripping pull pattern is.

The need (1) above is good: we should ensure all the inputs to pledge calculation are available from the power & reward actors.

Other "needs" that would make the miner actor more complicated are less appealing to build in to the base protocol. I think there's probably a lot that can be done with user-programmed miner-owner actors which enforce limitations on how some parties can interact with an SP, and keep track of more extensive metadata.

[raulk]

Yeah, I meant the borrower/loaner (corrected).

• Dripping = you drip as much collateral as the miner will need to satisfy their pledge obligations for the declared amount.
• Pull = you don't transfer that collateral proactively, but rather let the miner withdraw it by pulling it out of you. Basically, inversion of control in timed processes.

[raulk]

(2) would be resolved by having the loan contract (or an associated contract) be the beneficiary. Is that correct?

[steven004]

Ability to easily calculate pledge needed to onboard X amount of power today.

This can be done easily off chain using available chain data history, though it may not be very precise for the current epoch. It should be good enough to evaluate. And an offline tool could be helpful on this. I do not think a primitive provided by FVM is very necessary.

Ability to earmark funds as only deployable as pledge collateral (otherwise the lender could withdraw the funds immediately)

This is good, but, once the beneficiary is set to the loan contract. It actually consider all the balance and future reward as the collateral. The borrower can not do much more things using the loan in the current network. This limit does not looks so necessary either.

[awmacpherson]

For (3), is there any friction (other than deployment fees) to controlling permissions by deploying a new miner actor for each loan? Then the lending contract can simply take ownership of the miner actor and terminate sectors in case of delinquency.

[anorth]

I wrote up a moderately detailed design for a lending market some months ago. It's a different flavour to the OP, a bit simpler, but I think there's likely room for multiple different models. As far as I can tell, the beneficiary address is the only protocol hook needed for this to work, although of course there are tradeoffs.

[leotons]

I have read your design and have a few questions to ask:

1. what is the purpose of designing the LoanAgent contract, can't one contract address be used to take over the ownership of all nodes?
2. Currently there is no way to implement liquidation in defi protocol, may I ask if the built-in contract may provide the function of terminating sectors in the future?
3. is there any other way to implement liquidation?

[anorth]

My design doesn't mention a loan agent, I think you are referring to another one.

Right now there is no way for a contract to terminate sectors, but I expect it to be possible in the future as we expand the API exported by built-in actors.

[misilva73]

Do you have any thoughts around how to compute the lender's collateral? I.e., is this supposed to cover the collateral requirements for the agreed onboarding rate?

What happens if the lender's collateral is not large enough to cover the entire onboarding period?

[steven004]

For a lending contract, the following primitives might be required:

1. A miner's balance query based on MinerID for calculating collateral and its quality, including available, pledge collateral, lockedReward, etc;
2. A miner's beneficiary address and beneficiary terms query / check;