Proposal
That Provider 0x882ee9cebe3d7b38eebd640b89de01b326351679 be chilled under FIP.02 for collusion.
FIP.02 defines collusion as:
“Collusion, defined as multiple FTSO data providers showing a strong statistical correlation in their submissions or clearly submitting through the same node.”
The first limb asks one question: do the providers show a strong statistical correlation in their submissions? It contains no requirement of agreement, coordination, intent, or common control. The adjacent definition of duplication does contain a common-control element, so the drafters knew how to write one and did not write one here.
No coordination is alleged. None is required for the definition to be met, and nothing below asserts any.
The evidence
Over 120 consecutive voting rounds (1,454,168 to 1,454,287), every pair of the 101 providers revealing values was compared cell by cell. A cell counts only where both providers priced the same feed in the same round, and counts as agreement only where the encoded integer is identical to the last digit.
Provider 0x882ee9cebe3d7b38eebd640b89de01b326351679 submitted byte-identical values to its closest peer on 89.7% of the cells they both priced.
| Peer | Byte-exact agreement | Cells compared |
|---|---|---|
| Kiln | 89.7% | 7,440 |
| Last Oracle | 88.8% | 7,440 |
| Encode Club | 88.7% | 7,440 |
| 0x7bb4e0ab | 88.7% | 7,320 |
| Nansen | 88.3% | 7,440 |
| Scintilla | 88.3% | 7,440 |
And 19 further providers at or above 60%, 25 in total.
Providers outside this group agree with one another at about 9.2% on the same measure. Two independent implementations reading different venues essentially never produce the same integer to the last digit on a volatile feed, which is why the field rate is the natural null and why 89.7% is not a coincidence of market conditions.
Provider 0x882ee9cebe3d7b38eebd640b89de01b326351679 holds 0.15% of network voting power. The protocol counts it as an independent observation. On this measurement it is not one.
A separately operated assessment reaches the same conclusion
cerberusonchain.xyz publishes its own analysis of Flare providers, built and run by someone else. Its authors describe it as “an implementation-likeness model, not an accuracy ranking”. It scores candidates against two anchors, a captured deployment of the stock example provider and the passive Flare Network Test provider, using exact value matches, agreement within 5 basis points, mean error magnitude, directional agreement, band crossing and update cadence scored with Cohen’s kappa, fed into a class-balanced logistic model and reported only above a calibrated likelihood of 65%.
It assesses Provider 0x882ee9cebe3d7b38eebd640b89de01b326351679 an example-provider match at 96.5% likelihood (snapshot 2026-09-09).
The two assessments share no signal. One counts byte-exact cells; the other fits a model on proximity, error magnitude, direction and timing against anchor deployments. Neither was built from the other. Where both hold a verdict they agree on 92 of 98 providers, 93.9%.
This is corroboration, not the case. It is inference about which software a provider runs, it carries zero confirmed positives, and it cannot place anyone in breach of FIP.02. The infraction above is the byte-exact agreement, which is a count. The value of a second party arriving at the same group by a different route is that the group is unlikely to be an artefact of how either was built.
How to verify this before voting
Do not take it on trust. Every input is public:
- This provider’s live figures: 0xb0a1797e… — past readings
- Method in full, including what it cannot establish: Oracle Independence
- Procedure: decode each round’s reveals from the Submission contract
0x2cA6571Daa15ce734Bbd0Bf27D5C9D16787fc33f, selector0x9d00c9fd; take the 4-byte value per feed in canonical order; for every pair, count cells where both priced the feed and the integers are equal. Voting round isfloor((unixtime - 1658429955) / 90); round R reveals during R+1.
There is no model here and no reference instance. The figure is a count of reveals already on chain.
The entity, and what a chill has to cover
| Role | Address |
|---|---|
| Identity | 0x882ee9cebe3d7b38eebd640b89de01b326351679 |
| Submit | 0xb0a1797e150ee76f5f2d2de951544c4d592594b7 |
| Delegation | 0x99307a8f46cbcc9238a80be8ed955f3e8b491ed4 |
| Node 1 | 0xe88fb423f4ec8a8b985fbe49548dddc58bed5968 |
Provider 0x882ee9cebe3d7b38eebd640b89de01b326351679 has 1 registered node. That matters for how the chill is executed rather than for whether it is warranted.
FIP.16 registration weight is computed from two sources: mirrored stake across a provider’s node ids, and the WNat delegated to its delegation address. VoterRegistry.chill takes a list of beneficiaries, so a chill must name the delegation address and every node id above. Chilling the delegation address alone leaves roughly 80% of an average provider’s registration weight untouched, which is the appearance of a sanction rather than a sanction. With every leg named, registration weight is zero and require(_weight > 0) prevents registration for the epochs concerned.
Precedent
The Management Group has chilled for collusion repeatedly, and has done so on findings of the same kind: FLRLabs and LoveFTSO (2023), HXK Oracle, Sirius and CoffeeFTSO (2023), Best FTSO and tSovreign (2023), O1FTSO and Flare Ocean (2024), FTSO UK and SolidiFi Nexus (2025), Sceptre and Rotko (2026). In the FTSO UK and SolidiFi case the group found that “by mirroring data, the providers acted as a single entity, not as the two independent oracles they are registered as.”
Every one of those was voted one provider to a proposal. This proposal follows that practice.
What a chill means here
Under FIP.02 a first chill removes a provider for two reward epochs; a second is a permanent ban. This is a first chill.
A “for” vote is a vote to chill
