Our team has been fully prepared for KYC since January when we submitted our towolabs pull request. We have been patiently waiting for the process to be completed.
You asked if our price should be low if Binance does not respond. Here’s a more detailed explanation of our equation:
Our price is calculated using the formula: our_price = 0.1 * Kraken + 0.7 * Bitrue + 0.2 * Binance.
If Binance becomes 0, we use a trick to multiply the calculated price by 1.25.
We do this because the weight sum should be 1.0, but if some exchanges are not responding, the total weight is only 0.8. So we multiply by 1.25 (=1.0 / 0.8).
Mathematically, if exchanges that respond with low prices are not responding, our calculated price becomes high. If exchanges that respond with high prices are not responding, our calculated price becomes low.
I hope this explanation helps. Let me know if you need more technical details or have any other questions.
Several teams have gone through KYC but still had a dev that built their TSO algo that was “hired” from a freelance service. I.e. toadz, fat cats, oracle swap. All KYCed team with annon tso devs. There is a clear pattern. You have already stated that you team was brought together with a similar method. It’s very suspicious that you avoid directly answering this question. I’ll ask again. Is your algo dev annon? Where was he found and hired from?
What does this mean?
We have been fully prepared?
Where is your dev from?
As those other providers have shown, there is a clear path forward but it does require a bit of honesty and an effort to rebuild in house in a way that contributes to the robustness of the system.
We’re happy to discuss that question with the flare foundation if necessary. We’re in no obligation to share any of that type of information with you or another other data provider.
The purpose of this forum is for us to discuss and make an informed decision on whether or not you should be chilled. The information you are providing does not refute any of the doubts that I have. This forum is where the foundation will look at the evidence to determine whether a vote gets vetoed or not. There is a clear pattern as to how these scamming devs have infiltrated data providers and your refusal to answer simple questions that would still protect the privacy of your dev is not very promising. You have already said how your team was brought together. I’m simply asking if the dev that designed your algorithm came from the freelance service you mentioned? I’m not saying there is anything malicious being done on your part but many others have made what they thought to be a good hire that turned out to be a very sly group of naughty devs.
Kindly provide comprehensive evidence of collusion. These questions raise significant concerns regarding potential breaches of privacy and the protection of our algorithm, even down to the smallest details. Considering your role as a data provider, there is a risk of a conflict of interest, as it might lead to attempts to trace and influence our developer to join your team. While we acknowledge the possibility of discussing these questions with the flare foundation, sharing them with other data providers could be detrimental to preserving the decentralisation of the network.
I think your responses to the questions provide plenty of evidence regarding collusion.
You are right, you have no obligation to provide anything.
Your intent seems to be to deflect, remain obtrusive and provide hollow responses to genuine questions that are being asked, none being that difficult.
That said, if you are using Intellectual Property that does not belong to you, that has been paid for by an entity with plenty of legal representation, privacy will be the least of your concerns.
The logic that anyone on here is looking to onboard your “Dev” is ludicrous, not to mention the irony of you wanting to preserve the integrity of the network.
Thank for your time.
Well, as far as I’m concerned, the more they try to justify themselves, the more certain I am that they’re not being honest.
Based on the evidence gathered by Neil, we support chilling both providers.
Considering your role as a data provider, there is a risk of a conflict of interest, as it might lead to attempts to trace and influence our developer to join your team.
which itself would be collusion and so a proposal wouldbe brought forward against said data providers as it centralsies the FTSO/STSO
well said - responses dont make sense
You do realize this forum and everything said here is because Flare foundation has deemed it necessary that such discussions should be persued? This isn’t just some random TSO’s coming together and getting rid of competition. This (the forum, not this post in particular) is a FF backed initiative to get rid of suspicious players. And when the motion is finally put to them they will be looking at all the sensless responses you have written here in your defense - I wonder how they will percieve your legitimacy after that.
The fact that you keep deflecting instead of answering simple questions is just proving our point that you and your team are in fact suspicious. How exactly do you think we could track down and influence a dev after you say he was hired from a job board? Its a simple question that has nothing to do with decentralisation. As far as Im concerned all users of your products should be worried that they have a bad actor working as a dev for your team. I hope for your sake the dev doesn’t have the private keys of your provider, though I am all the more confident you are just using an API.
Oh and comprehensive evidence has been provided, its in the first comment to this thread. Maybe take a real look at whats being said.
You are correct, you are not obligated. I have other matters to look into, so will leave this metadata here for the public to decide if the timelines are a bit suspicious – no need to address, I have more if we’d prefer to discuss directly with FF instead and just move to vote.
Timeline, 5 days from “looking for developer” to Towo Commit/Submissions
Jan 8 2023 - Jan 13 2023
Social Media Post (Jan 8)
“Looking for developers. Let’s build a FTSO”
Scrape: data-id=“urn:li:comment:(ugcPost:7009863845481431040,7017703436729151488)”
Presumably: Sun, 08 Jan 2023 04:08:01 GMT (UTC)
GIT Towo Commit Metadata (Jan 13)
From 0288432488aaa3e1b3b8d658279d0f44318938f3 Mon Sep 17 00:00:00 2001
From: XCBA [email protected]
Date: Fri, 13 Jan 2023 18:18:54 +0900
Subject: [PATCH] add FLRLabs FTSO
…14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png | Bin 0 → 85000 bytes
…43F0a819DCCddEb05A282c78027873aB5Be35cf5.png | Bin 0 → 85000 bytes
bifrost-wallet.providerlist.json | 16 ++++++++++++++++
3 files changed, 16 insertions(+)
create mode 100644 assets/0x14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png
create mode 100644 assets/0x43F0a819DCCddEb05A282c78027873aB5Be35cf5.png
diff --git a/assets/0x14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png b/assets/0x14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png
new file mode 100644
index 0000000000000000000000000000000000000000…1d425ba0c776e39b3264fd002b8cdce1723d8714
Thank you for this information
Seeing evidence and responses to allegations on social media early on, we were leaning towards collusion. The evidence provided here and the responses from both sides seems to also point to collusion. Compelling information gathered. It just seems odd to have same spikes and matching submit paths if different algorithms were in use. We currently support the chill, but will keep reviewing the forum until time to vote to be fair.
I checked your day 1 performance on your Songbird provider. The first thing that strikes me is that you start with more than 50% success rate. That’s the first red flag as starting a new provider with that kind of success rate is ridicilously high.
I noticed you had one price spike the first day, and guess what, LoveFTSO had the same price spike. This happened price epoch 230905 (Jan 10th 2023). To me, this is a smoking gun evidence. Again, it’s beyond any reasonable doubt your developer is colluding with, or is the same developer as LoveFTSO.
It’s more and more evident you are only trying to deceive us by making up “plausible” stories to sway those who are in doubt whether you are legit or not. I’m cannot claim that you are aware that your developer is a colluder but I’m sure he is.
I don’t think a single chilling is enough if FLRLabs returns after a potential first chilling and continues with the same success rate as now.
Link to FLRLABS vs LoveFTSO comparison day 1 of FLRLABS below
https://songbird-ftso-monitor.flare.network/price?currency=BTC&startTime=1d&providerAddress=0x2602f6456287a167b0214c3dbe8b4162f0ec5409,0x43f0a819dccddeb05a282c78027873ab5be35cf5&endTime=1673391648&relative=true
Here’s the final piece to make this FF veto proof – Same developer on both commits. My advice, handle this like OS, Fat Cats and OG Toadz did – the truth will set you free:
Love FTSO Commit 12/21/2022
From 65a7dcff7dec5fb5d75e804356e8fcffc2d1c3a4 Mon Sep 17 00:00:00 2001
From: XCBA [email protected]
Date: Wed, 21 Dec 2022 02:10:31 +0900
Subject: [PATCH] add: logo and description.
…2602f6456287A167B0214c3dbe8b4162f0Ec5409.png | Bin 0 → 13840 bytes
…beC604772722fe2E7A2a7b96339fFA71CeaBF4e7.png | Bin 0 → 13840 bytes
bifrost-wallet.providerlist.json | 16 ++++++++++++++++
3 files changed, 16 insertions(+)
create mode 100644 assets/0x2602f6456287A167B0214c3dbe8b4162f0Ec5409.png
create mode 100644 assets/0xbeC604772722fe2E7A2a7b96339fFA71CeaBF4e7.png
diff --git a/assets/0x2602f6456287A167B0214c3dbe8b4162f0Ec5409.png b/assets/0x2602f6456287A167B0214c3dbe8b4162f0Ec5409.png
new file mode 100644
index 0000000000000000000000000000000000000000…2e7d329813fdc714bed9c55cba4258a12a4ec2fe
GIT binary patch
literal 13840
FLRLABS Commit 1/13/2023
From 0288432488aaa3e1b3b8d658279d0f44318938f3 Mon Sep 17 00:00:00 2001
From: XCBA [email protected]
Date: Fri, 13 Jan 2023 18:18:54 +0900
Subject: [PATCH] add FLRLabs FTSO
…14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png | Bin 0 → 85000 bytes
…43F0a819DCCddEb05A282c78027873aB5Be35cf5.png | Bin 0 → 85000 bytes
bifrost-wallet.providerlist.json | 16 ++++++++++++++++
3 files changed, 16 insertions(+)
create mode 100644 assets/0x14b424Bc9E9B8091A40384ff3d8F0C3DfC1a2879.png
create mode 100644 assets/0x43F0a819DCCddEb05A282c78027873aB5Be35cf5.png
Based on the evidence reported and considering how evasive the answers given by the interested party was, we totally support the proposal.