Skip to content
FAssets logo
Flare svg 2025 - Bitgo resize
Back to All News

How FAssets evolves in v1.3

Flare Updates

FAssets brings assets like XRP into DeFi through a collateralized, rule-based architecture.

Version 1.3 updates that architecture with a more direct minting path, simpler routing into FXRP, clearer controls around mint execution and flow, and a design that moves FAssets closer to its longer-term direction.
Recent bridge incidents have made these design questions more visible across the market. That makes this a good time to explain how FAssets works today, what changes in v1.3, and where those changes sit within the broader system.

FAssets today

Minted FAssets are backed by agent-posted collateral locked in smart contracts.

v12flow

Positions are monitored against the required Collateral Ratio (CR), challenged with proofs when violations occur, and supported by graduated emergency controls.

The protocol continuously measures each position against its required collateral ratio. If a position becomes unhealthy, liquidation can begin immediately by anyone.

The system also distinguishes between market-driven deterioration and protocol violations. Undercollateralization is handled through unhealthy-position liquidation. Non-permitted payments and similar violations can be challenged with FDC proofs and pushed into full liquidation.

Governance also has emergency controls with different scopes, so the protocol can respond proportionally rather than relying on a single binary shutdown.

What changes in v1.3

V1.3 sits between the current FAssets system and the later v2 architecture. It was already on the roadmap, but recent market events have made it more important to explain how the minting path is being updated.

The main change is in minting.

FAssets v1.3


In the current model, minting is tied to a chosen agent. In v1.3, users initiate minting by sending XRP to the core vault on XRPL, and an executor relays the proof to Flare to complete the mint.

That makes the minting path more direct. It removes mint-side bottlenecks tied to agent capacity, simplifies routing, and moves the system toward an architecture that can support broader access over time.
Agents remain essential on redemption, and the collateralized redemption model stays in place.

What v1.3 adds

A more direct minting path also requires clearer execution controls. V1.3 adds mechanisms around who can complete a mint, how mint proofs are used, and how larger flows are handled.
These include:

  • Executor restrictions: v1.3 can limit who is allowed to complete a minting flow, depending on how that mint is initiated.
  • Proof-use binding: The proof flow can specify who is permitted to present the proof, narrowing the scope for misuse around execution.
  • Hourly mint limits: Mint volume is capped over shorter time windows to moderate sudden spikes.
  • Daily mint limits: Broader daily caps help keep total system exposure within defined bounds.
    Large-mint thresholds: Mintings above a defined size are treated differently from ordinary flow.
  • Automatic delays for large mintings: Larger mintings are delayed rather than processed immediately through the normal fast path.

These mechanisms make the minting path more scalable in normal operation while keeping execution and flow governed by explicit rules as activity grows. 

Version 1.3 also matters beyond this release. A more direct minting path and clearer execution controls move FAssets toward a cleaner architecture for broader adoption.

That makes XRPFi easier to access through the channels users already trust, while keeping the protocol’s rules explicit as the system scales.

FAssets (FXRP) and FXRP OFT

Core FXRP / FAssets functionality on Flare is separate from FXRP’s OFT route.

The OFT route handles cross-network transfers, moving FXRP between Flare and other supported networks such as Base, HyperEVM, HyperCore and Monad. FAssets is the collateralized asset system on Flare, including minting, redemption, liquidation, collateral enforcement, and the changes introduced in v1.3.
That is why the recent OFT pause applied to cross-network transfers, not to core FAssets functionality on Flare.

Flare has also updated the FXRP OFT route separately. As reflected in the Flare Developer Hub, FXRP OFT routes are supported by four DVNs: LayerZero Labs, Nethermind, Canary, and Horizen. That work sits alongside the architectural changes introduced in FAssets v1.3.

Bridges still matter

Bridges still matter because liquidity, demand, and execution are distributed across networks. The question is not whether cross-chain systems should exist, but what kind of architecture they run on.
FAssets v1.3 moves that architecture forward with a more direct minting path, clearer execution controls, and better-defined handling for larger flows. That makes XRPFi easier to access without loosening the rules that hold the system together.
V1.3 will launch on Songbird first,continuing Flare’s practice of using its canary network as a live proving ground for protocol upgrades before mainnet deployment.