Menedżerowie aktywów szykują się na XRPL Batch. Co ta funkcja właściwie potrafi?

Ripple twierdzi, że zarządzający aktywami przygotowują się do korzystania z XRP Ledger Batch. Typ transakcji może sprawić, że kilka działań w księdze zakończy się sukcesem lub porażką razem, ale awaryjne wydanie oprogramowania przeniosło uwagę z oczekiwanego uruchomienia 29 września na poprawkę bezpieczeństwa z 9 października. Możliwość ta jest konkretna. Podobnie jak dowody na to, że adopcja instytucjonalna pozostaje perspektywiczna.

Główna obietnica jest prosta: sprawić, by powiązane kroki rozliczyły się w jednym zamknięciu księgi. Zarządzający aktywami, który musi dostarczyć token i otrzymać płatność, może preferować wymianę wszystko-albo-nic zamiast najpierw wysyłać aktywo i mieć nadzieję, że pieniądze dotrą. RippleX opisał zarządzających aktywami i projekty komercyjne przygotowujące się do tej funkcji, co omówiono w wcześniejszym raporcie o zainteresowaniu instytucjonalnym. Nie wymienił publicznie produkcyjnego zarządzającego aktywami z aktywną transakcją Batch w mainnecie na tym koncie.

Status zmienił się przed pierwotnym oczekiwaniem na koniec września. Ogłoszenie o wydaniu XRPL Foundation nazywa wersję 3.4.1 aktualizacją awaryjną dla kwestii wrażliwych na bezpieczeństwo. Dodaje fixBatchV1_2, prosi serwery o szybką aktualizację i mówi, że oczekiwano, iż poprawka zostanie włączona 9 października, jeśli utrzyma się wsparcie superwiększości. To oczekiwanie warunkowe, a nie stała obietnica uruchomienia.

Batch koordynuje działania w ramach jednego zamknięcia księgi

Specyfikacja XLS-0056 opisuje transakcję zewnętrzną zawierającą od dwóch do ośmiu transakcji wewnętrznych. Zaangażowane konta zatwierdzają kolekcję. Wybrany tryb kontroluje, co się dzieje, gdy akcja wewnętrzna zawiedzie. Księga przetwarza kolekcję w jednym zamknięciu, unikając luki między niepowiązanymi zgłoszeniami, która mogłaby pozostawić jednego uczestnika z tylko połową transakcji.

Załóżmy, że fundusz przenosi roszczenie o obligację tokenizowaną i otrzymuje token dolara. Dwie zwykłe transakcje mogłyby zostać złożone osobno. Jeśli pierwsza się powiedzie, a druga zawiedzie, kontrahenci mają spór operacyjny i potencjalną stratę. W trybie wszystko-albo-nic obie akcje wewnętrzne muszą się powieść, aby zamierzona wymiana została zakończona. To przekonujący przypadek użycia instytucjonalnego, zakładając, że token, instrument płatniczy, kontrahenci i uprawnienia są już na miejscu.

Batch nie tworzy obligacji, nie weryfikuje jej własności poza łańcuchem ani nie zmusza banku do wykupu tokena płatniczego. Koordynuje działania w księdze. Ostateczność rozliczenia prawnego, ograniczenia transferu, depozyt i wykup nadal zależą od odpowiednich instrumentów i instytucji. Rozróżnienie to ma znaczenie, ponieważ technicznie atomowy transfer jest tylko jedną częścią dostawy za płatność.

The single-account tutorial shows the more straightforward case. Multiple actions from one account can be packaged in a specified mode. Multi-account transactions add signatures from the accounts whose balances or permissions are affected. The multi-account tutorial describes that coordinated signing process.

Four modes produce four different bargains

ALLORNOTHING is the clean two-sided trade. Every required inner action must succeed or the intended group does not settle. ONLYONE tries alternatives and stops after the first success, such as orders at different tolerances. UNTILFAILURE processes a sequence up to a failure. INDEPENDENT allows actions in the same wrapper to succeed or fail independently. Calling all four modes atomic in the everyday sense would hide the possibility of partial completion.

The modes alter product design. A fund moving two assets against one payment needs to decide whether a single failed transfer should cancel the full package. A market maker submitting fallback offers might prefer ONLYONE. An issuer distributing multiple payouts might tolerate independent outcomes, but then its operations team has to reconcile which recipients were paid. The mode is a risk decision, not a formatting choice.

The eight-action cap is another real limit. A manager attempting to settle 1,000 investor transfers cannot wrap all 1,000 into one Batch under the current proposal. At the theoretical minimum of 125 eight-action packages, those groups would not themselves be atomic with each other. Fees, signatures, account sequence management and service capacity become practical constraints even before the off-chain business process is considered.

The earlier technical report noted the upgrade’s long development and audit history. That background is relevant to timing but should not be confused with a claim that every application built on top has been audited.

The outer success code is an accounting trap

The specification says an outer Batch transaction can report tesSUCCESS even when inner transactions fail. Its outer result covers sequence and fee processing. To know whether a payment or delivery occurred, software must inspect inner transaction metadata and individual result codes. This is an unusually concrete integration hazard for any institution whose back office translates a generic success status into a booked asset movement.

