[DataCap Refresh] <2nd> Review of <Pluskit>

[PluskitOfficial]

Basic info

1. Type of allocator: [manual]

2. Paste your JSON number: [1016]

3. Allocator verification: [yes]

4. Allocator Application

5. Compliance Report

6. Previous reviews

• 1st review Outcome: 2.5 PiB

Current allocation distribution

Client name	DC granted
CrypBell	1.75 PiB
AWS	2 PiB
Nami	1.5 PiB

I. CrypBell

• DC requested: 2 PiB
• DC granted so far: 1.75 PiB

II. Dataset Completion
aws s3 ls --no-sign-request s3://oedi-data-lake/nrel-pds-building-stock/

III. Does the list of SPs provided and updated in the issue match the list of SPs used for deals?
Yes, the list of all used SPs is stated in advance. There were three SPs(f03216485/f02816097/f03214920) that have stopped working with the client are listed in advance but not actually used.

IV. How many replicas has the client declared vs how many been made so far:
10 vs 9. There is one replica less than promised.

V. Please provide a list of SPs used for deals and their retrieval rates

SP ID	% retrieval	Meet the >75% retrieval?
f01084413	41.95%	NO
f02826007	0.00%	NO
f03100009	0.00%	NO
f03228358	0.00%	NO
f02827996	0.00%	NO
f03066836	87.21%	YES
f03088052	92.34%	YES
f0671982	0.00%	NO
f03156722	88.90%	YES
f01431043	94.25%	YES

I. AWS

• DC requested: 2 PiB
• DC granted so far: 2 PiB

II. Dataset Completion
s3://4dn-open-data-public/

III. Does the list of SPs provided and updated in the issue match the list of SPs used for deals?
Yes, the list of all used SPs is stated in advance. There were three SPs(f0420161/f01844043/f03251993) that have stopped working with the client are listed in advance but not actually used.

IV. How many replicas has the client declared vs how many been made so far:
9 vs 10. There is one replica more than promised.

V. Please provide a list of SPs used for deals and their retrieval rates

SP ID	% retrieval	Meet the >75% retrieval?
f01084413	41.94%	NO
f03231666	94.41%	YES
f03216485	81.26%	YES
f03228358	0.00%	NO
f03233966	0.00%	NO
f01660795	93.03%	YES
f01975299	95.11%	YES
f03066836	87.28%	YES
f03099987	97.00%	YES
f03192503	0.36%	NO
f02828242	96.21%	YES

I. Nami

• DC requested: 3 PiB
• DC granted so far: 1.5 PiB

II. Dataset Completion
https://1drv.ms/f/s!AiKLgLredLbdcGp-eHSe5ImMSC8?e=aCtA6V

III. Does the list of SPs provided and updated in the issue match the list of SPs used for deals?
Yes, the list of all used SPs is stated in advance. There were three SPs(f03156722/f02816097/f03251993) that were stated in advance but not used thereafter.

IV. How many replicas has the client declared vs how many been made so far:
10 vs 5. It is currently the first round of storage, which is temporarily five replicas less than promised number.

V. Please provide a list of SPs used for deals and their retrieval rates

SP ID	% retrieval	Meet the >75% retrieval?
f02029742new	92.70%	YES
f01660795	93.03%	YES
f03300709	93.29%	YES
f03088052	92.36%	YES
f03099987	97.00%	YES

Allocation summary

7. Notes from the Allocator
   Since this round of distribution, we have strengthened the review of retrieval success rate and SPs list matching degree.
   In terms of retrieval rate review, we have inquired and followed up on less than 75% of SPs, and we will accept the clients’ reason if it is judged to be basically reasonable. However, we found that the level of rigor was not enough, and we will further review them on a case-by-case basis and ensure that the reasons for the problematic SPs are sufficiently credible.
   In terms of SPs’ update review, we check whether the SPs that have been used have been promised by the clients in advance, but we do not check whether the SP been promised in advance has been actually used, and this point will be strengthened in the future to ensure that the full match before and after use.

8. Did the allocator report up to date any issues or discrepancies that occurred during the application processing?
   No.

9. What steps have been taken to minimize unfair or risky practices in the allocation process?
   On the one hand, we strengthened the review to further enhance the review of data repeatability, SPs update and retrieval rate. On the other hand, we reduced the allocation amount to suspicious signs, such as [DataCap Application] <CrypBell> - <End-Use Load Profiles> PluskitOfficial/bookkeeping#11.

10. How did these distributions add value to the Filecoin ecosystem?
    We actively engage with potential clients and try to steer them to the Filecoin network.

11. Please confirm that you have maintained the standards set forward in your application for each disbursement issued to clients and that you understand the Fil+ guidelines set forward in your application
    Yes.

12. Please confirm that you understand that by submitting this Github request, you will receive a diligence review that will require you to return to this issue to provide updates.
    Yes.

[filecoin-watchdog]

CrypBell

• Data was stored previously, yet this argument was already raised in a previous review. 61% of the data has no retrievability.
• The list of SPs should be updated in the original thread/application, as it is difficult to compare based on comments.
• SP f01084413 potentially operates under a VPN/PROXY, which is forbidden according to allocator rules. Do allocators use any tools to monitor this and detect such cases? Since this is only a potential indication, the client should still provide an explanation.
• The data preparation step is not described, meaning the community has no ability to connect sealed data to the original files or to recreate the preparation steps.

