Issue Description
In AccountDelete (src/libxrpl/tx/transactors/account/AccountDelete.cpp), AMM pseudo-accounts are protected from deletion only incidentally: the ltAMM ledger entry type is absent from the nonObligationDeleter switch (lines 175–200), so nullptr is returned, which causes tecHAS_OBLIGATIONS. This protection is a side-effect of the switch's default case, not an explicit design guard.
If ltAMM is ever added to nonObligationDeleter in a future refactor (e.g., for cleanup purposes), the protection silently disappears.
Steps to Reproduce
Not currently exploitable — AMM accounts cannot be deleted today.
Expected Result
Add an explicit check in AccountDelete::preclaim to reject deletion of AMM pseudo-accounts:
if (sleAccount->isFieldPresent(sfAMMID))
return tecHAS_OBLIGATIONS;
This makes the intent explicit and future-proof.
Actual Result
Protection relies on ltAMM being absent from the nonObligationDeleter switch — an implicit, fragile invariant.
Environment
All versions with AMM support (XLS-30).
Supporting Files
N/A
Issue Description
In
AccountDelete(src/libxrpl/tx/transactors/account/AccountDelete.cpp), AMM pseudo-accounts are protected from deletion only incidentally: theltAMMledger entry type is absent from thenonObligationDeleterswitch (lines 175–200), sonullptris returned, which causestecHAS_OBLIGATIONS. This protection is a side-effect of the switch's default case, not an explicit design guard.If
ltAMMis ever added tononObligationDeleterin a future refactor (e.g., for cleanup purposes), the protection silently disappears.Steps to Reproduce
Not currently exploitable — AMM accounts cannot be deleted today.
Expected Result
Add an explicit check in
AccountDelete::preclaimto reject deletion of AMM pseudo-accounts:This makes the intent explicit and future-proof.
Actual Result
Protection relies on
ltAMMbeing absent from thenonObligationDeleterswitch — an implicit, fragile invariant.Environment
All versions with AMM support (XLS-30).
Supporting Files
N/A