Ripple informuje, że zarządzający aktywami przygotowują się do korzystania z typu transakcji Batch w XRP Ledger — funkcji, która pozwala kilku działaniom w księdze powieść się lub niepowodzenie łącznie. Awaryjna aktualizacja oprogramowania przesunęła jednak uwagę z oczekiwanej aktywacji 29 września na poprawkę bezpieczeństwa 9 października. Sama funkcja jest konkretna — i równie konkretny jest dowód, że adopcja instytucjonalna pozostaje prospektywna.

Główna obietnica jest prosta: powiązane kroki mają się rozliczyć w ramach jednego zamknięcia księgi. Zarządzający aktywami, który musi dostarczyć token i otrzymać płatność, może preferować wymianę all-or-nothing zamiast wysyłania najpierw aktywa i liczenia na to, że pieniądze dotrą. Rozliczenie obu stron wymiany w jednym kroku to długą tradycję mająca dyscyplina delivery-versus-payment w tradycyjnych rynkach papierów wartościowych, a Batch ma zapewnić jej wersję natywną dla księgi. RippleX opisał zarządzających aktywami i projekty komercyjne przygotowujące się do tej funkcji, co opisano we wcześniejszym raporcie o zainteresowaniu instytucjonalnym. Wtym opracowaniu nie wskazano publicznie produkcyjnego zarządzającego aktywami z aktywną transakcją Batch na mainnecie.

JUST IN: Brad Garlinghouse highlights why Ripple cannot control the $XRP Ledger Ripple operates only a small share of XRPL validators, and the $150M+ hack involving co-founder Chris Larsen showed that the company cannot reverse transactions or recover lost $XRP . pic.twitter.com/Pt4czYNSf1 — crypto.news (@cryptodotnews) September 27, 2026

Termin zmienił się przed pierwotnym oczekiwaniem końca września. Komunikat XRPL Foundation o wydaniu opisuje wersję 3.4.1 jako awaryjną aktualizację dotyczącą kwestii wrażliwych bezpieczeństwowo. Dodaje ona fixBatchV1_2, wzywa serwery do szybkiej aktualizacji i informuje, że poprawka miała się aktywować 9 października, jeśli utrzyma się poparcie superwiększości. Aktywacja poprawki w XRP Ledger zależy od rozproszonego głosowania walidatorów, a nie od jednostronnej decyzji, więc termin wynika od operatorów sieci, a nie od jakiejkolwiek pojedynczej organizacji. To oczekiwanie warunkowe, a nie stała obietnica startu.

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. Zainteresowane konta zatwierdzają zbiór, a wybrany tryb steruje tym, co dzieje się, gdy działanie wewnętrzne zawiedzie. Księga przetwarza zbiór w jednym zamknięciu, eliminując lukę między niezależnymi przesłaniami, która mogłaby pozostawić jedną ze stron z połową transakcji.

Załóżmy, że fundusz przenosi tokenizowane Roszczenie obligacyjne i otrzymuje token dolara. Dwie zwykłe transakcje mogłyby zostać przesłane osobno; jeśli pierwsza się powiedzie, a druga zawiedzie, strony stają przed sporem operacyjnym i potencjalną stratą. W trybie all-or-nothing oba działania wewnętrzne muszą się powieść, aby zamierzona wymiana została zrealizowana. To najbardziej przekonujący przypadek instytucjonalny — 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 off-chain ani nie zmusza banku do wykupu tokena płatniczego. Koordynuje działania w księdze. Prawna ostateczność rozliczenia, ograniczenia transferu, depozyt i wykup nadal zależą od odpowiednich instrumentów i instytucji. To rozróżnienie ma znaczenie, bo technicznie atomowy transfer to tylko część zasady delivery versus payment.

JUST IN: $XRP Ledger's Batch feature passes, set for activation on September 29 The upgrade, which has secured 29 Yes votes, will allow up to 8 XRPL transactions to be bundled into one, enabling atomic asset swaps, bundled DEX trades, $NFT -for- $NFT exchanges and single-transaction… pic.twitter.com/7CH34N1at — crypto.news (@cryptodotnews) September 15, 2026

Poradnik dla pojedynczego konta pokazuje prostszy przypadek: wiele działań z jednego konta można spakować w określonym trybie. Transakcje wielokontowe dodają podpisy kont, których salda lub uprawnienia są objęte. Poradnik wielokontowy opisuje ten skoordynowany proces podpisywania.

Cztery tryby to cztery różne układy

