We welcome @FlareNetworks to the recommended XRP Ledger validator list published by the XRPL Foundation. Flare aligns with the core values of the @XRP Ledger, is actively participating in governance, and contributes to the broader ecosystem.

The XRP Ledger is no longer experiencing those occasional slower ledger closes following the publication of the recommended xrpld configuration. We are continuing to prepare a dot release for the community to address the behavior observed.

We've begun rolling out a recommended xrpld config change to hub, validator and node operators to address the issue for now. In parallel, we're testing fixes for a point release that will address the root cause. We'll continue updating the community as we progress.

This is still the case, and you may occasionally observe slower-than-usual ledger close times on the XRP Ledger. Outside of this, closing times are normal. We're aware of the issue and are finalizing a fix release targeting it as soon as possible.

Some ledger closings on the XRP Ledger are currently slower than usual, and ledgers can occasionally take longer to close. Outside of this closing times are normal. We have been actively investigating this and working on a fix since earlier today. We'll keep you updated!

XRP Ledger version 3.4.1 is now the minimum required version after the recent amendments were activated. This release patched critical parts of the XRP Ledger. The vulnerability report can be found here: Public release notes:

xrpld 3.4.1 is being released with a Batch fix and stability improvements. We’re asking validators and node operators to upgrade as soon as possible. There has been no impact to mainnet, and no loss of funds. There is also a new fix amendment, fixBatchV1_2, which addresses a minor issue with Batch that does not pose a risk to funds. The amendment is marked as Default Yes. Both Batch and the fix amendment are in the activation period and set to activate in 2 weeks. A detailed technical report will be shared after the fix amendment has been activated.

XRP Ledger version 3.4.0 is now available ✅ New amendments for voting: - Lending Protocol v1.1 - closed-ended vaults and cash-basis accounting. - fix Cleanup - bundled fixes. Performance and Stability: - Online delete now pauses on ledger history gaps, so nodes stay closer to the tip. - Peer protocol hardening and faster MPT freeze checks. Packages have moved to with an XRPLF signing key. Nodes on 3.3.0 or earlier must update their repo config. Release blog post:

Formal Verification for the XRP Ledger Lending Protocol. The Lending Protocol (XLS-66) and Single Asset Vaults (XLS-65) are not smart contracts. They are native financial logic inside xrpld. FV raises assurance above ordinary testing. Specify the behavior that must always hold, prove it in a machine-checked model, and keep that model aligned with the production code. In depth thread why @CommonPrefix picked Lean 4 to perform FV on XRPL. ICYMI: Formal Verification is part of the new security approach to amendments -

Run an XRP Ledger node/validator? I need just a few minutes of your experience. Fill in the operator survey here👇 and help shape the new XRPL node documentation for aimed at builders and enterprises.

The Batch V1.1 amendment shipped in xrpld 3.3.0 and is now up for voting. After the v1.0 signature bug was caught in February (pre-Mainnet, no funds at risk), we rebuilt it: root-cause fix, 4 senior reviewers, a Sherlock attackathon, and audits from Halborn and Common Prefix. We also fixed a few other bugs our new AI red-teaming efforts caught along the way. What changed and why it's ready: Atomic transactions on the XRPL, no smart contracts needed. Try it on Devnet today.

Lending v1.1 ships in XRPL 3.4.0 Join us on why it matters, what's new, and what it unlocks. • @angell_denis CTO, XRPLF • @ja_akinyele Head of Engineering, RippleX • @jazzicoop Head of Product, RippleX • @v_tumas Senior Software Engineer, RippleX

The same technology that just let Claude formalize Fermat's Last Theorem is also being used to formally verify the XRP Ledger. We're working with @CommonPrefix to prove, mathematically, that XRPL's most critical parts do exactly what we expect them to do.

The refreshed is now live. New design. Clearer paths for institutions, developers, community members, and newcomers to learn about the XRP ecosystem. Find developer resources and explore use cases across payments, tokenization, trading, and more. See what's new:

Please update your XRPL nodes to 3.3.0! Over 60% of $XRP Ledger nodes have already been updated to version 3.3.0. This version includes, among other improvements, the feature amendments Batch, Dynamic MPT, Permission Delegation, Sponsor, and Confidential Transfer, as well as a fix bundle.

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of manifests from unknown validator keys. 3.2.1 adds four limits: 1) Size cap per manifest - any single manifest larger than expected is rejected. 2) Receive cap - incoming batches over the limit are discarded, instead of breaking the peer connection. 3) Send cap - the bulk manifest greeting sent to each new peer is now bounded. 4) Cache cap - once 100 unknown keys are held, new ones are refused. We also no longer persist manifests from unknown keys to disk, so a flood cannot survive a restart. Please update immediately by following these steps: 1) Update normally to XRPL 3.2.1 2) Wait 1–2 min, confirm xrpld is running, it does not need to be in status full or proposing. 3) Restart xrpld again - very important.