Merge branch 'develop' into copilot/add-augmented-submit-fields

Co-authored-by: mvadari <8029314+mvadari@users.noreply.github.com>

.claude/CLAUDE.md

@@ -1,54 +0,0 @@
-# Workflow Orchestration
-
-## 1. Plan Mode Default
-- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
-- If something goes sideways, STOP and re-plan immediately - don't keep pushing
-- Use plan mode for verification steps, not just building
-- Write detailed specs upfront to reduce ambiguity
-
-## 2. Subagent Strategy
-- Use subagents liberally to keep main context window clean
-- Offload research, exploration, and parallel analysis to subagents
-- For complex problems, throw compute at it via parallelizing
-- One task per subagent for focused execution
-
-## 3. Self-Improvement Loop
-- After ANY correction from the user: update `tasks/lessons.md` with the pattern
-- Write rules for yourself that prevent the same mistake
-- Ruthlessly iterate on these rules until mistake drops
-- Review lessons at session start for relevant project
-
-## 4. Verification Before Done
-- Never mark a task complete without proving it works
-- Diff behavior between main and your changes when relevant
-- Ask yourself: "Would a staff engineer approve this?"
-- Run tests, check logs, demonstrate correctness
-
-## 5. Demand Elegance (Balanced)
-- For non-trivial changes: pause and ask "is there a more elegant way?"
-- If a fix feels hacky: "Know now, do later, implement the elegant solution"
-- Skip this for simple, obvious fixes - don't over-engineer
-- Challenge your own first solution
-
-## 6. Autonomous Bug Fixing
-- When given a bug report: just fix it. Don't ask for hand-holding
-- Point at logs, errors, failing tests - then resolve them
-- Zero context switching required from the user
-- Go fix failing CI tests without being told how
-
-# Task Management
-
-1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
-2. **Verify Plans**: Check in before starting implementation
-3. **Track Progress**: Mark items complete as you go
-4. **Explain Changes**: High-level summary at each step
-5. **Document Results**: Add review section to `tasks/todo.md`
-6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
-
-# Core Principles
-
-**Simplicity First**: Make every change as simple as possible. Impact minimal code.
-
-**No Boilerplate**: Skip documentation. No README/docs bloat. Test only if requested.
-
-**Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

.claude/skills/amendment.md

@@ -1,530 +0,0 @@
-# XRPL Amendment Creation Skill
-
-This skill guides you through creating XRPL amendments, whether for brand new features or fixes/extensions to existing functionality.
-
-## Amendment Types
-
-There are two main types of amendments:
-
-1. **New Feature Amendment** (`feature{Name}`) - Entirely new functionality
-2. **Fix/Extension Amendment** (`fix{Name}`) - Modifications to existing functionality
-
-## Step 1: Determine Amendment Type
-
-Ask the user:
-- Is this a **brand new feature** (new transaction type, ledger entry, or capability)?
-- Or is this a **fix or extension** to existing functionality?
-
----
-
-## For NEW FEATURE Amendments
-
-### Checklist:
-
-#### 1. Feature Definition in features.macro
-**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
-
-- [ ] Add to TOP of features.macro (reverse chronological order):
-```
-XRPL_FEATURE(YourFeatureName, Supported::no, VoteBehavior::DefaultNo)
-```
-- [ ] This creates the variable `featureYourFeatureName` automatically
-- [ ] Follow naming convention: Use the feature name WITHOUT the "feature" prefix
-- [ ] Examples: `Batch` → `featureBatch`, `LendingProtocol` → `featureLendingProtocol`
-
-#### 2. Support Status
-- [ ] Start with `Supported::no` during development
-- [ ] Change to `Supported::yes` when ready for network voting
-- [ ] Use `VoteBehavior::DefaultNo` (validators must explicitly vote for it)
-
-#### 3. Code Implementation
-- [ ] Implement new functionality (transaction type, ledger entry, etc.)
-- [ ] Add feature gate check in preflight:
-```cpp
-if (!env.current()->rules().enabled(feature{Name}))
-{
-    return temDISABLED;
-}
-```
-
-#### 4. Disable Route Handling
-- [ ] Ensure transaction returns `temDISABLED` when amendment is disabled
-- [ ] Implement early rejection in preflight/preclaim phase
-- [ ] Add appropriate error messages
-
-#### 5. Test Implementation
-Create comprehensive test suite with this structure:
-
-```cpp
-class {FeatureName}_test : public beast::unit_test::suite
-{
-public:
-    void testEnable(FeatureBitset features)
-    {
-        testcase("enabled");
-
-        // Test with feature DISABLED
-        {
-            auto const amendNoFeature = features - feature{Name};
-            Env env{*this, amendNoFeature};
-
-            env(transaction, ter(temDISABLED));
-        }
-
-        // Test with feature ENABLED
-        {
-            Env env{*this, features};
-
-            env(transaction, ter(tesSUCCESS));
-            // Validate new functionality works
-        }
-    }
-
-    void testPreflight(FeatureBitset features)
-    {
-        testcase("preflight");
-        // Test malformed transaction validation
-    }
-
-    void testPreclaim(FeatureBitset features)
-    {
-        testcase("preclaim");
-        // Test signature and claim phase validation
-    }
-
-    void testWithFeats(FeatureBitset features)
-    {
-        testEnable(features);
-        testPreflight(features);
-        testPreclaim(features);
-        // Add feature-specific tests
-    }
-
-    void run() override
-    {
-        using namespace test::jtx;
-        auto const all = supported_amendments();
-        testWithFeats(all);
-    }
-};
-```
-
-#### 6. Test Coverage Requirements
-- [ ] Test amendment DISABLED state (returns `temDISABLED`)
-- [ ] Test amendment ENABLED state (returns `tesSUCCESS`)
-- [ ] Test malformed transactions
-- [ ] Test signature validation
-- [ ] Test edge cases specific to feature
-- [ ] Test amendment transition behavior
-
-#### 7. Documentation
-- [ ] Create specification document (XLS_{NAME}.md)
-- [ ] Document new transaction types, ledger entries, or capabilities
-- [ ] Create test plan document
-- [ ] Document expected behavior when enabled/disabled
-
----
-
-## For FIX/EXTENSION Amendments
-
-### Checklist:
-
-#### 1. Fix Definition in features.macro
-**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
-
-- [ ] Add to TOP of features.macro (reverse chronological order):
-```
-XRPL_FIX(YourFixName, Supported::no, VoteBehavior::DefaultNo)
-```
-- [ ] This creates the variable `fixYourFixName` automatically
-- [ ] Follow naming convention: Use the fix name WITHOUT the "fix" prefix (it's added automatically)
-- [ ] Examples: `TokenEscrowV1` → `fixTokenEscrowV1`, `DirectoryLimit` → `fixDirectoryLimit`
-- [ ] Start with `Supported::no` during development, change to `Supported::yes` when ready
-
-#### 2. Backward Compatibility Implementation
-**Critical**: Use enable() with if/else to preserve existing functionality
-
-```cpp
-// Check if fix is enabled
-bool const fix{Name} = env.current()->rules().enabled(fix{Name});
-
-// Conditional logic based on amendment state
-if (fix{Name})
-{
-    // NEW behavior with fix applied
-    // This is the corrected/improved logic
-}
-else
-{
-    // OLD behavior (legacy path)
-    // Preserve original functionality for backward compatibility
-}
-```
-
-**Alternative pattern with ternary operator:**
-```cpp
-auto& viewToUse = sb.rules().enabled(fix{Name}) ? sb : legacyView;
-```
-
-#### 3. Multiple Fix Versions Pattern
-For iterative fixes, use version checking:
-
-```cpp
-bool const fixV1 = rv.rules().enabled(fixXahauV1);
-bool const fixV2 = rv.rules().enabled(fixXahauV2);
-
-switch (transactionType)
-{
-    case TYPE_1:
-        if (fixV1) {
-            // Behavior with V1 fix
-        } else {
-            // Legacy behavior
-        }
-        break;
-
-    case TYPE_2:
-        if (fixV2) {
-            // Behavior with V2 fix
-        } else if (fixV1) {
-            // Behavior with only V1
-        } else {
-            // Legacy behavior
-        }
-        break;
-}
-```
-
-#### 4. Test Both Paths
-Always test BOTH enabled and disabled states:
-
-```cpp
-void testFix(FeatureBitset features)
-{
-    testcase("fix behavior");
-
-    for (bool withFix : {false, true})
-    {
-        auto const amend = withFix ? features : features - fix{Name};
-        Env env{*this, amend};
-
-        // Setup test scenario
-        env.fund(XRP(1000), alice);
-        env.close();
-
-        if (!withFix)
-        {
-            // Test OLD behavior (before fix)
-            env(operation, ter(expectedErrorWithoutFix));
-            // Verify old behavior is preserved
-        }
-        else
-        {
-            // Test NEW behavior (after fix)
-            env(operation, ter(expectedErrorWithFix));
-            // Verify fix works correctly
-        }
-    }
-}
-```
-
-#### 5. Security Fix Pattern
-For security-critical fixes (like fixBatchInnerSigs):
-
-```cpp
-// Test vulnerability exists WITHOUT fix
-{
-    auto const amendNoFix = features - fix{Name};
-    Env env{*this, amendNoFix};
-
-    // Demonstrate vulnerability
-    // Expected: Validity::Valid (WRONG - vulnerable!)
-    BEAST_EXPECT(result == Validity::Valid);
-}
-
-// Test vulnerability is FIXED WITH amendment
-{
-    Env env{*this, features};
-
-    // Demonstrate fix
-    // Expected: Validity::SigBad (CORRECT - protected!)
-    BEAST_EXPECT(result == Validity::SigBad);
-}
-```
-
-#### 6. Test Coverage Requirements
-- [ ] Test fix DISABLED (legacy behavior preserved)
-- [ ] Test fix ENABLED (new behavior applied)
-- [ ] Test amendment transition
-- [ ] For security fixes: demonstrate vulnerability without fix
-- [ ] For security fixes: demonstrate protection with fix
-- [ ] Test edge cases that triggered the fix
-- [ ] Test combinations with other amendments
-
-#### 7. Documentation
-- [ ] Document what was broken/suboptimal
-- [ ] Document the fix applied
-- [ ] Document backward compatibility behavior
-- [ ] Create test summary showing both paths
-
----
-
-## Best Practices for All Amendments
-
-### 1. Naming Conventions
-- New features: `feature{DescriptiveName}` (e.g., `featureBatch`, `featureHooks`)
-- Fixes: `fix{IssueDescription}` (e.g., `fixBatchInnerSigs`, `fixNSDelete`)
-- Use CamelCase without underscores
-
-### 2. Feature Flag Checking
-```cpp
-// At the point where behavior diverges:
-bool const amendmentEnabled = env.current()->rules().enabled(feature{Name});
-
-// Or in view/rules context:
-if (!rv.rules().enabled(feature{Name}))
-    return {};  // or legacy behavior
-```
-
-### 3. Error Codes
-- New features when disabled: `temDISABLED`
-- Fixes may return different validation errors based on state
-- Document all error code changes
-
-### 4. Test Structure Template
-```cpp
-class Amendment_test : public beast::unit_test::suite
-{
-public:
-    // Core tests
-    void testEnable(FeatureBitset features);      // Enable/disable states
-    void testPreflight(FeatureBitset features);   // Validation
-    void testPreclaim(FeatureBitset features);    // Claim phase
-
-    // Feature-specific tests
-    void test{SpecificScenario1}(FeatureBitset features);
-    void test{SpecificScenario2}(FeatureBitset features);
-
-    // Master orchestrator
-    void testWithFeats(FeatureBitset features)
-    {
-        testEnable(features);
-        testPreflight(features);
-        testPreclaim(features);
-        test{SpecificScenario1}(features);
-        test{SpecificScenario2}(features);
-    }
-
-    void run() override
-    {
-        using namespace test::jtx;
-        auto const all = supported_amendments();
-        testWithFeats(all);
-    }
-};
-
-BEAST_DEFINE_TESTSUITE(Amendment, app, ripple);
-```
-
-### 5. Documentation Files
-Create these files:
-- **Specification**: `XLS_{FEATURE_NAME}.md` - Technical specification
-- **Test Plan**: `{FEATURE}_COMPREHENSIVE_TEST_PLAN.md` - Test strategy
-- **Test Summary**: `{FEATURE}_TEST_IMPLEMENTATION_SUMMARY.md` - Test results
-- **Review Findings**: `{FEATURE}_REVIEW_FINDINGS.md` (if applicable)
-
-### 6. Amendment Transition Testing
-Test the moment an amendment activates:
-
-```cpp
-void testAmendmentTransition(FeatureBitset features)
-{
-    testcase("amendment transition");
-
-    // Start with amendment disabled
-    auto const amendNoFeature = features - feature{Name};
-    Env env{*this, amendNoFeature};
-
-    // Perform operations in disabled state
-    env(operation1, ter(temDISABLED));
-
-    // Enable amendment mid-test (if testing mechanism supports it)
-    // Verify state transitions correctly
-
-    // Perform operations in enabled state
-    env(operation2, ter(tesSUCCESS));
-}
-```
-
-### 7. Cache Behavior
-If amendment affects caching (like fixBatchInnerSigs):
-- [ ] Test cache behavior without fix
-- [ ] Test cache behavior with fix
-- [ ] Document cache invalidation requirements
-
-### 8. Multi-Amendment Combinations
-Test interactions with other amendments:
-
-```cpp
-void testMultipleAmendments(FeatureBitset features)
-{
-    // Test all combinations
-    for (bool withFeature1 : {false, true})
-    for (bool withFeature2 : {false, true})
-    {
-        auto amend = features;
-        if (!withFeature1) amend -= feature1;
-        if (!withFeature2) amend -= feature2;
-
-        Env env{*this, amend};
-        // Test interaction behavior
-    }
-}
-```
-
-### 9. Performance Considerations
-- [ ] Minimize runtime checks (cache `rules().enabled()` result if used multiple times)
-- [ ] Avoid nested feature checks where possible
-- [ ] Document performance impact
-
-### 10. Code Review Checklist
-- [ ] Both enabled/disabled paths are tested
-- [ ] Backward compatibility is preserved (for fixes)
-- [ ] Error codes are appropriate
-- [ ] Documentation is complete
-- [ ] Security implications are considered
-- [ ] Cache behavior is correct
-- [ ] Edge cases are covered
-
----
-
-## Common Patterns Reference
-
-### Pattern: New Transaction Type
-```cpp
-// In transactor code:
-TER doApply() override
-{
-    if (!ctx_.view().rules().enabled(feature{Name}))
-        return temDISABLED;
-
-    // New transaction logic here
-    return tesSUCCESS;
-}
-```
-
-### Pattern: New Ledger Entry Type
-```cpp
-// In ledger entry creation:
-if (!view.rules().enabled(feature{Name}))
-    return temDISABLED;
-
-auto const sle = std::make_shared<SLE>(ltNEW_TYPE, keylet);
-view.insert(sle);
-```
-
-### Pattern: Behavioral Fix
-```cpp
-// At decision point:
-bool const useFix = view.rules().enabled(fix{Name});
-
-if (useFix)
-{
-    // Corrected behavior
-    return performCorrectValidation();
-}
-else
-{
-    // Legacy behavior (preserved for compatibility)
-    return performLegacyValidation();
-}
-```
-
-### Pattern: View Selection
-```cpp
-// Select which view to use based on amendment:
-auto& applyView = sb.rules().enabled(feature{Name}) ? newView : legacyView;
-```
-
----
-
-## Example Workflows
-
-### Workflow 1: Creating a New Feature Amendment
-
-1. User requests: "Add a new ClaimReward transaction type"
-2. Skill asks: "What should the amendment be called? (e.g., BalanceRewards - without 'feature' prefix)"
-3. Add to features.macro:
-```
-XRPL_FEATURE(BalanceRewards, Supported::no, VoteBehavior::DefaultNo)
-```
-4. Implement transaction with `temDISABLED` gate using `featureBalanceRewards`
-5. Create test suite with testEnable, testPreflight, testPreclaim
-6. Run tests with amendment enabled and disabled
-7. When ready, update to `Supported::yes` in features.macro
-8. Create specification document
-9. Review checklist
-
-### Workflow 2: Creating a Fix Amendment
-
-1. User requests: "Fix the signature validation bug in batch transactions"
-2. Skill asks: "What should the fix be called? (e.g., BatchInnerSigs - without 'fix' prefix)"
-3. Add to features.macro:
-```
-XRPL_FIX(BatchInnerSigs, Supported::no, VoteBehavior::DefaultNo)
-```
-4. Implement fix with if/else using `fixBatchInnerSigs` to preserve old behavior
-5. Create test demonstrating vulnerability without fix
-6. Create test showing fix works when enabled
-7. When ready, update to `Supported::yes` in features.macro
-8. Document both code paths
-9. Review checklist
-
----
-
-## Quick Reference: File Locations
-
-- **Amendment definitions (ONLY place to add)**: `include/xrpl/protocol/detail/features.macro`
-- **Feature.h (auto-generated, DO NOT EDIT)**: `include/xrpl/protocol/Feature.h`
-- **Feature.cpp (auto-generated, DO NOT EDIT)**: `src/libxrpl/protocol/Feature.cpp`
-- **Test files**: `src/test/app/` or `src/test/protocol/`
-- **Specifications**: Project root (e.g., `XLS_SMART_CONTRACTS.md`)
-- **Test plans**: Project root (e.g., `BATCH_COMPREHENSIVE_TEST_PLAN.md`)
-
-## How the Macro System Works
-
-The amendment system uses C preprocessor macros:
-
-1. **features.macro** - Single source of truth (ONLY file you edit):
-```
-XRPL_FEATURE(Batch, Supported::yes, VoteBehavior::DefaultNo)
-XRPL_FIX(TokenEscrowV1, Supported::yes, VoteBehavior::DefaultNo)
-```
-
-2. **Feature.h** - Auto-generated declarations from macro:
-```cpp
-extern uint256 const featureBatch;
-extern uint256 const fixTokenEscrowV1;
-```
-
-3. **Feature.cpp** - Auto-generated registrations from macro:
-```cpp
-uint256 const featureBatch = registerFeature("Batch", ...);
-uint256 const fixTokenEscrowV1 = registerFeature("fixTokenEscrowV1", ...);
-```
-
-**DO NOT** modify Feature.h or Feature.cpp directly - they process features.macro automatically.
-
----
-
-## When to Use This Skill
-
-Invoke this skill when:
-- Creating a new XRPL amendment
-- Adding a new transaction type or ledger entry
-- Fixing existing XRPL functionality
-- Need guidance on amendment best practices
-- Setting up amendment tests
-- Reviewing amendment implementation
-
-The skill will guide you through the appropriate workflow based on amendment type.

.gitignore

@@ -69,3 +69,5 @@ DerivedData
 
 # AI tools.
 /.augment
+/.claude
+/CLAUDE.md

API-CHANGELOG.md

@@ -71,6 +71,12 @@ This release contains bug fixes only and no API changes.
 
 This release contains bug fixes only and no API changes.
 
+## Unreleased Changes
+
+### Additions and bugfixes
+
+- `submit`: Augmented response fields (`accepted`, `applied`, `broadcast`, `queued`, `kept`, `account_sequence_next`, `account_sequence_available`, `open_ledger_cost`, `validated_ledger_index`) are now included in sign-and-submit mode. Previously, these fields were only returned when submitting a binary transaction blob. ([#6304](https://github.com/XRPLF/rippled/pull/6304))
+
 ## XRP Ledger server version 2.5.0
 
 [Version 2.5.0](https://github.com/XRPLF/rippled/releases/tag/2.5.0) was released on Jun 24, 2025.

src/test/rpc/Submit_test.cpp

@@ -0,0 +1,96 @@
+#include <test/jtx.h>
+
+#include <xrpld/core/ConfigSections.h>
+
+#include <xrpl/protocol/jss.h>
+
+namespace xrpl {
+
+class Submit_test : public beast::unit_test::suite
+{
+public:
+    void
+    testAugmentedFields()
+    {
+        testcase("Augmented fields in sign-and-submit mode");
+
+        using namespace test::jtx;
+
+        // Enable signing support in config
+        Env env{*this, envconfig([](std::unique_ptr<Config> cfg) {
+                    cfg->loadFromString("[" SECTION_SIGNING_SUPPORT "]\ntrue");
+                    return cfg;
+                })};
+
+        Account const alice{"alice"};
+        Account const bob{"bob"};
+
+        env.fund(XRP(10000), alice, bob);
+        env.close();
+
+        // Test 1: Sign-and-submit mode should return augmented fields
+        {
+            Json::Value jv;
+            jv[jss::tx_json][jss::TransactionType] = jss::Payment;
+            jv[jss::tx_json][jss::Account] = alice.human();
+            jv[jss::tx_json][jss::Destination] = bob.human();
+            jv[jss::tx_json][jss::Amount] = XRP(100).value().getJson(JsonOptions::none);
+            jv[jss::secret] = alice.name();
+
+            auto const result = env.rpc("json", "submit", to_string(jv))[jss::result];
+
+            // These are the augmented fields that should be present
+            BEAST_EXPECT(result.isMember(jss::engine_result));
+            BEAST_EXPECT(result.isMember(jss::engine_result_code));
+            BEAST_EXPECT(result.isMember(jss::engine_result_message));
+
+            // New augmented fields from issue #3125
+            BEAST_EXPECT(result.isMember(jss::accepted));
+            BEAST_EXPECT(result.isMember(jss::applied));
+            BEAST_EXPECT(result.isMember(jss::broadcast));
+            BEAST_EXPECT(result.isMember(jss::queued));
+            BEAST_EXPECT(result.isMember(jss::kept));
+
+            // Current ledger state fields
+            BEAST_EXPECT(result.isMember(jss::account_sequence_next));
+            BEAST_EXPECT(result.isMember(jss::account_sequence_available));
+            BEAST_EXPECT(result.isMember(jss::open_ledger_cost));
+            BEAST_EXPECT(result.isMember(jss::validated_ledger_index));
+
+            // Verify basic transaction fields
+            BEAST_EXPECT(result.isMember(jss::tx_blob));
+            BEAST_EXPECT(result.isMember(jss::tx_json));
+        }
+
+        // Test 2: Binary blob mode should also return augmented fields (regression test)
+        {
+            auto jt = env.jt(pay(alice, bob, XRP(100)));
+            Serializer s;
+            jt.stx->add(s);
+
+            auto const result = env.rpc("submit", strHex(s.slice()))[jss::result];
+
+            // Verify augmented fields are present in binary mode too
+            BEAST_EXPECT(result.isMember(jss::engine_result));
+            BEAST_EXPECT(result.isMember(jss::accepted));
+            BEAST_EXPECT(result.isMember(jss::applied));
+            BEAST_EXPECT(result.isMember(jss::broadcast));
+            BEAST_EXPECT(result.isMember(jss::queued));
+            BEAST_EXPECT(result.isMember(jss::kept));
+            BEAST_EXPECT(result.isMember(jss::account_sequence_next));
+            BEAST_EXPECT(result.isMember(jss::account_sequence_available));
+            BEAST_EXPECT(result.isMember(jss::open_ledger_cost));
+            BEAST_EXPECT(result.isMember(jss::validated_ledger_index));
+        }
+    }
+
+    void
+    run() override
+    {
+        testAugmentedFields();
+    }
+};
+
+BEAST_DEFINE_TESTSUITE(Submit, rpc, xrpl);
+
+}  // namespace xrpl

src/xrpld/rpc/detail/TransactionSign.cpp

@@ -699,6 +699,8 @@ transactionFormatResultImpl(Transaction::pointer tpTrans, unsigned apiVersion)
             jvResult[jss::engine_result] = sToken;
             jvResult[jss::engine_result_code] = tpTrans->getResult();
             jvResult[jss::engine_result_message] = sHuman;
+
+            RPC::populateAugmentedSubmitFields(jvResult, tpTrans);
         }
     }
     catch (std::exception&)
@@ -712,6 +714,28 @@ transactionFormatResultImpl(Transaction::pointer tpTrans, unsigned apiVersion)
 
 //------------------------------------------------------------------------------
 
+void
+populateAugmentedSubmitFields(Json::Value& jvResult, std::shared_ptr<Transaction> const& transaction)
+{
+    auto const submitResult = transaction->getSubmitResult();
+
+    jvResult[jss::accepted] = submitResult.any();
+    jvResult[jss::applied] = submitResult.applied;
+    jvResult[jss::broadcast] = submitResult.broadcast;
+    jvResult[jss::queued] = submitResult.queued;
+    jvResult[jss::kept] = submitResult.kept;
+
+    if (auto currentLedgerState = transaction->getCurrentLedgerState())
+    {
+        jvResult[jss::account_sequence_next] = safe_cast<Json::Value::UInt>(currentLedgerState->accountSeqNext);
+        jvResult[jss::account_sequence_available] = safe_cast<Json::Value::UInt>(currentLedgerState->accountSeqAvail);
+        jvResult[jss::open_ledger_cost] = to_string(currentLedgerState->minFeeRequired);
+        jvResult[jss::validated_ledger_index] = safe_cast<Json::Value::UInt>(currentLedgerState->validatedLedger);
+    }
+}
+
+//------------------------------------------------------------------------------
+
 [[nodiscard]] static XRPAmount
 getTxFee(Application const& app, Config const& config, Json::Value tx)
 {

src/xrpld/rpc/detail/TransactionSign.h

@@ -15,6 +15,18 @@ class TxQ;
 
 namespace RPC {
 
+/** Populate augmented submit fields into a JSON result.
+    This helper populates the submit result flags (accepted, applied,
+    broadcast, queued, kept) and current ledger state fields
+    (account_sequence_next, account_sequence_available, open_ledger_cost,
+    validated_ledger_index) from a Transaction pointer.
+
+    @param jvResult The JSON result to populate
+    @param transaction The transaction containing the submit result and state
+*/
+void
+populateAugmentedSubmitFields(Json::Value& jvResult, std::shared_ptr<Transaction> const& transaction);
+
 Json::Value
 getCurrentNetworkFee(
     Role const role,

src/xrpld/rpc/handlers/Submit.cpp

@@ -127,23 +127,7 @@ doSubmit(RPC::JsonContext& context)
             jvResult[jss::engine_result_code] = transaction->getResult();
             jvResult[jss::engine_result_message] = sHuman;
 
-            auto const submitResult = transaction->getSubmitResult();
-
-            jvResult[jss::accepted] = submitResult.any();
-            jvResult[jss::applied] = submitResult.applied;
-            jvResult[jss::broadcast] = submitResult.broadcast;
-            jvResult[jss::queued] = submitResult.queued;
-            jvResult[jss::kept] = submitResult.kept;
-
-            if (auto currentLedgerState = transaction->getCurrentLedgerState())
-            {
-                jvResult[jss::account_sequence_next] = safe_cast<Json::Value::UInt>(currentLedgerState->accountSeqNext);
-                jvResult[jss::account_sequence_available] =
-                    safe_cast<Json::Value::UInt>(currentLedgerState->accountSeqAvail);
-                jvResult[jss::open_ledger_cost] = to_string(currentLedgerState->minFeeRequired);
-                jvResult[jss::validated_ledger_index] =
-                    safe_cast<Json::Value::UInt>(currentLedgerState->validatedLedger);
-            }
+            RPC::populateAugmentedSubmitFields(jvResult, transaction);
         }
 
         return jvResult;