# Flare Wants XRP Holders to Do More Without Opening Another Wallet

> Flare’s Filip Koprivec explains why the next step for XRP is making yield and credit accessible from the wallet holders already use—and why simplifying the experience still requires painstaking work underneath.

By Lidia Yadlos · October 14, 2026

Canonical: https://blockster.com/flare-wants-xrp-holders-to-do-more-without-opening-another-wallet

The first problem Flare encountered after making XRP usable in DeFi was surprisingly ordinary: people did not want another wallet.

Moving an asset onto a new blockchain opened up possibilities. It also handed its owner a new set of chores. Set up an account. Find the right gas token. Learn which application to use. Work out how to get the money back.

For developers accustomed to moving between networks, those steps could seem routine. For someone who simply wanted to do more with their XRP, they were reasons to stop.

Speaking with Blockster’s Ivan Zhelev, Flare’s Filip Koprivec described how that experience changed the project’s priorities. Building a bridge was only the beginning. Flare also needed to carry the user’s instructions across it.

The ambition now is for an XRP holder to choose a financial action from a familiar wallet while Flare handles the operations behind it. Earning yield is already part of that experience. Bringing borrowing into the same flow is one of the next steps Koprivec outlined.

That puts a practical question at the center of Flare’s strategy: how much blockchain machinery should someone have to operate to use their own money?

## The Wallet Was the Obstacle

Flare’s FAssets system gives XRP a representation on Flare called FXRP. In the process Koprivec described, XRP is sent to a designated vault on the XRP Ledger, the transaction is verified, and FXRP is issued on Flare.

The asset can then interact with applications there. But the original experience still expected users to become comfortable with another chain.

“We quickly discovered that it’s crucial to allow people to start on XRPL and just treat Flare and the whole FXRP ecosystem as an abstraction,” Koprivec said.

Flare Smart Accounts address that problem by allowing instructions from the XRP Ledger to trigger actions on Flare. A holder can ask for XRP to be converted into FXRP and deposited into a supported vault as part of the same flow.