Imagine a trade feed that reads only the outer result and credits a customer with a tokenized security. If the relevant inner transfer did not succeed, the feed and ledger diverge. The system needs to associate every inner action with its parent and its own result. The spec recommends using the ParentBatchID relationship in explorers and indexers. A desk should test failures in every mode, not only the happy path.

The mistake can survive ordinary controls because the outer transaction is real and has a transaction ID. A reconciliation system built for one transaction equaling one business action may pass its first check. The proper control links the business instruction to the mode, the complete signed package, every inner result and the eventual asset balances. That is work an asset manager must perform even if the network layer is correct.

The arithmetic is modest but revealing. A maximum Batch containing eight inner transactions is one outer submission, yet it can require at least eight outcome checks, plus the outer fee and sequencing check. For 125 full packages representing 1,000 inner actions, the back office needs 1,000 action-level outcomes, not 125 green status lights.

The security fix changes the activation story

The foundation’s September 25 notice says fixBatchV1_2 rejects inner transactions with the wrong wrapper and includes additional security and stability fixes. It withholds source code temporarily because of the security-sensitive nature of the change, promising publication and a retrospective later. That limits outsiders’ ability to inspect the exact patch before disclosure. It is a reason for precise attribution, not a reason to speculate about undisclosed exploitability.

The notice says servers below 3.4.1 would become amendment blocked if the fix enables while they have not upgraded. Validator votes and node upgrades therefore matter to production access. A quorum signaling support is not the same thing as every wallet, custodian, API provider and accounting tool being ready for Batch. The earlier XRPL node upgrade coverage illustrates the operational effect of an amendment block in a previous release.

There is also a history a reporter cannot omit. A February vulnerability disclosure describes a flaw in an earlier Batch design that could have skipped authorization checks for other signers when an unfunded signer appeared first. The amendment had not gone live. The security audit account examined how independent review caught problems before production use. The September patch concerns a separately described wrapper issue; neither incident proves the current design is unsafe, but both explain why deployment timing deserves scrutiny.

What institutions could gain, and what they still need

Atomic delivery against payment is the strongest case. A manager could coordinate a token transfer with payment on the same ledger, limiting the temporary exposure created by sequential transfers. An issuer could bundle account setup, authorization and issuance steps where the protocol permits those transaction types. Trading firms could use alternative execution paths. These are capabilities, not evidence of live assets and trades.

Tokenized assets require issuers, transfer agents or other responsible entities, rules on eligible holders, custody procedures, and a payment instrument with acceptable redemption terms. A Batch can make the on-chain legs execute under a chosen rule. It cannot make a security legally valid in another jurisdiction, obtain customer consent for an unrelated action or guarantee an external cash leg at a commercial bank.

Ripple’s case deserves its strongest version. A ledger-level mechanism can reduce coordination work for developers and remove a real class of partial settlement failures. The XRPL feature overview described Batch alongside other institutional functionality, though each amendment follows its own process. If named managers later show live, repeated settlement of real tokenized assets with correctly reconciled inner results, the adoption claim will have hard evidence behind it.

The limit is equally clear. A company preparing a pilot is not an asset manager using Batch in production. No public preparation claim tells us volumes, fees saved, settlement disputes prevented or which institution assumes off-chain obligations. An announcement can be true and still be too early to support those larger conclusions.

Głos księgi to dopiero pierwszy test gotowości

Oczekiwana aktywacja fixBatchV1_2 9 października zależy od trwałego wsparcia walidatorów. Operatorzy muszą uruchomić kompatybilne oprogramowanie. Portfele muszą pokazywać użytkownikom wszystkie wewnętrzne akcje i wybrany tryb przed zebraniem podpisu, zgodnie z zaleceniami specyfikacji. Indeksery muszą ujawniać wyniki nadrzędne i podrzędne. Powiernicy potrzebują kontroli polityk dla podpisów wielu kont. Menedżerowie aktywów potrzebują uzgodnień i dokumentacji prawnej.

Nie ma jednego procentu pokazującego całą tę gotowość. Głosowanie walidatorów mierzy zgodę na zmianę protokołu. Testem produkcyjnym jest to, czy prawdziwi użytkownicy mogą przygotować, podpisać, przesłać, sprawdzić i odzyskać się z nieudanej partii bez niezgodnych zapisów. Bez odpowiedzi pozostaje pytanie komercyjne, która nazwana instytucja pokaże powtarzalny przypadek użycia, gdy poprawka i narzędzia będą już działać.

Na co uważać

• Status poprawki: Czy fixBatchV1_2 utrzyma wsparcie i włączy się w oczekiwanym dniu 9 października.
• Aktualizacje serwera: Udział operatorów uruchamiających 3.4.1, zanim poprawka bezpieczeństwa stanie się obowiązkowa.
• Ujawnienie: Publikacja wstrzymanego źródła poprawki i obiecanego retrospektywnego przeglądu.
• Wyniki wewnętrzne: Wsparcie portfeli i indekserów dla wyświetlania trybu, linków nadrzędnych i wyników na poziomie akcji.
• Dowody produkcyjne: Nazwany menedżer aktywów raportujący rzeczywisty wolumen partii i swoje kontrole rozliczeniowe.

FAQ