Ripple Custody (Vault) 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
• Circle Arc ledger support
• Sui ledger support

New features:

• EIP-7702 delegation for Ethereum accounts
• Multi-purpose token (MPT) operations in the UI
• Notary hot failover and anti-rewind modes
• Address-level manifest signing for Bitcoin-family ledgers

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.

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. For more information, see Omnibus general availability and the Omnibus overview.

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 and Gas Station.

System-signed intents, introduced in version 1.36, let an authenticated service submit selected intent types without a client-side signature. Ripple Custody (Vault) 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 and System-signed intent configuration.

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 and the Data export overview.

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. 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.

• 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.
• 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.
• 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.

• Ripple Custody (Vault) 1.42
  • Omnibus support in the Portfolio Data Export Service
  • Duplicate endpoint prevention becomes optional
  • Deterministic token lookup by on-ledger identity
  • Signing and mobile notification security improvements
  • UI v2 reliability improvements
• Ripple Custody (Vault) 1.41
  • Address validation for endpoints
• Ripple Custody (Vault) 1.40
  • Ledger accounting refactor, phase 2
  • Destination tag and memo support
  • Solana cold vault enablement: delegated nonce authority
• Ripple Custody (Vault) 1.39 (internal release with no client-facing changes)
• Ripple Custody (Vault) 1.38
  • Omnibus general availability
  • Gas Station general availability
  • Ledger accounting refactor
• Ripple Custody (Vault) 1.37
  • Portfolio Data Export Service
• Ripple Custody (Vault) 1.36
  • System-signed intents
  • Omnibus
  • Thales Luna PCIe HSM support
• Ripple Custody (Vault) 1.35
  • MPC wrapping key rotation

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.

• 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.

• Ledger accounting migration. LTS releases can't be skipped, and 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.

• 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.

• 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 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.<name>.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. For the procedure, see the Ledger accounting phase 2 migration guide. For the UIS v2 configuration and node requirements, see Unified Indexer Service. 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.

• Negative balances. The totalAmount and availableAmount balance fields can hold negative values. Update integrations that parse them as unsigned. See 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.

• 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 (Vault) always rejects duplicates. See 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 and 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.

• 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.

Ripple Custody (Vault) version 1.43 adds support for the Canton Network, 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 (Vault) 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.

To get started, see Connect your validator. The API changes are additive, and no existing operation changes. For the API fields and limits, see 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.

Ripple Custody (Vault) version 1.43 adds support for the Arc blockchain, Circle's EVM-compatible layer-one (L1) network, which uses USDC as its native currency.

For supported operations, see Supported blockchain ledgers. For the payloads needed to add or update the Arc ledgers, see Dynamic ledger payloads and Dynamic ledger update payloads.

Ripple Custody (Vault) version 1.43 adds support for the Sui 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. For supported operations, see Supported blockchain ledgers. For the payloads needed to add or update the Sui ledgers, see Dynamic ledger payloads and Dynamic ledger update payloads.

Ripple Custody (Vault) version 1.43 supports 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, which sends native tokens to sponsored accounts.

For the full procedure, see Delegate Ethereum accounts to a smart contract with the API. For the new Sponsored fee strategy, see Fee strategy and maximum fee.

Ripple Custody (Vault) version 1.43 adds XRP Ledger multi-purpose token (MPT) 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.

Ripple Custody (Vault) version 1.43 adds three anti-rewind modes that control how strictly the notary applies anti-rewind protection:

• 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.

For the setup, monitoring, and response procedures, see Set up notary hot failover. For the Genesis field, see Genesis payload reference.

Ripple Custody (Vault) 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 (Vault) 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.

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, 1.36, 1.37, 1.38, 1.39, 1.40, 1.41, and 1.42.

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.

Ripple Custody (Vault) 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.

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).