# Ripple Custody 1.34 (April 14, 2026) Version 1.34 is a long-term support (LTS) release for both SaaS and on-premises deployments, and introduces support for the following new features: - [Available balance](#available-balance) - [Vault key rotation for both IBM HSM and MPC wrapping keys](#vault-key-rotation) - [Keycloak session limiting and inactivity timeout](#keycloak-session-limiting-and-inactivity-timeout) OpenTelemetry configuration change If you deploy or upgrade to Custody Application v1.34.x and have explicitly enabled OpenTelemetry monitoring, define the OTLP export protocol in your environment before starting the upgraded services. See [OpenTelemetry protocol configuration](#opentelemetry-protocol-configuration). IBM HSM (s390x architecture) deprecation for non-secure components Starting in version 1.34, Ripple Custody supports s390x (IBM) architecture for secure components only, including the notary and vault. Non-secure components are not supported on s390x architecture. Contact your Ripple liaison if you have an existing deployment that includes non-secure components on s390x architecture. Version 1.34 also includes the features of the following short-term support (STS) SaaS versions: - [Ripple Custody 1.33](/products/custody/support/change-history/v133) - [Skip quarantine for internal transfers](/products/custody/support/change-history/v133#skip-quarantine-for-internal-transfers) - [Ripple Custody 1.32](/products/custody/support/change-history/v132) - [Gas Station Service](/products/custody/support/change-history/v132#gas-station-service) - [Multi-Purpose Token (MPT) issuer operations](/products/custody/support/change-history/v132#multi-purpose-token-mpt-issuer-operations) - [MPT dry-run support](/products/custody/support/change-history/v132#mpt-dry-run-support) - [Ripple Custody 1.31](/products/custody/support/change-history/v131) - [Token Management system](/products/custody/support/change-history/v131#token-management-system) - [Multi-Purpose Token (MPT) holder operations](/products/custody/support/change-history/v131#multi-purpose-token-mpt-holder-operations) - [Ripple Custody 1.30](/products/custody/support/change-history/v130) - [Travel Rule integration](/products/custody/support/change-history/v130#travel-rule-integration) - [Securosys HSM integration](/products/custody/support/change-history/v130#securosys-hsm-integration) - [Ripple Custody 1.29](/products/custody/support/change-history/v129) - [Unspent transaction output (UTXO) allowlisting via the UI](/products/custody/support/change-history/v129#unspent-transaction-output-utxo-allowlisting-via-the-ui) - [Hardware security module (HSM) backups](/products/custody/support/change-history/v129#hardware-security-module-hsm-backups) - [Ripple Custody 1.28](/products/custody/support/change-history/v128) - [Multi-party computation (MPC) backups](/products/custody/support/change-history/v128#multi-party-computation-mpc-backups) - [Ripple Custody 1.27](/products/custody/support/change-history/v127) - [Unspent transaction output (UTXO) allowlisting](/products/custody/support/change-history/v127#unspent-transaction-output-utxo-allowlisting) ## Available balance Version 1.34 introduces a new field `availableAmount` in the returned payload from the [Get account balances](/products/custody/reference/api/openapi/accounts/getaccountbalances) API operation. You can use this new field to fetch the currently available balance for each account, which is more accurate than calculating it from the other fields (`totalAmount`, `reservedAmount`, and `quarantinedAmount`). For more information, contact your Customer Partner Engineer (CPE). If you are currently calculating an available balance using the formula: available balance = `totalAmount` - `reservedAmount` - `quarantinedAmount` this may produce an incorrect available balance in certain situations, such as an incoming transaction in the `Detected` state. For this reason, it is recommended to use the `availableAmount` field instead. For more information about account balances, see [Check account balances](/products/custody/accounts-and-assets/accounts/manage-accounts-api#check-account-balances). ## Vault key rotation Ripple Custody version 1.34 introduces support of key rotation of the wrapping key for vaults deployed on IBM HSM and MPC. ### IBM HSM wrapping key rotation Version 1.34 introduces a new intent, `v0_RewrapVaultKeyMaterial`, to support rotation of the IBM HSM wrapping key. For more information and instructions for rotating the wrapping key, see [IBM HSM wrapping key rotation](/products/custody/identity-and-access/vault-management/vault-wrapping-key-rotation-ibm-hsm). ### MPC wrapping key rotation For MPC vaults, in addition to the new `v0_RewrapVaultKeyMaterial` intent, version 1.34 also introduces a new MPC node contract parameter, `NEXT_KEK_PROVIDER_EMBED`, to contain the new key encryption key (KEK) for updating both the customer-hosted and Ripple-hosted MPC nodes. For more information and instructions, see [MPC wrapping key rotation](/products/custody/identity-and-access/vault-management/vault-wrapping-key-rotation-mpc). ## Keycloak session limiting and inactivity timeout Ripple Custody version 1.34 adds support for Keycloak's control of the number of concurrent sessions a user can have open at the same time, as well as the timeout for session inactivity. Prerequisites include: * Keycloak **26.x** or later. * Custody LTS Version **1.34** or later. * Admin access to the Keycloak [Admin Console](https://www.keycloak.org/docs/latest/server_admin/index.html). For more information, see the following tutorials: * [Keycloak session limiting](/products/custody/identity-and-access/sso/keycloak-session-limiting) * [Keycloak inactivity timeout](/products/custody/identity-and-access/sso/keycloak-inactivity-timeout) ## Breaking changes ### OpenTelemetry protocol configuration Version LTS 1.34.x includes a major upgrade to the underlying OpenTelemetry (OTel) Java Agent to address recent upstream security vulnerabilities (CVEs). While this upgrade ensures your deployment remains secure, it introduces a behavioral change in how telemetry data is exported. This change only affects your environment if both of the following apply: - You are deploying or upgrading to Custody Application v1.34.x. - You have explicitly enabled OpenTelemetry monitoring in your deployment. In the newer version of the OpenTelemetry agent, the upstream maintainers changed the default export protocol from `grpc` to `http/protobuf`. However, standard OTel gRPC collectors typically listen on port `4317`. If you upgrade to v1.34.x without adjusting your configuration, the agent will attempt to send `http/protobuf` traffic to the gRPC port, resulting in your telemetry collector rejecting the data. You may see the following errors in your service logs, and your observability dashboards will stop receiving new data: ```text WARN - OTLP exporter endpoint port is likely incorrect for protocol version "http/protobuf". Port 4317 typically uses grpc. ERROR - Failed to export spans. Connection reset by peer ``` This issue only impacts observability and telemetry collection. Core application functionality, performance, and data integrity remain completely unaffected. To maintain your current telemetry flow and preserve the gRPC export behavior on port `4317`, you must explicitly define the protocol in your environment before starting the upgraded services. Apply one of the following configuration changes depending on your deployment method. #### Option 1: Environment variable (recommended for Docker/Helm) Add the following environment variable to your container or OS startup environment: ```bash OTEL_EXPORTER_OTLP_PROTOCOL="grpc" ``` #### Option 2: Java Virtual Machine (JVM) options If you manage JVM arguments directly, append the following system property: ```bash JAVA_TOOL_OPTIONS="-Dotel.exporter.otlp.protocol=grpc" ``` If you have any questions or require assistance implementing this configuration change, contact your assigned CPE or the [Technical Services team](https://metaco.atlassian.net/servicedesk/customer/portal/1). ## Distribution and deployment ### On-premises Version 1.34 will be available for on-premises customers to download and install starting on April 14, 2026. You can pull the containers from Ripple’s repository using the `1.34.0` tag. On-premises Version 1.34 also includes all the cumulative updates from STS (SaaS) Versions [1.27](/products/custody/support/change-history/v127), [1.28](/products/custody/support/change-history/v128), [1.29](/products/custody/support/change-history/v129), [1.30](/products/custody/support/change-history/v130), [1.31](/products/custody/support/change-history/v131), [1.32](/products/custody/support/change-history/v132), and [1.33](/products/custody/support/change-history/v133). As with all new long-term support (LTS) releases, this version triggers the deprecation of the previous LTS version (v1.26.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](/products/custody/support/release-management). ### Ripple Cloud Ripple Custody Version 1.34 will be progressively deployed across SaaS environments starting on April 14, 2026 with production environments scheduled for deployment on April 27, 2026. This may be delayed, based on customer feedback. ### 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](/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).