Why independent providers matter

The FTSO is trustworthy for one reason: many providers price each feed separately, so no single mistake or interest can move the consensus far. That guarantee depends on the providers actually being separate — and the network has rules, and a record of enforcing them, for when they are not.

What the count is worth

A consensus of a hundred providers is only as strong as the number of independent judgements behind it. If several registered providers are in fact one operator, one shared system, or one coordinated group, the field looks wider than it is: their weight lands in the same place, the weighted median and the reward band move towards it, and the protection a dApp thinks it is getting from a hundred voices is really coming from fewer.

It also changes who gets paid. Accuracy rewards are split among the providers inside the band, so weight that should have been spread across separate operators is concentrated in a group that agrees with itself by construction. Independent providers that disagree with that group for good reasons are pushed toward the edge of a band it helped draw.

The two things the rules prohibit

Under FIP.02, providers police each other through the FTSO Management Group. Its infractions are deliberately not written as a rulebook — cases are judged on their evidence — but the enforcement record settles on two named classes:

• Collusion, which FIP.02 defines as “multiple FTSO data providers showing a strong statistical correlation in their submissions or clearly submitting through the same node.” Past cases have turned on shared nodes, algorithms passed between operators, shared paid data subscriptions and shared people.
• Duplication — one entity running more than one provider with largely the same code and output. One entity may run several validator nodes; it may not register several submitting providers.

The open question in 2026 is shared code. A sizeable group of providers runs Flare’s published example implementation — which its documentation says is not meant for production — with little or no change, and so submits byte-identical values round after round. In September 2026 a chill proposal was brought against one such provider under the correlation limb of the definition above, described by its author as the first of a series. The discussion is public and divided: some members argue identical submissions are correlation by definition, others that the example code is not harmful enough to punish.

How it is detected

Cases are brought in public forum threads, and the evidence that has carried them is consistent:

• Co-timed errors. Every provider occasionally submits a bad value. Two providers submitting the same bad value in the same round, across several feeds, while the rest of the field tracks normally, is very hard to explain without a shared system. It is the co-timing, not the error, that counts.
• Exact matches above the ambient rate. Honest providers match each other’s submissions exactly some of the time; a pair matching far more often than that baseline stands out.
• Synchronised downtime. Providers that go dark and return together, with no wider outage to explain it.
• Funding and identity links. Shared wallets or exchange accounts, transfers between providers, and shared developers or commit authors.

Claims like “we use the same hosting company” or “our models converged” have generally not been accepted on their own: lots of honest providers share a host, and independent models do not produce identical anomalies.

What happens when it is found

After a discussion window in which the accused provider is invited to respond, the Management Group votes on-chain. A first strike is a chill: the provider is suspended for two reward epochs. A second strike is a permanent ban, and the record follows the provider’s addresses across FTSO versions. The process has been used repeatedly since 2023, including in the FTSOv2 era.

For a delegator the cost is direct: a chilled provider earns nothing for the epochs it is suspended, so neither do the FLR delegated to it.

What a delegator can check

No public signal proves a provider is independent, and none of the ones below is an accusation on its own. Together they are the evidence that is available:

• Each provider’s page on Providers carries an independence reading from Cerberus On-Chain, with its per-channel evidence, and any signed self-declaration the provider has published, side by side.
• Node uptime and eligibility history — sudden shared gaps are one of the classic markers.
• How long a provider has existed. Legitimate providers usually take months to reach top accuracy; a brand-new address at the top from day one is something investigators have looked at.
• Byte-exact agreement with other providers, which independent community tools now publish per provider — the measure the 2026 debate is about.
• The forum itself. Enforcement threads are public at forum.flare.network.

Last reviewed October 2026