Community Review of CloudX Lab Allocator

[CloudX-Lab]

Latest Allocator Report: https://compliance.allocator.tech/report/f03019835/1725323234/report.md

2 clients receiving allocations over several rounds.
CloudX-Lab/filecion#10
CloudX-Lab/filecion#14

KYC: We request clients to send us an email to confirm their identity.

CloudX-Lab/filecion#10 (comment)

CloudX-Lab/filecion#14 (comment)

SP list: Our clients have porvided their sps in their applications and given update to us later.

CloudX-Lab/filecion#10 (comment)

CloudX-Lab/filecion#14 (comment)

Retrieval Success Rate

Retrieval report - https://compliance.allocator.tech/report/f03019835/1725323234/report.md

The majority of the sps are supporting the retrieval, I will urge the clients to communicate with the sps, and continue to selecte sps who support the retrieval.

We will continue to focus on the client's condition and keep communicating with the client in time, so that our allocator allocation is reasonable to help data stored in the Filecoin network and promote the development of the Fil+ project.

[filecoin-watchdog]

Allocator Application
Allocator compliance Report

Example 1
There is a strange allocation on April 16 of 35 GB:

There is no GitHub issue to check what the case is.

Example 2
Allocator established in their Application that the allocation schedule will be 5% of the total DC requested, or 50% of the weekly DC requested, whichever is lower. The client asked for 4,5 PiB and 512TiB weekly, which means the first tranche should be 225TiB. The first tranche was 512 TiB. Why did the Allocator decide to change their schedule?

SPs provided:
f02207907-US
f02365890-HK
f01106276-CN
f02169597-CN
f01844999-US

The client has updated their SPs after the first allocation to be:
f03139960-CQ
f01082888-HK
f01084913-HK
f02824216-NB
f03088052-HK
f02370792-SZ

No explanation for changing SPs was made on the GitHub issue. Has the allocator made sure it was a legitimate change?

All of the SPs have a retrieval rate below 1%.

Example 3
Allocator established in their Application that the allocation schedule will be 5% of the total DC requested, or 50% of the weekly DC requested, whichever is lower. The client asked for 10 PiB and 512TiB weekly, which means the first tranche should be 250TiB. The first tranche Was 100 TiB. Why did the Allocator decide to change their schedule?

The first tranche was on June 14, while the Client didn’t answer all the questions (including KYC) until June 20. Why did the Allocator send the first tranche before confirming all necessary information with the client?

Also, the tranche looks like it was triggered manually because no GitHub mention is visible.

Around 50% of used SPs have a retrieval rate of less than 75% (5 out of 10).

[CloudX-Lab]

@filecoin-watchdog

Example 1
This is just a test for trigger.

Example 2
Considering the amount of data they have in a single replica, 711 TiB, we believe that the first allocation should be increased properly. So we decided in the first round to allocate 512TiB.
Our allocators support our clients in making timely adjustments to their plans, as long as they are compliant, updating in a timely manner will help their data distribution go better.
The client spoke with sps about the problem of retrieval, and sps responded that they are upgrading the program and have resumed the retrieval gradually. Now these nodes are waiting for the spark to do retrieve.

Example 3
Since we are not very skilled in the work of signing, we signed and approved 100TiB by accident while reviewing the application. After we interviewed the client and allocated them the first round, we observed the client's process of storing data and concluded that the client was able to do a qualified data storage. That's why we didn't take back the 100 TiB.
https://check.allocator.tech/report/CloudX-Lab/filecion/issues/10/1723451507861.md
https://check.allocator.tech/report/CloudX-Lab/filecoin/issues/10/1726754527861.md
Comparing the client's reports in different time periods, it can be seen that the client is improving the distribution and the number of nodes supporting retrieval is increasing.
The client keeps giving me feedback about sp. For the current problems, they promised to deal with them after the National Day holiday and resume the retrival.

As we continue to collect the shortages of our past work and keep the good parts, we will continue to do our best to do a good job with allocator.

[galen-mcandrew]

In your allocator application, you claimed you would be using standardized and software-based allocations to clients. That is not the same as making individual decisions for each client, according to various and ambiguous details. In the future, you will need to adhere to your stated allocation tranche schedule.

Given the details in these reports: https://check.allocator.tech/report/CloudX-Lab/filecoin/issues/14/1727796211309.md & https://check.allocator.tech/report/CloudX-Lab/filecion/issues/10/1723451507861.md, we are seeing these issues:

• duplicate data
• low retrieval rates
• low regional distribution (only 1-2 regions)

Given this review, we are requesting that the allocator verify that they will uphold all aspects & requirements of their initial application. If so, we will request an additional 2.5PiB of DataCap from RKH, to allow this allocator to show increased diligence and alignment.

@CloudX-Lab can you verify that you will enforce program and allocator requirements? (for example: public diligence, tranche schedules, and public scale retrievability like Spark). Please reply here with acknowledgement.

[CloudX-Lab]

@galen-mcandrew Yes. We will improve our work and manage the cooperation with each client carefully.

[Kevin-FF-USA]

DataCap has been partially refiled.
f2o2obeorcnu4zp6zbs6i2pxkzqppxyxommqpsefi