Community Diligence Review of 1475 Allocator

[filecoin-watchdog]

Review of Allocations from @1475Notary Allocator Application: https://github.com/filecoin-project/notary-governance/issues/1047

First and only example: DataCap was given to: https://github.com/1475Notary/1475-Allocator/issues/5

Public Open Dataset - key compliance requirement: Retrievability

1st point) New GitHub ID. No sign of KYC or KYB of client or dataset as mentioned in allocator application - need gov team to investigate details

2nd point) All DataCap given to this one client over 5 allocations 500TiB, 1P, 1P, 500TiB, 1.9P in 21 days

3rd point) Client said these were the SPs f02816050|USA f0148494|ShamShuiPo f01841134|Guizhou f03027241|HK f02029743|Singapore

Actual data storage report: https://check.allocator.tech/report/1475Notary/1475-Allocator/issues/5/1717769209203.md

Provider | Location | Total Deals Sealed | Percentage | Unique Data | Duplicate Deals | Mean Spark Retrieval Success Rate 7d f03087446new | Los Angeles, California, USHawk Host Inc. | 1.67 PiB | 36.90% | 1.67 PiB | 0.00% | - f03089385new | New York City, New York, USSingleHop LLC | 1.90 PiB | 42.14% | 1.90 PiB | 0.00% | - f03027241 | New York City, New York, USSingleHop LLC | 199.97 TiB | 4.32% | 199.97 TiB | 0.00% | - f02816050 | London, England, GBSpeedyPage Ltd | 619.72 TiB | 13.40% | 619.72 TiB | 0.00% | - f03087482 | Dulles Town Center, Virginia, USSpeedyPage Ltd | 150.00 TiB | 3.24% | 150.00 TiB | 0.00%

One SPs from original list match. No Diligence on any SPs. One SP sealing 40% (1.9PiBs)

4th point) 0% retrievability on all SPs

[1475Notary]

@filecoin-watchdog After completing our review of ourselves, we responded as follows:

Before we allocate datacap to client, we would check the identity of our clients. We do not reject new clients to apply. We used to do KYC in application and slack.

One SPs from original list match.

There're two sps from original list match. Clients have indicated that they may change the sps they work with. We remind clients to pay attention to the amount of sp's that they work with, and at least find 5 sp's to cooperate with. It seems that client meets the requirements so far.

We have used http/graphsync, which has been recommended by the community, to check the sp and get a successful retrieval. But we've asked clients to talk to sp so that their program can support spark retrieval. They're already upgrading the program code. We're also following the discussion about retrieval in the community. Appreciate the help the spark team gave everyone.

[Kevin-FF-USA]

HI @1475Notary

Appreciate you taking the time to share how the 1475 Allocator is conducting diligence, sounds like the process is being doing outside of Github and in separate comms - which is fine. To make the applications more publicly reviewable, recommend sharing some of the main questions you ask in Github in your https://github.com/1475Notary/1475-Allocator/tree/main/applications.

Even screenshots are fine.

Could you commit to this going forward?

[1475Notary]

@Kevin-FF-USA Yes, we will continue to keep records and updating on github. Also, we have communicated with client that their sp have made updates in their codes. When they continue to receive data to store, their nodes will show a high retrieval success rate on spark. Can look forward to the following reports.

[galen-mcandrew]

Based on a further diligence review, this allocator pathway is partially in compliance with their application - https://github.com/filecoin-project/notary-governance/issues/1047#issuecomment-1890608948

Specifically:

• Single client is almost the entire interaction, this allocator is not acting in compliance with their stated diligence and intervention requirements
• Minimal evidence of client due diligence in GitHub repo (different from allocator application (https://github.com/filecoin-project/notary-governance/issues/1047#issuecomment-1890608948))
• Deals are not distributed geographically, only 2 regions and likely those are configured via VPN (different from allocator application of 3-4 regions)
• Deals are not distributed across SPs, with single new SP (created 5/20) holding over 40% (different from application, requires distribution plan)
• None of the SPs taking deals show any retrievability at scale (minerIDs not visible to Spark team, no other evidence of retrieval)
• There were additional claims in the allocator application regarding smart contracts and tools in development (such as questions 21 & 42), but no clear evidence of these tools being utilized. If there are some additional public dashboards or information, hopefully this team can reply with some evidence.

As a reminder, the allocator team is responsible for verifying, supporting, and intervening with their clients. If a client is NOT providing accurate deal-making info (such as incomplete or inaccurate SP details) or making deals with noncompliant unretrievable SPs, then the allocator needs to intervene and require client updates before more DataCap should be awarded.

Given this mixed review, we are requesting that the allocator verify that they will uphold all aspects & requirements of their initial application. We are also requesting further justification of the above issues, along with updates on previous claims (such as smart contracts and onboarding tools in development). Based on that additional information, we will request an additional 2.5PiB of DataCap from RKH, to allow this allocator to show increased diligence and alignment.

1475Notary can you verify that you will enforce program and allocator requirements if granted a partial refresh?
(for example: public diligence, tranche schedules, and public scale retrievability like Spark).

Please reply here with acknowledgement and any additional details for our review.

[1475Notary]

@galen-mcandrew Thank you for the detailed message. We verify we will enforce program and allocator requirements if granted a partial refresh.

We have communicated with client that their sp have made updates in their codes. When they continue to receive datacap to store, their nodes will show a high retrieval success rate on spark. We do develop smart contracts to track DataCap allocation. Here's the progress. Once we finish it, we will use it on our daily work.

[galen-mcandrew]

Excellent, would love to get more details about these smart contracts. Perhaps you could write up a description and record something to share during an upcoming governance call. @Kevin-FF-USA could you help schedule some time for @1475Notary to present in an upcoming call?