Ripple shipped three targeted bug fixes this week: a WebSocket memory leak patch in the client SDK, a VaultClawback edge-case correction, and a safeguard preventing MPToken deletion when escrows are active.
> impact
**What changed.** Three fixes landed across the Ripple ecosystem. First, a client SDK commit by Kuan Lin replaces `.on('connected')` with `.once()` in the WebSocket reconnection logic, eliminating a bug where event listeners silently accumulated on every reconnect cycle. Second, PR #6646 by Vito Tumas corrects `VaultClawback` behavior when a zero-amount clawback is issued — the clawback amount is now properly clamped to `assetsAvailable`, closing an edge case where the operation could behave unexpectedly against vault state. Third, PR #6635 by Zhiyuan Wang prevents `MPToken` deletion when an active escrow is attached to the token, guarding against escrowed fund loss or inconsistent ledger state.
**Why it matters.** The SDK fix is a classic silent-failure bug: applications maintaining long-lived connections to `rippled` nodes — indexers, bots, monitoring services — would gradually leak memory and potentially fire duplicate event handlers without any obvious error. The VaultClawback fix hardens DeFi-adjacent vault logic on XRPL by ensuring zero-amount inputs don't bypass intended constraints. The MPToken escrow guard is a data-integrity safeguard that's critical for anyone building token lifecycle flows that interact with XRPL's escrow primitives.
**Impact for developers.** If you run persistent WebSocket connections to rippled, upgrade your `xrpl` client library immediately — the listener leak is proportional to reconnection frequency and can degrade production stability over hours or days. Vault integrators should review their clawback call paths, especially any logic that passes `0` or computed amounts that could resolve to zero. Teams building on MPTokens with escrow functionality should audit their token deletion flows and ensure they account for the new constraint that tokens with active escrows are now non-deletable at the ledger level.
> Try this now
try this
# --- SDK Fix: .on() → .once() for reconnect listeners ---
# Before (leaky): every reconnect adds another listener
# client.on('connected', () => {
# console.log('Reconnected to rippled');
# // This handler now exists N times after N reconnects
# });
# After (fixed): listener fires once, then is removed
# client.once('connected', () => {
# console.log('Reconnected to rippled');
# // Clean — only one handler per reconnect cycle
# });
# --- Verify the fix in your own app ---
# const { Client } = require('xrpl');
# const client = new Client('wss://s1.ripple.com');
#
# // Monitor listener count to confirm no accumulation
# setInterval(() => {
# console.log('connected listeners:', client.listenerCount('connected'));
# }, 5000);
#
# await client.connect();
# --- VaultClawback zero-amount edge case (PR #6646) ---
# // Previously, issuing a clawback with Amount = 0 could behave
# // unexpectedly. Now the ledger clamps to assetsAvailable:
# {
# "TransactionType": "VaultClawback",
# "Account": "rIssuer...",
# "VaultID": "<vault_hash>",
# "Amount": "0" // Now safely resolves to min(0, assetsAvailable) = 0
# }
# --- MPToken deletion guard (PR #6635) ---
# // Attempting to delete an MPToken with an active escrow
# // now returns tecHAS_OBLIGATIONS instead of succeeding:
# {
# "TransactionType": "MPTokenAuthorize",
# "Account": "rHolder...",
# "MPTokenIssuanceID": "<token_id>",
# "Flags": 1 // tfMPTUnauthorize (delete)
# // Result: tecHAS_OBLIGATIONS if escrow is active
# }
# // Developers should check for this error code in token
# // lifecycle management and surface it to users accordingly.