Common Price Fluctuations (spikes) between Ivy Oracle + Anon

AtlasTSO · August 15, 2024, 12:37pm

Provider Name(s):
Anon
@ivy_oracle

Provider Delegation Addresses:
Anon Flare address: 0x1FF09da268c7bA834aBCC6d7Ba64D2B7dDC4fb37
Anon Songbird address : Unknown
Ivy Oracle Flare address: 0x64D998BC81424131E5aF05071263fDeBD1a82986
Ivy Oracle Songbird address: 0xa174d46ef49d7d4a0328f9910222689e9eab2f45

Network: Evidence on Flare, Action required on Both Networks

Overview:
Good afternoon and sorry for my bad English,
Im gonna present data that shows many price spikes common between these 2 providers in a number and scale great enough that i feel is pretty telling of something being off.
I have run an analyzer for 7M Flare epochs ending in June and these 2 providers showed up in over 50 cases to have spikes ranging from 700000% to 3%. I picked only a few dozen because i feel they represent the case enough.
All the other providers had 0-3 mentions in the same epoch as others so this feels overwhelming.

This will be a long thread and i ask the rest of the members to look at each piece of data individually and form their own opinion, also i ask you to reserve judgement until the mentioned providers have a chance to give their own side of the story.

As the network gets more mature and dapps start to use the data we provide i would also like to introduce the first vote that takes into consideration price protection mechanisms and ask people to post their opinions on it, because these 2 providers post such erroneous prices that inhibit the FTSO system.

1st Offense: Yes on both (Ivy Oracle and Anon)
Previously Chilled: No on both (Ivy Oracle and Anon)

Timeframe for Open Discussion: 10 Days

Request of Management Group Members: AtlasTSO respectively asks all MG members for input on the evidence provided in this proposal and to participate in subsequent onchain voting following the discussion period. I also ask the opinions of the members on if price protection should be something that should be considered an offence.

Request to the Flare Foundation: If voting meets quorum, AtlasTSO respectfully requests that the Foundation action a Two Epoch chill of Anon in Flare Network and Ivy Oracle in Songbird and Flare Network

Evidence:

XRP
Case 1
Anon = 208k
Ivy = 5M

https://flare-ftso-monitor.flare.network/price?currency=XRP&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1711071013&startTime=3h

Case 2
Anon = 1.87M
Ivy = 50k

https://flare-ftso-monitor.flare.network/price?currency=XRP&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1711132573&startTime=3h

Case 3
Anon = 555k
Ivy = 12k

https://flare-ftso-monitor.flare.network/price?currency=XRP&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1713059653&startTime=3h

Case 4
Anon = 895k
Ivy = 3M

https://flare-ftso-monitor.flare.network/price?currency=XRP&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714066573&startTime=3h

ADA
Case 1
Anon = 19M
Ivy = 15k

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1713115453&startTime=3h

Case 2
Anon = 9.8M
Ivy = 3.7M

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714066573&startTime=3h

Case 3
Anon = 3.4M
Ivy = 2.8M

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714674613&startTime=3h

Case 4
Anon = 1.5M
Ivy = 120k

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1716873673&startTime=3h

Case 5
Anon = 18M
Ivy = 9.8M

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1717126033&startTime=3h

Case 6
Anon = 1.6M
Ivy = 1.5M

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718075353&startTime=3h

Case 7

https://flare-ftso-monitor.flare.network/price?currency=ADA&relative=true&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718717413&startTime=3h

ALGO
Case 1

https://flare-ftso-monitor.flare.network/price?currency=ALGO&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718075353&startTime=3h

Case 2

https://flare-ftso-monitor.flare.network/price?currency=ALGO&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718717413&startTime=3h

ARB
Case 1

https://flare-ftso-monitor.flare.network/price?currency=ARB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718607973&startTime=3h

BNB
Case 1
Anon = 893K
Ivy = 14M

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1711070653&startTime=3h

Case 2
Anon = 5.9M
Ivy = 1.6M

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1711132213&startTime=3h

Case 3
Anon = 1.3M
Ivy = 460k

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1713352693&startTime=3h

Case 4
Anon = 9.3M
Ivy = 900k

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1713392293&startTime=3h

