Further to this
https://songbird-ftso-monitor.flare.network/price?currency=BTC&startTime=12h&providerAddress=0x08eb910e9288e5c6baf6e1a74d5d1d23284360a4,0x66064b9755ff3c26c380be0fbe7f38df6222ba15,0x939789ed3d07a80da886a3e3017d665cbb5591dc&endTime=1687504616&relative=false
tSoveriegn
Songbird: 0x66064b9755ff3c26c380be0fbe7f38df6222ba15
Best FTSO
Songbird: 0x939789ed3d07a80da886a3e3017d665cbb5591dc
Edit: missed out
WorldsFTSO
Songbird: 0x08eb910e9288e5c6baf6e1a74d5d1d23284360a4
It appears sent same price for BTC on multiple epochs on BTC - a very liquid market
Songbird epochs
epochs 309188 to 309195
1 Like
Collusion: defined as multiple FTSO data providers showing a strong statistical correlation in their submissions or clearly submitting through the same node.
Can someone post BestFTSO admitting on ftso telegram channel that they use same node and data feeds?
3 Likes
I think this is what you’re referring to @AtlasTSO
2 Likes
so the question comes, if they run different algos, how are they able to submit the same price for a liquid market on multiple epochs?
2 Likes
Same thing looks to have happened on eth also
tSoveriegn
Songbird: 0x66064b9755ff3c26c380be0fbe7f38df6222ba15
Best FTSO
Songbird: 0x939789ed3d07a80da886a3e3017d665cbb5591dc
Edit: missout out
WorldsFTSO
Songbird: 0x08eb910e9288e5c6baf6e1a74d5d1d23284360a4
https://songbird-ftso-monitor.flare.network/price?currency=ETH&startTime=12h&providerAddress=0x08eb910e9288e5c6baf6e1a74d5d1d23284360a4,0x66064b9755ff3c26c380be0fbe7f38df6222ba15,0x939789ed3d07a80da886a3e3017d665cbb5591dc&endTime=1687504616&relative=false
epochs 309188 to 309195
Edit: I am sure there ar emany other instances
2 Likes
edited the epoch numbers missed out a 1:
309188 rather than 30988
Sorry for all the edits - its my first time
So in Summary:
-
It seems strance that all 3 tSoveriegn, Best FTSO, WorldsFTSO went down and came online at the same time (songbird epochs 309839 to 309858)
-
It looks like WorldsFTSO (0x08eb910e9288e5c6baf6e1a74d5d1d23284360a4) and tSoveriegn (0x66064b9755ff3c26c380be0fbe7f38df6222ba15) mgiht be sending similar prices (songbird epochs 309188 to 309195)
WorldsFTSO, tSoveriegn and Best FTSO are you able to explain why?
1 Like
These three have been explicitly tied to same node and admitted to sharing coin api subscription. For me that alone is bad for the data provider system but it looks like their algos are remarkably similar as well. I would be in favor of chilling these providers and hopefully after they are chilled they come back and work indecently.
4 Likes
In the trio’s defense, they did explicitly say that flare gave them the approval to share a node when applying for/receiving the flr grant (imo, not healthy for the network and shouldn’t have been allowed by flare.) This was confirmed by flare. Expect a heavy defense by best… they have been on the network for a long time and we owe them the benefit of the doubt. With that said, the similarities of the algos themselves are inexcusable and best knows better. At this time, 4dads as a team echos @Brent-4Dads sentiment until we hear a rebuttal.
2 Likes
Edit from above post. Indecently=Independently
1 Like
I believe Best has lost the right to benefit from doubt based on this evidence. Perhaps they had received approval for utilizing the same infrastructure but having the same submission for both ETH and BTC at any given time is a clear tell. Not to mention these providers have all started submitting accurate pricing at the same time.
These providers should all be chilled.
2 Likes
Have more than enough information on above.
I agree with chilling these FTSO’s.
1 Like
Sharing a node may be fine, but sharing the very same centralized feed means that the submissions are highly correlated each other. The algorithms are also not much different, given that they produced the same result in case of feed failure, as shown by the provided evidences.
2 Likes
I believe it was mentioned, in the early days, that sharing a node was a possibility, but in recent times it’s been suggested otherwise.
Still, it’s an easy fix, spin up a dedicated node for each of the three providers.
I support chilling these providers
So we have, identical data, same node which probably causes identical down time, sharing APIs datafeeds running slightly different algo or same algo and slightly different model. They can just run one provider together instead of 3 right? Why build 3 providers if you are close buddies like this and risk being a colluder. Fishy.
1 Like
Too much to manage maybe?
Maybe, which is why they pool resources and divide their costs / 3. But they also receive a boost on all 3 providers, so that doesn’t balance.