New BSIP: Transferring/trading active credit deal offer ownership

[grctest]

BSIP: ---
Title: Enable transferring/trading active credit deal offer ownership
Authors: R & JohnR
Status: Draft
Type: Protocol
Created: 29/02/2024
Discussion: N/A

Abstract

Enable lenders to transfer/trade an active credit deal's offer ownership, whilst maintaining the credit deal.

Motivation

When a credit deal is created, the lender and borrower are locked into the agreement.

The borrower at any time can close the credit offer, or they can wait for the end of the credit offer to resolve either repayment or handover of loan collateral.

During this time, the lender has to wait for either scenario to play out.

The lender earns nothing until it's repaid or closed; this could potentially be years depending on the terms of the credit offer.

Lenders should have greater options to monetize their end of the credit deal, especially if they've fallen on hard times and need to bail on the terms of the loan without degrading the borrower's experience.

Rational

The trading/transferring of lending ownership is a very well recognized feature of traditional lending markets; it's often the case that the loan you took out changes hands multiple times without the borrower's knowledge.

This would ease lenders worries about lack of liquidity when participating in the credit offer mechanism; by offering them the ability to properly get out of the credit deal without affecting the terms of the credit deal for the borrower they'd be more likely to lock up funds for longer periods of time in the Bitshares credit offer mechanism.

In the scenario where a lender transfers/trades the deal to another user, the borrower on the BTS DEX would be able to transparently monitor who the lender is at all times, something that's not on offer in the traditional lending markets.

If a lender wants out of their credit deal, negotiations may be limited to transfer memo based communications, offering a means of trading their lender position for even a potential loss would negate the need for communications between lenders and borrowers.

Specifications

The credit_deal_summary_object already includes: account_id_type offer_owner; ///< Owner of the credit offer, redundant info for ease of querying

We would need an additional operation for updating the offer_owner, with it evaluated within void database::update_credit_offers_and_deals().

For trading the additional operations would be required:

• Create credit deal trade offer (offered/requested amount of collateral asset +- offset amount)
• Accept credit deal trade offer

Fees would be collectable from these new operations.

Discussion

Would this encourage greater participation in the credit offer mechanism?

What is an appropriate fee for this new operation?

Should the user be able to block such a transfer? Should that be a premium feature when accepting a credit offer (creating a credit deal) so as to avoid reputational association with new lender?

Should the lender instead receive a token which represents the credit deal? Similar to how liquidity pool staking returns a pool share asset? In such a scenario the offer_owner would be whoever owned the token. That said, I don't think this could be done without first creating a pool share asset style UIA for each individual credit offer (expensive and bloat?).

Summary for Shareholders

Affects credit offer mechanism.

The Borrower in an established credit deal would be affected only by the new association of the new borrower; there's potential reputational risk as a borrower if the loan is transferred to an undesirable account. The terms of the credit deal other than the lender would not change though, so the asset risk profile wouldn't change.

New page in the UI would be needed for offering the sale of credit deals (by lender), and for the purchasing of the credit deal.

New core functionality would be needed.

Additional fees for the reserve pool from the new operations

Copyright

N/A

See Also

Competitor platforms seem to provide the lender a token in return for their credit deal positions, which they can make use of during the lending period.

[abitmore]

As mentioned in Telegram, tokenization of credit deals, along with simple asset pooling, may be doable.

[grctest]

Do you think the tokenization of credit deals is worthwhile implementing in terms of DEX business case or just that it's doable?

[abitmore]

Do you think the tokenization of credit deals is worthwhile implementing in terms of DEX business case or just that it's doable?

I mean if I'm to implement something related to this, I would prefer tokenization of credit deals over transferring ownership.

[grctest]

Each tokenized credit deal would need its own UIA similar to a liquidity pool share asset, right? Considering the borrower can close the credit deal early, such a token might not have its intended purpose for long, leaving the token expired & unusable like a prediction market asset?

[abitmore]

Each tokenized credit deal would need its own UIA similar to a liquidity pool share asset, right? Considering the borrower can close the credit deal early, such a token might not have its intended purpose for long, leaving the token expired & unusable like a prediction market asset?

I think the token can be settled when the deal closes, then the owner can reuse it.