XRP Ledger Gets Major Software Upgrade; Here’s What Changed

XRP Ledger developers have announced the release of rippled 2.0, an update that introduces two new feature amendments: XLS-38 Cross-Chain Bridge and XLS-40 Decentralized Identity.

Aside from this, there are fix amendments as well as numerous other improvements.

New amendments

There are two new feature amendments, as stated above: the XLS-38 Cross-Chain Bridge will allow XRP and fungible tokens issued on the XRPL to flow between the XRPL Mainnet and the XRPL Sidechains, as well as between the XRPL Mainnet and the planned EVM sidechain.

The Cross-Chain Bridge is protected by independent witness servers, which certify any transactions that cross chains.

The XRP Ledger developers have released the latest version of the`rippled`software, version 2.0. This code powers the core #XRPL.

This update introduces:
1️⃣ XLS-38 Cross-Chain Bridge
2️⃣ XLS-40 Decentralized Identity
3️⃣ Core ledger updates
4️⃣ API version 2https://t.co/eg2HSrpE4N

— RippleX (@RippleXDev) January 10, 2024

XLS-40 Decentralized Identity (DID) is a system that allows users to have complete control over their online identity in a self-sovereign way.

The XLS-40 DID implementation will be interoperable with any distributed ledger or network and will leverage the World Wide Web Consortium (W3C) standard to enable verified, self-sovereign digital identification.

XLS-40 is a lightweight amendment that adds a new ledger object. This object can be created, updated and deleted by associated transactions.

The new software release also incorporates API updates. API v2 has been released, which cleans up the API by removing obsolete fields and methods, renaming fields that were frequently misread and increasing response consistency.

A few issues arose, such as those with authorized trustlines as well as a combination of flags when an exchange rate on an offer differs from the order book rate. These were categorized as core ledger updates.

To add new features to the XRPL Mainnet, XLS specs involving breaking changes to the core protocol must go through an amendment procedure in which the validator community votes on the feature.

For an amendment to pass, at least 80% of validators must vote “yes” or “accept” on the amendment. This level must be maintained for a minimum of two weeks.

If both conditions are met, the amendment will take effect, and the functionality described in the XLS standard will become live on mainnet. This procedure is followed for each amendment separately.

Source