[DataCap Refresh] <1st> Review of <SDMR>

[Hunter3576]

What type of Audit did you opt into? Choose from dropdown

Public Open Data

What is your JSON hash (starts with 'rec')

rec5sJJ5lyEULdxDR

Link to your allocator operations description

https://github.com/Hunter3576/SDMR

Compliance Report

https://datacapstats.io/allocators/f03145507/reports/62972607-31eb-441f-9257-0170c405eaab

Previous Reviews

It's the first time.

Client Allocation Table

Client name	DC granted
Shanghai Youhe Medical Technology Co., Ltd.	2.5 PiB
LiKONG	1.37 PiB

Client-specific Breakdown

Client 1

I. Shanghai Youhe Medical Technology Co., Ltd.

• DC requested: 5PiB
• DC granted so far: 2.5PiB

II. Dataset Completion
(Provide deal(s) containing sample(s) of data)
https://drive.google.com/drive/folders/18_efiSz4cYJ_xVxEzTMwgIAirdTBeG6b?usp=drive_link
III. SP Match
(Does the list of SPs provided match the list in the CID report?)
yes
IV. Replica Count
Promised vs delivered:
10 vs 10

V. SP Retrieval Performance

SP ID	% retrieval	Meets >75%?
f03081952	22.44%	NO
f03373337	0.00%	NO
f03373373	5.94%	NO
f03373733	3.34%	NO
f03377773	4.87%	NO
f03377778	0.00%	NO
f03567896	16.44%	NO
f03567899	10.29%	NO
f03577777	2.94%	NO
f03577778	9.88%	NO

---

Client 2

I. LiKONG

• DC requested: 4PiB
• DC granted so far: 1.37PiB

II. Dataset Completion
(Provide deal(s) containing sample(s) of data)
http://www.likongzhineng.com/uploads/soft/20250625/1-250625160209122.pdf
http://www.likongzhineng.com/uploads/soft/20250625/1-250625155922Z2.pdf
http://www.likongzhineng.com/uploads/media/20230417/1-23041G55J2145.mp4
http://www.likongzhineng.com/uploads/media/20230417/1-23041G55615133.mp4
III. SP Match
(Does the list of SPs provided match the list in the CID report?)
yes
IV. Replica Count
Promised vs delivered:
9 vs 6

V. SP Retrieval Performance

SP ID	% retrieval	Meets >75%?
f03620433	16.00%	NO
f03620434	20.00%	NO
f03620441	29.79%	NO
f03620442	42.42%	NO
f03620446	0.00%	NO
f03620447	4.26%	NO

---

(Add more client blocks as needed)

Notes from the Allocator

It was found that the retrieval rate of SP corresponding to 2 clients fluctuated a lot, and by checking the slack, it was found that some people also encountered the same problem

Issues or discrepancies reported?

yes

Investigated suspected VPN situation
Hunter3576/SDMR#7 (comment)

Failure of retrieval rate

Steps to minimize unfair or risky practices

Issuance of datacap in batches as per official requirements and due diligence before issuance, manual triggering of bots after issuance, report viewing and timely raising of any issues

Value to the Filecoin ecosystem

Bringing in more area SPs

Confirm you maintained your application standards for all client allocations

Yes

Do you understand that a diligence review will follow and require updates to this issue?

Yes

[filecoin-watchdog]

[DataCap Application] Shanghai Youhe Medical Technology Co., Ltd. – Enterprise Open Data # 4
http://43.228.212.174:7000/piece/baga6ea4seaqfknykclzy27d5anslu7scbi2xxmlwe5euxtqkerthdrkvhwcbwny

• After 18% of the download, the server returned 404 Not Found. This issue was repeated several times at different times of the day.
• Although an index file was provided, it contains no context for the file names or pieces. A potential user trying to download a specific dataset would not know which piece contains the desired content.
  For example: if I were searching for data on surgical procedures, how would I know which piece to download? Without such information, the dataset is not meaningfully accessible.
• Spark retrievability is low and should be closer to the target of 75%. RPA retrievability is much better, but real HTTP download testing was not possible due to the repeated 404 errors.
• In Round 6, the maximum replica limit is 8. The allocator should be aware of and comply with this rule, as they confirmed it during the renewal of the application.
• Evidence of proper diligence towards client identification was provided.

[DataCap Application] LiKong – Enterprise Data # 7
http://43.156.115.95:58420/piece/baga6ea4seaqfvuposwm46m7emj7wqucgjdbunwxyq7f5rern2jrhemd64pqqgcy

• After 18% of the download, the server returned 404 Not Found. This was observed multiple times during testing.
• Many fields in the application are blank. Even if explanations were given in conversation, the application should be updated with this information.
• No index file was provided to help community users understand the contents of each piece.
• Data distribution and replication are good.
• Spark HTTP retrievability should be closer to 75%. RPA retrievability indicates almost 100% accessibility; however, this could not be confirmed with a full HTTP download, as it was impossible due to the repeated 404 errors.
• Evidence of proper diligence towards client identification was provided.

[Amin-Foundation]

Transparency & Community Engagement: The allocator is recent and is still building its relationship with the program. The application is generally complete, and the team has demonstrated an acceptable level of transparency by proactively flagging issues and concerns. Their diligence in client verification is noted as a positive indicator of responsible compliance and following their allocation schedule.

Data Distribution: There is sufficient geographical spread across more than three countries/regions. While there is a concentration in Asia, it aligns with the allocator’s client pool. Data concentration at the SP level is currently within acceptable limits but approaching compliance thresholds, with several SPs holding between 8–9% of the total allocation. The allocator should closely monitor this to ensure no single SP exceeds 10% of the total granted DataCap.

Replication & Redundancy: Replication levels remain within acceptable limits for both clients, and no significant concerns are noted at this stage.

Retrievability & Quality: This is the primary area requiring improvement. Current spark retrieval rates are significantly below compliance thresholds at 11.4%. While no instances are null and RPA retrieval metrics are positively high, improvements in spark retrieval performance are expected. Overall, and as flagged by the community watchdog, data quality remains unverified due to the absence of file indexing documentation for Public-Open data. This documentation should be provided without delays to enable proper accessibility and quality assessment.

DataCap Usage Analysis: Distribution velocity is satisfactory, and tranche allocations are aligned with expected scheduled outputs. As noted above, concentration at the SP level remains a risk and should be monitored closely.

Notable Flags

• No index files available for spot auditing Public-Open data, immediate attention required
• Low spark retrievability but good RPA results (mixed performance), requiring immediate attention

The allocator is new and has no prior performance record in this program, considering the mixed results but taking into account the positive steps towards compliance with the Fil+ program, we will recommend throttling the allocation to 2.5 PiB, with the expectation that the allocator addresses the flagged issues; particularly in improving retrieval rates and providing indexing documentation. Without measurable improvement, the allocator will face a potential rejection in the next refresh cycle.

[Hunter3576]

@filecoin-watchdog @Amin-Foundation Thank you for your detailed review!
I'd like to confirm a question.

In Round 6, the maximum replica limit is 8. The allocator should be aware of and comply with this rule, as they confirmed it during the renewal of the application.

One of the clients currently has 10 replicas, can I continue to support the rest of his data storage if that client guarantees to keep only 8 replicas in subsequent allocations