XLS-85d: Token-Enabled Escrows#5185
Conversation
|
@oleks-rip Thank you for the initial review. Right now I'm just focusing on the actual core implementation and how it effects MPT and IOU. I will address the nit changes you requested once the core implementation is done. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5185 +/- ##
=========================================
+ Coverage 78.9% 79.0% +0.1%
=========================================
Files 817 817
Lines 71139 71737 +598
Branches 8262 8313 +51
=========================================
+ Hits 56112 56657 +545
- Misses 15027 15080 +53
🚀 New features to boost your workflow:
|
- makeFieldAbsent `sfLockedAmount` on mptoken - add logging to MPTLock and MPTUnlock - remove canAdd check for MPT - add max MPT amount tests - add overflow check to canSubtract - use MPTAmount:: value_type max/min
|
@XRPLF/rpc-reviewers we would like to cut the release candidate for 2.5.0 today - any chance you can take a look at this PR for the RPC-related changes? |
|
@dangell7 I'm planning on merging this soon - is it ready to go? |
|
| auto const k = keylet::escrow(ctx.tx[sfOwner], ctx.tx[sfOfferSequence]); | ||
| auto const slep = ctx.view.read(k); | ||
| if (!slep) | ||
| return tecNO_TARGET; |
There was a problem hiding this comment.
@dangell7 since this check is being moved up, doesn't it need to be amendment-guarded, due to the possibility of the transaction error changing since they're now checked in a different order?
There was a problem hiding this comment.
this check was moved up from the the start of doApply. The order shouldn't change.
There was a problem hiding this comment.
There are a number of checks in Transactor that occur between preclaim and doApply
There was a problem hiding this comment.
Yes looks like it thank you
* Update the `account_info` API so that the `allowTrustLineLocking` flag is included in the response. * The proposed `TokenEscrow` amendment added an `allowTrustLineLocking` flag in the `AccountRoot` object. * In the API response, under `account_flags`, there is now an `allowTrustLineLocking` field with a boolean (`true` or `false`) value. * For reference, the XLS-85 Token-Enabled Escrows implementation can be found in #5185
…draw Similarly to other transaction typed that can create a trust line or MPToken for the transaction submitter (e.g. CashCheck #5285, EscrowFinish #5185 ), VaultWithdraw should enforce reserve before creating a new object. Additionally, the lsfRequireDestTag account flag should be enforced for the transaction submitter.
…draw (#5857) Similarly to other transaction typed that can create a trust line or MPToken for the transaction submitter (e.g. CashCheck #5285, EscrowFinish #5185 ), VaultWithdraw should enforce reserve before creating a new object. Additionally, the lsfRequireDestTag account flag should be enforced for the transaction submitter. Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
…draw (#5857) Similarly to other transaction typed that can create a trust line or MPToken for the transaction submitter (e.g. CashCheck #5285, EscrowFinish #5185 ), VaultWithdraw should enforce reserve before creating a new object. Additionally, the lsfRequireDestTag account flag should be enforced for the transaction submitter. Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
…draw (#5857) Similarly to other transaction typed that can create a trust line or MPToken for the transaction submitter (e.g. CashCheck #5285, EscrowFinish #5185 ), VaultWithdraw should enforce reserve before creating a new object. Additionally, the lsfRequireDestTag account flag should be enforced for the transaction submitter. Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
High Level Overview of Change
XLS: XRPLF/XRPL-Standards#248
XLS PR: XRPLF/XRPL-Standards#272
Context of Change
Type of Change
.gitignore, formatting, dropping support for older tooling)API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)