Case 5
Anon = 5K
Ivy = 1.9K

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1717816333&startTime=3h

Case 6
Anon = 1.4M
Ivy = 1.2M

https://flare-ftso-monitor.flare.network/price?currency=BNB&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1718075173&startTime=3h

MATIC
Case 1
Anon = 1M
Ivy = 470K

https://flare-ftso-monitor.flare.network/price?currency=MATIC&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714669933&startTime=3h

Case 2

https://flare-ftso-monitor.flare.network/price?currency=MATIC&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1715065573&startTime=3h

SOL
Case 1
Anon = 8M
Ivy = 480K

https://flare-ftso-monitor.flare.network/price?currency=SOL&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1713202033&startTime=3h

Case 2
Anon = 3.5M
Ivy = 1.5M

https://flare-ftso-monitor.flare.network/price?currency=SOL&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714066213&startTime=3h

Case 3
Anon = 651K
Ivy = 2.6M

https://flare-ftso-monitor.flare.network/price?currency=SOL&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714669933&startTime=3h

USDT
Case 1

https://flare-ftso-monitor.flare.network/price?currency=USDT&relative=false&providerAddress=0x64d998bc81424131e5af05071263fdebd1a82986,0x1ff09da268c7ba834abcc6d7ba64d2b7ddc4fb37&endTime=1714989433&startTime=3h

ivy_oracle · August 15, 2024, 10:16pm

Thank you @AtlasTSO for compelling together all information and opening this discussion. Ivy Oracle has been operating on the flare network for more than 2 years and have always remained independent.

Argument

The evidence you provided proves that FTSO provider Anon is using similar approach to tackling the price data providing problem. It does not, however, prove that we are colluding in any way.

We are aware of the price spike and have a deep understanding of why they are happening (see Explanation section below). Evidence you provided proves without a doubt Anon is making the same mistake we are, but nothing more.

No Common Down Time

One approach to identifying collusion is by analysing down time. Colluders share resources such as servers, nodes and data, failure of a shared component causes all involved colluder down time simultaneously. Referring to previous chillings, synchronised downtime has always been a key evidence.

Here at Ivy Oracle we strive to achieve 0 downtime through resilient and highly available architecture.
Although our uptime is not perfect, we maintain our own complex architecture hosted on AWS and we continuously to make it better. Therefore, you can find no synchronised down time between Ivy Oracle and Anon. The reason for this is simple, Ivy Oracle is operated independently, in both personal and infrastructure.

No Ties on Collusion Tool

Another common approach for identifying collusion is to make use of the collusion tool on the FTSO Monitor, shows at 0.95 and 0.99, there is no relation between Anon and Ivy Oracle

Threshold: 0.95

Threshold: 0.99

Explanation for Common Spikes

Since March 21st, our team has taken the initiative to expand the pool of data used for price submission calculation. We hypothesised taking in a wider range of data type and channel type data would yield higher quality submissions. And we were confidence our algorithm was sophisticated enough to filter out any low quality data points.

The newly added data includes

ask and bid prices on the order book that are not yet executed in any trades,
lower volume CEX
price pair with less popular stable currency (eg. TUSD, DAI, FDUSD).

In May our team realised due to the addition of these data, our algorithm is unable to filter out data sources that cause extreme price spike. For example, low volume exchange with empty order book suddenly receiving extremely high or low asks or bids. We realised the limitation of our mistake and started the effort to fix that.

This effort was put on hold in favour of FTSOv2, but we have restarted that effort in August.

Next Step

We estimate that our effort in tackling the low quality data will be complete by the end of August. From which there will nolonger be any price spike from Ivy Oracle.

If there are any doubt from AltasTSO, other KYC’ed FTSO providers or any reputable 3rd party, our team is more than happy to schedule discovery calls to audit our code and algorithm, or review our AWS infrastructure (under NDA). We are proud of the code quality of our project, and we are committed to open communication to clear any issues.

Neil_AU · August 16, 2024, 8:48am

Thanks to @AtlasTSO for gathering the evidence and @ivy_oracle for your reply.

My opinion is that this is not a case of collusion with another party but rather Ivy Oracle running a second provider.

