What shipped
On October 5, Ripple released Custody 1.43 as a long-term support release for SaaS and on-premises deployments. The release adds support for Canton Network, Circle Arc, and Sui; Ethereum EIP-7702 delegation; notary hot failover and selectable anti-rewind modes; and address-level manifest signing for Bitcoin-family ledgers. It also collects the behavior and API changes delivered in short-term releases 1.35 through 1.42 for customers upgrading from 1.34.
For on-premises deployments, Ripple says version 1.43 cannot be skipped on the path to later versions. Outstanding accounting migrations must run on 1.43: phase 1 must complete before phase 2, and phase 2 moves EVM, Solana, Stellar, TRON, and XRPL processing to the rewritten Unified Indexer Service, UIS v2. These are Ripple’s reported capabilities and upgrade requirements; the production conclusions below are Ineeza analysis.
An upgrade is now a financial-state transition
Ineeza analysis: a custody upgrade that changes balance tracking, transaction preparation, nonce or sequence reservation, broadcast, confirmation tracking, and reorg handling is not just a software rollout. It changes the machinery that decides what money exists and where a transfer is in its lifecycle. The migration plan should therefore define a signed state boundary: software and chart versions, enabled ledgers, last processed blocks, pending intents, reserved nonces, account balances, and reconciliation totals immediately before and after cutover.
The release notes say the UIS v2 migration runs once and affected networks should move together. A network switched after that migration can come online without its tracked addresses migrated. This makes partial rollout a data-completeness risk, not merely a temporary compatibility issue. Operators should inventory every configured network from the deployed system, compare it with the migration manifest, and block completion until both sets match.
The replay window needs an explicit recovery decision
Ineeza analysis: Ripple says UIS v2 replays from each ledger’s last processed block, but starts from the chain tip when that block is more than 24 hours old, leaving the intervening events unreplayed. A maintenance window must therefore include a measured freshness gate for every ledger and a documented decision for any gap. “Service is running” is not proof that the custody record is complete.
Before traffic resumes, teams should reconcile onchain balances, internal positions, pending and failed transactions, fee movements, and sequence state against an independently captured checkpoint. Recovery testing should cover a cutover that overruns the replay window, a ledger that is unavailable during validation, and a rollback after some networks have advanced. Evidence for sign-off should be durable enough for finance, security, and audit teams to reproduce the decision later.
Delegation creates persistent wallet authority
Ripple’s EIP-7702 support lets an Ethereum account sign a delegation while a separate funded sponsor broadcasts it and pays the delegation gas. Ripple warns that the delegated contract fully controls the account until revocation and that the delegation does not expire automatically. The sponsor pays only for the delegation transaction; this mechanism is separate from Ripple Custody Gas Station.
Ineeza analysis: delegation approval should bind the account, target code address, verified code hash, permitted networks, business purpose, and planned revocation. Contract allowlisting by address alone is insufficient when upgradeable code can change behind that address. Monitoring must treat a delegation as continuing authority, surface unexpected code or implementation changes, and prove revocation onchain before operational policy considers the power removed.
Availability and integrity are one policy choice
Ripple also introduces STRICT, BALANCED, and DISABLED anti-rewind modes for the notary. STRICT retains the earlier behavior and does not allow failover; BALANCED permits an unknown collection but rejects a conflicting one; DISABLED skips the anti-rewind check. BALANCED and DISABLED can use a standby notary that takes over after the serving notary is silent for a configured period of at least 10 minutes.
Ineeza analysis: that setting is a security posture, not a generic high-availability toggle. Operators should document the threat model and recovery evidence that justify the selected mode, alert on every failover and mode change, and restrict changes through an independently approved intent. Disaster-recovery exercises must verify both sides of the tradeoff: that processing can resume after a real outage and that restored or conflicting state cannot silently authorize a second history.
Ineeza’s view
Ripple Custody 1.43 is material because one LTS boundary combines a mandatory accounting migration, broader ledger support, persistent smart-contract authority, and a configurable integrity-versus-availability decision. Safe adoption depends on treating the rollout as a versioned financial-state transition: establish complete pre-migration evidence, make the network set atomic, reconcile after replay, bind and monitor delegated authority, and test notary recovery under the exact policy that production will use.