Add stFLR Feed to FTSO on Flare

ftso group test
1

:studio_microphone:Add stFLR feed to FTSO on Flare

Flare Foundation Proposal to the Infrastructure Provider Management Group (MG) to add a new Custom Price Feed to the existing set of feeds on Flare

stFLR/USD

Background:

With the recent adoption of FIP.13 / STP.10, FTSO now supports “Custom Feeds” — enabling price feeds not only for standard traded assets, but also for tokens whose value is derived via on-chain logic (e.g. liquid-staked tokens, restaked tokens, or wrapped / derivative tokens). The first Custom Feed implemented under this framework was for sFLR — with price determined by combining the FLR/USD price (from FTSO) with a ratio from sFLR’s staking contract

As adoption of FXRP grows, there is clear demand for a reliable, on-chain USD price feed for stFLR to further enable XRPFi on Flare. This would unlock better DeFi integration for stFLR (collateralization, lending/borrowing, DEX support, yield-bearing strategies). As outlined in this request https://github.com/flare-foundation/developer-hub/issues/1183, we ask the MG to consider the proposal

Business Justification:

  • Collateralization & DeFi utility: The stFLR/USD feed improves the way stFLR can be used as collateral in lending/borrowing or other DeFi protocols on Flare — improving capital efficiency and attracting more users.

  • Accurate risk management: Having a decentralized, oracle-backed USD price feed ensures reliable liquidation mechanisms and fair valuations for stFLR-based assets.

  • Ecosystem growth & composability: stFLR becomes more composable — usable in DeFi, leveraged strategies, and composable products — increasing demand and utility of FXRP on Flare-native protocols.

  • User adoption: stFLR has seen immense growth and huge user adoption immediately after launch signalizing large community support.

Consistency with governance precedent: Given that Custom Feeds were explicitly introduced to support liquid-staked tokens based on other assets and other non–CEX-listed or on-chain tokens, stFLR falls squarely within the intended use-case.

Risk Considerations & Mitigations:

- As outlined in FIP.13, Custom Feeds rely on the correctness of the underlying smart-contract logic rather than the general FTSO data-provider mechanism — meaning each feed’s risk must be individually assessed.

- For stFLR, this means the staking contract must be audited, secure, and stable. Link to contract on the Flare Block Explorer provider here: https://flare-explorer.flare.network/address/0x188fF275F36A5194A04C91F4a0058610BffC960c?tab=contract

Ask:

The MG is requested to review and approve adding stFLR as a Custom Feed to FTSO — enabling an stFLR/USD feed via the mechanism defined in FIP.13/ STP.10

Process:

An official request posted in open forum on Discourse for MG members to voice their support or raise any concerns. The Flare Foundation will then initiate a transaction from the polling contract on Flare for MG members to cast on-chain votes either for or against adding stFLR feed to Flare. Voting is rejection based and would require 66% participation amongst all eligible MG members and more than 50% of the votes going against the proposal for it to be rejected. Otherwise, the Foundation will proceed with adding to h stFLR/USD pair on Flare sometime after the voting period expires.

2

It seems proper to have this feed added.

3

The assumption here is the price will be determined by combining the FLR/USD price (from FTSO) with a ratio from stFLR’s staking contract. This makes sense and is in line current precedent.

This feed addition looks fine to be added.

4

FTSOCAN fully supports this additional feed for stFLR.

5

The StFlrCustomFeed contract is a relatively straightforward wrapper — only about 60 lines of Solidity — that derives a stFLR price by combining the FLR/USD reference feed from Flare’s Fast Updates system with the stFLR-to-FLR exchange rate provided by the stFlr contract. From what I can see in the source code alone, the contract appears well-structured and no critical vulnerabilities were identified.

That said, I want to be upfront about the limitations of this analysis. I was only able to review this single contract in isolation. I don’t have visibility into the implementation of the interfaces it depends on — IICustomFeed, IStFlr, or the inner workings of Flare’s ContractRegistry, FastUpdater, and FeeCalculator. The actual security posture depends heavily on how those external contracts behave, and any assumptions I’ve made about their correctness could be wrong.

On the positive side, all state variables are immutable (set once at deployment and never changeable), there’s no mutable storage at all (which effectively eliminates reentrancy concerns within the contract itself), and Solidity 0.8.27 provides built-in overflow protection. There are no privileged roles or admin functions, so there’s no centralization risk internal to this contract.

The minor concerns I noticed are more about robustness than exploitability. The constructor doesn’t validate its inputs — for instance, there’s no check against a zero address for the stFlr contract or empty feed IDs. In practice this is low-risk since the constructor only runs once at deploy time, but it would be a reasonable safeguard against misconfiguration. Additionally, when getCurrentFeed() forwards native tokens to the FastUpdater, it’s not entirely clear from this code alone whether excess funds would be refunded to the caller or left stranded. Users should ideally call calculateFee() first to determine the correct amount to send.

In short, the contract itself looks clean and minimal, but a complete security assessment would really need to include the surrounding contracts and the broader system architecture. I’d recommend treating this as a starting point rather than a definitive audit.

Will support this proposal

6

Aternety supports this proposal.

7

Linden Services supports this proposal.

8

OD supports it.
(and adds this for 20 characters…)

9

AU will support this proposal.

10

FlareBeacon supports this proposal

11

AimlezzFTSO support this.