XLS-93: Token PayChan - #536
Conversation
dangell7
changed the title
dangell7
changed the title
|
@dangell7 I can't review this PR until it's updated to match the latest |
sorry, done |
|
It looks like the |
|
Does locking a token into a payment channel prevent deletion of the source's trustline (IOU) or MPToken (MPT) while the channel is open? The spec doesn't state this either way, and the "Channel Closure → Source Lacks Trustline or MPT Holding" failure conditions suggest the source's holding may be absent at closure — implying deletion is not blocked. If that's the intent, then in MPT: sfLockedAmount is tracked on the source's MPToken. If that object can be deleted while a channel holds locked value, the per-holder locked accounting is orphaned (the issuance-level sfLockedAmount still counts it, but the holder record is gone). |
| - **MPTs**: If the source does not hold the MPT, the transaction fails with `tecOBJECT_NOT_FOUND`. | ||
|
|
||
| - **Source or Destination is Frozen or Token is Locked:** | ||
| - **IOU Tokens**: If the token is frozen (global/individual/deepfreeze) for the source or the destination, the transaction fails with `tecFROZEN`. |
There was a problem hiding this comment.
Individual freeze on the destination: an individual freeze stops the frozen holder from sending, not receiving (only deep freeze blocks receiving). As the destination is only a receiver, an individual freeze on the destination alone shouldn't prevent creation. This also seems inconsistent with the Claim section ("Global/Individual Freeze: The transaction succeeds").
There was a problem hiding this comment.
This matches XLS-85 escrow today, same shared helper. Claim only checks deep freeze so the payee isn't stranded. Added a note to the spec.
There was a problem hiding this comment.
Glad to hear payee is not stranded.
So xls-85 is off too and too late (or doesn't worth) to fix?
There was a problem hiding this comment.
btw, this is not a blocker. Just curious. All my comments are addressed. Thanks.
| - **IOU Tokens**: If the source lacks a trustline with the issuer, the transaction fails with `tecNO_LINE`. | ||
| - **MPTs**: If the source does not hold the MPT, the transaction fails with `tecOBJECT_NOT_FOUND`. | ||
|
|
||
| - **Source or Destination is Frozen or Token is Locked:** |
There was a problem hiding this comment.
I think a token can be sent back to its issuer even under deep freeze (per the base freeze rules — the holder can always pay the issuer directly, which holds for individual, global, and deep freeze). If so, opening a channel whose destination is the issuer isn't disallowed by existing freeze rules. I think it's reasonable to disallow it here anyway, but I'd like to confirm that's intentional rather than a side effect of the blanket freeze check. The same applies to MPT (lock).
There was a problem hiding this comment.
dest=issuer is allowed, claims just redeem to the issuer. Only create during global freeze is blocked, same as escrow. Spec is explicit now.
There was a problem hiding this comment.
thanks! you have to resolve the comment since I don't have the button.
|
|
||
| ### 1.4.1. IOU Tokens (`TransferRate`) | ||
|
|
||
| - **Rate Capped at Creation**: The `TransferRate` is captured at the time of `PaymentChannelCreate` and stored in the `PaymentChannel` object. At claim time, the lower of the stored rate and the issuer's current rate is applied: an increase by the issuer does not affect existing channels, while a decrease passes through to claims. |
There was a problem hiding this comment.
This differs from XLS-85 (Token Escrow), which uses the rate captured at creation and applies it at finish regardless of later issuer changes — no "lower of" comparison. Since XLS-93 otherwise mirrors XLS-85 closely, I wanted to confirm this divergence is intentional.
I like being favoring the destination too. But a quick search by claude says the majority of IOUs have no fee. So maybe it does not worth the extra complexity.
There was a problem hiding this comment.
The live XLS-85 implementation already does min(stored, current), its the XLS-85 spec text thats stale. XLS-93 matches the code.
| - **Global/Individual Freeze**: The transaction succeeds, allowing the channel to be closed. | ||
| - **MPTs**: | ||
| - **Lock Conditions (Deep Freeze Equivalent)**: The transaction succeeds, allowing the channel to be closed. | ||
|
|
There was a problem hiding this comment.
I think in principle, the destination should be able to claim what it has already earned, up until expiration.
The Normal Claim path reflects this — it checks only destination-side conditions, not the source. But the closure path adds source-side checks (source auth, trustline/MPT holding, freeze), and since a fully-drained channel closes automatically, the payee's final claim is a closure — so it gets gated differently from an identical non-draining claim.
This opens a griefing vector: a source can manipulate its own state (e.g. removing its trustline, or getting itself frozen/locked) to make those checks fail and block the payee's claim. Unclaimed funds return to the source at expiration, so the source can wait out the channel and recover value the payee had already earned.
There was a problem hiding this comment.
A draining claim doesn't close the channel, and closeChannel only runs the source side checks when there's a remainder to refund. The payee can always take earned funds with a plain claim before expiration. Reworded the closure section to scope the failure conditions to the refund.
|
Please address CI failures and follow the standard templates. |
|
@pwang200 Correct, inherited from XLS-85. IOU line can be deleted (refund then fails tecNO_LINE until its recreated), MPT can't (tecHAS_OBLIGATIONS). Spec documents both, per line lock accounting would be a separate fix amendment covering escrow too. |
|
Restructured to the template, validator passes now. |
4 participants
High Level Overview of Change
Context of Change
Type of Change