Version 1.40 is a short-term support (STS) SaaS release that introduces the following changes:
- Phase 2 of the ledger accounting refactor: A rewrite of the Unified Indexer Service (UIS) changes transaction response fields for chains served by the UIS. Phase 2 also changes fee estimation for XRPL and Solana.
- Destination tag and memo support for endpoints and transfers on XRPL, Stellar, and Hedera, with duplicate endpoint prevention.
Ripple Custody version 1.34 introduced Ledger accounting refactor phase 1 with core balance tracking and transaction processing in a new event-driven accounting service. The new service introduced behavioral changes for API integrations, with a one-time migration for on-premises deployments to activate the new accounting flow.
Ripple Custody version 1.40 continues migrating transaction processing to the refactored blockchain integration. This phase changes selected transaction response fields and adjusts fee estimation on some chains.
If your integration reads rawTransaction or senderLedgerSpecificMetadata from transaction responses, update it before adopting version 1.40. These fields are no longer populated for chains served by the Unified Indexer Service (UIS).
Version 1.40 rewrites the Unified Indexer Service (UIS). For chains served by the UIS, the following fields in APIs that return a transaction (the ledgerTransactionData object) are no longer populated. For the list of chains that use the UIS, see Supported chains and indexer types.
rawTransaction— previously the raw, ledger-native encoding of the broadcast transaction. To inspect a confirmed transaction on chain, useledgerTransactionData.ledgerTransactionIdwith a blockchain explorer.senderLedgerSpecificMetadata— previously persisted during transaction preparation and used when broadcasting the transaction. The refactor no longer requires it.
On-premises customers should be aware that the rewrite of the UIS will be available for on-premises deployment starting in the next LTS release. At that time, those blockchains configured with type: "uis" will need to be updated to use the new UIS.
Version 1.40 changes how Ripple Custody estimates XRPL transaction fees:
- Transactions are no longer padded to a default of 200 drops. As a result, standard payments submitted during network congestion are more likely to remain pending until the network clears.
- The validation previously applied to the specified-fee strategy no longer applies below 50 XRP. No transaction can consume more than 50 XRP in fees.
Ripple Custody now estimates Solana transaction fees using a combination of derivation and on-chain simulation performed by the indexer, rather than deriving fee costs in the notary alone. This change is not expected to affect transaction behavior in any significant way.
Ripple Custody version 1.40 introduces destination tag and memo support for endpoints and transfers on XRPL, Stellar, and Hedera, with duplicate endpoint prevention.
Endpoints on XRPL, Stellar, and Hedera can now store a destination tag or memo in their parameters field:
- XRPL:
destinationTag, an integer from 0 to 4294967295. - Stellar:
memo, a typed object (Text,Id,Hash, orReturn). - Hedera:
memo, a UTF-8 string of 1 to 100 bytes.
Ripple Custody validates the value against the target ledger's format when you create or update an endpoint. When a transfer uses a tagged endpoint as its destination, Ripple Custody reads the tag from the endpoint, and you can't override the tag on the transfer. For more information, see Manage endpoints.
Transfer order outputs now accept an optional, typed tag object when the destination is a plain address or an endpoint without a tag, on ledgers that support tags. The Transfers page shows an editable tag field in that case, and a read-only tag when the destination endpoint carries one. You no longer need the Payments (transaction order) flow to set an XRPL destination tag. For more information, see Send assets with the API.
Endpoints are now unique per domain, address, ledger, and destination tag. Ripple Custody enforces uniqueness when you create or update an endpoint. An empty tag counts as a value, so only one tag-less endpoint can exist per domain, address, and ledger. Automations that re-register an existing endpoint, for example as an idempotent setup step, now fail where they previously created a duplicate. Check for an existing endpoint first, or handle the rejection. A dry run of the intent reports the conflict before you submit.
Ripple Custody doesn't remove duplicate endpoints created before this release. It attributes transaction history to an endpoint by its ID using the full uniqueness key, so the history for an endpoint no longer switches between endpoints that share an address.
Ripple progressively deploys Version 1.40 across SaaS environments starting August 17, 2026.
Ripple takes great care in testing its applications and ensuring that there are no regressions or breaking changes. Should you experience unexpected behavior, reach out to the Support team by creating a ticket on our Support Portal or contact your Customer Partner Engineer (CPE).