Minimum Viable Borrowing (MVB) on CKB

English CKB Development & Technical Discussion
1

a big thanks to Phroi :smiley:

In this use case, a user has x CKB (or iCKB) and would like to borrow against it.

With this protocol, a trustless secured loan is created between lender and borrower.

Terms of Loan
The interest rate and loan term t are agreed to before the loan is originated and the borrower can pay back the loan at any time (and would only pay interest on the actual term of the loan)

The loan is issued 1:1 with collateral provided by borrower (and to keep the agreement trustless, they lock up the entirety of the interest for the loan)

Loan transaction
The following arrangement should be created through a partially signed transaction between lender and borrower.

  1. Borrower funds cell_0 with capacity x CKB
    ----spending conditions
    -----spend_path0: after timelock t lender can spend (cell_1 must also be included in spend to enforce timelock)
    -----spend_path1: (at any time) borrower can spend to create a locked cell adding an arbitrary amount of CKB (similar to 2 phase DAO withdrawal)

  2. cell_1 is timelocked to t, to enforce term of loan

  3. lender funds cell_2, which contains (x - total loan interest) CKB, spendable by borrower immediately

Closing the Loan
If the term of the loan expires without repayment, the lender claims the collateral backing the loan + interest payments.

If the borrower pays back the loan, they will claim their collateral less applicable interest payments (in the 2nd transaction of the withdrawal flow) and the remaining balance will be spendable by the lender.

In the case of iCKB, a ratio of CKB to iCKB would implicitly be agreed to by the amount of CKB provided by the lender against the borrower’s iCKB collateral

4 Likes
2

Glad you appreciated, just it’s that our assumptions are so very similar:

  1. No margin calls
  2. No oracles
  3. Pre-agreed assetA/assetB ratio
  4. Pre-agreed contract duration
  5. P2P

The protocol you are proposing is strikingly similar to EthLend, so let’s digress a bit.

EthLend was a P2P lending protocol and indeed followed the these assumptions, so it had no margin calls.

Personally I never used it, but in simple terms worked roughly like this:

  1. Let’s assume you had 1M CKB,
  2. You could lock 1M CKB and ask to borrow 0.08 BTC from a lender for say 48 hours.
  3. You posted the borrowing request.
  4. Lenders would look at your past borrowings & repayments history
  5. A Lender would choose to lend you those 0.08 BTC (or not)
  6. Also, if you didn’t misbehave, you gained some native tokens

EthLend was working until it was not working anymore: borrowers could choose to opportunistically default on a borrowing, if the asset borrowed was more valuable than the collateral at the end of the loan.

Fast forward Aave, EthLend successor, introduced margin calls and oracles to make sure that borrowers would not default catastrophically on loans. Also Aave now is not P2P anymore, but centralized and overly complex at that.

This is the critical point: how can we incentivize the borrower enough so that he’ll pay-back the loan? (It’s an open problem and there is no easy solution)

Say we still want to maintain those 5 assumptions to create a DeFi primitive, then I only ever saw one way out: this is not Borrowing, but a different contract (for example a “:rightwards_hand::leftwards_hand::handshake:” contract) and must be priced accordingly to the risk the Lender Liquidity Supplier takes. This sets right the expectations of both parties.

Basically the solution is to remove the implicit assumption that this is some kind of borrowing, it is not. It’s something else and there still is a place for these contracts in the DeFi world.

@matt_ckb let’s assume that we implement your protocol, I lock 1M CKB and borrow switch 0.08 BTC from you for say 48 hours.

In which way would I bring you harm if I changed my mind 10 times about keeping those 1M CKB vs those 0.08 BTC?

Nothing, after 48 hours you will just get anyway what remains in the contract, right?

In which way would I bring you harm if I changed my mind 10 times about keeping those 1M CKB vs those 0.08 BTC while also switching back and forth the assets that are locked inside the contract?

Nothing, after 48 hours you will just get anyway what remains in the contract, right? Actually by giving me this possibility you could price the contract higher, so you would gain a bit more.

This is exactly a “:rightwards_hand::leftwards_hand::handshake:” contract.

Love and Peace, Phroi

1 Like
3

