Discussion & Governance Proposal Regarding SolidiFiHQ & FTSO UK

ftso group test
,
1

Hello everyone,

This post serves as a formal summary of the facts and a basis for discussion regarding the observed collusion between FTSO providers SolidiFiHQ and FTSO UK. The goal is to transparently review the evidence and discuss a proposed course of action before initiating an on-chain governance vote.

1. The Observation: What Was Seen

It has been consistently observed that SolidiFiHQ and FTSO UK are submitting 100% identical price data.

  • Details: This occurs 24/7 across all available price feeds. The data is identical down to the last decimal in every submission.

  • Verification: This is public, on-chain data that anyone can verify using tools like Flare Systems Explorer or Catenalytica.

  • Implication: The statistical probability of this happening organically between two truly independent providers is zero. This is clear evidence of a shared data source and infrastructure.

2. Analysis: Why This Is a Problem

This behavior violates the foundational principles of the FTSO system and introduces significant risk to the network.

  • It Breaks Decentralization: The FTSO’s entire purpose is to produce a reliable price by aggregating data from many independent providers. When two providers submit one data stream, they are no longer independent. This weakens the oracle and creates a central point of failure.

  • It Is a Centralized Structure: SolidifiHQ has admitted to running a hosting service for blockchain projects. Their defense is that a “configuration error” caused a client (FTSO UK) to receive the same data as their own FTSO.

  • Intent vs. Impact: The claim of an “accident” is irrelevant.

    1. The event itself proves that their centralized setup is a systemic risk. A single error compromised two providers at once—the exact scenario decentralization is meant to prevent.

    2. The core violation is offering and using an “FTSO as a Service” model in the first place. A provider’s fundamental duty is to be independent, not to resell another provider’s data stream.

3. Summary of Charges

For the purpose of this discussion, the actions of the providers can be summarized into the following charges:

  • Charge 1: Collusion and Lack of Independence By mirroring data, the providers acted as a single entity, not as the two independent oracles they are registered as. This behavior is functionally equivalent to a Sybil attack.

  • Charge 2: Creation and Use of a Centralized Infrastructure SolidifiHQ is charged with creating a centralized point of failure. FTSO UK is charged with forfeiting its operational independence by consuming this service.

  • Charge 3: Introduction of Systemic Risk Both providers are responsible for creating a fragile structure where a single error impacted multiple providers, undermining the security and integrity of the Flare Network.

4. Proposed Action: Governance Vote

To address these violations and uphold network integrity, a governance proposal should be considered. The following sanctions are proposed for discussion:

  • A one (1) week “Chill” for both SolidiFiHQ and FTSO UK.

  • The issuance of one (1) Strike against both providers.

We invite both providers to present their case and respond to the community in this thread. All community members are encouraged to review the evidence and engage in a factual discussion below. Following this discussion, a formal “Chill Proposal” will be submitted to on-chain governance.

Hit rate comparison:

image
image1080Ă—2011 75 KB
image
image1080Ă—1979 79.5 KB

Evidence FDC Collusion:

image
image1080Ă—1918 97.6 KB
image
image1080Ă—1996 98.9 KB

Proof Price Collusion 100%

image
image2048Ă—922 135 KB

image
image2048Ă—922 138 KB

image
image2048Ă—922 128 KB

image
image2048Ă—922 125 KB

**
Sources:**
Observation and discussion led by HP Mana

3 Likes
2

After following along and reviewing the evidence this does seem to fit the collusion criteria. Looking forward to the response from SolidiFi and UK teams.

2 Likes
3

Does anyone know how long the price and fdc submissions were identical?

From what I understand based on Solidifi and UK’s response internally, FTSO UK is paying SolidiFi to run their data provider as a service. I have two opinions about this

  1. This is a TERRIBLE look for both parties. Running the actual data provider is one of our simpler tasks as infra providers. If UK and Solidifi need to share this responsibility, I question their ability to do the rest of the job
  2. If done honestly, with two truly unique provider instances that do not influence each other, I don’t think this deal is explicitly against the rules. I may be mistaken, if so please link the precedent

So this proposal for me is not about their arrangement, but whether or not collusion happened. I think it’s plausible this was a genuine configuration error.

My support of this proposal kind of hinges on how long the issue was happening before it was fixed. If this was happening for under an epoch, then I’m willing to give the benefit of the doubt and assume it was a configuration error. If this is a longstanding issue, even as a mistake, then it’s proper price collusion that’s hard for me to pass by

4

For me, the main pain point is that one FTSO has/had control over another FTSO’s infrastructure. As a provider, as a service, or whatever. That should never be the case, no matter what. And since both parties have admitted it, that’s enough to assess the consequences. The price collusion and the FDC collusion are merely the consequence of the misconduct that has already been admitted. Therefore the detailed data is not needed to show here but available on the chain for those who are interested in.

2 Likes
6

There is no doubt that the two providers use the same infrastructure, the same code, the same software instance, so if an action to sanction is proposed in the management group, we will support it.

I would have hesitated if it were only a matter of sharing a node, or subscribing to node-as-a-service, but here it seems that the entire solution is being shared. And I have absolutely no doubt about the ability of both providers to manage an infrastructure provider on their own, which makes what they did even more serious in my eyes.

1 Like
7

We also support this. Thank you for the research!

2 Likes
8

Hello, thank you for bringing this discussion forward.

We do no think this behavior aligns with the spirit of fair play we should maintain in the ecosystem. While participation is encouraged, actions that could be seen as trying to game the system or unfairly influence the process don’t seem to fall within the intended rules of engagement.

We are in favor of taking a “chill” approach to governance. We should prioritize long-term stability and fairness over sudden, potentially disruptive maneuvers. Let’s focus on constructive discussion and adherence to the foundational principles.

