Conversation
Sync: Ripple(d) 2.4.0
* 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.
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`.
Backport of XRPLF/rippled#6325. The python version runs ~80x faster.
…gparse" This reverts commit 5c1d7d9.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #718 +/- ##
==========================================
+ Coverage 66.57% 66.59% +0.02%
==========================================
Files 837 837
Lines 78540 78593 +53
Branches 44600 44642 +42
==========================================
+ Hits 52288 52342 +54
+ Misses 17859 17855 -4
- Partials 8393 8396 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
RichardAH
reviewed
Apr 30, 2026
Support cases where you want to use a Hook without a HookName, even though it is currently set in the Definition.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
High Level Overview of Change
Add support for named hooks via a new optional HookName field on hook definitions/usages.
This change introduces the featureNamedHooks amendment, allows SetHook to create/install/update hooks with an optional UTF-8 hook name, and updates hook execution/fee calculation so named hooks only run when the incoming transaction includes the matching HookName. The PR also adds coverage for invalid names, create/install/update flows, strong/weak execution paths, and callback/emitted transaction behavior.
Context of Change
Today hooks are selected only by install position and existing hook matching rules. This change adds a lightweight name-based gate so an installed hook can require an explicit transaction opt-in through HookName.
The implementation keeps HookName on the installed ltHook object rather than the shared hook definition, which avoids changing hook bytecode identity and lets different accounts install the same hook definition with or without a name. Validation enforces that HookName is either empty or a valid UTF-8 string between 4 and 16 bytes (8 to 32 hex chars in JSON form). Transactions carrying HookName are preflight-validated.
Type of Change
Before / After
Before:
HookName.After: