Conversation
- not fully tested - need to modify: Reserve check where using sfOwnerCount
| TYPED_SFIELD(sfSponsor, ACCOUNT, 27) | ||
| TYPED_SFIELD(sfHighSponsor, ACCOUNT, 28) | ||
| TYPED_SFIELD(sfLowSponsor, ACCOUNT, 29) | ||
| TYPED_SFIELD(sfCounterpartySponsor, ACCOUNT, 30) |
There was a problem hiding this comment.
XLS-68 updated, sfCounterpartySponsor not present
There was a problem hiding this comment.
@mvadari
I believe this field is necessary, but was it missing from the spec?
| featureSponsor, | ||
| noPriv, | ||
| ({ | ||
| {sfCounterpartySponsor, soeOPTIONAL}, |
There was a problem hiding this comment.
XLS-68 updated, please fix (sfSponsor)
| featureSponsor, | ||
| noPriv, | ||
| ({ | ||
| {sfCounterpartySponsor, soeOPTIONAL}, |
|
|
||
| auto reserveSponsorAccSle = getTxReserveSponsor(view(), ctx_.tx); | ||
|
|
||
| if (feeAmount && (*feeAmount).xrp() > (*sponsorAccSle)[sfBalance]) |
There was a problem hiding this comment.
SponsorshipSet update path: balance check uses total feeAmount instead of delta
In SponsorshipSet::doApply(), the balance check at line 225 compares the total new feeAmount from the transaction against the sponsor's current balance. This check runs before both the Create and Update code paths. For the Create path, this is correct. However, for the Update path (line 276+), the check is incorrect because it should compare only the delta (new - current) against the balance.
| } | ||
|
|
||
| FeePayer | ||
| Transactor::getFeePayer(ReadView const& view, STTx const& tx) |
There was a problem hiding this comment.
A drive-by thought: would it be better to have this function live in STTx?
There was a problem hiding this comment.
Upon further review of this function, I think what makes more sense is a simpler function in STTx that just returns sfSponsor.value_or(sfDelegate).value_or(sfAccount) (I know this isn't completely correct but my point is that it just returns the account, which this function can ingest for the more complicated analysis, but the STTx helper function may be useful elsewhere)
There was a problem hiding this comment.
If a FeeSponsor exists, we need to know whether it's PreFunded or CoSigning.
To determine this, we need a "view".
That's why I've implemented it as Transactor::getFeePayer(). And Instead of just returning an AccountID, it returns information such as the AccountKeylet and the field where the fee is deducted.
|
|
||
| FeePayer | ||
| Transactor::getFeePayer(ReadView const& view, STTx const& tx) | ||
| { |
There was a problem hiding this comment.
Another drive-by thought: we could merge a refactor version of introducing getFeePayer into develop to make this PR a bit smaller/easier to read.
High Level Overview of Change
Context of Change
Type of Change
API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)