ALLORNOTHING to czysta dwustronna transakcja: każde wymagane działanie wewnętrzne musi się powieść, inaczej zamierzona grupa nie zostanie rozliczona. ONLYONE próbuje alternatyw i zatrzymuje się po pierwszym sukcesie, na przykład zleceń o różnych tolerancjach. UNTILFAILURE przetwarza sekwencję aż do niepowodzenia. INDEPENDENT pozwala działaniom w tym samym opakowaniu powieść się lub zawieść niezależnie. Nazywanie wszystkich czterech trybów atomowymi w potocznym znaczeniu ukrywałoby możliwość częściowej realizacji.

Tryby zmieniają projekt produktu. Fundusz przenoszący dwa aktywa wobec jednej płatności musi zdecydować, czy pojedynczy nieudany transfer powinien anulować cały pakiet. Market maker wysyłający oferty rezerwowe może preferować ONLYONE. Emitent rozdzielający wiele wypłat może tolerować niezależne wyniki, ale jego zespół operacyjny będzie musiał uzgodnić, którzy odbiorcy zostali opłaceni. Wybór trybu to decyzja o ryzyku, a nie kwestia formatowania.

Limit ośmiu działań to kolejna realna ograniczenie. Zarządzający próbujący rozliczyć 1 000 transferów inwestorów nie może zapakować wszystkich 1 000 w jeden Batch w ramach obecnej propozycji. Przy teoretycznym minimum 125 pakietów po osiem działań te grupy same w sobie nie byłyby względem siebie atomowe. Opłaty, podpisy, zarządzanie sekwencją kont i przepustowość usług stają się praktycznymi ograniczeniami, zanim jeszcze uwzględni się proces biznesowy off-chain.

Wcześniejszy raport techniczny odnotował długi rozwój i historię audytów tej aktualizacji. To tło ma znaczenie dla harmonogramu, ale nie należy go mylić z twierdzeniem, że każda zbudowana na tym aplikacja została poddana audytowi.

Zewnętrzny kod sukcesu to pułapka księgowa

Specyfikacja mówi, że zewnętrzna transakcja Batch może zgłosić tesSUCCESS nawet gdy transakcje wewnętrzne zawiodą; jej zewnętrzny wynik obejmuje przetwarzanie sekwencji i opłat. Aby wiedzieć, czy płatność czy dostawa nastąpiły, oprogramowanie musi sprawdzić metadane transcji wewnętrznych i poszczególne kody wyników. To wyjątkowo konkretna pułapka integracyjna dla każdej instytucji, której back office przekłada ogólny status sukcesu na zaksięgowany ruch aktywów.

Wyobraźmy sobie feed transakcyjny, który czyta tylko wynik zewnętrzny i uznaje klienta tokenizowanym papierem wartościowym. Jeśli odpowiedni transfer wewnętrzny nie doszedł do skutku, feed i księga rozjeżdżają się. System musi powiązać każde działanie wewnętrzne z jego rodzicem i własnym wynikiem. Specyfikacja zaleca korzystanie z relacji ParentBatchID w eksploratorach i indekserach, a biuro powinno testować niepowodzenia w każdym trybie, nie tylko ścieżkę optymistyczną.

Błąd może przetrwać zwykłe kontrole, bo transakcja zewnętrzna jest realna i ma identyfikator transakcji. System uzgadniania oparty na założeniu, że jedna transakcja to jedno działanie biznesowe, może przejść pierwszą kontrolę. Właściwa kontrola łączy instrukcję biznesową z trybem, kompletnym podpisanym pakietem, każdym wynikiem wewnętrznym i końcowymi stanami aktywów — to praca, którą zarządzający aktywami musi wykonać nawet jeśli warstwa sieciowa działa poprawnie.

JUST IN: Asset managers are preparing for $XRP Ledger's next payments upgrade Batch V1.1 can bundle up to eight transactions into one operation, with RippleX saying commercial projects are already being built around the feature ahead of activation. pic.twitter.com/DmleX4GBiA — crypto.news (@cryptodotnews) September 20, 2026

Arytmetyka jest skromna, ale wymowna. Maksymalny Batch z ośmioma transakcjami wewnętrznymi to jedna przesłanka zewnętrzna, a może wymagać co najmniej ośmiu sprawdzeń wyników, plus sprawdzenia opłaty i sekwencji zewnętrznej. Dla 125 pełnych pakietów reprezentujących 1 000 działań wewnętrznych back office potrzebuje 1 000 wyników na poziomie działań, a nie 125 zielonych świateł.

