XLS-0066d Lending Protocol #240
Conversation
|
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. |
|
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 |
- 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
|
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:
***@***.***>
|
|
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:
***@***.***>
|
Co-authored-by: Ed Hennis <[email protected]>
|
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
|
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 |
|
Yeah, I think the potential for confusion is a very good argument, that I
couldn't agree more with. Let's add LoanSequence to LoanBroker. Though,
this still might have the issue of UX confusion, as if I tried looking up
all my Loans I might have a lot of Loans with LoanSequence number 1.
However, I think this is the most elegant solution, and the UIs should be
weary of this nuance
…On Tue, Apr 29, 2025, 21:20 Ed Hennis ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In XLS-0066d-lending-protocol/README.md
<#240 (comment)>:
> +The `LoanID` is calculated as follows:
+
+- Calculate [`SHA512-Half`](https://xrpl.org/docs/references/protocol/data-types/basic-data-types/#hashes) of the following values:
+ - The `Loan` space key `0x004C` (capital L)
+ - The [`AccountID`](https://xrpl.org/docs/references/protocol/binary-format/#accountid-fields) of the Borrower account.
+ - The `LoanBrokerID` of the associated `LoanBroker` object.
+ - The `Sequence` number of the **`LoanSet`** transaction. If the transaction used a [Ticket](https://xrpl.org/docs/concepts/accounts/tickets/), use the `TicketSequence` value.
...And now I've had another idea, and it might be even simpler, especially
when you consider the RPC parameters.
The LoanID is the hash of *only*
- The Loan space key 0x004C (capital L)
- The LoanBrokerID of the associated LoanBroker object.
- The LoanSequence of the associated LoanBroker object.
- This will be a new field that is initialized to 1 when the
LoanBroker is created, and incremented during every LoanSet.
Pros:
- It's one *less* thing you need to have to find the Loan.
- It's still guaranteed unique, because the LoanBrokerID is unique.
- It's unambiguous: No user is going to see a loan with the same
LoanBrokerID / Sequence combo. (Maybe we change the Loan field from
Sequence to LoanSequence, too, just to make it clearer.)
- The RPC parameters become that much simpler:
- LoanBrokerID and LoanSequence
- Or, if you don't remember the LoanBrokerID, you could use its
components: AccountID and seq of the loan broker owner's
transaction that created the LoanBroker, plus LoanSequence.
—
Reply to this email directly, view it on GitHub
<#240 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMDKUYRTXHGXDO6YXPS76L237GIFAVCNFSM6AAAAABQGMS3AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMBUG4ZDQOBYGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Agreed, we should emphasize that the "key" is the |
Co-authored-by: Ed Hennis <[email protected]>
Co-authored-by: Ed Hennis <[email protected]>
Co-authored-by: Ed Hennis <[email protected]>
Co-authored-by: Ed Hennis <[email protected]>
Co-authored-by: Ed Hennis <[email protected]>
…oker pseudo-accounts are not funded
Co-authored-by: Mayukha Vadari <[email protected]>
Tapanito
force-pushed
the
xls-66-lending-protocol
branch
from
1a3e31d to
ed5a62d
Compare
Discussion thread can be found here: #190
Development branch can be found here: TBD