[Flare’s documentation](https://dev.flare.network/smart-accounts/overview) describes an account on Flare controlled through the user’s XRPL address. The Flare Data Connector verifies the relevant XRP Ledger transaction, allowing the account to execute the instruction. Users do not need to hold FLR to operate the service.

The distinction is practical. The holder is still using applications and contracts on another blockchain, but the familiar wallet remains the point of control.

> “You don’t have to leave your XRP wallet.”

— [Filip Koprivec](https://x.com/j00sko), [Flare](https://flare.network/)

Koprivec said withdrawal instructions can also begin on the XRP Ledger. The goal is to make entering and leaving a position understandable without requiring the user to reconstruct every intermediate step.

After working with developers and users, he said, the team had seen how difficult it was to persuade people to create another wallet and adopt another chain. A useful bridge had to take them all the way to the action they wanted to complete.

[Post from @FlareNetworks on X](https://twitter.com/FlareNetworks/status/2106957551837266298)

## A Mathematician’s Approach to Moving Money

Koprivec’s explanation of Flare’s architecture begins with his background in mathematics.

A blockchain system needs a broad design: what it should do, why it should exist and how its components fit together. It also needs someone to keep asking what happens in the cases that design has not yet accounted for.

“You can’t say, ‘Okay, we’ve covered most of the cases,’” he said. “You really have to make sure that the proof covers everything.”

That is the standard he brings to engineering, rather than a claim that a live protocol can be proven immune to failure.

For Flare, he said, it informed the decision to build data verification into the network’s architecture. A bridge depends on information about what happened somewhere else. A price-dependent financial application also depends on reliable prices. Koprivec’s argument is that those inputs deserve the same attention as the chain processing the transaction.

In his account, a fast bridge with an overlooked weakness leaves the whole system exposed at that point. Flare therefore chose to integrate the mechanisms that supply external data and prices into its network design.

The same thinking appears in how he describes the movement of XRP. The system checks transactions against the actions its contracts authorize, requires collateral from agents and can penalize agents that behave incorrectly.

It also limits what can happen if something goes wrong. Koprivec pointed to restrictions on the core vault, time-delayed movements and limits on minting and cross-chain transfers as ways to reduce exposure.

> “We really don’t want to have a huge honeypot on the XRP Ledger or anywhere.”

— [Filip Koprivec](https://x.com/j00sko), [Flare](https://flare.network/)

The emphasis is revealing. Even while expressing confidence in the architecture, he returned to containment: how much an attacker could extract, which actions a vault can perform and where a limit should stop activity.

For a holder deciding whether to move assets, those are more useful questions than a sweeping promise of security.

## Two Vaults, Two Different Decisions

The word “vault” can make this system sound simpler than it is.

Koprivec drew a distinction between the core vault that forms part of the FAssets mechanism and a DeFi vault a user selects afterward.

The first concerns the XRP supporting the bridge. The second concerns what the holder chooses to do with the resulting asset. Different applications offer different strategies, opportunities and risks.

Making the first stage easier does not settle the second decision. A user still needs to understand where a return comes from, what can cause a loss and how withdrawals work.

Firelight makes that distinction concrete. Koprivec highlighted its launch with Sentora as an example of XRP being used to supply capital for DeFi cover.

According to [Flare’s October 6 announcement](https://flare.network/news/firelight-is-live-backed-by-staked-fxrp-on-flare), Firelight’s initial cover applies to Sentora’s USD Protected Vault and Protected RWA Vaults. Holders can use Smart Accounts to mint FXRP and deposit it into Firelight from an XRPL wallet.

The deposited capital backs coverage for other vaults. Operators pay for that cover, funding rewards distributed to stakers.

That means the holder supplying capital is taking on risk. Flare says the staker’s deposit does not itself receive cover, and both deposited capital and accumulated rewards can be slashed. Withdrawals are also subject to an unstaking period associated with the coverage commitments.

Flare reported in the same announcement that FXRP had passed 150 million minted, with more than 90% deployed in onchain finance across seven networks.

Those figures show how far the asset has moved beyond a bridging demonstration. The next test is whether users can understand the financial position they are entering as easily as they can initiate the transaction.

[Post from @FlareNetworks on X](https://twitter.com/FlareNetworks/status/2107549228524306497/video/1)

## Borrowing Without Selling Is the Next Interface Challenge

Koprivec’s next objective is credit.

He described planned Smart Accounts improvements that would let holders borrow dollars against their XRP exposure without selling it. In the interview, he placed those improvements on the roadmap for later in 2026.

Borrowing against FXRP already has a precedent. As [Blockster reported in August](https://blockster.com/xrp-holders-can-now-borrow-rlusd-on-ethereum-using-fxrp), FXRP became usable as collateral to borrow RLUSD through a Sentora-curated market on Morpho on Ethereum.

That route involves minting FXRP, moving it to Ethereum and deploying it as collateral. The proposed Smart Accounts experience would bring more of those operations behind instructions originating from an XRP wallet.

The distinction matters when assessing what Flare is promising. Koprivec is describing a simpler route into credit, building on financial capabilities that already exist.

For someone who wants liquidity while retaining XRP exposure, that could remove several operational hurdles. The underlying borrowing position would still need managing. Blockster’s earlier coverage notes that the FXRP/RLUSD market has interest rates tied to utilization and collateral positions subject to liquidation thresholds.

A successful interface will need to make those obligations visible even as it handles the chain-to-chain activity in the background.

The account may become easier to use. The debt still belongs to the borrower.

## Bitcoin Brings a Longer Commitment

Koprivec also outlined plans to extend the approach to Bitcoin, connecting Flare Confidential Compute with a future FBTC offering and the possibility of credit, lending and yield.

Flare’s work on confidential compute already reaches beyond that roadmap. Blockster has covered its use on Songbird to [verify information about Hex Trust’s USDX backing without exposing private financial records](https://blockster.com/flare-lets-hex-trust-verify-usdxs-backing-without-revealing-private-financial-records). Koprivec’s Bitcoin comments describe another intended application, rather than confirmation that the full borrowing experience is available.

Adding a native asset is a substantial engineering commitment, he said. The system must correctly observe the underlying blockchain, account for its edge cases and continue maintaining that support.

That also explains why Flare does not attempt to rebuild every connection. For EVM networks and Solana, Koprivec said it uses LayerZero, alongside additional monitoring and work on transfer security.

Bringing in an asset such as Bitcoin calls for a different level of involvement. It means understanding another chain well enough to support it over time.

“There’s no sense in us bridging Bitcoin onchain and then at some point saying, ‘Oh, we’re not going to support it anymore,’” he said.

> “We would rather be very, very safe than just add chains one after another and forget something.”

— [Filip Koprivec](https://x.com/j00sko), [Flare](https://flare.network/)

That approach ties together the two sides of the interview: the desire to make the user’s experience simpler, and the insistence that someone still has to account for the details.

For Flare, the immediate opportunity is to let an XRP holder move from a decision—earn yield, withdraw, eventually borrow—to a completed action without assembling the process themselves.

Whether that experience earns lasting use will depend on more than the number of steps it removes. Holders will also need clear terms, dependable execution and a way to understand what their money is doing.

The bridge can recede from view. The financial decision should remain clear.