There’s no doubt in my mind that Ivy Oracle has developed their own code and can demonstrate that they run it on their own infrastructure. Reviewing that is a pointless exercise unless the ‘anon’ provider gives the same access for comparison purposes, which is unlikely to happen. I’d love to be proven wrong.

I struggle with idea there’s another random provider ‘making the same mistake’ and ‘tackling the problem’ in the same way. It’s not an upstanding provider we’re referring to, it’s an anon provider with similar success to Ivy.

‘No common downtime’ is somewhat irrelevant. If one provider can run with minimal downtime, it stands to reason their second provider would operate similarly.

The collusion tool on Flare isn’t currently useful due to the pro providers running the same sample provider code, which heavily skews the ties towards those providers. If those providers were removed, many of the relationships would be different, and the tool would be more useful, similar to its effectiveness on Songbird.

Hopefully other providers can review the above thoroughly and give their point of view.

ivy_oracle · August 17, 2024, 2:42am

Thank you @Neil_AU for joining the discussion.

I would like to discuss the baselessness of the current accusations being made against Ivy Oracle.

No Evidence For Operating Two Providers

There is no evidence provided that supports the claim that “Ivy Oracle” is running a second provider. There are no transactions or financial linkage between the providers in question; no submissions, reward or uptime patterns can be identified between the two providers, except for the price spikes.

Reviewing previously passed proposals on colluding providers, there are either admissions of collusion, or irrefutable patterns in submission. Neither of which have been presented here. The only proposal that came close was the “Sirius FTSO and HXK Oracle” proposal, in which spikes are backed up by admission of sharing said provider’s codebase and algorithm (see Reference section).

Price Spike is Not Evidence of Collusion

Price spike is the result of low quality data, not collusion. Based on the accusations, it is clear that the cause of price spikes is not well understood, and this section outlines why price spike happens, and it happens even in the absence of collusion.

Passing extremely large prices into a model results in extremely large submissions. As previously mentioned, Ivy Oracle has been using a wide range of data, including unexecuted ask and bid prices on the order book from all exchanges, high or low volume. Examples of extremely large asking prices from selected exchanges that are used by Ivy Oracle are included under the “Reference” section.

Cryptocurrency exchanges with publicly available order book data are finite. Two providers having price spikes only shows they retrieve data from the same publicly available data source. Ivy Oracle has collected order book data from a wide range of exchanges. Sharing price spikes is the natural outcome of this.

The price spike evidence provided by @AtlasTSO is incomplete, and does not represent the full picture. Since March 2024, Anon has experienced a total of 8249 price spike submissions, of which less than 0.6% are shared with Ivy Oracle. On top of that, Ivy Oracle is not the only provider that suffers from price spikes. Among them is FTSO AU (see Reference).

Edit: Per @AtlasTSO’s response, removing USDC and XDC, over a 6 months period (80,948 epochs) Anon experienced a total 212 spikes, of which less than 20% (41 spikes) are shared with Ivy Oracle, that is 0.05% of all Ivy Oracle’s submissions.

Again, Ivy Oracle is committed to providing high quality price data for the flare network, and is working tirelessly to update our code to eliminate price spike in our submissions.

Reference

Previously Passed Proposals

Pricing links between 3 SGB anonymous providers
- Providers in question have identical incorrect submissions and similar reward rate movements.
Pricing links between FLR Labs, Civil FTSO and two other anonymous providers
- Submission consistently outside reward band over significant period of time
Pricing links between BestFTSO and AilandFlare
- Near identical submission outside reward band over significant period of time
Coffee FTSO is a clone of LoveFTSO
- Submission consistently outside reward band over significant period of time
Sirius FTSO and HXK Oracle Same Dev and or Algorithm - #5 by Sirius
- Admission of algorithm sharing by provider
- Price spike

Large Ask Prices on Order Book

Picking from a few high volume and low volume exchange, one can easily find a large number of extremely high ask prices on their order book.

Binance BNB/DAI - ask prices up to 2K.

KuCoin ALGO/USDT - ask prices up to 400

Mexc XRP/USDT - ask prices up to 500,000,000 (500M)

https://www.mexc.com/exchange/XRP_USDT