Poprawka bezpieczeństwa zmienia historię aktywacji

Komunikat fundacji z 25 września mówi, że fixBatchV1_2 odrzuca transakcje wewnętrzne o niewłaściwym opakowaniu i zawiera dodatkowe poprawki bezpieczeństwa i stabilności. Kod źródłowy jest tymczasowo wstrzymany ze względu na wrażliwy bezpieczeństwowo charakter zmiany, z obietnicą publikacji i analizy powydarzeniowej później. To ogranicza możliwość zbadania dokładnej łatki przez osoby zewnętrzne przed ujawnieniem. Takie tymczasowe wstrzymanie kodu to powszechna praktyka skoordynowanego ujawniania luk w branży oprogramowania. To powód do precyzyjnego przypisywania faktów, a nie powód do spekulacji o nieujawnionej podatności.

Zgodnie z komunikatem serwery poniżej 3.4.1 zostałybyablokowane względem poprawki, jeśli ta się aktywuje, zanim je zaktualizują. Głosy walidatorów i aktualizacje węzłów mają więc znaczenie dla dostępu produkcyjnego. Kworum sygnalizujące poparcie to nie to samo, co gotowość każdego portfela, depozytariusza, dostawcy API i narzędzia księgowego na Batch. Wcześniejsze doniesienia o aktualizacji węzłów XRPL ilustrowały operacyjny skutek blokady poprawki w poprzednim wydaniu.

Jest też historia, której nie można pominąć. Lutowe ujawnienie podatności opisywało błąd we wcześniejszym projekcie Batch, który mógł pomijać kontrole autoryzacji dla innych podpisujących, gdy nieopłacony podpisujący pojawiał się pierwszy; poprawka nie była wtedy aktywna. Relacja z audytu bezpieczeństwa pokazywała, jak niezależny przegląd wychwycił problemy przed użyciem produkcyjnym. Wrześniowa łatka dotyczy osobno opisanego problemu z opakowaniem; żadne z tych wydarzeń nie dowodzi, że obecny projekt jest niebezpieczny, ale oba wyjaśniają, dlaczego termin wdrożenia zasługuje na wnikliwość.

Co instytucje mogą zyskać i czego jeszcze potrzebują

Atomowe delivery versus payment to najmocniejszy przypadek. Zarządzający mógłby skoordynować transfer tokena z płatnością w tej samej księdze, ograniczając przejściową ekspozycję tworzoną przez transfery sekwencyjne. Emitent mógłby pakować kroki zakładania konta, autoryzacji i emisji tam, gdzie protokół na to pozwala. Firmy handlowe mogłyby korzystać z alternatywnych ścieżek wykonania. To możliwości, a nie dowód na żywe aktywa i transakcje.

Tokenizowane aktywa wymagają emitentów, agentów transferu lub innych podmiotów, zasad dotyczących uprawnionych posiadaczy, procedur depozytowych i instrumentu płatniczego o akceptowalnych warunkach wykupu. Batch może sprawić, że on-chainowe nogi wykonają się według wybranej reguły. Nie może uczynić papieru wartościowego prawnie ważnym w innej jurysdykcji, uzyskać zgody klienta na niezwiązane działanie ani zagwarantować zewnętrznej nogi gotówkowej w banku komercyjnym. Szerokim tłem są trwające eksperymenty branży zarządzania aktywami z tokenizowanymi funduszami i obligacjami, które sprawiają, że mechanika rozliczeń pozostaje powracającym pytaniem operacyjnym, zanim jeszcze pojawią się wolumeny produkcyjne.

Przypadek Rippala zasługuje na swoją najsilniejszą wersję Mechanizm na poziomie księgi może zmniejszyć pracę koordynacyjną deweloperów i wyeliminować realną klasę częściowych niepowodzeń rozliczenia. Przegląd funkcji XRPL opisywał Batch obok innych funkcji instytucjonalnych, choć każda poprawka przechodzi własny proces. Jeśli wskazani zarządzający pokażą później żywe, powtarzalne rozliczenia realnych tokenizowanych aktywów z poprawnie uzgodnionymi wynikami wewnętrznymi, twierdzenie o adopcji będzie miało twarde dowody.

