The XRP Ledger Foundation has added Flare to its recommended validator list and removed Anodos Finance at its own request, with the foundation and Ripple now publishing matching sets of 35 validator keys.
Summary
- Flare has joined the foundation’s recommended list, which contains 35 validator keys at the reporting cutoff.
- Ripple’s published list contains the same 35 keys, including the entry associated with Flare’s validator domain.
- Anodos requested removal as it prepares to shut down its XRP Ledger validator this month.
- Flare’s existing FXRP services include vault deposits and borrowing RLUSD against XRP-linked collateral.
XRP Ledger Foundation said in its announcement that Flare participates in XRPL governance and contributes to the ecosystem, while a separate post attributed Anodos’ removal to its decision to retire its validator by the end of October.
XRP Ledger lists contain the same 35 validators
“We welcome Flare to the recommended XRP Ledger validator list,” the foundation wrote. Its accompanying explanation cited Flare’s alignment with XRPL’s core values and participation in governance. In the second post, the organization thanked Anodos for its contributions and collaboration with the XRP ecosystem.
A direct examination of the foundation’s published validator-list payload found 35 entries under sequence number 2026102701. Ripple’s separately published payload, carrying sequence number 86, contained the same 35 validation public keys when checked for this report.
Comparing the two sets produced 35 shared entries and no keys unique to either publisher. Both payloads included a validator manifest containing the domain xrpl-verification.flare.network.
The comparison measures membership in the published lists; it does not establish which configuration every individual server operator uses. The records were checked at approximately 8:35 p.m. UTC on Oct. 28, or 2:05 a.m. IST on Oct. 29.
XRPL’s technical documentation says the default server configuration uses recommended lists from both the foundation and Ripple. A server using multiple publishers combines their lists, counting a validator appearing on both only once. The documentation notes that the two publishers’ lists are typically similar or identical.
Server operators choose whom they trust
According to XRPL’s documentation, a Unique Node List determines which validators’ votes a server considers during consensus. Operators control their own lists, although the documentation says substantial overlap between servers’ trusted validators is necessary to avoid disagreements over validated ledgers.
List publishers select the validators they recommend but do not perform day-to-day transaction validation through that publishing role, XRPL’s documentation explains. Publishers set their own inclusion criteria and update recommendations to add reliable operators or remove those retiring from service.
XRPL’s FAQ describes recommended-list selection as relying on past performance, verified identities, and responsible IT practices. The FAQ says validators group transactions into ordered units and agree on their ordering to prevent double spending; running a validator does not require paying a fee or holding XRP.
On incentives, the FAQ states that validators receive no XRP rewards for operating their servers. It identifies network reliability and stable development as reasons businesses using XRPL may choose to run validators. The foundation’s posts did not announce a payment, grant, or FXRP product launch alongside the membership changes.
Flare’s FXRP services predate its list inclusion
Flare’s work with XRP-based decentralized finance began before the validator announcement. As crypto.news previously reported, Flare activated FXRP on mainnet in September 2025, starting with version 1.2 of its FAssets protocol and a first-week minting cap of 5 million FXRP.
In its original launch announcement, Flare described FXRP as a one-to-one representation of XRP secured by an overcollateralized system of independent agents and its native data protocols. Once minted, the token could be integrated into lending markets, decentralized exchanges and other applications on Flare, according to that announcement.
By July 28, Flare had introduced single-signature vault deposits through Smart Accounts v1.3. Flare’s release said the update combined two previously separate XRPL signatures into one, allowing users to mint FXRP and deposit it into a selected vault without managing a separate EVM wallet or gas token.
The company’s July documentation explains that an XRPL transaction memo encodes the requested action. Flare Data Connector proves the transaction on Flare, where a smart contract mapped to the XRPL address executes the instruction. Supported connections listed in that release included D’CENT, Xaman, Joey Wallet, Ledger and WalletConnect.
FXRP collateral supports RLUSD borrowing on Ethereum
On Aug. 3, Flare announced that Sentora had accepted FXRP as collateral in its RLUSD Main vault on Morpho. An Aug. 4 report detailed the FXRP-backed RLUSD borrowing route, which lets holders borrow Ripple’s dollar stablecoin against their XRP-linked position.
Flare’s announcement described an Ethereum-based process: users mint FXRP, bridge it to Ethereum, supply it to the specific Morpho market, and borrow RLUSD within that market’s loan-to-value limit. Interest changes with utilization, and liquidators can repay debt and claim collateral if a position crosses its liquidation threshold, according to the release.
RLUSD launched in December 2024 under a New York Department of Financial Services limited-purpose trust company charter, Ripple said in its launch announcement. Ripple described the stablecoin’s backing as dollar deposits, U.S. government bonds and cash equivalents, with monthly third-party reserve attestations.
In an Oct. 6 update, Flare said Firelight had gone live with cover for Sentora’s USD Protected Vault and Protected RWA Vaults. Its description says FXRP stakers supply the capital backing covered vaults, with eligible events reviewed by a five-firm Risk Consortium. Flare states that staked capital and compounded rewards are subject to slashing, and withdrawals must accommodate the protocol’s coverage periods.