-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XLS-39d: Clawback specification #104
Conversation
Title in the filename should be lowercase and the draft should use the template format: https://github.com/XRPLF/XRPL-Standards/blob/master/xls-template.md Also, for good measure, the author of the proposal should move this from discussion to draft, but if he is OK with it in the current form, let's progress 👍 CC: @nbougalis |
@Silkjaer Normally it would be owner of discussion to move it into PR. But this time is an exception since I will be the one updating this spec from now on |
I'm fine with @shawnxie999 taking over this proposal. |
My comment is about this statement (and other similar statements in the spec):
I think that having the ability to freeze (or unfreeze) as part of the clawback makes sense and provides the issuer flexibility, but there's no real technical reason to freeze a trustline prior to executing a clawback, and you shouldn't present it as such. |
@nbougalis Also from a design perspective, it will give token holders more confidence that their funds won't be randomly clawback from them, if clawback is implemented to be part of freeze. |
Perhaps operationally that's how it's done, but the spec shouldn't present this as a de-facto technical requirement. |
If this isn't part of the technical requirement, it will give more flexibility for the issuer. But, I think it would be more important to care about what the token holder think when it comes to the clawback ability. When this amendment goes live, token holders will be really concerned knowing that the issuer can randomly clawback all of their funds. |
I've updated the spec to add an additional |
Updated the spec again to reflect the change of the global flag: from |
The latest revision removed the flags for clawback transaction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spec looks great! Simple and direct.
I spotted a couple of editing kinds of things that might want to be cleaned up. But nothing that should hold up release.
|------------|:----------------:|:---------:|:-------------:| | ||
| `Amount` |:heavy_check_mark:| `object` | `AMOUNT` | | ||
|
||
Indicates the amount being clawed back, as well as the counterparty from which the amount is being clawed back from. It is not an error if the amount exceeds the holder's balance; in that case, the maximum available balance is clawed back. It returns `temBAD_AMOUNT` is the amount is zero. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "... from which the amount is being clawed back from.
Nit: "is the amount" -> "if the amount"
This proposal introduces one new transaction: `Clawback` | ||
|
||
#### 3.3.1. `Clawback` transaction | ||
The **`Clawback`** transaction modifies a trustline object, by adjusting the balance accordingly and, if instructed to, by changing relevant flags. If possible (i.e. if the `Clawback` transaction would leave the trustline is in the "default" state), the transaction will also remove the trustline. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the Clawback
transaction no longer affects trust line flags 🎉 . So I think the part of the sentence about "changing relevant flags" should be removed. Consider changing the sentence to something like...
The
Clawback
transaction modifies a trustline object by adjusting the balance. If theClawback
transaction leaves the trustline in the "default" state, the transaction also removes the trustline.
This really is the first issue that has highlighted the interdependency that is some times present in tickets for me, this proposal has in its discussion phase treaded lightly on the fact that it effects others. I would like to understand the rational given that the AMM was excluded from the scope of this? Yet other non-spendable transaction types like Escrows (for IOU's XLS-34) are not. Both are at similar stage of completed. Possibly going forward, a review of what amendments are effected, proposed as well us the current working body of work should be one of the agreed upon gates before the XLS gets closed. |
@lathanbritz Perhaps the spec was not clear. Payment channel and escrow of IOU is excluded from as well. In other words, clawback cannot clawback the tokens that are locked up in escrow or payment channel. It would not affect other amendments |
Thank you @shawnxie999 maybe the review process could specifically require a effected/not-effected table as the XLS agreed upon and closed, would be very helpful. |
I think that's a good idea. Should we update the template to introduce a new section for this? @intelliot |
Latest version: XLS-39d: Clawback
This is the XLS-39d spec proprosal for what originally is in discussion.
Proposed implementation: XRPLF/rippled#4553