XLS-0066d Lending Protocol #240

Tapanito · 2024-10-18T17:31:46Z

Discussion thread can be found here: #190
Development branch can be found here: TBD

sappenin · 2024-11-25T16:47:12Z

@Tapanito this PR seems ready to merge -- do you agree?

(Note that per the DRAFTS section of the CONTRIBUTING guidelines, merging does not mean endorsement or even a completed spec, but instead offers a way for spec editors to more easily edit using PRs).

Tapanito · 2024-12-04T14:10:41Z

Before merging, I'd like to have at least one review by an engineer to ensure everything is in order. In addition, similarly to Single Asset Vault, it is simpler/more convenient to edit a PR with various small design changes (e.g. names), rather than open a new PR for each of them. As a result, keeping a PR open allows to have a spec. that is more readily in-alignment with implementation.

sappenin · 2024-12-04T18:00:03Z

Makes sense, especially if it's more convenient. Just didn't want you (or anyone reading along) to think that merging here implies "finished product" (that's why we have a d designator, to indicate draft status).

XLS-0066d-lending-protocol/README.md

- Adds VaultNode to LoanBroker object to track in which owner directory of the Vaults pseudo-account the LoanBroker object is referenced. - Adds LoanBrokerNode to Loan object to track in which owner directory of the LoanBroker object the Loan is references. - Replaces CurrentTime to LastClosedLedger.CloseTime. - Changes the LoanBroker.Delete transaction to automatically return any outstanding Cover to the LoanBroker.Owner. - Adds a balance check to the LoanBrokerCoverDeposit transaction when depositing XRP. - Adds a check to LoanBrokerCoverWithdraw to ensure the CoverAvailable does not drop below Mimimum Cover Required.

Co-authored-by: Ed Hennis <[email protected]>

… when the last Loan is delete

… for the missing flc

Tapanito · 2025-01-28T19:24:07Z

Hmmm, that would make sense, but let me make sure there are no legitimate use cases we would block.

…

On Tue, Jan 28, 2025, 19:18 Ed Hennis ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In XLS-0066d-lending-protocol/README.md <#240 (comment)>: > +$$ +valueChange = (prepaymentPenalty) - (interestOutstanding - accruedInterest) +$$ + +Note that `valueChange <= 0` as an early repayment reduces the total value of the Loan. In theory, yes, it is possible to have valueChange > 0. Remember: prepaymentPenalty = principalOutstanding \times closeInterestRate valueChage > 0 suggests that the borrower would pay MORE to close the Loan early, than repay the loan in scheduled payments. Yeah, those would be pretty cruddy terms to accept on a loan. So do we make valueChange <= 0 a hard requirement to stop loan sharking? 😁 — Reply to this email directly, view it on GitHub <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMDKUYNBBEOX2W5APQBDZ32M7J2BAVCNFSM6AAAAABQGMS3AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKNZZGIYDQNJVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Tapanito · 2025-01-28T19:31:34Z

I prefer to measure a year in cups of coffee ☕

…

On Tue, Jan 28, 2025, 19:24 Ed Hennis ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In XLS-0066d-lending-protocol/README.md <#240 (comment)>: > +$$ +periodicRate = \frac{interestRate \times paymentInterval}{365 \times 24 \times 60 \times 60} +$$ If we assume that, by monthly payments you mean every 30 days, then 12% interest rate then the periodic rate would be (12 * 30) / 365 (the hours and seconds cancel out) or ~= 0.986` Ok. Perfect. Thanks! I was imaging a theoretical situation where I make 12 payments equally spaced across the year (i.e. every 365/12 = ~30.417 days or every 24*365/12 = 730 hours. Since the loans are timed in seconds, those terms are possible, and actually kinda interesting.) ...And now I'm humming *Seasons of Love*... — Reply to this email directly, view it on GitHub <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMDKU2W6CZJOD2BQQSNFRL2M7KOLAVCNFSM6AAAAABQGMS3AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKNZZGIYTSMBRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

ximinez

Updates look good.

XLS-0066d-lending-protocol/README.md

Co-authored-by: Ed Hennis <[email protected]>

XLS-0066d-lending-protocol/README.md

ximinez · 2025-03-18T23:59:08Z

XLS-0066d-lending-protocol/README.md

+| ----------------- | :----------------: | :-------: | :-----------: | :-----------: | :------------------------------------------------ |
+| `TransactionType` | :heavy_check_mark: | `string`  |   `UINT16`    |   **TODO**    | The transaction type.                             |
+| `LoanBrokerID`    | :heavy_check_mark: | `string`  |   `HASH256`   |     `N/A`     | The Loan Broker ID to deposit First-Loss Capital. |
+| `Amount`          | :heavy_check_mark: | `object`  |   `NUMBER`    |       0       | The Fist-Loss Capital amount to deposit.          |


sfAmount is an AMOUNT field, which requires currency, issuer, etc. I assume that's not what you want, in which case, we've got sfNumber

@ximinez I'm just getting to reviewing the comments now. Are you suggesting we rename Amount field to Number ?

@Tapanito Either

Change the type of Amount to AMOUNT to match the pre-existing defintion.

OR Change the name of Amount to an existing NUMBER field, or a new field that will be created as NUMBER. It could be Number, but it doesn't have to.

ximinez · 2025-03-19T00:00:44Z

XLS-0066d-lending-protocol/README.md

+| ----------------- | :----------------: | :-------: | :-----------: | :-----------: | :------------------------------------------------------------ |
+| `TransactionType` | :heavy_check_mark: | `string`  |   `UINT16`    |   **TODO**    | Transaction type.                                             |
+| `LoanBrokerID`    | :heavy_check_mark: | `string`  |   `HASH256`   |     `N/A`     | The Loan Broker ID from which to withdraw First-Loss Capital. |
+| `Amount`          | :heavy_check_mark: | `object`  |   `NUMBER`    |       0       | The amount of Vault asset to withdraw.                        |


Also here: sfAmount is an AMOUNT field, which requires currency, issuer, etc. I assume that's not what you want, in which case, we've got sfNumber

Perhaps it's worth keeping it as amount, and chaking the type to amount too? Just in case, in the future, we want to support depositing different cover assets?

Perhaps it's worth keeping it as amount, and chaking the type to amount too? Just in case, in the future, we want to support depositing different cover assets?

But doesn't the deposit go into the Single Asset Vault? That can't hold different types of assets.

Perhaps it's worth keeping it as amount, and chaking the type to amount too? Just in case, in the future, we want to support depositing different cover assets?

But doesn't the deposit go into the Single Asset Vault? That can't hold different types of assets.

But one possible reason to keep this as an Amount is to ensure that it's the right kind of amount, and that the broker doesn't get their asset types mixed up. In that case, it would fail if its the wrong kind of asset.

@ximinez , let's keep it as Amount?

@ximinez , what do you think?

@ximinez , what do you think?

Yeah, I'm fine with keeping it Amount, but the type MUST be changed to AMOUNT.

XLS-0066d-lending-protocol/README.md

Tapanito · 2025-03-19T22:08:49Z

No, since we introduced a pseudo-account for the LoanBroker, the deposit will go there

…

On Wed, 19 Mar 2025 at 23:03, Ed Hennis ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In XLS-0066d-lending-protocol/README.md <#240 (comment)>: > + +##### 3.1.3.3 Invariants + +**TBD** + +[**Return to Index**](#index) + +#### 3.1.4 `LoanBrokerCoverWithdraw` + +The `LoanBrokerCoverWithdraw` transaction withdraws the First-Loss Capital from the `LoanBroker`. + +| Field Name | Required? | JSON Type | Internal Type | Default Value | Description | +| ----------------- | :----------------: | :-------: | :-----------: | :-----------: | :------------------------------------------------------------ | +| `TransactionType` | ✔️ | `string` | `UINT16` | **TODO** | Transaction type. | +| `LoanBrokerID` | ✔️ | `string` | `HASH256` | `N/A` | The Loan Broker ID from which to withdraw First-Loss Capital. | +| `Amount` | ✔️ | `object` | `NUMBER` | 0 | The amount of Vault asset to withdraw. | Perhaps it's worth keeping it as amount, and chaking the type to amount too? Just in case, in the future, we want to support depositing different cover assets? But doesn't the deposit go into the Single Asset Vault? That can't hold different types of assets. — Reply to this email directly, view it on GitHub <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMDKUZ7CZWQZZUZKUFZQZD2VHSULAVCNFSM6AAAAABQGMS3AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOMBQGM3TONZRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Sincerely, Vytautas Tumas

ximinez · 2025-03-20T16:30:33Z

No, since we introduced a pseudo-account for the LoanBroker, the deposit will go there

Right, I wasn't thinking about that, but if there is a loan default, and funds have to be paid out of the Cover Amount, wouldn't that go to the SAV?

Tapanito · 2025-03-20T16:58:24Z

No, since we introduced a pseudo-account for the LoanBroker, the deposit will go there

Right, I wasn't thinking about that, but if there is a loan default, and funds have to be paid out of the Cover Amount, wouldn't that go to the SAV?

Yes, 100%, the cover amount liquidation, in essence, will become a transfer of asset from one pseduo-account to another, with some accounting state changes.

ximinez · 2025-03-21T19:11:42Z

No, since we introduced a pseudo-account for the LoanBroker, the deposit will go there

Right, I wasn't thinking about that, but if there is a loan default, and funds have to be paid out of the Cover Amount, wouldn't that go to the SAV?

Yes, 100%, the cover amount liquidation, in essence, will become a transfer of asset from one pseduo-account to another, with some accounting state changes.

Right, so they should be the same currency, no? I'm fine with it being an STAmount as long as we're on the same page that the transaction should fail if it's not the same currency as the SAV.

XLS-0066d-lending-protocol/README.md

ximinez · 2025-04-07T21:11:22Z

XLS-0066d-lending-protocol/README.md

+| `Flags`                |                    | `string`  |   `UINT32`    |       0       | Specifies the flags for the Lending Protocol.                                                                                                      |
+| `Data`                 |                    | `string`  |    `BLOB`     |     None      | Arbitrary metadata in hex format. The field is limited to 256 bytes.                                                                               |
+| `ManagementFeeRate`    |                    | `number`  |   `UINT16`    |       0       | The 1/10th basis point fee charged by the Lending Protocol Owner. Valid values are between 0 and 10000 inclusive.                                  |
+| `DebtMaximum`          |                    | `number`  |   `NUMBER`    |       0       | The maximum amount the protocol can owe the Vault. The default value of 0 means there is no limit to the debt.                                     |


Also, should this value have a maximum? Maybe maxMPTokenAmount?

std::uint64_t constexpr maxMPTokenAmount = 0x7FFF'FFFF'FFFF'FFFFull;

Tapanito added 2 commits October 18, 2024 18:28

adds lending protocol spec

ba3a750

improves the description of the management fee

d3e6115

renames field names from plural to singular

b297e6e

ximinez suggested changes Jan 24, 2025

View reviewed changes

Tapanito and others added 7 commits January 27, 2025 16:40

removes CoverAvailable check from LoanBrokerDelete transaction

f18e8f1

Apply suggestions from code review

44e1b57

Co-authored-by: Ed Hennis <[email protected]>

cleans up latex code

1a437ee

updates LoanDelete transaction to delete the LoanBroker DirectoryNode…

9f47ea2

… when the last Loan is delete

in case insufficient first loss capital add loan broker fees to cover…

60a311e

… for the missing flc

fixes loan object ownership

9090bd3

adds pseudo-account to the LoanBroker

8851620

ximinez approved these changes Jan 29, 2025

View reviewed changes

Tapanito added 2 commits January 31, 2025 12:51

adds counterparty to LoanSet transaction

0f6644c

updates failure conditions of LoanSet transaction

14a634f

ximinez suggested changes Mar 12, 2025

View reviewed changes

XLS-0066d-lending-protocol/README.md Outdated Show resolved Hide resolved

ximinez suggested changes Mar 12, 2025

View reviewed changes

XLS-0066d-lending-protocol/README.md Outdated Show resolved Hide resolved

Update XLS-0066d-lending-protocol/README.md

b77401b

Co-authored-by: Ed Hennis <[email protected]>

ximinez suggested changes Mar 19, 2025

View reviewed changes

Tapanito added 2 commits March 19, 2025 11:30

addresses PR comments

aa50126

fixes signature field name

9acddc1

ximinez suggested changes Mar 31, 2025

View reviewed changes

XLS-0066d-lending-protocol/README.md Outdated Show resolved Hide resolved

Tapanito added 2 commits April 4, 2025 12:42

changes internal type of cover rate variables

294f582

renames singular vault attributes to plural

8740e2f

ximinez reviewed Apr 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

XLS-0066d Lending Protocol #240

XLS-0066d Lending Protocol #240

Tapanito commented Oct 18, 2024

sappenin commented Nov 25, 2024

Tapanito commented Dec 4, 2024

sappenin commented Dec 4, 2024

Tapanito commented Jan 28, 2025 via email

Tapanito commented Jan 28, 2025 via email

ximinez left a comment

ximinez Mar 18, 2025

Tapanito Apr 4, 2025

ximinez Apr 4, 2025

ximinez Mar 19, 2025

Tapanito Mar 19, 2025

ximinez Mar 19, 2025

ximinez Mar 19, 2025

Tapanito Mar 21, 2025

Tapanito Apr 4, 2025

ximinez Apr 4, 2025

Tapanito commented Mar 19, 2025 via email

ximinez commented Mar 20, 2025

Tapanito commented Mar 20, 2025

ximinez commented Mar 21, 2025

ximinez Apr 7, 2025

ximinez Apr 7, 2025

	\| `DebtMaximum` \| \| `number` \| `NUMBER` \| 0 \| The maximum amount the protocol can owe the Vault. The default value of 0 means there is no limit to the debt. \|
	\| `DebtMaximum` \| \| `number` \| `NUMBER` \| 0 \| The maximum amount the protocol can owe the Vault. The default value of 0 means there is no limit to the debt. Must not be negative. \|

XLS-0066d Lending Protocol #240

Are you sure you want to change the base?

XLS-0066d Lending Protocol #240

Conversation

Tapanito commented Oct 18, 2024

sappenin commented Nov 25, 2024

Tapanito commented Dec 4, 2024

sappenin commented Dec 4, 2024

Tapanito commented Jan 28, 2025 via email

Tapanito commented Jan 28, 2025 via email

ximinez 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

Tapanito commented Mar 19, 2025 via email

ximinez commented Mar 20, 2025

Tapanito commented Mar 20, 2025

ximinez commented Mar 21, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment