XRPLF Merges PermissionedDEX Cleanup Fix Behind fixCleanup3_4_0

Direct answer: the fix moves expired-credential cleanup into the transaction apply path

XRPLF merged PR #6827 into the `rippled` `develop` branch on September 2, 2026. The `fixCleanup3_4_0`-gated change lets PermissionedDEX `OfferCreate` and `Payment` paths remove expired credential ledger entries and return `tecEXPIRED` in the tested cases. The patch is not in stable 3.3.0 and is not active on Mainnet. [1][2][8][9]

[Confirmed fact] The merge changes `OfferCreate.cpp`, `Payment.cpp`, and `PermissionedDEX_test.cpp`. GitHub records 317 additions and 10 deletions in the commit, while the pull request records three changed files and a merge into `develop`. Those numbers describe reviewed source and regression coverage, not a count of affected Mainnet accounts or a deployed binary. [1][2]

The pull request describes a specific architectural mismatch. PermissionedDEX used `accountInDomain()` during `preclaim()`, where the code can read a credential and decide whether it is expired but cannot mutate the ledger. The old path could therefore reject an account without deleting the expired `Credential` ledger entry. The PR describes the resulting entries as able to persist, hold owner reserve, and add ledger data. [1][5][12]

This is a transaction-processing correction, not a new access right. The patch does not create a new PermissionedDEX amendment, let an arbitrary account trade in a domain, change the open DEX, or establish a loss event. It changes the cleanup behavior attached to a future amendment gate after a domain-scoped `OfferCreate` or `Payment` has already been submitted. [1][2][3]

Section sources[1][2][8][9][3]

Why expired credentials matter to a PermissionedDEX order book

A PermissionedDEX is a domain-scoped set of order books. The XRP Ledger documentation describes three roles: traders, a domain owner who controls the accepted credential list, and credential issuers who approve accounts. A permissioned offer carries a `DomainID`, and the account placing it must hold a valid credential accepted by that domain. [3][4]

The Credential ledger entry is more than a label read by an application. Its `Expiration` field records the time after which the credential is expired, and its accepted state determines whether the subject has made it valid. The protocol reference says an accepted Credential counts as one owner-reserve item for the subject account; before acceptance, it counts against the issuer. [4][5]

That reserve connection gives the cleanup issue a concrete operational consequence. The current XRP Ledger reserve documentation lists a 1 XRP base reserve and a 0.2 XRP owner-reserve increment per item on Mainnet, although those settings can change through fee voting. Removing an object removes its owner-reserve burden. The PR does not publish a count of stale entries or a measured XRP amount locked by this bug. [1][12]

Expired credentials also interact with offers without being identical to offers. The official PermissionedDEX documentation says an offer becomes invalid when its account credential expires or is deleted. Invalid offers are treated like unfunded offers and removed when a transaction modifies the relevant order book, but they can remain in ledger data until that happens. If a credential is renewed first, an offer that was not removed can become valid again. [3]

Section sources[3][4][5][12][1]

What PR #6827 changes in OfferCreate and Payment

[Confirmed fact] The new path keeps the read-only membership check in `preclaim()`, but uses `credentials::validDomain()` when `fixCleanup3_4_0` is enabled. If the only problem is an expired credential, preclaim allows the transaction to reach `doApply()` rather than stopping the cleanup opportunity at the read-only boundary. If the domain or credential relationship is otherwise invalid, the code preserves the existing `tecNO_PERMISSION` behavior. [1][2]

In `OfferCreate::doApply()`, the patch calls `verifyValidDomain()` for the account placing the domain offer. That helper works on the mutable apply view and can call the expired-credential removal path. The code performs this check before it creates the offer sandboxes, because returning a `tec` result through the cancellation branch could otherwise discard a deletion made inside a temporary view. [1][2]

In `Payment::doApply()`, the same pattern covers the payment account and destination when a `DomainID` is present. The domain owner remains a special case because the owner is always treated as a member of its own domain. The payment still has to satisfy the domain-scoped transaction rules; the cleanup call does not turn a non-member into an authorized trader. [1][2][3][6]

The visible result-code change is deliberate. The new regression cases expect `tecEXPIRED` when an expired credential is found under the gate, while the pre-gate comparison expects `tecNO_PERMISSION`. In other words, the transaction remains unsuccessful for the expired account, but the failed attempt now becomes an opportunity to delete the stale Credential entry. [1][2]

Section sources[1][2][3][6]

The important compromise: this is not a blanket order-book garbage collector

XLS-0081 contains an explicit reason for the older behavior. Its Payment section says a payment would not delete expired credentials while traversing permissioned offers. The specification notes that a domain can have up to 10 accepted credentials, so a payment touching an order book could potentially delete up to 10 Credential objects for each offer. It warns that the resulting metadata could affect ledger throughput. [6]

PR #6827 takes a narrower route than scanning every offer encountered by a payment. Its `Payment::doApply()` cleanup is attached to the sender and destination checks at the start of the transaction path. Its `OfferCreate` cleanup is attached to the account submitting the offer. The patch therefore addresses the account-level stale entry without silently turning every payment into a deep credential sweep. [1][2]

The added tests make that boundary visible. In the sender-expired, destination-expired, and both-expired cases, the expired credential under test is removed when the gate is enabled, while a separate `bob` credential and its existing offer are still expected to remain. That is evidence about the tested state transition, not a guarantee that every possible order-book path behaves identically. [2]

This distinction matters for operators and readers. Credential cleanup and offer cleanup are related but separate operations. The documentation still says an invalid offer may wait for an order-book-modifying transaction, and the new patch does not publish a sweeping deletion algorithm for all such offers. A dashboard that collapses both objects into one stale-record count would overstate what the merge fixes. [3][5][6]

Section sources[6][1][2][3][5]

What the regression tests establish, and what they do not

The new test coverage is broader than a single expired-offer assertion. It checks a nonexistent domain rejection, an expired credential during `OfferCreate`, an expired sender credential during `Payment`, an expired destination credential, and a payment where both relevant credentials have expired. It also compares the feature-enabled and feature-disabled result codes and checks whether the credential ledger entry still exists after the transaction. [1][2]

That test design establishes the intended cleanup contract: the account is not allowed to continue trading or paying through the expired domain credential, but the failed transaction can remove the expired Credential entry when `fixCleanup3_4_0` is active. The test assertions are strong evidence of intended behavior in the XRPLF unit-test environment. They are not an on-ledger report from a production PermissionedDEX. [1][2]

Independent context supports the underlying lifecycle model without validating this patch. XRPL Commons reported in January 2026 that it manually tested Credential creation, acceptance, verification, deletion, domain management, and permissioned DEX operations on Devnet. Its report says expired credentials correctly prevented access and separately warns that domain operators need clear credential-lifecycle guidance. It does not claim to have measured PR #6827 or a Mainnet reserve effect. [7]

[Unresolved uncertainty] The public PR and test diff do not provide a benchmark for added metadata size, transaction throughput, cleanup frequency, or the number of live accounts that could exercise the path. They also do not establish an exploit, malicious issuer, drained order book, financial loss, or customer outage. The defensible claim is a correctness and housekeeping fix with a stated performance tradeoff, not a disclosed incident. [1][2][6][7]

Section sources[1][2][7][6]

Mainnet status: the prerequisites are enabled, but the cleanup gate is not

A live public snapshot is useful here because it separates existing PermissionedDEX support from the new fix. Queried on September 3, 2026 at 11:04:55 UTC, Ripple’s `s1.ripple.com:51234` feature response reported `Credentials`, `PermissionedDEX`, and `PermissionedDomains` as enabled and supported. The same response did not contain a `fixCleanup3_4_0` entry. [9][10]

The paired `server_info` snapshot identified that public service as `rippled_version` 3.3.0 and `libxrpl_version` 3.3.0, with Clio 2.8.0 and validated ledger sequence 106732408 at the time checked. Those are attributed, time-sensitive values from one public endpoint, not a census of all validators or development nodes. [9]

The stable-release record points the same way. XRPLF’s latest listed stable `rippled` release is 3.3.0, published August 6, 2026. PR #6827 was merged into `develop` on September 2, after that release, and the commit itself is gated on `fixCleanup3_4_0`. A develop merge is evidence of source integration, not evidence that the stable binary or network has adopted the behavior. [1][2][8]

