Ang mga developer ng XRP Ledger ay naglabas ng xrpld bersyon 3.3.0 noong Agosto 6, inilalapit ang ilang pagbabago sa protocol sa posibleng pag-activate ng mainnet.
Kinumpirma ng opisyal na release ng GitHub ang paggawa sa ConfidentialTransfer, BatchV1_1, Sponsor at DynamicMPT, kasama ang mga pag-aayos at iba pang pagbabago sa protocol. Ang software release mismo ay hindi nag-a-activate ng mga feature na ito sa network.
Mahalaga ang pagkakaiba dahil inilalarawan ng ilang ulat ang anim na upgrade bilang aktibo na. Sa ilalim ng proseso ng pag-amyenda ng XRP Ledger, ang mga bagong feature ng protocol ay nangangailangan ng suporta ng validator bago ang pag-activate. Kailangan ng isang amyenda na panatilihin ang higit sa 80% na suporta mula sa mga pinagkakatiwalaang validator sa loob ng dalawang tuloy-tuloy na linggo bago magkabisa.
Ang ConfidentialTransfer ay idinisenyo upang magdagdag ng privacy para sa Multi-Purpose Tokens, o MPTs. Sinasabi ng dokumentasyon ng XRPL na ginagamit ng amyenda ang cryptography upang protektahan ang mga indibidwal na balanse at halaga ng paglilipat habang pinapanatili ang mga mekanismo na nagpapahintulot sa mga awtorisadong partido, kabilang ang mga issuer o auditor, na i-verify ang impormasyon na kinakailangan para sa compliance.
Ang feature ay nananatiling sakop ng pag-activate ng amyenda, kaya hindi pa dapat ilarawan ang mga pribadong paglilipat ng MPT bilang aktibo sa XRPL mainnet.
Ang BatchV1_1 ay isa pang pangunahing bahagi. Ang pamantayan ng XLS-56 ay nagbibigay-daan sa maraming transaksyon na mapagsama-sama at maproseso nang sabay-sabay, kabilang ang mga transaksyon na kinasasangkutan ng iba't ibang account. Ang atomic execution ay makakatulong sa mga settlement workflow kung saan kailangang magtagumpay ang ilang aksyon nang sabay-sabay sa halip na iwanan ang isang bahagi na natapos habang ang isa pa ay nabigo.
Ang Batch ay may mahalagang kasaysayan. Ang isang naunang bersyon ay na-disable bago ang pag-activate ng mainnet matapos matuklasan ang isang isyu sa seguridad sa logic ng pag-sign ng transaksyon. Kalaunan ay lumipat ang XRPL Foundation patungo sa BatchV1_1 bilang kinorektahang kapalit. Gaya ng naunang naiulat sa security coverage ng XRPL, pinalakas ng mga developer ang pormal na pagsusuri sa mga kamakailang upgrade.
Ang Permission Delegation ay sumunod sa katulad na landas. Inihayag ng XRPL noong Setyembre 2025 na ang isang bug sa naunang amyenda ay maaaring nagpahintulot sa isang hindi awtorisadong transaksyon na maningil ng bayarin sa ibang account sa ilalim ng tiyak na mga kondisyon. Pinayuhan ang mga validator na bumoto ng hindi, at ang vulnerable na feature ay hindi kailanman na-activate. Binuo ang PermissionDelegationV1_1 bilang kapalit nito.
Ang binagong konsepto ay nagpapahintulot sa isang account na magbigay ng tinukoy na mga pahintulot sa transaksyon nang hindi ipinapasa ang pangunahing private key nito, sumusuporta sa mga operational wallet na may limitadong awtoridad.
Ang Sponsor, batay sa XLS-68, ay idinisenyo upang pahintulutan ang ibang account na magbayad ng mga bayarin sa transaksyon o mga kinakailangan sa reserba habang pinapanatili ng user ang kontrol sa account at mga key. Maaaring payagan ng feature ang mga aplikasyon na mag-onboard ng mga user nang hindi kinakailangan na kumuha sila ng XRP para lamang matugunan ang mga gastos sa network. Malinaw na sinusuportahan ng panukalang XLS-68 ang sponsorship ng bayarin at reserba habang pinapanatili ang kontrol ng user sa key.
Ang DynamicMPT ay para sa mga token issuer. Ang panukalang XLS-94 ay nagpapahintulot sa mga issuer na magtalaga ng mga napiling katangian ng MPT bilang mutable kapag gumagawa ng token, pagkatapos ay i-update ang mga pinapayagan na field sa paglaon. Ang pamantayan ay inilaan upang iakma ang nagbabagong pangangailangan ng negosyo o compliance nang hindi ginagawang malayang i-edit ang bawat katangian ng token.
Sama-sama, ang mga feature na ito ay akma sa lumalaking pokus ng XRPL sa tokenized finance. Sa kaugnay na coverage ng tokenization, iniulat ng crypto.news na sinubukan ng JPMorgan, Mastercard, Ondo Finance at Ripple ang isang tokenized Treasury redemption gamit ang XRPL.
Kinakailangan ang isang pagwawasto tungkol sa malawakang kumakalat na "anim na upgrade." Ang fixCleanup3_2_0 ay kabilang sa naunang xrpld 3.2.0 cycle, hindi sa bagong inilabas na 3.3.0 feature package. Sa halip, ipinapakita ng 3.3.0 GitHub changelog ang paggawa sa LendingProtocolV1_1 at isang hiwalay na fixCleanup3_3_0 track kasama ang mga pangunahing feature.
Samakatuwid, ang release ay hindi dapat basahin bilang anim na tapos na kakayahan na nagiging available nang sabay-sabay. Ito ay isang milestone ng server-software na nagbibigay sa mga validator at operator ng code na kailangan para sa mga desisyon sa amyenda. Ang mga indibidwal na amyenda ay maaaring magkaroon ng iba't ibang timeline ng pagboto at maaaring mabigo na ma-activate kung ang suporta ay bumaba sa kinakailangang threshold.
Mahalaga na ang proseso ng pamamahala na ito ay dati nang nagpapakita ng halaga. Ang orihinal na mga amyenda ng Batch at Permission Delegation ay itinigil matapos matukoy ang mga bug bago ang mainnet activation, na nagpapakita na ang pagsasama sa software o pagboto ng validator ay hindi katulad ng production deployment.
Kailangan na ngayong suriin ng mga node operator ang bersyon 3.3.0 at magpasya kung ia-upgrade at susuportahan ang mga indibidwal na amyenda. Ang eksaktong mga petsa ng pag-activate ay depende sa pagboto ng validator, sa halip na ang software release noong Agosto 6. Ang mga tuntunin ng amyenda ng XRPL ay nangangailangan ng supermajority na magpatuloy nang tuloy-tuloy sa loob ng dalawang linggo.
Para sa mga may hawak ng XRP, ang agarang pagbabago ay teknikal sa halip na pinansyal. Pinapalawak ng Bersyon 3.3.0 ang potensyal na toolkit ng network para sa privacy, multi-step settlement, delegated authority, sponsored onboarding at configurable token issuance, ngunit wala sa mga ito ang gumagarantiya ng mas mataas na demand ng XRP o pagtaas ng presyo.
Ang susunod na mapapatunayan na mga milestone ay ang pag-aampon ng validator sa 3.3.0, mga antas ng suporta sa amyenda at mga nakatakdang petsa ng pag-activate. Hanggang matugunan ang mga threshold na iyon, ang mga bagong kakayahan ay dapat ilarawan bilang inilabas sa node software at gumagalaw sa pamamahala, hindi bilang ganap na aktibong mga feature ng XRP Ledger mainnet.
Ang mga desisyon ng validator, sa halip na marketing ng release, ang magpapasya kung kailan magiging magagamit ang bawat feature sa mainnet.