4DN Data Coordination and Integration Center

• Unique data stored by the client is 514.18 TiB, which is almost twice the declared size of a single copy (270 TiB).
• SP f01084413 potentially operates under a VPN/PROXY, which is forbidden according to allocator rules. Do allocators use any tools to monitor this and detect such cases? Since this is only a potential indication, the client should still provide an explanation.
• Retrievability on part of the SPs is “0”, yet the client explained that they stopped sealing to problematic providers.

Nami

• SP f03099987 is sealing over 30% of the data.
• 5 stored copies vs. 10 declared, but this number is increasing.
• Retrievability on all SPs is above 90%.

As previously pointed out by the watchdog review, duplicated data was found on the network, raising concerns. However, since then, the allocator has not provided any explanation or clarification to clients regarding this issue.

Additionally, the site https://pluskit.io/ is not working. Could you clarify whether the tools mentioned in your application and README file (link), including those shown in the screenshots, are operational and usable?

[Kevin-FF-USA]

HI @PluskitOfficial.
Was there anything you'd like to add in response to the Watchdog before this moves forward to Governance reviews?

[PluskitOfficial]

Yes, @Kevin-FF-USA, we'll get back to @filecoin-watchdog in a couple of days.

[PluskitOfficial]

@filecoin-watchdog @Kevin-FF-USA
CrypBell

Data was stored previously, yet this argument was already raised in a previous review. 61% of the data has no retrievability.

We previously understood that we only needed to strictly review the data repeatability of subsequent new applications. We will pay attention to it in the future.
As for those SPs that are not retrieved, we have checked and inquired one by one, and these SPs are the clients have stopped cooperating with.

The list of SPs should be updated in the original thread/application, as it is difficult to compare based on comments.

The client has updated the SPs list several times in advance as required, and we have also checked the list information one by one to confirm that the SPs list is used consistently. Among them, three SPs are declared to be used in advance, but are not used later, we think this is also in line with the requirements. In the follow-up review, we will ask clients to change the SPs’ list in the original thread to be consistent with the SPs list actually used.

SP f01084413 potentially operates under a VPN/PROXY, which is forbidden according to allocator rules. Do allocators use any tools to monitor this and detect such cases? Since this is only a potential indication, the client should still provide an explanation.

We currently do not have the tools to monitor this situation, we will try to find such kind of tools in the future. Besides, we will ask the client to provide an explanation.

The data preparation step is not described, meaning the community has no ability to connect sealed data to the original files or to recreate the preparation steps.

We will ask the client to specify more detailed data preparation steps in the original thread of the application.

4DN Data Coordination and Integration Center

Unique data stored by the client is 514.18 TiB, which is almost twice the declared size of a single copy (270 TiB).

We did not pay attention to the size of the storage quantity before, and we will ask the client to explain the excess stored data.

SP f01084413 potentially operates under a VPN/PROXY, which is forbidden according to allocator rules. Do allocators use any tools to monitor this and detect such cases? Since this is only a potential indication, the client should still provide an explanation.

We currently do not have the tools to monitor this situation, we will try to find such kind of tools in the future. Besides, we will ask the client to provide an explanation.

Retrievability on part of the SPs is “0”, yet the client explained that they stopped sealing to problematic providers.

Yes, we have checked the SPs list, and for the part “0”, the client explained that he has stopped cooperation.

Nami

SP f03099987 is sealing over 30% of the data. SP f03099987

We were aware of this problem and have asked the client for an explanation. The client pointed out that the packaging speed is not the same which leading to this problem. The number of other SPs packaging will be increased in the future to ensure that it will not exceed 30%.

5 stored copies vs. 10 declared, but this number is increasing.

Yes, when we submitted the data, we looked up 5 stored copies, and now it has been updated to 8.

Retrievability on all SPs is above 90%.

Yes, the client's retrieval success rate is currently performing well.

As previously pointed out by the watchdog review, duplicated data was found on the network, raising concerns. However, since then, the allocator has not provided any explanation or clarification to clients regarding this issue.

We have paid attention to the problem in the new application, but did not give special explanation to the previous issues. We will do this in the future.

Additionally, the site https://pluskit.io/ is not working. Could you clarify whether the tools mentioned in your application and README file (link), including those shown in the screenshots, are operational and usable?

The website is still operational and can be opened normally. However, because the staff has left office, there are problems with data access. The normal data will be restored after the new employees are in place. Besides, our subsequent focus will be on client engagement.

[filecoin-watchdog]

@PluskitOfficial Thank you for your response and clarifications regarding data retrievability and SP usage. We appreciate your commitment to resolving any outstanding concerns. Please ensure that the data preparation process is well-documented so stored data can be linked back to the original sources. In addition, the website https://pluskit.io/ will provide a good example of allocator involvement.

[PluskitOfficial]

@filecoin-watchdog Thank you! We'll continue trying our best to engaging in the work.

[PluskitOfficial]

@Kevin-FF-USA @filecoin-watchdog Is there any further questions?

[Kevin-FF-USA]

Hi @PluskitOfficial
Thanks for your patience, this application for refresh is currently undergoing final Governance review. You should see an update from Galen later this week with actionable input.