# Ripple Custody 1.40 (August 17, 2026) 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. - Delegated nonce authority for Solana durable nonce accounts, in version 1.40.3: A hot vault account can create a nonce account owned by a cold vault account, which enables cold vault signing on Solana through the API. ## Ledger accounting refactor, phase 2 Ripple Custody version 1.34 introduced [Ledger accounting refactor phase 1](/products/custody/v1.40/support/change-history/v134#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. ### Updated UIS - Transaction response field changes Integration change 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](/products/custody/v1.40/overview/architecture/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](/products/custody/v1.40/overview/architecture/unified-indexer-service#supported-chains-and-indexer-types). - `rawTransaction` — previously the raw, ledger-native encoding of the broadcast transaction. To inspect a confirmed transaction on chain, use `ledgerTransactionData.ledgerTransactionId` with a blockchain explorer. - `senderLedgerSpecificMetadata` — previously persisted during transaction preparation and used when broadcasting the transaction. The refactor no longer requires it. Pending change for on-premises deployments 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. ### XRPL fee estimation changes 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. ### Solana fee estimation changes 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. ## Destination tag and memo support Ripple Custody version 1.40 introduces destination tag and memo support for endpoints and transfers on XRPL, Stellar, and Hedera, with duplicate endpoint prevention. ### Destination tags and memos on endpoints 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`, or `Return`). - 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](/products/custody/v1.40/accounts-and-assets/endpoints/manage-endpoints#destination-tag-and-memo-payloads). ### Destination tags on transfers 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](/products/custody/v1.40/transactions/send-and-receive/send-assets-api#destination-tags-on-transfers). ### Duplicate endpoint prevention Behavior change 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. ## Solana cold vault enablement: delegated nonce authority Ripple Custody version 1.40.3 introduces an optional nonce authority on Solana durable nonce accounts. A hot vault account creates and funds a durable nonce account and names a different account, typically an account in a cold vault, as the nonce authority. The cold vault account owns the nonce and signs every later transaction that uses it. After this one-time setup, the cold vault signs Solana transactions without the hot vault. Previously, a nonce account created through Ripple Custody always belonged to the account that paid for it. A cold vault account can't sign the creation transaction within Solana's recent-blockhash window, so a cold vault could only use a nonce account created with external Solana tooling. Version 1.40.3 removes that dependency. Requires the Unified Indexer Service v2 Delegated nonce authority requires the Unified Indexer Service (UIS) v2, introduced with [ledger accounting refactor phase 2](#ledger-accounting-refactor-phase-2). SaaS deployments run UIS v2 from version 1.40. On-premises deployments receive it in the next LTS release. API only Version 1.40.3 delivers delegated nonce authority through the API. Fee change for delegated authorities When the nonce authority is a different account from the fee payer, the transaction carries two signatures and its base fee doubles from 5,000 to 10,000 lamports. Set `maximumFee` accordingly. A dry run reports a maximum fee that is too low before you submit. The new fields are optional. Integrations that don't set them behave as before. For the setup procedure, see [Set up Solana durable nonce accounts with the API](/products/custody/v1.40/accounts-and-assets/accounts/ledger-specific-settings/solana-api). ## Distribution and deployment Ripple progressively deploys Version 1.40 across SaaS environments starting August 17, 2026. ## Activation and support 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](https://metaco.atlassian.net/servicedesk/customer/portal/1) or contact your Customer Partner Engineer (CPE).