Submitted for discussion and a vote of the FTSO Management Group, and thereafter for the consideration of the Flare Foundation
11 September 2026
Download the full proposal as a PDF
Context
FIP.02 lists the infractions for which a data provider may be chilled. It 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.”
It separately defines duplication as:
“Duplication, defined as multiple FTSO data providers on the same chain, controlled by the same entity, and running largely the same codebases, resulting in substantially similar submissions.”
FIP.02 also states that “infractions are purposely undefined” and that the group decides case by case.
The two definitions differ in a way that decides this proposal. Duplication requires that the providers be “controlled by the same entity”. Collusion contains no such requirement. It contains no requirement of agreement, coordination, intent, or common control. It asks one question only: do the providers show a strong statistical correlation in their submissions?
The drafters knew how to write a common-control element, because they wrote one into the very next definition. They did not write one into collusion.
That first limb, the one this proposal relies on, is called the correlation limb below. It is the only part of the definition invoked, and nothing in this proposal alleges that any provider coordinated with any other.
The measurement
Across 120 consecutive voting rounds (1,452,488 to 1,452,607), every pair of the 101 providers revealing values was compared cell by cell. A cell counts as agreement only when both providers revealed a usable value and the encoded integer is identical to the last digit. Not close. Identical.
| Pairing | Pairs | Mean | Median | 75th pct | Max |
|---|---|---|---|---|---|
| Correlated block x block | 325 | 77.44% | 77.31% | 85.94% | 91.02% |
| Block x rest of field | 1,950 | 10.43% | 7.16% | 11.41% | 45.42% |
| Rest of field x rest of field | 2,775 | 9.18% | 8.72% | 11.57% | 44.77% |
Twenty-six providers, holding 22.8% of the network’s voting power, agree with at least one other provider to the last digit on at least 60% of priced cells. Within that block the average pair and the median pair each agree on 77% of cells. The rest of the field agrees with itself at 9.2%. The tightest pair in the block reaches 91.0%.
The same measurement drawn as a graph, on the same window as the table above: rounds 1,452,488 to 1,452,607, measured 11 September 2026. Each circle is one of the 101 providers revealing values; a line joins two providers that revealed byte-identical values on at least 60% of the cells both priced. A line is a direct count, not an inference. Red rings mark the providers this project classifies as running the reference implementation, grey another median implementation, green those its tick-grid screen excludes; the classification colours a circle and plays no part in deciding who is drawn or who is joined. At this threshold the block is not a scatter of coincidental pairs: 26 providers carry 313 of the 325 lines that could exist between them, 96.3% of a complete graph, while the independent majority carries none.
The separation is clean. Ranking every provider by its agreement with its single closest peer, the highest outside the block sits at 45.4% and the lowest inside it at 66.6%. The distribution is bimodal rather than continuous, and it stays that way: across forty consecutive measurement runs in the ten days to 11 September, a median of 54 providers sat below 20% and 25 at or above 70%, while the whole 40% to 60% range held a median of three providers out of about a hundred, and never more than five. The block itself is stable at 23 to 28 providers, median 26, across those same forty runs.
This measurement involves no inference about which software anyone runs. It reads reveals off the chain and counts. There is no reference instance, no calibration, no threshold, and no model. It is reproducible by anyone with a Flare RPC endpoint, and the procedure is short enough to state in full: decode each round’s reveals from the Submission contract, take the 4-byte value per feed in canonical order, and for every pair of providers count the cells where both priced the feed and the encoded integers are equal. No other input is required. The addresses, selector and round formula are in the appendix, the method is documented at oracleindependence.com/method, and the resulting figures are published and updated continuously at oracleindependence.com.
Two separately operated assessments identify substantially the same group. Alongside the measurement above, oracleindependence.com publishes an example-provider classification, and cerberusonchain.xyz publishes its own analysis of Flare providers. Both methods are set out here in the same detail as the measurement, because the weight this proposal places on their agreeing depends entirely on their having nothing in common.
The classification at oracleindependence.com rests on three signals, none of which counts a byte-exact cell. The first is a tick-grid lattice: how often a provider’s encoded value lands on a coarse exchange tick grid, measured against the per-round leave-one-out rate of the rest of the field on the same feed, so that the field reads 1.00 by construction. The second is a per-cell hit pattern: which feed and tick cells a provider over-hits, correlated against reference instances and normalised by those instances’ own cross-configuration agreement. The third is a USDC configuration signature: the shipped feeds.json prices USDC/USD from USDC/USDT books times the provider’s own USDT/USD, and USDC/USDT ticks at 1e-4, so that ratio must land on a 1e-4 grid. The third needs no reference instance at all, using only a provider’s own two submitted values. The class is read from a trailing window rather than the full record, so a provider that changes what it does leaves it within days; only exclusion is decided on the whole record, because that is the clearing half of the screen and should not be withdrawn because a window is young. The site holds zero confirmed positives.
The model at cerberusonchain.xyz is described by its authors as “an implementation-likeness model, not an accuracy ranking”. Each candidate is scored against two anchors: a captured deployment of the stock example provider, and the passive on-chain Flare Network Test provider. The raw signals are exact value matches, agreement within 5 basis points, mean error magnitude, directional agreement when values update, and whether both values cross a robust population band on the same signed side. Those are then taken relative to the population, using precision, recall and lift against an expected coincidence rate, so that ordinary market-wide movement and sporadic coincidence are discounted. Update timing is scored separately using Cohen’s kappa across feeds, which removes the chance agreement implied by each series’ own update rate. Eighteen features built this way, across both anchor families, feed a class-balanced logistic model under L2 regularisation, fitted on known example implementations as positive controls and independent providers as negative controls. A provider is reported only above a calibrated implementation likelihood of 65%.
The two share no signal. One reads tick-grid occupancy, per-cell hit patterns and a stablecoin configuration artefact; the other fits a model on proximity, error magnitude, direction, band crossing and update cadence against anchor deployments. Neither was used to build the other. Where both hold a verdict they agree on 93 of 98 providers, 94.9%.
Both are public, both are continuously updated, and the group should treat them as what they are: two parties who arrived at the same conclusion by different routes. Neither depends on the other, and neither depends on this proposal. That two methods with nothing in common land on the same group is evidence the group is real rather than an artefact of how either was built.
The one distinction that matters for the vote is what each establishes. Both are inference about cause, and the Cerberus authors are explicit that their model cannot establish accuracy or intent, only implementation similarity. The infraction this proposal asks the group to find is the byte-exact agreement itself, which is measurement.
The finding this proposal asks the group to make
On the plain text of FIP.02, the test is met. No coordination is alleged, and none is required.
No agreement, conspiracy, or coordination between these providers is alleged, and none has been found. The available evidence is consistent with independent operators each independently downloading the same reference implementation published by Flare and running it on its shipped default configuration, and in a handful of cases with operators reading the same venues by the same method using their own code. Precision here makes the finding harder to dismiss, not easier.
Twenty-six data providers showing 77% byte-exact agreement against a field baseline of 9.2%, a factor of 8.4, is a strong statistical correlation in their submissions. That is the entire test. The definition is met, and it is met by a margin that leaves no room for argument about where the line sits.
The Management Group has previously found that “by mirroring data, the providers acted as a single entity, not as the two independent oracles they are registered as,” and chilled on that basis. The conduct found there was 100% identical data across two providers. What is measured here is 77% median identity across twenty-six. If the earlier finding was correct, this one follows.
Why the absence of coordination does not change it
That does not change the network’s position, and the text is why. The correlation limb asks about correlation in submissions, not about arrangements between parties. Whether the correlation arises from a conspiracy or a shared dependency, the network is in the identical position: twenty-six registered oracles are returning one answer. The protocol counts them as twenty-six independent observations. They are not.
An operator who cannot say why their submissions are identical to twenty-five others has not answered the question. They have restated it.
Flare’s documentation already says not to do this
The correlation is traceable to ftso-v2-example-value-provider and its shipped feeds.json, which names a fixed list of exchange venues. Flare publishes this software, and Flare’s own developer documentation tells operators not to run it in production. Under the heading Implement Your Own Production Provider, the Flare Developer Hub states that the example implementation “is intended ONLY for testing, demonstration, or initial integration purposes”, and that “for reliable mainnet operation and reward eligibility, you MUST implement, deploy, and maintain your own robust Feed Value Provider”.
That the default was published is therefore not a mitigation, and it was never a permission. Flare conditioned reward eligibility on running an implementation of one’s own, in the same document that explains how to become a provider. FIP.02 protects the network from a state of affairs rather than from a state of mind, and a provider running the example implementation on mainnet is in the condition the correlation limb describes whether or not it read the instruction.
The mechanism is more general than the software, and the measurement shows it: a provider that returns an observed trade price verbatim agrees byte-for-byte with anyone reading the same venue, whatever code either of them runs. The shipped default is the commonest route into that condition rather than the only one, which is why section 2 tests the condition and not the software.
The risk being protected against
A weighted median is robust while correlated weight is below 50%. At 22.8%, a correlated excursion does not by itself move the median, and this proposal does not claim otherwise.
What the figures mean is that the effective number of independent observations behind Flare’s prices is far smaller than 101. A block agreeing at 77% median identity is closer to one observation counted twenty-six times than to twenty-six confirmations. The margin to the level at which correlation becomes decisive is materially thinner than the provider count implies, and it narrows every time a new operator deploys the default.
The failure mode is a venue-side event, an outage, a stale book, a bad print, reaching many participants at once and arriving looking like consensus rather than like a fault. Correlated observers do not merely fail together. They mask the failure, because agreement is the signal the protocol uses to decide what is true.
The bad print is not hypothetical; it is the shipped behaviour. In ftso-v2-example-value-provider, each configured exchange contributes a single observation, its own last trade price, and weightedMedian() returns one of those prices verbatim: the median by price, weighted by exp(-LAMBDA * age) with a default LAMBDA of 0.00005. Two properties follow. There is no volume weighting, so a trade of one satoshi and a trade of a hundred bitcoin count the same at the same age; and there is no averaging within a venue, so each venue’s contribution is one trade rather than a summary of many. The median across venues does resist a single odd print, but only while several venues are trading: weight decays fast, a trade thirty seconds old carrying about a fifth of the weight of one that just happened and a minute-old trade about a twentieth, so when the other venues are quiet or stale a single fresh print can exceed half the total weight and is then returned outright. The protection is weakest exactly where a bad print matters most, in thin or quiet markets, and whatever it returns it returns identically for every operator reading the same venues. Flare’s own documentation requires “data cleaning, validation, and aggregation”; the example implementation does none of the first two and the least that counts as the third.
This proposal does not allege harm to price quality, and the available metric cannot settle the question either way. On Flare’s own primary success rate these providers are indistinguishable from the rest of the field, 46.0% against 46.5%, but that rate scores a provider on landing in the reward band around the median, and a block holding 22.8% of registration weight and submitting identical values substantially anchors the median it is scored against. The dispersion shows it: across this block the median absolute deviation of that rate is 0.4 percentage points, against 11.3 for the rest of the field. They do not merely score near the field, they score almost identically to one another, which is the correlation surfacing in the measure rather than evidence about quality. The infraction is the correlation, and section 2 tests nothing else.
Specification
1. Finding. The Management Group finds that sustained byte-exact submission agreement at the levels measured constitutes a strong statistical correlation in submissions within the meaning of FIP.02, and therefore an infraction, irrespective of whether the providers concerned coordinated with one another.
2. Standard. So that this finding is a rule and not a discretion, the group adopts an operational threshold, called the threshold wherever it appears below: sustained pairwise byte-exact agreement at or above 60% of priced cells, measured over no fewer than 100 voting rounds, is a rebuttable finding of correlated submission. Agreement below that figure is not, so the two states partition the field with no case falling between them. The threshold sits in the sparse region between the two modes of a bimodal distribution, not part-way along a continuum: over the ten days to 11 September the 40% to 60% range held a median of three providers out of about a hundred, while twenty-five sat at or above 70%. The same standard binds every provider.
The order of the tranches in 3a turns on a second figure, called the pattern score: the normalised per-cell hit-pattern signal described in the measurement section above and published per provider at oracleindependence.com, read on its trailing window. The pattern score decides two things: the class that forms part of the membership test in 3a, and the order of the tranches within it. Neither can place a provider above the threshold that the measurement has not already placed there.
3. Remediation before sanction. Twenty-three providers meet all three tests in 3a: the twenty-six above the threshold, less two that the classification does not identify and one the third-party assessment does not cover. Chilling them at once would remove 18.5% of voting power in a single action and would itself be the systemic event this proposal seeks to prevent. The group therefore resolves:
- 3a(i) The affected set. Fixed by the last measurement published at
oracleindependence.combefore this resolution passes: the providers that are above the threshold, classified as candidates on that publication, and assessed an example-provider match bycerberusonchain.xyz. It does not change afterwards. That measurement is the procedure stated above and in the appendix, computed from reveals decoded off the chain and reproducible by anyone with a Flare RPC endpoint. - 3a(ii) Tranches. The set is divided as follows: providers are ordered by the pattern score rounded to two decimal places, descending; ties broken by agreement descending, then registration weight descending, then submit address ascending; taking them in that order, each provider joins the current tranche unless doing so would carry it above 5% of network voting power, in which case it opens the next; and a provider whose own weight exceeds 5% forms a tranche alone. Voting power is registration weight as returned by
VoterRegistry.getVoterRegistrationWeight, read at the reward epoch of the measurement that fixes the set. On the figures current at the date of this proposal the rule yields five tranches, the largest holding 4.84% of network voting power. The rule is applied to the current measurement and published atoracleindependence.com/remediation, recomputed as the measurement moves, so any provider can see which tranche it would fall in and check the ordering against its own figures. - 3a(iii) Notice. Served on the first tranche no later than 14 days after passage, and on each subsequent tranche one reward epoch after the one before, so that the tranches resolve in sequence rather than together. It is served by the group, individually for each provider, as a dedicated thread for that provider on the Flare governance forum, and in addition to any contact of record where one exists. Registration as a data provider is a wallet signature and carries no contact address, so for most providers no private channel exists and publication is the only channel that reaches every subject. Notice is therefore effective on the date the thread is published. Each notice states that provider’s own measurements, the rounds they were taken over, the tranche it falls in, and the dates on which its remediation window opens and closes.
- 3a(iv) The notice thread is the record. That thread is also the record the group later votes on. Where a window closes without remediation, the proposal that opens under 3d is an individual management proposal whose
urlfield is that provider’s notice thread, so the notice, the provider’s own reply, and the case members vote on are one document and not three. A provider that remediates leaves a thread recording that it did. This follows existing practice: every management proposal about a provider carries a link to a forum thread, and the group has voted providers separately while a single thread covered several of them. - 3b. A remediation window of eight reward epochs, running from the date of notice to that provider’s tranche under 3a, in which to bring pairwise agreement below the threshold.
- 3c. A provider is treated as remediated when pairwise agreement sits below the threshold on the same sustained basis on which section 2 makes the finding.
- 3d. Where a provider is still above the threshold at the close of its window, a management proposal naming that provider alone opens immediately, with its notice thread under 3a(iii) as the linked record. No further finding is needed: the window has closed and the measurement is published. The group then votes, and the vote decides the chill. The durations are FIP.02’s, a first chill removing a provider for two reward epochs and a second being a permanent ban. This proposal creates no sanction of its own. It supplies a measurable trigger for the one FIP.02 already provides, and the window in 3b exists so that as few providers as possible reach it. The measurement decides only whether the vote is called, never how it goes. The mechanism is
VoterRegistry.chill, taking an array ofbytes20beneficiaries and auint32epoch count, against both legs: the provider’s delegation address and every node id registered to it. Both are required. Chilling the delegation address alone leaves 80.6% of an average provider’s weight and 94.7% of the block’s, which is not a sanction but the appearance of one. - 3e. A provider that remediates within its window is not referred and not chilled, and nothing is recorded against it.
- 3f. Recurring review. Eight reward epochs after the last tranche’s window closes, and every eight reward epochs thereafter, the group applies the tests in 3a(i) to the measurement current on that date and publishes the result, including a review that identifies nobody. A provider meeting all three tests that has not already been through 3a to 3e enters them, in tranches formed under 3a(ii), on the same notice and window. A provider previously chilled under 3d that is above the threshold again has already had its window; it is notified and referred under 3d without a further one, as a second chill. The review lapses once the Foundation has implemented 4a and three consecutive reviews have identified nobody. Section 3 is intended only as a transitional enforcement mechanism until the underlying cause has been removed.
4. Requests to the Flare Foundation.
- 4a. Change the default venue configuration shipped with
ftso-v2-example-value-providerso that it does not hand every operator an identical list. Shippingfeeds.jsonempty would be sufficient, and is the smallest change that works: an operator who must name venues before the software will run cannot inherit anyone else’s choice, and the correlation this proposal addresses could not form in the first place. The documentation already tells operators not to run it in production, and the measurement shows that a documented warning has not been enough: every new operator deploying the default enters a chillable condition as soon as its submissions have been measured. Changing the default makes the software agree with the documentation. Implementing this change removes the principal pathway by which new providers enter the condition addressed by this proposal, allowing the recurring review in section 3f to conclude once existing cases have been resolved. - 4b. Carry the documentation’s warning into the software itself. The Developer Hub is unambiguous, but the repository describes it only as “a sample implementation” and nothing warns at startup. A provider that reads the README and not the entity guide gets no signal at all; a warning when the software is run against mainnet on an unmodified configuration reaches the operator at the moment it matters.
- 4c. Within one reward epoch of a proposal passing under 3d, either execute the chill the group has voted for or publish a reasoned decision declining it. A passed proposal must not remain pending beyond that period: one left open indefinitely leaves a provider neither sanctioned nor cleared, and it is the group’s vote that is left in the air. The schedule in 3a and 3b is the group’s to keep, and the vote in 3d is the group’s to take; the chill itself is the Foundation’s act.
5. Disclosure of what is already public. The measurement, the per-provider figures and the classification are published at oracleindependence.com, under a method page that states in full what each signal can and cannot establish. The assessment at cerberusonchain.xyz is published on the same terms, and neither site requires the other’s cooperation to be checked. Every provider named can read their own row on both, reproduce it, and dispute it on the same public data.
Arguments against
“They did not coordinate, so it is not collusion.” The definition in FIP.02 contains no coordination element, while the adjacent definition of duplication does. This is addressed above.
“Flare published the software.” It did, and told operators not to run it in production in the same documentation that explains how to become one, conditioning reward eligibility on implementing their own. Publication was never permission. Section 4 asks the Foundation to close the gap between what its documentation says and what its software ships, which bears on how the condition spread; it does not bear on whether the network currently has twenty-six independent oracles.
“There is no measured harm.” Correct. FIP.02 is preventative, and the infraction it names is the correlation itself.
“Correlated but correct beats diverse but buggy.” The standard is pairwise agreement, not implementation quality, and section 2 sets no requirement about how a provider brings its agreement down.
“You are sanctioning on a model that has zero confirmed positives.” The model cannot put anyone in breach. The finding and the standard are the measurement, and a provider is proceeded against only where the measurement already places it above the threshold; the classification only removes providers from that group. Its effect is that fewer providers are sanctioned than the standard reaches, never more.
“This sets a precedent that could chill honest providers.” A real risk, and the reason section 2 fixes an explicit, measurable, uniformly applied threshold instead of leaving the clause to case-by-case discretion.
Vote
Members are asked to vote on the Specification. Sections 1 and 2 are the substance: whether the correlation limb of FIP.02 means what it says, and on what standard it is applied. Sections 3 to 5 follow from them.
This vote chills nobody and names nobody. It adopts a standard and the procedure by which the standard is applied. Every provider it eventually reaches is served notice first, has eight reward epochs to bring its agreement below the threshold, and is voted on individually under 3d only if that window closes without remediation. A member who votes for this is voting for the rule, and keeps an unbroken vote on each provider separately, on that provider’s own published record.
On passage, the proposal is transmitted to the Flare Foundation for consideration of section 4.
Checking this yourself
| Flare’s instruction on the example provider | dev.flare.network/run-node/flare-entity |
| Method, in full | oracleindependence.com/method |
| Live figures and per-provider detail | oracleindependence.com |
| Tranches under 3a, computed live | oracleindependence.com/remediation#tranches |
| Whether each provider’s agreement is falling | oracleindependence.com/remediation |
| Success rates | Flare’s own systems explorer, taken verbatim |
| Second assessment, separately operated | cerberusonchain.xyz |
| Its method, in full | cerberusonchain.xyz/#methodology |
| Reveals | Submission contract 0x2cA6571Daa15ce734Bbd0Bf27D5C9D16787fc33f, selector 0x9d00c9fd, FTSO protocol id 100 |
| Voting round | floor((unixtime - 1658429955) / 90); round R reveals during R+1 |
| Voting weight | VoterRegistry.getVoterRegistrationWeight(address,uint256) at 0xA480457953Af3583E54DCd630b219353B8FC9Af7 |
| Network weight total | getWeightsSums(uint256) at the same address |
| Chill mechanism | VoterRegistry.chill (array of bytes20, uint32 epochs); weight computed by FlareSystemsCalculator at 0xf9cCe0Bd286bb38A9A0cD15fDDC5431F03568Db0 |
Every figure in this proposal derives from these sources alone.