50x BNB/USDT

Other Provider’s Spikes

FTSO AU (0x4990320858AE3528B645C60059281a66C3488888)

BNB/USD submission - 516,82,788.15865 and 73,824,796.69644
https://flare-ftso-monitor.flare.network/price?currency=BNB&startTime=1h&providerAddress=0x4990320858ae3528b645c60059281a66c3488888&endTime=1723779055

FTSO AU (0x4990320858AE3528B645C60059281a66C3488888)

XDC/USD submission - 74,868.27276
https://flare-ftso-monitor.flare.network/price?currency=XDC&startTime=1h&providerAddress=0x4990320858ae3528b645c60059281a66c3488888&endTime=1717788655

ON_STRIKE_DISBAND_MG · August 17, 2024, 3:15am

Can’t contribute anything of value here, other than saying 4dads is present, i appreciate both of your time spent on compiling evidence and counterarguments – on a personal note, appreciate you both @AtlasTSO and @ivy_oracle and the diligence on both sides – 4dads hasn’t discussed this internally, but we’ll vote (yes or no – doubtful it would be unanimous between us 4) to reach quorum if this gets to a voting phase

ON_STRIKE_DISBAND_MG · August 17, 2024, 4:05am

To address your question around price protections @AtlasTSO, yes, I believe every provider should implement some kind of safeguard.

Should it be a published guideline? Sure, but leave the methodology to the discretion of the provider or publish a few examples from the community.

Should it be a punishable offense? Sure, if the provider fails to safeguard within a reasonable timeframe after a warning — but be reasonable.

Similar guidelines should be posted for depeg protections as well on stable coins if we decide to implement.

Regarding this case with @ivy_oracle , no, I do not believe he should be punished for anomalies in his submission data. However, I believe your actual concern is collusion - which we will decide based on the facts and progression of the discussions.

Moe_Sun-Dara · August 17, 2024, 6:10am

We are observing this dicussion, but cannot contripute anytihng new at this moment in time. I would like to thank all in this chat.

Neil_AU · August 17, 2024, 8:05am

The price spikes between the two providers is the backbone of the case presented by Atlas, not what evidence doesn’t exist. What evidence doesn’t exist doesn’t negate what does.

Everything you mention is missing, and I agree it’s missing, could be easily addressed when creating a second provider: a new provider address funded by a CEX and submit using a dedicated node.

I’m sure there are many more spikes, but do ours happen at the same time as another provider to the frequency laid out in the proposal? That’s the crux of the proposal, many spikes happening at the same time as another provider, not that spikes are happening.

Neil_AU · August 17, 2024, 8:25am

I’m pleading with the owner of the provider 0x1FF09da268c7bA834aBCC6d7Ba64D2B7dDC4fb37 to put their hand up and join the conversation, your ability to submit on Flare is also under threat … it’s in your interest to comment and clear your name and that of Ivy Oracle.

AtlasTSO · August 17, 2024, 9:53am

Thank you all for participating @ivy_oracle @Neil_AU @ON_STRIKE_DISBAND_MG

Im gonna address things i read in these posts not in order.

Price fluctuations.
Yes they are happening to everyone but what is important is the scale and common timing. I feel there is a reason why 98 other providers dont have 30+ common spikes with each other. I was careful to not include spikes of low percentage value from the median 1-2% and i wouldnt bring a case where someone had only a handful of them shared with someone else.

Anon’s number of spikes.
The number ivy oracle mentioned is true BUT it can be attributed to one token USDC which i just didnt include even if it included common fluctuations with ivy oracle because it wouldnt be fair to him. Anon was off on USDC for months and if u exclude that token the number of fluctuations are actually a lot lower than u mention

I didnt use USDC and XDC because they are special tokens with limited markets so in all others tokens this anon has 39 spikes in the same epoch with @ivy_oracle and 2 spikes with solarius and ugaenn from the providers in the top20 by RR

Orderbooks causing price fluctuations
The outside values of an order book cannot cause such fluctuations unless the order book gets washed out.(Those with the % on the top cant be using them) These exchanges also seem ones that are usable by most others and im using all of them except the BNB one but i never had a situation like this.

