Community Review of LendMi Allocator

[LendMi]

Application Link: (Issues · LendMi-Finance/LendMi-Storage ) Notary Application Form: (https://github.com/LendMi-Finance/LendMi-Storage/issues/1014) Compliance Report: (https://compliance.allocator.tech/report/f03011025/1728607131/report.md ) Collaborating Client 1: ([DataCap Application] · Issue #10 · LendMi-Finance/LendMi-Stor) Collaborating Client 2: ([DataCap Application] - <DATA RELEASE 7> · Issue #15 · LendMi-Finance/LendMi-Storage ) Dear FIL+ Governance Team, @galen, @kevin, @filwatchdog, After onboarding as a V5 notary, we immediately began DataCap allocation. Our first allocation took place on April 30th, but we were not yet familiar with the system at https://allocator.tech/ . During our first round, we intended to approve only 512TiB, but mistakenly allocated 1PiB to [DataCap Application] · Issue #10 · LendMi-Finance/LendMi-Stor . As a V4 notary, we were accustomed to requesting 1PiB of DataCap, which would then be reduced to 512TiB. However, in the new https://allocator.tech/ system, selecting 1PiB resulted in the entire amount being allocated to the client. This was never our intention; we simply did not yet fully understand the platform. The Spark system was introduced around May and June, but unfortunately, 80% of our allocations were already completed during April and May, resulting in a low retrieval rate for Spark. By June, we had fully understood the rules of the https://allocator.tech/ platform and were also familiar with the requirements of Spark. We successfully allocated 512TiB to a new client in June [DataCap Application] - <DATA RELEASE 7> · Issue #15 · LendMi-Finance/LendMi-Storage , and the retrieval rate by the storage provider (SP) reached 50%. The transition from V4 to V5 brought significant changes in rules, practices, and tools. During this period, our clients were facing high borrowing costs and often urged us via phone calls, emails, and in-person meetings to provide the DataCap they needed. These clients are ones we have known and worked with for over two years, and we have personally assessed their companies and technical capabilities. As a result, we made our allocations more leniently. Unfortunately, we did not provide documentation on our due diligence efforts conducted through other channels like Telegram, email, or in-person meetings on GitHub. We sincerely apologize for this oversight and assure you that we will take greater care in conducting and documenting our due diligence publicly in the future. We respectfully ask for another chance, and we are committed to showing you our fast progress and diligence. Our team is based in Singapore, and we are fully capable of communicating in English and traveling internationally. We would be very grateful for an opportunity to hold a call or an in-person meeting to discuss our case further. Thank you for your time and understanding.

[filecoin-watchdog]

@LendMi Allocator Application Compliance Report

• This allocator has determined that he will have high tranches for his clients. However, having 5 PiB at his disposal has caused rapid consumption of DC.

• During our first round, we intended to approve only 512TiB, but mistakenly allocated 1PiB

According to the allocator application, the first tranche should be 1PiB. I’m confused. Could you explain why you wanted to lower the first tranche?

• The Spark system was introduced around May and June, but unfortunately, 80% of our allocations were already completed during April and May, resulting in a low retrieval rate for Spark.

Two of this allocator's only clients have dealt with only 7 SPs in total. All SPs have a retrieval rate below 1%. Considering the above explanation, what further actions were taken after the Spark system was introduced? Especially since the LAMOST client was being processed in July when the Spark system was already introduced.

5 PiB granted to clients:	Client Name	DC
LAMOST	1PiB
Element84	4PiB

Example 1 - Element84 The dataset this client wants to store in filecoin has already been stored several times. Did the allocator ask what is the purpose of storing the same data again? github search results Inconsistent information about the total amount of DC requested versus the expected dataset size (5 PIB vs 16.4 PiB).

SPs provided: 1.f02813403 UK 2.f02814393 US 3.f02830321 VN 4.f02837226 UK 5.f02864300 US

SPs used for deals: f02813403 f02894286 f02864300 f02870401 f02830321

The list differs slightly and it was not explained with the client.

The client didn’t confirm that this is a public dataset. No info on data preparation. No additional questions were asked, and the allocator went straight to granting DC. The retrieval rate is 0%.

Example 2 - LAMOST The dataset this client wants to store in filecoin has already been stored several times. Did the allocator ask what is the purpose of storing the same data again? https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+lamost+dr7&type=issues

The client didn’t confirm that this is a public dataset. No info on data preparation. KYC was requested but wasn’t finished through kyc.allocator.tech.

Only 2 SPs were used for deals. Both match the provided SPs list, yet with 1PIB, it was possible to store datasets across more SPs. The allocator requires 5 replicas, while only 2 were made so far.

---

Unfortunately, we did not provide documentation on our due diligence efforts conducted through other channels like Telegram, email, or in-person meetings on GitHub.

Overall, this allocator did a good self-review and pointed out most of the things that might have been done better. However, this does not change the fact that if any checks and arrangements with clients were made, there is no trace of them in the GitHub threads, which makes it impossible to review whether the allocator, who should already be experienced in granting DCs and checking clients, is actually doing it with due diligence.

[LendMi]

Hi, thank you for your question. We observed that there may be 5 allocators who, due to unfamiliarity with https://allocator.tech/, mistakenly allocated 1PiB to the customer at the beginning. It should not happen that multiple people make such a mistake, but it also shows that the https://allocator.tech/ rules at that time were different from the https://filplus.fil.org/#/ rules of V4, so the accident occurred. Of course, we quickly discovered and corrected this error, so when we allocated to the second customer, we only allocated 512TiB. Over the past few months, after our observations, we found that allocating 512TiB in the first round was also a relatively large amount, so we decided to start with 256TiB or 100TiB in the next round. We used fewer DCs to verify in the first round. Whether the customer is compliant, including whether the disclosed SP is the same as the actual SP, whether CID is shared, whether Spark is supported, whether VPN is used, whether duplicate data is stored, etc.

When we submitted the review, the bot showed that f02870401 had a retrieval success rate of 55.09%. This proves that our team has the ability to help SPs support Spark. Our team can promise the governance team that in the next round, we will only cooperate with SPs that support Spark. If the governance team needs to test our technical capabilities, we can show you our technical solutions, our understanding of the principles of Spark, and how we will assist SPs in supporting Spark through emails and meetings.

Thank you for showing us how to check whether a data set is stored multiple times. Our team will work hard to find new data sets, including company data, public data, etc.

On October 15, we participated in the Call 2: 1900 pdt / 0200 utc meeting and made a speech. Next, we will participate in the meeting on October 29th Call 1: 0900 pdt / 1600 utc and make a speech. I hope the governance team will see the sincerity and efforts of our team. If you can give us the next opportunity, we will definitely improve the diligence of due diligence, strictly review customers, feedback the content of telephone and offline communication with customers to GitHub, require customers to support Spark and only cooperate with SPs that support Spark, and verify the integrity of customers starting from smaller DCs. Next, we will definitely do better!

[galen-mcandrew]

Agree with the watchdog regarding the accurate self-review, which is helpful in completing our diligence investigation. I also agree that there are some inconsistencies and issues. We will need to see improvements in the following areas:

• retrieval scores increasing above 75%
• dataset replicas across the ecosystem being accurately reported and investigated
• SP distribution lists remaining accurate, with justification
• VPN usage being noted and tracked
• regional distribution increasing to match application requirements
• DataCap tranches to clients being consistent, starting small and scaling up with trust and compliance

We will request an additional 2.5PiB of DataCap, to allow this allocator to show increased diligence and alignment.