Granica jest równie jasna. Firma przygotowująca pilotaż to nie zarządzający aktywami używający Batch w produkcji. Żadne publiczne twierdzenie o przygotowaniach nie ujawnia wolumenów, zaoszczędzonych opłat, zapobiecanych sporów rozliczeniowych ani tego, która instytucja przyjmuje zobowiązania off-chain. Ogłoszenie może być prawdziwe, a mimo to za wczesne, by uzasadnić te większe wnioski.

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

Oczekiwana aktywacja fixBatchV1_2 9 października zależy od utrzymującego się poparcia walidatorów. Operatorzy muszą uruchamiać zgodne oprogramowanie. Portfele muszą pokazywać użytkownikom wszystkie działania wewnętrzne i wybrany tryb przed zebraniem podpisu, zgodnie z zaleceniem specyfikacji. Indeksery muszą ujawniać wyniki rodzica i dzieci. Depozytariusze potrzebują kontroli zasad dla podpisów wielokontowych. Zarządzający aktywami potrzebują uzgadniania 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ć, zbadać i odzyskać się z nieudanego Batch bez rozbieżnych zapisów. Bez odpowiedzi pozostaje pytanie komercyjne: która wskazana instytucja pokaże powtarzalny przypadek użycia, gdy poprawka i narzędzia będą żywe.

Na co zwracać uwagę

• Status poprawki: Czy fixBatchV1_2 utrzyma poparcie i aktywuje się w oczekiwanym terminie 9 października.
• Aktualizacje serwerów: Odsetek operatorów uruchamiających 3.4.1, zanim poprawka bezpieczeństwa stanie się obowiązkowa.
• Ujawnienie: Publikacja wstrzymanego kodu źródłowego łatki i obiecanej analizy powydarzeniowej.
• Wyniki wewnętrzne: Wsparcie portfeli i indekserów dla wyświetlania trybu, powiązań rodzica i wyników na poziomie działań.
• Dowody produkcyjne: Wskazany zarządzający aktywami raportujący żywy wolumen Batch i swoje kontrole rozliczeniowe.

FAQ

Czy XRPL Batch jest już żywy na mainnecie?

Odpowiednie poprawki i ich status na żywo trzeba sprawdzić w momencie publikacji. Wydanie z 25 września opisywało poprawkę bezpieczeństwa, która miała się aktywować 9 października, jeśli utrzyma się poparcie walidatorów.

Ile transakcji może zawierać Batch?

Opubowana specyfikacja XLS-0056 ustanawia minimum dwie i maksimum osiem transakcji wewnętrznych w obecnym projekcie.

Czy Batch gwarantuje powodzenie każdego działania wewnętrznego?

Tylko tryb all-or-nothing jest zaprojektowany wokół wspólnego powodzenia całej grupy. Inne tryby celowo dopuszczają inny wzorzec częściowego wykonania.

Czy jeden zarządzający może podpisywać za każdego kontrahenta?

Nie. W wielokontowym Batchu objęte konta muszą zatwierdzić podpisany zbiór zgodnie z zasadami podpisywania protokołu.

Czy tesSUCCESS oznacza, że transakcja się rozliczyła?

Nie samo w sobie. Wynik zewnętrzny może być pomyślny, gdy działanie wewnętrzne zawiedzie, więc systemy muszą sprawdzić każdy wynik wewnętrzny i końcowe salda.

Czy Batch uczyni tokenizowane papiery wartościowe prawnie rozliczonymi?

Może koordynować kroki on-chain. Prawa, wykup i każda zewnętrzna noga płatnicza nadal zależą od warunków aktywa i stosownej infrastruktury.

Co zmieniło się w wersji 3.4.1?

Fundacja opisała awaryjne wydanie bezpieczeństwa dodające fixBatchV1_2, w tym odrzucanie transakcji wewnętrznych o niewłaściwym opakowaniu.

Czy zarządzający aktywami pokazali żywe użycie?

Ripple informował o przygotowaniach, ale wskazane publiczne opracowanie nie wymieniło produkcyjnego zarządzającego z powtarzalnym, żywym rozliczeniem Batch.

To analiza edukacyjna, a nie porada inwestycyjna. Ten artykuł ma charakter wyłącznie informacyjny i edukacyjny i nie stanowi porady finansowej ani inwestycyjnej. Dane odzwierciedlają zgłoszenia regulacyjne i relacje dostępne w chwili pisania i zmieniają się z każdym ujawnieniem. Nic tutaj nie jest rekomendacją kupna, sprzedaży ani utrzymywania jakiegokolwiek papieru wartościowego lub aktywa. Zawsze prowadź własne badania. Informacje są aktualne na 29 września 2026 roku.