i don’t see any reason to incentivize them paying back the loan. The reason that it is minimum viable is it is only CKB/iCKB involved. In either case the lender collects a return on their asset and doesn’t lose anything.

The borrower could choose to sell those CKB for BTC, rolling the dice that they will be able to navigate the markets and get their collateralized CKB back in addition to more assets, but from a protocol perspective it’s agnostic.

1 Like
4

iCKB got one external audit, one internal review and I spent years simplifieng the iCKB core contract to be as simple as possible, so it’s pretty damn safe.

That said, what happens if iCKB core contract is hacked while a MVB is ongoing? (irrealistic, agreed)

In this highly hypothetical scenario, CKB price would not change much, but iCKB Token price would go to zero, as the hacker may print infinite iCKB Tokens and/or take control of the iCKB Deposit pool.

In this highly hypothetical scenario, a MVB on CKB/iCKB (locking some iCKB to borrow some CKB), considered a 100% safe lending, becomes insolvent for the lender.

Accounting for this kind of corner cases is what makes protocols resilient.

Then again, maybe it’s just a question of naming things, so it’s just marketing in the end. Maybe I should just call my proposal Schroedinger’s Borrowing :smirk_cat:

1 Like
5

you are right… just CKB for CKB is a better MVB :smiley:

6

Look, the grand idea behind MVB is: let’s create sustainable value and venues for long term CKB holders in a way that simple, hack-free and effective.

This motivation is more than commendable! :clap::clap::clap:

As long as users understand the perks & risks involved with MVB, you have my full support.

Abstracting all details, at high level MVB works like this:

  • the Lender in the end gets back minValue(AssetA, AssetB) + fee
  • the Borrower in the end gets maxValue(AssetA, AssetB) - fee

In case that AssetA and AssetB have roughly a constant value respectfully to each other in the MVB contract lifespan, this works well. In practice this applies well to CKB and iCKB, except for highly hypothetical scenarios.

Let’s iron out together the technical details now.

This is doable, sure, but it also brings some unnecessary complications:

  1. This creates a disadvantage for the Lender that the Borrower can exploit. In particular a Borrower can close early all borrowings in which the lended asset go down in relative value. Conversely he can choose to keep open all the borrowings in which the lended asset go up in relative value and default on them. This attack provides an unfair advantage to the borrower and exploits the absence of margin calls.
  2. This means that the lender will not see his fee until the MVB contract expires. This is rough as the lender is completely illiquid as his capital is completely locked up for the contract duration.
  3. From my iCKB experience I know that Nervos L1 on-chain determinism makes this a bit rough to develop. In particular the issue is that when validating a tx we cannot access the current time.

That’s why I would propose to fully remove this feature.

On the other side, let’s say a borrower has no more need for a MVB contract, he can just sell the MVB contract to someone else.

@matt_ckb what’s your take on this?

1 Like
7

Because this is minimum viable, the protocol should only consider collateralizing CKB to borrow CKB. This removes any arbitrage opportunities related to changes in ratio of assetA to assetB (which can be properly handled by a more thoughtful protocol).

What MVB does is provide a CKB hodler (lender) guaranteed yield on their asset, while providing a CKB holder (borrower) the ability to take advantages of market opportunities without selling their CKB.

The price of this ability is the yield that is paid to the lender.

8

Thank you for clarifying!!

In the traditional finance, MVB would be called passbook loans and they are basically used to:

improve your credit score if your bank or credit union reports your payments to the credit agencies.

If you specialize MVB exclusively on CKB/CKB loans, then the locked funds could be put into NervosDAO. This should offset some of the interests paid to the lender.

All in all, to me it seems that MVB is just optimizing for an external system that is not expressed in the use-cases. In simpler words, MVB doesn’t make sense unless we assume the existence of an external reward that offsets the interests paid to the lender.

Care to explain more this detail?

Love & Peace, Phroi

9

yes, everything that is possible in the markets :sweat_smile:

a borrower can take advantage of temporary arbitrage opportunities (or anything else that would be beneficial to them), if they are effective, they can increase their total assets while holding on to their current assets.

a borrower could deposit their CKB into the DAO, but the flexibility in keeping them liquid seems to fit better