# Ripple Custody 1.43 (October 5, 2026) Version 1.43 is a long-term support (LTS) release for both SaaS and on-premises deployments. New ledgers: - [Canton Network support](#canton-network-support) - [Circle Arc ledger support](#circle-arc-ledger-support) - [Sui ledger support](#sui-ledger-support) New features: - [EIP-7702 delegation for Ethereum accounts](#eip-7702-delegation-for-ethereum-accounts) - [Multi-purpose token (MPT) operations in the UI](#multi-purpose-token-mpt-operations-in-the-ui) - [Notary hot failover and anti-rewind modes](#notary-hot-failover-and-anti-rewind-modes) - [Address-level manifest signing for Bitcoin-family ledgers](#address-level-manifest-signing-for-bitcoin-family-ledgers) Check your integration before you upgrade from 1.34 Version 1.43 includes behavior and API changes introduced in the STS releases since version 1.34. On-premises customers upgrading from version 1.34 should review [Deployment-affecting changes](#deployment-affecting-changes) before they upgrade. ## Changes since version 1.34 Version 1.43 includes everything that the short-term support (STS) SaaS releases 1.35 to 1.42 delivered. This section summarizes the main changes for customers who upgrade from version 1.34, lists every change by version, and lists the changes that can affect your integration or deployment. ### Key new features #### Omnibus Omnibus lets you hold pooled funds on-chain in an omnibus wallet, and track each tenant's position off-chain with virtual accounts. Deposit wallets identify incoming funds, automated sweeps move them into the omnibus wallet, and internal transfers between virtual accounts settle off-chain without network fees. System-signed intents automate deposit wallet creation and sweeps, so these operations don't need a user signing key. Omnibus launched as a beta in version 1.36 and became generally available in version 1.38, which changed the Omnibus API and added omnibus accounts to the console. Omnibus requires the [ledger accounting refactor](#ledger-accounting-refactor). For more information, see [Omnibus general availability](/pt-br/products/custody/support/change-history/v138#omnibus-general-availability) and the [Omnibus overview](/pt-br/products/custody/accounts-and-assets/omnibus/overview). #### Gas Station Gas Station pays transaction fees for sponsored accounts by funding them with the native token just in time. It became generally available in version 1.38, with simpler onboarding: instead of a bot user and its signing key, you register the Gas Station service caller in your identity provider and admit its funding intents with a system-signed intent policy. You can also create gas stations in the console. For more information, see [Gas Station general availability](/pt-br/products/custody/support/change-history/v138#gas-station-general-availability) and [Gas Station](/pt-br/products/custody/accounts-and-assets/gas-station/overview). #### System-signed intents System-signed intents, introduced in version 1.36, let an authenticated service submit selected intent types without a client-side signature. Ripple Custody signs the proposal internally, and your policies admit it only when a matching policy sets `intentOrigin` to `SystemSigned`. Omnibus and Gas Station use system-signed intents to automate deposit wallet creation, sweeps, and fee funding, so these services don't need a user signing key. Processing stays off until you register the system signing public key, enable the feature, and create the matching policies. For more information, see [System-signed intents](/pt-br/products/custody/support/change-history/v136#system-signed-intents) and [System-signed intent configuration](/pt-br/products/custody/deployment/reference/system-signed-intents). #### Portfolio Data Export Service The Portfolio Data Export Service, introduced in version 1.37, generates reconciliation-grade reports as CSV or JSON files through the API: - **Position Reports** show each account's balance for each asset at a point in time. - **Movement Reports** list every transfer in a date range, with amounts, fees, on-chain details, and counterparties. Each export includes control totals, so downstream systems can confirm that a file is complete. Version 1.42 adds an Omnibus Position Report for omnibus domains. On-premises, the service needs the `export` and `gas-station` components, and Position Reports need the accounting service. For more information, see [Portfolio Data Export Service](/pt-br/products/custody/support/change-history/v137#portfolio-data-export-service) and the [Data export overview](/pt-br/products/custody/data-export/overview). #### Ledger accounting refactor The ledger accounting refactor moves balance tracking and transaction processing to a new event-driven accounting service. Phase 1 shipped in version 1.34, with further phase 1 changes in [version 1.38](/pt-br/products/custody/support/change-history/v138#ledger-accounting-refactor). Phase 2, in version 1.40, moves blockchain-specific operations for EVM, Solana, Stellar, TRON, and XRPL networks to UIS v2, the rewritten Unified Indexer Service, and changes selected transaction response fields and fee estimation on XRPL and Solana. Omnibus, Position Reports, endpoint address validation, Solana delegated nonce authority, and Canton all depend on the refactor. Behavioral changes for API integrations Both phases of the ledger accounting refactor change how Ripple Custody behaves for API integrations. Before you upgrade, review the [phase 1 behavioral changes](/pt-br/products/custody/operations-and-maintenance/upgrading/ledger-accounting-migration#behavioral-changes) and the [phase 2 behavioral changes](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2), and update your integrations. Migration required for on-premises deployments - **Upgrade path:** Version 1.43 can't be skipped. Upgrade to version 1.43 first, run any outstanding migrations on version 1.43 (phase 1 if needed, then phase 2), and only then upgrade to a later version. - **Phase 1:** If you didn't complete the ledger accounting migration on version 1.34, complete it on version 1.43, before you start phase 2 and before you use Omnibus or Position Reports. If you completed it on version 1.34, you don't need to run it again. The migration is a one-time procedure that needs a maintenance window. See the [Ledger accounting phase 1 migration guide](/pt-br/products/custody/operations-and-maintenance/upgrading/ledger-accounting-migration). - **Phase 2:** Version 1.43 is the first on-premises release with UIS v2, and you run the migration yourself. EVM, Solana, Stellar, TRON, and XRPL networks that use legacy indexers or UIS v1 (`type: "uis"`) must move to UIS v2 (`type: "uis-v2"`), and phase 1 must be complete first. For the changes, see [Ledger accounting refactor, phase 2](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2). #### Endpoint improvements - **Destination tags and memos.** Version 1.40 lets endpoints and transfers carry a destination tag or memo on XRPL, Stellar, and Hedera. You can set an XRPL destination tag on a transfer without the Payments flow. See [Destination tag and memo support](/pt-br/products/custody/support/change-history/v140#destination-tag-and-memo-support). - **Address validation.** Version 1.41 checks endpoint addresses against the ledger's format on EVM ledgers, Solana, Stellar, Tron, and XRPL, and rejects an invalid address before it causes a stuck transaction. See [Address validation for endpoints](/pt-br/products/custody/support/change-history/v141#address-validation-for-endpoints). - **Duplicate endpoints.** Version 1.40 rejected duplicate endpoints, and version 1.42 makes this optional with the deprecated `allowDuplicate` field. The API accepts duplicates by default, and the UI prevents them by default. See [Duplicate endpoint prevention becomes optional](/pt-br/products/custody/support/change-history/v142#duplicate-endpoint-prevention-becomes-optional). ### All changes and links - [Ripple Custody 1.42](/pt-br/products/custody/support/change-history/v142) - [Omnibus support in the Portfolio Data Export Service](/pt-br/products/custody/support/change-history/v142#omnibus-support-in-the-portfolio-data-export-service) - [Duplicate endpoint prevention becomes optional](/pt-br/products/custody/support/change-history/v142#duplicate-endpoint-prevention-becomes-optional) - [Deterministic token lookup by on-ledger identity](/pt-br/products/custody/support/change-history/v142#deterministic-token-lookup-by-on-ledger-identity) - [Signing and mobile notification security improvements](/pt-br/products/custody/support/change-history/v142#signing-and-mobile-notification-security-improvements) - [UI v2 reliability improvements](/pt-br/products/custody/support/change-history/v142#ui-v2-reliability-improvements) - [Ripple Custody 1.41](/pt-br/products/custody/support/change-history/v141) - [Address validation for endpoints](/pt-br/products/custody/support/change-history/v141#address-validation-for-endpoints) - [Ripple Custody 1.40](/pt-br/products/custody/support/change-history/v140) - [Ledger accounting refactor, phase 2](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2) - [Destination tag and memo support](/pt-br/products/custody/support/change-history/v140#destination-tag-and-memo-support) - [Solana cold vault enablement: delegated nonce authority](/pt-br/products/custody/support/change-history/v140#solana-cold-vault-enablement-delegated-nonce-authority) - [Ripple Custody 1.39](/pt-br/products/custody/support/change-history/v139) (internal release with no client-facing changes) - [Ripple Custody 1.38](/pt-br/products/custody/support/change-history/v138) - [Omnibus general availability](/pt-br/products/custody/support/change-history/v138#omnibus-general-availability) - [Gas Station general availability](/pt-br/products/custody/support/change-history/v138#gas-station-general-availability) - [Ledger accounting refactor](/pt-br/products/custody/support/change-history/v138#ledger-accounting-refactor) - [Ripple Custody 1.37](/pt-br/products/custody/support/change-history/v137) - [Portfolio Data Export Service](/pt-br/products/custody/support/change-history/v137#portfolio-data-export-service) - [Ripple Custody 1.36](/pt-br/products/custody/support/change-history/v136) - [System-signed intents](/pt-br/products/custody/support/change-history/v136#system-signed-intents) - [Omnibus](/pt-br/products/custody/support/change-history/v136#omnibus) - [Thales Luna PCIe HSM support](/pt-br/products/custody/support/change-history/v136#thales-luna-pcie-hsm-support) - [Ripple Custody 1.35](/pt-br/products/custody/support/change-history/v135) - [MPC wrapping key rotation](/pt-br/products/custody/support/change-history/v135#mpc-wrapping-key-rotation) ### Deployment-affecting changes The following changes can affect existing integrations and on-premises deployments. Check them before you upgrade. Each links to its release note for details. - **Genesis `antiRewindMode` field.** New installations must include `antiRewindMode` in the Genesis request. See [Anti-rewind mode](/pt-br/products/custody/governance/genesis/payload-reference#anti-rewind-mode). - **`HMZ_NOTARY_ALLOW_EMPTY_COLS` retired.** The notary reads `HMZ_NOTARY_ALLOW_EMPTY_COLS=true` as the `BALANCED` anti-rewind mode. Replace it with the `antiRewind.seedMode` chart value or a `v0_SetSystemProperty` intent. See [Notary configuration](/pt-br/products/custody/deployment/reference/kms-notary#hot-failover-fields). - **Ledger accounting migration.** Version 1.43 can't be skipped: on-premises deployments must run their outstanding ledger accounting migrations on version 1.43 before they upgrade to a later version. Deployments that didn't complete the phase 1 migration on version 1.34 must complete it on version 1.43, before phase 2 and before they use Omnibus or Position Reports. See [Ledger accounting refactor](#ledger-accounting-refactor). - **UIS v2, the rewritten Unified Indexer Service.** Ledger accounting refactor phase 2 moves blockchain-specific operations — transaction preparation, nonce and sequence reservation, broadcast, confirmation tracking, and reorg handling — into UIS v2 for EVM, Solana, Stellar, TRON, and XRPL networks; other protocols are unchanged. For chains served by UIS v2, transaction responses no longer populate `rawTransaction` or `senderLedgerSpecificMetadata`. XRPL and Solana fee estimation also change. See [Ledger accounting refactor, phase 2](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2). - **Migration to UIS v2 for on-premises deployments.** EVM, Solana, Stellar, TRON, and XRPL networks move to UIS v2; legacy indexers, UIS v1, and mixed setups are no longer supported for them. Set `type` to `"uis-v2"` for each of these networks, replacing `"legacy"` or `"uis"`. Before you upgrade: - Complete the [ledger accounting phase 1 migration](/pt-br/products/custody/operations-and-maintenance/upgrading/ledger-accounting-migration) first. You can't move directly from a deployment without phase 1 to phase 2. - Plan to move every network of these protocols at the same time. The migration runs only once, and a network that you switch to UIS v2 after the migration completes goes live without its tracked addresses migrated. - Keep the time between the upgrade and the migration short. UIS v2 replays events from each ledger's last processed block, but if that block is more than 24 hours old, UIS v2 starts from the chain tip, and the events in the gap aren't replayed. - If a ledger uses `raw_config`, declare `ledger..indexer-network-name` explicitly. Otherwise, chart rendering fails, and the error message shows the exact line to add. After the upgrade, the old indexer pods are removed, but their database schemas remain; drop them manually to reclaim the space. To plan the migration, contact your Customer Partner Engineer (CPE). - **Canton account keys.** If you use Canton, account provider details can contain a key with the new `VaultReserved` type. Update integrations that read the `keys` array and accept only the existing key types. See [Canton Network support](#canton-network-support). - **Negative balances.** The `totalAmount` and `availableAmount` balance fields can hold negative values. Update integrations that parse them as unsigned. See [Support for negative balances](/pt-br/products/custody/support/change-history/v138#support-for-negative-balances). - **Endpoint address validation.** Endpoint creation and update reject an address that doesn't match the ledger's format. See [Address validation for endpoints](/pt-br/products/custody/support/change-history/v141#address-validation-for-endpoints). - **Duplicate endpoints.** The API accepts duplicate endpoints by default. To reject them, set the deprecated `allowDuplicate` field to `false`. Ripple plans to remove the field on October 1, 2027, after which Ripple Custody always rejects duplicates. See [Duplicate endpoint prevention becomes optional](/pt-br/products/custody/support/change-history/v142#duplicate-endpoint-prevention-becomes-optional). - **Gas Station and Omnibus API changes.** Both features reached general availability with API changes, and Gas Station onboarding replaces the bot user with system-signed intents. If you used the beta, review [Gas Station general availability](/pt-br/products/custody/support/change-history/v138#gas-station-general-availability) and [Omnibus general availability](/pt-br/products/custody/support/change-history/v138#omnibus-general-availability). - **Auth & Sign app version 5.12.0.** Signing uses server-generated verification codes. Apps older than 5.12.0 can't sign once Ripple turns off compatibility mode, so update the app on every signing device. On-premises deployments control compatibility mode in the notifications configuration. See [Signing and mobile notification security improvements](/pt-br/products/custody/support/change-history/v142#signing-and-mobile-notification-security-improvements). - **Data export account types.** For omnibus domains, export account-type columns can contain `omnibus` and `deposit wallet`, and Position Report totals exclude virtual account balances. See [Omnibus support in the Portfolio Data Export Service](/pt-br/products/custody/support/change-history/v142#omnibus-support-in-the-portfolio-data-export-service). ## Canton Network support Ripple Custody version 1.43 adds support for the [Canton Network](/pt-br/products/custody/accounts-and-assets/blockchains/canton), the public Layer 1 network that regulated institutions use for tokenization, settlement, and repo. You can hold and transfer Canton Coin and CIP-56 tokens in the same custody platform, policy engine, and audit trail as the rest of your digital assets, instead of in a separate custodian. - **Bring your own validator.** Ripple Custody connects to a Canton validator that you or your node provider operate, and keeps each party's signing key in your vault. - **Transfer pre-approvals.** Each account receives assets without signing every incoming transfer, which suits cold vaults and long approval flows. - **Two-step transfers.** Accept or reject incoming transfer offers, and withdraw outgoing offers that the receiver hasn't acted on. Availability Canton is available on-premises and, through the hybrid model, for SaaS. It requires [ledger accounting refactor phase 2](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2). In this release, you manage Canton through the API. To get started, see [Connect your validator](/pt-br/products/custody/accounts-and-assets/blockchains/canton/connect-your-validator). The API changes are additive, and no existing operation changes. For the API fields and limits, see [Canton reference](/pt-br/products/custody/accounts-and-assets/blockchains/canton/reference). Canton accounts list their party key with a new `VaultReserved` key type. If your integration reads account keys, check that it accepts this type. See [Account keys](/pt-br/products/custody/accounts-and-assets/blockchains/canton/reference#account-keys). ## Circle Arc ledger support Ripple Custody version 1.43 adds support for the [Arc](https://www.arc.io/) blockchain, Circle's EVM-compatible layer-one (L1) network, which uses USDC as its native currency. For supported operations, see [Supported blockchain ledgers](/pt-br/products/custody/reference/supported-ledgers#ethereum-virtual-machine-evm-ledgers). For the payloads needed to add or update the Arc ledgers, see [Dynamic ledger payloads](/pt-br/products/custody/accounts-and-assets/blockchains/dynamic-ledgers-payloads) and [Dynamic ledger update payloads](/pt-br/products/custody/accounts-and-assets/blockchains/dynamic-ledgers-update-payloads). ## Sui ledger support Ripple Custody version 1.43 adds support for the [Sui](https://sui.io/) blockchain. You can receive, hold, quarantine, release, and send native SUI and fungible Sui coins, including regulated coins such as Circle's native USDC, through the API. Sui transactions have a configurable validity window of up to 14 epochs, to fit cold vault signing and long approval flows. In this release, manage Sui through the API only. Don't use the UI for Sui. For an overview, see [Sui](/pt-br/products/custody/accounts-and-assets/blockchains/sui). For supported operations, see [Supported blockchain ledgers](/pt-br/products/custody/reference/supported-ledgers#other-ledgers). For the payloads needed to add or update the Sui ledgers, see [Dynamic ledger payloads](/pt-br/products/custody/accounts-and-assets/blockchains/dynamic-ledgers-payloads) and [Dynamic ledger update payloads](/pt-br/products/custody/accounts-and-assets/blockchains/dynamic-ledgers-update-payloads). ## EIP-7702 delegation for Ethereum accounts Ripple Custody version 1.43 supports [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) delegation for Ethereum accounts. An account, such as a deposit wallet that holds tokens but no ETH, can adopt the code of a smart contract, while a separate sponsor account broadcasts the delegation and pays the gas. Two new operations on Ethereum transaction orders enable this: - **SetDelegation**, from the account to delegate. The account signs the delegation, and the order waits for a sponsor. To revoke a delegation, delegate to the zero address. - **SubmitAuthorization**, from a separate, funded sponsor account. It broadcasts one or more waiting delegations in a single transaction and pays the gas. An account can't sponsor its own delegation. A sponsor pays the gas for the delegation transaction only. This is separate from [Gas Station](/pt-br/products/custody/accounts-and-assets/gas-station/overview), which sends native tokens to sponsored accounts. Delegate only to audited contracts The contract fully controls a delegated account until you revoke the delegation, which doesn't expire on its own. Delegate only to audited contracts, and revoke delegations you no longer need. Requirements EIP-7702 delegation requires the Pectra hard fork on the network, Vault image 1.35.0 or later, and [ledger accounting refactor phase 2](/pt-br/products/custody/support/change-history/v140#ledger-accounting-refactor-phase-2). For the full procedure, see [Delegate Ethereum accounts to a smart contract with the API](/pt-br/products/custody/accounts-and-assets/accounts/ledger-specific-settings/ethereum-api). For the new `Sponsored` fee strategy, see [Fee strategy and maximum fee](/pt-br/products/custody/transactions/reference#fee-strategy-and-maximum-fee). ## Multi-purpose token (MPT) operations in the UI Ripple Custody version 1.43 adds XRP Ledger [multi-purpose token (MPT)](/pt-br/products/custody/accounts-and-assets/tokenization/xrpl-mpts) operations to the UI. Previously, you could manage MPTs only through the API. From an account, click **Create order** and select **Ledger-specific operations** to: - **As an issuer:** create, destroy, and claw back tokens, authorize and revoke holders, and freeze or unfreeze one or all holders. - **As a holder:** opt in to a token. - **As an issuer or holder:** send tokens with **Transfer token**. An issuer uses the same operation to mint tokens to a holder. To select an MPT, choose **Listed asset** if its ticker is allowlisted, or enter its issuance ID as an **Unlisted asset**. Each operation creates an intent that you sign with the app, like any other UI operation. Escrow operations remain API only. For the UI and API procedure for each operation, see [Supported operations](/pt-br/products/custody/accounts-and-assets/tokenization/xrpl-mpts#supported-operations). ## Notary hot failover and anti-rewind modes Ripple Custody version 1.43 adds three anti-rewind modes that control how strictly the notary applies [anti-rewind protection](/pt-br/products/custody/overview/security/data-integrity-and-audit-trail#anti-rewind-modes): - `STRICT` keeps the behavior of earlier versions. Failover isn't possible. - `BALANCED` accepts a collection that the anti-rewind file has no record of, and rejects a conflicting one. This mode enables failover. - `DISABLED` skips the anti-rewind check. This mode also enables failover. In `BALANCED` or `DISABLED` mode, you can run a standby notary that takes over automatically when the serving notary is silent for 15 minutes. You can configure this period to any value of 10 minutes or more. A notary outage then adds latency instead of stopping intent processing. You set the mode at Genesis and change it with a `v0_SetSystemProperty` intent. Existing platforms run in `STRICT` mode by default, unless the notary already runs with `HMZ_NOTARY_ALLOW_EMPTY_COLS=true`. Those platforms run in `BALANCED` mode, and their behavior doesn't change. A mode that you set at Genesis or with an intent takes precedence over both. Genesis requires antiRewindMode Genesis requests must include the new `antiRewindMode` field. This change doesn't affect platforms that completed Genesis on an earlier version. For the setup, monitoring, and response procedures, see [Set up notary hot failover](/pt-br/products/custody/operations-and-maintenance/security-maintenance/notary-hot-failover). For the Genesis field, see [Genesis payload reference](/pt-br/products/custody/governance/genesis/payload-reference#anti-rewind-mode). ## Address-level manifest signing for Bitcoin-family ledgers Ripple Custody version 1.43 can sign a manifest with the key of a specific address on Bitcoin-family ledgers: Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, and Dash. This lets you prove ownership of an individual address, for example for a Travel Rule check by a counterparty. Previously, you couldn't choose which address's key signed a manifest, so on these ledgers, where an account can have several addresses, you couldn't prove ownership of a specific one. To use it, set the new optional `address` field of a `v0_SignManifest` intent with `Unsafe` content to an address that Ripple Custody recorded for the account. The change is backward compatible: without `address`, manifests are signed as before. The feature is available through the API only. For details and an example, see [Sign with a specific Bitcoin-family address](/pt-br/products/custody/governance/intents/sign-and-store-payloads#sign-with-a-specific-bitcoin-family-address). ## Distribution and deployment ### On-premises Version 1.43 will be available for on-premises customers to download and install starting on the release date. You can pull the containers from Ripple’s repository using the `1.43.0` tag. On-premises Version 1.43 also includes all the cumulative updates from STS (SaaS) Versions [1.35](/pt-br/products/custody/support/change-history/v135), [1.36](/pt-br/products/custody/support/change-history/v136), [1.37](/pt-br/products/custody/support/change-history/v137), [1.38](/pt-br/products/custody/support/change-history/v138), [1.39](/pt-br/products/custody/support/change-history/v139), [1.40](/pt-br/products/custody/support/change-history/v140), [1.41](/pt-br/products/custody/support/change-history/v141), and [1.42](/pt-br/products/custody/support/change-history/v142). As with all new long-term support (LTS) releases, this version triggers the deprecation of the previous LTS version (v1.34.x), which will continue to be supported for 6 months following this release, unless specified otherwise in the master contract with Ripple. For more information about versioning, see [Versioning and release management](/pt-br/products/custody/support/release-management). ### Ripple Cloud Ripple Custody Version 1.43 will be progressively deployed across SaaS environments starting on the release date. To enable Canton in the hybrid model, contact your Ripple liaison with your validator details. ### 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](/pt-br/products/custody/support/get-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).