As Neil mentioned a lack of something that has not even been brought to the table doesnt really mean anything and that is because its not there because we have not even looked.

I hope you can come back with an actual explanation of why 98 providers were not affected on the same epochs for so many times or why didnt 2 named providers (ivy oracle and 4dads for example) but just an anon that we cannot ask for anything.

As a sidenote, just want to say that all here dont do this because its fun or we have the time to spare but we genuinely want to safeguard the FTSO system. There is only risk in our part of losing the credibility we have established after years of operating.
I was careful i think and i tried to be impartial and not write an opinion piece about those 2 because frankly i dont know them and i dont have anything bad to say about them but write just public stats i found on a public website.
I dont plan to write anything else for this case at this time and i will leave the rest of the management group to make up their minds and continue conversation in a civilized manner like we do until now.

Also would like if possible people to consider offering their opinion on my other proposition about safety mechanisms

ON_STRIKE_DISBAND_MG · August 17, 2024, 5:01pm

@AtlasTSO i am glad you’re talking safety mechanisms as a FTSO community in public space – historically, these have always been private discussions amongst FTSOs. If we do reach consensus on such price outliers and/or depeg protections, we should sticky the guidelines in another post and kindly ask flare to link the guidelines in the FTSO repository or a flare knowledge base for visibility. Mainly, with regards to depeg protections, I want a published ratio so data providers can have a level playing field and common rules/protections (edit: a published ratio for when a depeg lever is tripped, a feed cuts off.)

ON_STRIKE_DISBAND_MG · August 17, 2024, 6:14pm

@ivy_oracle one thing i do want to mention is that these extreme orders in a orderbook would be common across all orderbooks and exchanges. 4dads only deals in last ticks or spot price, so I can’t really speak intelligently to those that use various levels of trade or order book data. However, i do not believe you would be as successful as your provider is without taking these anomalies into account. I do not need to know any level of details of how you process the order books, but if you’re saying these yolo orders that never fill caused these spikes, you success would be magnitudes lower and filled with erroneous data.

AureusOx · August 19, 2024, 12:15pm

Thank you for this thorough display of commonalities @AtlasTSO. It’s hard to argue against the fact that this “Anon” provider is closely tied with @ivy_oracle based on this evidence.

I am in agreement with @Neil_AU, I do not believe this is a case of collusion. To me, seems like a case of @ivy_oracle running a secondary provider. Unfortunately, without admittance this is hard to 100% prove. The management group must use their best judgement and come to consensus on wether or not the proposed evidence provides enough of a reason for a provider to be chilled.

In the best interest of the FTSO, I do believe the evidence is sufficient for a chill. Given that we already have a rampant collusion problem, we can not afford to have providers attempting to circumvent the voting cap as the bad actors do.

As @ivy_oracle has had some tenure here, my mind is open for further discussion. Running a second provider has crossed the mind of every provider and is a topic of discussion as a way to circumvent colluders’ efforts. I continue to choose not to run a second provider in order to not harm the Aureus Ox brand and for the best interest of other honest providers.

When running a secondary provider you take on both of these risks and must assume the consequences in cases where evidence is hard to argue.

uglykitty · August 19, 2024, 5:02pm

@AtlasTSO and @ivy_oracle Thank you for the effort you each have put forward.

After reviewing, I am in agreement with how/why the spikes happened. Im still having a hard time believing that the “Anon Provider” created the same algo on their own.

From what has been presented it seams that @ivy_oracle is running a second provider.

cdubb_FlareFTSO · August 22, 2024, 3:36am

Ok, we are watching this thread and other communication going on. Spike timings are suspect, though the prices are pretty far off on the evidence provided. Possibly heavily using similar exchanges without controls could help account for similar timeline of spikes. Discussions elsewhere of Ivy having dev assistance, when previously stating he did it all on his own, and this happening shortly before anonymous started submissions is suspect.

No yay or nay decision yet for this one. Currently we are waiting for more information and to see how the ongoing discussions with Ivy go.

FTSO_EU · August 27, 2024, 3:41pm

Thanks @AtlasTSO and @ivy_oracle. In our opinion there is not enough evidence here. Explanations make sense.