* clang-format-18 pass over the json-tx touchpoints so the
clang-format CI workflow is green.
* regenerate hook/sfcodes.h (adds the sfJsonTxBody entry) so the
verify-generated-headers CI workflow is green.
hasBody was conflating 'field is declared' with 'field is non-empty'.
a classical tx could ride along with a spurious empty sfJsonTxBody and
silently fall through to the classical sig path.
now:
* hasBody = sfJsonTxBody is present (pure routing predicate)
* checkSignature / checkStructuralEquivalence reject an empty body up
front with an explicit 'JsonTxBody is empty.' error string
behaviour for well-formed json-tx and well-formed classical-tx is
unchanged; the classical+empty-body edge case now fails cleanly instead
of silently routing classical.
python exploration of the client-side (any json) and node-side (field-aware
codec: OP_FIELD / OP_NAME / OP_VALUE / OP_TAG / OP_RAW). not wired into
the c++ build; kept for design reference and size measurements.
introduces a signing scheme where the signature covers the raw utf-8
bytes of a tx_json_str the client produced, rather than the classical
binary signing payload. clients need no codec library: dump json,
sign bytes, post.
protocol:
* new sfJsonTxBody VL field (notSigning) carrying the exact ascii bytes
* new featureJsonTx amendment gating the new sign path
* STTx::checkSign routes to jsonTx::checkSignature when the amendment
is active and the body is present
* passesLocalChecks runs jsonTx::checkStructuralEquivalence so the body
must parse to the same canonical fields as the tx itself
helper:
* include/xrpl/protocol/JsonTx.h -- hasBody / body / bodyHash
(sha512half over the body) / checkSignature / checkStructuralEquivalence
rpc:
* submit_json_tx handler: { tx_json_str, signature } -> verify ascii sig,
stuff body + sig into the tx, forceValidity(SigGoodOnly), route through
the normal processTransaction flow. gated on featureJsonTx.
tests:
* ripple.app.JsonTx: feature gate, basic roundtrip, invalid params,
invalid json, bad signature, sig-over-different-bytes, wrong pubkey,
helper unit tests including structural-equivalence tamper case.
Due to rounding, the LPTokenBalance of the last LP might not match the LP's trustline balance. This was fixed for `AMMWithdraw` in `fixAMMv1_1` by adjusting the LPTokenBalance to be the same as the trustline balance. Since `AMMClawback` is also performing a withdrawal, we need to adjust LPTokenBalance as well in `AMMClawback.`
This change includes:
1. Refactored `verifyAndAdjustLPTokenBalance` function in `AMMUtils`, which both`AMMWithdraw` and `AMMClawback` call to adjust LPTokenBalance.
2. Added the unit test `testLastHolderLPTokenBalance` to test the scenario.
3. Modify the existing unit tests for `fixAMMClawbackRounding`.
* Add AMM bid/create/deposit/swap/withdraw/vote invariants:
- Deposit, Withdrawal invariants: `sqrt(asset1Balance * asset2Balance) >= LPTokens`.
- Bid: `sqrt(asset1Balance * asset2Balance) > LPTokens` and the pool balances don't change.
- Create: `sqrt(asset1Balance * assetBalance2) == LPTokens`.
- Swap: `asset1BalanceAfter * asset2BalanceAfter >= asset1BalanceBefore * asset2BalanceBefore`
and `LPTokens` don't change.
- Vote: `LPTokens` and pool balances don't change.
- All AMM and swap transactions: amounts and tokens are greater than zero, except on withdrawal if all tokens
are withdrawn.
* Add AMM deposit and withdraw rounding to ensure AMM invariant:
- On deposit, tokens out are rounded downward and deposit amount is rounded upward.
- On withdrawal, tokens in are rounded upward and withdrawal amount is rounded downward.
* Add Order Book Offer invariant to verify consumed amounts. Consumed amounts are less than the offer.
* Fix Bid validation. `AuthAccount` can't have duplicate accounts or the submitter account.
