This week's Ripple protocol updates enhance transaction reliability and correctness by fixing trustline limit checks for vault withdrawals, enforcing aggregate MaximumAmount in multi-send transactions, and decoupling the owner reserve from fees in delegate payments.

> impact

["Key updates have been shipped to the Ripple protocol to improve transaction correctness and reliability. A fix for share-denominated vault withdrawals now correctly validates the recipient's trustline limits before execution, preventing transactions that would have otherwise failed due to insufficient capacity. Concurrently, a bug in multi-send transactions has been addressed; the protocol now properly enforces the aggregate 'MaximumAmount' across all payments within a single multi-send, closing a loophole that could have led to unintended over-payments and strengthening the overall security of batched transactions.","A significant refinement was made to the economic logic of 'delegate payment' transactions. The owner reserve requirement has been decoupled from the transaction fee, correcting a flaw where these two distinct economic components were improperly linked. This change ensures that the protocol's handling of reserves and fees is more logical and predictable, aligning the implementation with its intended design. This leads to more accurate on-chain accounting and removes ambiguity in how these costs are assessed.","The decoupling of the reserve and fee in delegate payments is a potential breaking change for some applications. Developers who built logic for fee estimation or reserve management based on the previous coupled behavior must update their code. Your application should now treat the transaction fee and the owner reserve as two separate, independent values. Failure to adapt to this change may result in incorrect cost calculations, failed transaction submissions, or improper reserve management within your application. Please review any relevant code paths to ensure compatibility with the updated protocol logic."]

> Try this now

try this

# This example illustrates how to adjust your application's logic for the
# recent decoupling of owner reserve and transaction fees in delegate payments.

# --- BEFORE THE FIX ---
# Previously, some applications might have incorrectly coupled fee estimation
# with the owner reserve requirement. This logic is now deprecated.

def calculate_legacy_delegate_cost(transaction):
  # ⚠️ Deprecated Logic: Combining fee and reserve calculations.
  coupled_value = get_fee(transaction) + get_implicit_reserve_contribution(transaction)
  print(f"Estimated cost (incorrect): {coupled_value}")
  return coupled_value

# --- AFTER THE FIX ---
# The protocol now correctly separates the transaction fee from the owner
# reserve. Your application must handle these as two distinct values.

def calculate_correct_delegate_cost(transaction):
  # 1. Calculate the standard transaction fee.
  tx_fee = get_transaction_fee(transaction)
  print(f"Transaction Fee: {tx_fee}")

  # 2. Separately, check and manage the owner reserve requirement.
  # This is no longer tied to the fee calculation itself.
  reserve_requirement = check_owner_reserve(transaction['account'])
  print(f"Owner Reserve Requirement: {reserve_requirement}")

  # Your application logic should now ensure the sending account can cover
  # BOTH the transaction fee AND meets its reserve requirements independently.
  account_balance = get_account_balance(transaction['account'])
  if account_balance >= tx_fee + reserve_requirement:
    print("Sufficient funds for fee and reserve. Ready to submit.")
    # Proceed with transaction submission...
  else:
    print("Insufficient funds for fee and reserve requirements.")