Conversation
Replace checkMPTTxAllowed() with canMPTTradeAndTransfer().
Co-authored-by: xrplf-ai-reviewer[bot] <266832837+xrplf-ai-reviewer[bot]@users.noreply.github.com>
| } | ||
|
|
||
| return canTrade(ctx.view, ctx.tx[sfSendMax].asset()); | ||
| return tesSUCCESS; |
There was a problem hiding this comment.
Removed canTrade() check replaced with unconditional success — verify IOU tradeability is still enforced elsewhere at creation time.
The old code returned canTrade(ctx.view, ctx.tx[sfSendMax].asset()) here, which gated check creation on asset tradeability. The MPT path now has an explicit canTransfer guard (lines 148–153), but the IOU visitor branch (lines 103–135) should be audited to confirm an equivalent check exists. Dropping this shifts all IOU trade enforcement to cash time, creating a single point of failure if CheckCash is ever bypassed or misconfigured.
There was a problem hiding this comment.
This is not an issue. canTrade() was added for MPT/DEX feature. canTrade() returns tesSUCCESS for Issue. Since CheckCreate is not a DEX transaction, this logic is reverted to pre MPT/DEX code-base; i.e., return tesSUCCESS. canTransfer() is added only for MPTIssue to check if MPTCanTransfer flag is enabled.
| // Check once: if any involved account is frozen, the whole | ||
| // issuance transfer is considered frozen. Only need to check for | ||
| // frozen if there is a transfer of funds. | ||
| if (!frozen && isFrozen(view, account, MPTIssue{mptID})) |
There was a problem hiding this comment.
do we possibly want to include requireAuth as well?
There was a problem hiding this comment.
Sure. This is going to be a check for the receivers only, right?
There was a problem hiding this comment.
Would it also make sense to check for sender as well? Both should have auth when transferring
There was a problem hiding this comment.
The problem with send is that the send object could be deleted, in which case requireAuth fails. I can call it with WeakAuth, but it still might fail. The only thing that I can do if it's deleted is to check for MPTRequireAuth flag on the MPTokenIssuance and if set then check MPTAuthorized flag on before object. If the latter is not set then the invariant fails.
Co-authored-by: Shawn Xie <35279399+shawnxie999@users.noreply.github.com>
| // DEX transactions (AMM[Create,Deposit,Withdraw], cross-currency payments, offer creates) are | ||
| // subject to the MPTCanTrade flag in addition to the standard transfer rules. | ||
| // A payment is only DEX if it is a cross-currency payment. | ||
| auto const isDEX = [&tx, &txnType] { |
There was a problem hiding this comment.
txnType is captured by reference but never declared in scope — won't compile. Declare it before the lambda:
auto const txnType = tx.getTxnType();
auto const isDEX = [&tx, &txnType] {
| } | ||
|
|
||
| return canTrade(ctx.view, ctx.tx[sfSendMax].asset()); | ||
| return tesSUCCESS; |
There was a problem hiding this comment.
Unconditional tesSUCCESS replaces the prior canTrade call — confirm IOU trading restrictions are enforced elsewhere.
There was a problem hiding this comment.
This is correct change.
There was a problem hiding this comment.
Looked through this one
Potential validation gap at line 167 — the unconditional canTrade call for all asset types was replaced with tesSUCCESS; the IOU path may be missing an equivalent check. See inline.
Review by ReviewBot 🤖
Review by Claude Opus 4.6 · Prompt: V14
| } | ||
|
|
||
| return canTrade(ctx.view, ctx.tx[sfSendMax].asset()); | ||
| return tesSUCCESS; |
There was a problem hiding this comment.
canTrade was previously called unconditionally for all asset types — confirm it was a no-op for IOU assets, or add an IOU branch validation to avoid silently dropping that check.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #6855 +/- ##
=========================================
- Coverage 81.6% 81.6% -0.0%
=========================================
Files 1010 1010
Lines 75973 76030 +57
Branches 7610 7604 -6
=========================================
+ Hits 61993 62038 +45
- Misses 13980 13992 +12
🚀 New features to boost your workflow:
|
| ReadView const& view, | ||
| beast::Journal const& j) | ||
| { | ||
| // AMMClawback is called by the issuer, so freeze restrictions do not apply. |
There was a problem hiding this comment.
nit - this comment can probably be removed/changed
| if (!frozen && isFrozen(view, account, MPTIssue{mptID})) | ||
| { | ||
| frozen = true; | ||
| } |
There was a problem hiding this comment.
Could we combine the auth checks with the freeze logic here? That way we wouldn’t need separate frozen and reqAuth booleans—we could instead use a single illegalTransfer boolean that covers both cases. (it probably doesn't hurt to check auth for the sender)
* Combine frozen and reqAuth. * Check senders and receivers for reqAuth.
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
High Level Overview of Change