The official amendment process makes the remaining steps concrete. Transaction-processing bug fixes require amendments. The code must be included in a release, validators must support it, and the amendment must maintain more than 80% support for two weeks before it passes. The change then applies after the relevant flag-ledger sequence. None of those release, vote, or activation records is present for `fixCleanup3_4_0` in the evidence reviewed here. [10][11]

Section sources[9][10][8][1][2][11]

Implications for developers, domain operators, liquidity providers, and XRP readers

For client and application developers, the relevant compatibility matrix now has two dimensions: the transaction type and the server’s feature state. A domain-scoped `OfferCreate` or `Payment` should be tested against an expired credential on a pre-gate 3.3.0 server and on a future build that recognizes `fixCleanup3_4_0`. Clients should not hard-code a GitHub branch name as a capability check; they should read the connected server’s version and feature response. [1][9][10]

For domain owners and credential issuers, the practical lesson is lifecycle accounting. Expiration is a protocol field, not the same thing as deletion. Operators should record when a credential expires, whether it was accepted, which account bears the owner-reserve item, whether the account has a domain offer, and whether a later transaction removed the Credential entry. The future fix may make some failed account actions perform cleanup, but it does not replace deliberate renewal and deletion processes. [3][4][5][12]

For PermissionedDEX liquidity providers, an expired credential can invalidate an offer while leaving the offer object available for later cleanup or possible revalidation if the credential is renewed. That means order-book inspection should distinguish an invalid offer, its owner’s Credential entry, and any DomainID-specific directory entry. A successful cleanup test does not prove that an offer was deleted, that liquidity moved, or that a spread changed. [2][3][6]

For node operators and data providers, the evidence chain should be stored as separate fields: merge commit `7d72758`, stable package version, amendment name, server support, validator support, activation status, and observed transaction metadata. This is especially important because the live node already supports PermissionedDEX while the new cleanup gate is absent. Mixing those states would make a future release dashboard report the wrong behavior to integrators. [2][8][9][10]

For ordinary XRP holders and market readers, this record contains no new XRP supply event, price observation, demand measurement, institutional deployment, or payment-volume result. XRP can appear as an asset in a permissioned order book, but PR #6827 concerns expired credentials and transaction cleanup. No XRP price snapshot is used here because a market number would not improve the explanation of the protocol change. [1][3][9]

Section sources[1][9][10][3][4][5][12]

Evidence boundary: confirmed fact, bounded inference, and unresolved uncertainty

[Confirmed facts] XRPLF merged PR #6827 into `rippled` `develop` on September 2, 2026. The three-file change adds an amendment-gated `verifyValidDomain()` path to PermissionedDEX `OfferCreate` and `Payment` processing and adds regression coverage for expired credentials. The tests expect the stale Credential entry to be removed under the gate and preserved in the comparison path. [1][2]

[Bounded inference] If an equivalent implementation reaches a stable release and `fixCleanup3_4_0` activates, the tested account-level paths should remove expired Credential entries instead of leaving them behind after returning an expiration result. That could reduce stale reserve pressure for the affected accounts. This conclusion follows from the source and tests; it is not a measured Mainnet outcome and may not cover every combination of domain changes, payment paths, sponsorship, or concurrent ledger state. [1][2][3][5]

[Unresolved uncertainty] The record does not identify the future release version, validator support schedule, activation ledger, number of expired credentials, reserve value recovered, throughput impact, affected order books, or user losses. It also does not show that a PermissionedDEX account has exercised this exact path on Mainnet. Those questions require later release notes, feature responses, amendment votes, validated transaction metadata, and independent operational evidence. [1][6][9][10][11]

The useful conclusion is narrow. PR #6827 closes a cleanup gap at the account-level PermissionedDEX transaction boundary while preserving the distinction between credential entries and offers, and while leaving the original metadata-throughput concern visible. It is meaningful for XRPL developers and permissioned-market operators to test. It is not a live Mainnet upgrade, a security incident, or an XRP investment catalyst. [1][2][3][6]

Section sources[1][2][3][5][6][9][10][11]