2 Likes
9

nortso supports this motion as it’s evident that the mentioned providers have been violating the requirement that each provider must be independent. The only way that two providers consistently end up with the same price is by sharing the value-provider.

2 Likes
10

To uk / solidifi: uk, you’re an OG provider and ferdi at solidifi you’ve contributed to the ecosystem for a long time for what seems to be a thankless job. Honesty and transparency only with your peers - worst case it’s a chill, don’t let us ever question your integrities — we’ll all move on after correction. Open mind from 4dads on evidence, appreciate all you guys have done and sorry we’re here.

To flare: if they are found guilty and this passes, please execute in a timely manner. If it doesn’t, two options: 1) adopt the sip/fip language of proposal I drafted over a year ago - if flare fails to veto in X epochs, vote goes into effect 2) we hold price feeds hostage and burn the whole MG group down until we get #1 — don’t think others feel the same way? FAFO

To @pricekraken : I like this format for explaining to the public of why it’s harmful — well done, if co-authored with snow/hpmana, please give my thanks as well

4 Likes
11

We believe it is very unlikely that two sufficiently independent providers could submit nearly identical prices, even for a short period of time. This strongly suggests that more is being shared than just a submission node or a configuration setting, as one of the providers has claimed. It is likely that these providers share much more—possibly even their entire stack. We find the explanations provided to be insufficient, and the lack of transparency only adds to our concerns. We will support the proposal.

1 Like
12

Speaking for Team Tempest, we believe all providers / teams should be independent and run their own infrastructure, no ifs, not buts, no IaaS model. The network needs to be comprised of independent entities with skills in house to run their own infra. We think the IaaS model should be banned in order to ensure robust decentralisation of the network, not doing so harms the integrity of the Flare product we’ve all worked hard to support.

We support this proposal and the banning of shared infrastructure / IaaS models. I hope this is something the Flare team discuss internally.

2 Likes
13

Thank you for taking the time to put this proposal together, much appreciated.

14

Thank you for gathering the evidence.

Sadly, this matter was also posted on X by a whitelblower>>> https://x.com/so_annieways/status/1972490240968499320

This is bad press for Flare Networks and all of us involved.
We shoudl try to protect the hard work we’ve all been building for the past 7 years and especially now when the network is gaining more exposure with FAssets live.

Shame we failed to handle this internally…

We agree with the facts exposed… It all looks and sounds like collusion unfortunately…

15

The evidence looks clear, but we got a bit confused with the explanations given by both. If they could clarify fine otherwise we would vote for a collusion vote.

1 Like
16

Wanted to follow back up since I never gave a final opinion

I support the chill, only because I was told this identical-price issue lasted more than a week.

I’m not inherently against IaaS if done correctly. It doesn’t seem like this was done correctly, but both of these entities have been in the ecosystem for a while and I trust they will tighten operation after this incident

1 Like
17

Firstly, thank you @pricekraken for creating the discussion on Discourse.

As a founding FTSO on Flare it has always been our belief that processes such as this are needed to maintain the correct governance of the Flare network.

To answer the accusations of collusion and what is being presented, I will share what I also shared in the FTSO Telegram chat.

1. We manage our own Infra via Solidify Labs as the hosting provider. Much like using BlockDemon, Alchemy or Google’s GCP. We are provided a service with uptime guarantees, just like all hosting providers do.

If any Flare entity having a connection to an FTSO cannot offer other blockchain-related services, then I would consider the presence of Google here a contradiction to that. Given the Flare node service hosted in the GCP marketplace.

2. We use the base provider as an element in our pricing algorithm. This is known, and as has been shown, many providers use this within their own algos.

3. When the event in question happened, we were contracted by our service provider, Solidify Labs, to say an error had occurred in the configuration of a node and as such, we had been using the same node.

It was expected that this took place over around 7days. If evidence proves to the contrary, then we will be looking into this further ourselves.

So, at its base level, it’s an issue between us and our hosting provider. Who has always been a great support to the Flare network.

4. At no time have we admitted to explicitly sharing infra services. This is totally false and misrepresented.

5. We do have zero passes. This is due to us only having a self-bond of 1M. As can be verified by the Flare information.

(Staking: Providers need 80% uptime with a minimum of 1M FLR in active self-bond. To earn passes, they must hold at least 3M FLR in active self-bond and 15M in active stake. Providers with sufficient uptime but less stake do not gain or lose passes but still earn rewards.)

6. We are not active on Songbird, so these effects were only felt on Flare.

  1. The decision by Bifrost to remove us from their wallet app before the investigation and group decision were concluded is disappointing. As a centralised project on the network, they have the right to take such action, and it has already had a noticeable impact.

We have been and will remain a positive force for Flare. We have at times required help and assisted others in times of need. I hope this continues.

As an FTSO we have worked hard with Flare to bring new awareness and projects to the network. This will remain a key focus for us as we move forward.

This group was created for events such as these.

I maintain and state that at no time have we ever colluded or made attempts to game the system in any way. I contest this and reaffirm our innocence.

We will honour whatever terms are stated by the group and move forward.

Thank you to everyone who has responded with level-headedness and respect for the work we are all contributing to this ecosystem.

1 Like
18

Thank you @pricekraken for putting together the information and to @Jon-Sn0w for spotting it.

In my opinion, it is ok to temporaly share nodes if a provider has an issue, however, I fail to see how sharing a node would result in the exact same submissions for all providers using that given node.

To me this looks like a shared endpoint for prices, which is not acceptable. For this reason I will support the proposal.

19

The proposals are now open to vote!

FTSO UK

Solidifi Nexus

Track Voting here:
https://www.pricekraken.de/vote-status/