3rd Community Review of BDX Allocator

First Review https://github.com/filecoin-project/Allocator-Governance/issues/20 Second Review https://github.com/filecoin-project/Allocator-Governance/issues/142

Latest Allocator Compliance Review https://[compliance.allocator.tech/report/f03018484/1728866648/report.md](https://compliance.allocator.tech/report/f03018484/1728866648/report.md)

Given 2.5PiBs DataCap was given to: https://github.com/cryptoAmandaL/BDE-Allocator/issues/22 (2PiB) https://github.com/cryptoAmandaL/BDE-Allocator/issues/8 (0.5PiB)

#22 After KYC and the first round allocation, we found the retrieval success rate to be poor.

Then we have communicated with clients on this issue and get a response from this client. We decided to give him a chance to wait for sps' improvement.

When cid bot showed that client use more than 75% datacap, I got a new report.

Compared with two results in reports, we've seen a significant increase in the success rate of sps' retrieval. So we decided to give them a new round of allocation.

Compared with two results in reports, the retrieval success rate is decreasing. Client's sps are currently not capable of improving retrieval rates in a short time. So we closed this application and stop the work with this client.

@cryptoAmandaL Allocator Application Compliance Report First Review Second Review

1st Review score: 2.5PiB granted 2nd Review score: 2.5PiB granted

0.5 PiB granted to existing clients:	Existing Client Name	DC
NHGRI	0.5 PiB

2 PiB granted to new clients:	New Client Name	DC
ESGFand Pangeo	2 PiB

Example 1 - issue 8 The allocator has only allocated one allocation (512TiB) to this client since the last DC refresh, the client has not shown any improvement, so the allocator has closed the application.

I would like to point out, however, that the 3 previous CID reports were rather bad and the allocation of 512TiB seems to be unjustified.

Additionally, this dataset has already appeared multiple times in filecoin. The allocator should have checked and clarified these issues before granting the first allocation:

Example 2 - issue 22 The client requested 5 PiB and declared 7 data replicas of 1792TiB each. With this dataset size, a minimum of 12 PiB of data should be requested. It wasn’t raised by the allocator.

The dataset was stored multiple times:

SPs provided: f02169597 Shenzhen f02365890 Hongkong f0509981 Guizhou f01844118 Newyork f02834511 Hongkong

SPs Updated in the issue:	1st CID	2nd CID
f03099988 HongKong	0.00	0
f01084941 HongKong	0.00	5.35
f03100001 Shenzhen	0.05	0.04
f02046115 USA (actually HK)	0.00	0
f03030649 China	-	65.38
f03156722 HongKong	-	98.88
f03100003 Shenzhen	0.04	0.07

Additional SPs used for deals: f03100009 HK 0.00 f01975299 CN 0.00 f03100002 CN 0.05 f03100000 CN 0.07 f01084413 CN 90.91 f03214920 HK 0.00

The client updated the SP list after receiving the DC, so the SP list used for deals does not match the SP list provided in the form.

The first CID report showed that all seven SPs have retrieval rates below 1% or do not support spark. The allocator commented that this should be fixed, but granted another tranche.
The next report showed 6 additional SPs, about which the client did not inform the allocator via github issue. Only 1 SP has retrieval at a satisfactory level, while the rest are around 0.
Compared with two results in reports, we've seen a significant increase in the success rate of sps' retrieval. So we decided to give them a new round of allocation.

After the second tranche, only 2 SPs improved their results significantly, but the allocator considered that the results improved and that cooperation could continue. Considering the allocator's comment and report analysis, I don't understand where the significant increase was observed.

The last report shows that 5 out of 13 SPs have retrieval rates at a satisfactory level; 1 has retrieval around 30%, and the rest are 0%.
The client declared 7 replicas, but according to the report, there are 16 of them already.
The client declared that one of the SPs is from the US; according to the report, it is an SP from Hong Kong (f02046115). Suspected use of VPN.
The allocator declared in its application that it will require 4 geopolitical regions and 5 physical locations, but in the case of this application, the SPs come only from Hong Kong or China.

filecoin-project / Allocator-Governance

3rd Community Review of BDX Allocator #191