2nd Community Review of TOPPOOL Allocator

[TOPPOOL-LEE]

Review of TOPPOOL Allocations from @TOPPOOL-LEE
Allocator Application: filecoin-project/notary-governance#1046
First Community Diligence: #16
Allocator Compliance Report: https://compliance.allocator.tech/report/f03004870/1726704098/report.md

We believe that actions speak louder than words.
The quota we distribute to each client does not exceed 30%.
Each client partners with completely different SPs.
We have allocated the 10P quota to 4 clients, 32 SPs.
Most SPs support Spark.

10PiBs DataCap in 2nd round

example 1: TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#34 （1.5PiB)
Disclosed SP：
f02822222 Hong Kong
f03166666 Hongkong
f03166668 Hongkong
f02368946 Huhehaote
f02362412 California
f02639492 California

Actually cooperating SP：

example 2: TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#22 （2.25PiB)
Disclosed SP：
f01907578 Shanghai
f02870401 Jakarta
f03144037 Seoul, KR
f02894286 Seoul, KR
f01111110 Hanoi
f01909705 Hanoi
f02832475 Thailand

Actually cooperating SP：

example 3: https://github.com/TOPPOOL-LEE/Allocator-Pathway-TOP-POOL/issues/20（2.75PiB)
Disclosed SP：
f02956383 Hong Kong
f03148950 Hong Kong
f03035686 Shenzhen, Guangdong, CN
f03068013 Hong Kong
f03136267 Hong Kong
f03144077 Hong Kong

Actually cooperating SP：

example 4: TOPPOOL-LEE/Allocator-Pathway-TOP-POOL#18 （2.751PiB)
Disclosed SP：
f01422327 - Japan
f02252023 - Japan
f02252024 - Japan
f01989013 - Malaysia
f01989014 - Malaysia
f01989015 - Malaysia
f02105010 - Malaysia
f01111110 - Vietnam
f01909705 - Vietnam

Actually cooperating SP：

[TOPPOOL-LEE]

Hi, @galen-mcandrew @Kevin-FF-USA If it is convenient, we hope to participate in the meeting and speech

[filecoin-watchdog]

Allocator compliance Report

Example 1
Allocator has granted additional DC, which isn’t noted on the github issue.
The application was officially granted for refill on 12.05 and 10.07, but there is an additional 450TiB transfer on 16.05 Message ID

Example 2
Allocator has granted additional DC which isn’t noted on the github issue.
The application was officially granted for refill on 7.07, 9.07, 11.07 and 19.07, but there is an additional 280TiB transfer on 31.07 Message ID

Example 3
Small note - The client tried to contact the allocator several times through GitHub issue, but despite traces of activity, the allocator decided not to contact the client nor answer their questions.

The gov team should follow up about cases where DC is granted outside of GitHub issues.

[TOPPOOL-LEE]

@filecoin-watchdog Could you tell us more about what you want to express?
About example 1 and 2, what do 12.05 and 10.07, 7.07, 9.07, 11.07 and 19.07 mean? In addition, example 1 is the first round of 5P allocation.
example3, We allocated 2.14PiB in total for them, 256TiB in the first round. At the beginning, their support for spark was low, but they listed a lot of data, including support for boost retrieval, hoping that we could continue to support , so we supported them four times. However, they had 2 SPs that could not support Spark, so we decide not sign any more after signing 512TiB for the last time.
I saw the client's reply on GitHub, and we also called the client to explain the reason for not signing for them. If you don't believe it, I will let the client reply on GitHub.

[TOPPOOL-LEE]

[filecoin-watchdog]

@TOPPOOL-LEE Sorry for the confusion. Numbers you see are the dates. To ease reading and understanding, here's the corrected comments:

Example 1
Allocator has granted additional DC, which isn’t noted on the github issue.
The application was officially granted for refill on May 12 and July 10, but there is an additional 450TiB transfer on May 16.
Message ID

Example 2
Allocator has granted additional DC which isn’t noted on the github issue.
The application was officially granted for refill on July 7, July 9, July 11 and July 19, but there is an additional 280TiB transfer on July 31
Message ID

[TOPPOOL-LEE]

@filecoin-watchdog Thank you for detailed response.

Applicant for 1 gimims (Github)

Signature for 1:
Round 1: 100TiB（ 5P. We signed 100T for all clients in the 5P round.)
Round 2: 450TiB (via lotus)
Round 3: 512TiB

Collaborated with 6 SPs:
f01907578
f02036171
f02036170
f03144037
f03073961
f03073919

Regarding the signature for client 1 on May 16th, you mentioned that we did not use the https://allocator.tech/ system for signing but instead leveraged our self-developed lotus signing system to allocate 450TiB to the client.

Reason: At that time, the allocator.tech system was still unstable and prone to signing failures. Consequently, our team decided to develop the lotus signing system and considered contributing it to the community for free to address the issue of inefficient signing (though allocator.tech is well,now ).

On May 16th, our lotus signing system was ready, and client 1 need the next signature. We conducted tests and successfully signed the allocation.

Applicant for 2 AlfredZKY (Github)

Signature for 2:
Round 1: 256TiB(10P. We signed 25T for all clients in the 10 round.)
Round 2: 512TiB
Round 3: 1PiB
Round 4: 1PiB
Round 5: 280TiB (via lotus)

Collaborated with 9 SPs:
f02105010
f01989015
f02252024
f01909705
f01111110
f01989014
f01422327
f01989013
f02252023

On July 31st, we used lotus to sign 280TiB for client 2.

Reason: I was on a business trip (for 5 days) and did not take the Ledger. However, the client had borrowed FIL for staking and rented sealing machines,If the signature is delayed, it will cause unnecessary costs. then, we considering that the amount of DCs they need is small.Moreover, the client was Compliant, so I via lotus for the signature.

According to the https://compliance.allocator.tech/report/f03004870/1726704098/report.md report, we have collaborated with a total of 6 clients and 40 SPs, with the largest SP accounting for 5.96%.

So,If your concern about lotus is related to potential unfair distribution, I assure you that there is no such thing.

Initially, we worked with clients using Venus (which did not support Spark at the time). We promised during a meeting to discontinue collaborations with such , and we have upheld that commitment. so far, we have rejected all clients who use Venus and do not support Spark.

Now, we pledge not to use lotus for signing in the future to avoid any unnecessary misunderstandings. We will continue to uphold our principles and commitments!

[TOPPOOL-LEE]

We spoke at the meeting on September 3rd, and if necessary, we can continue to speak on October 1st.

[TOPPOOL-LEE]

@filecoin-watchdog Please tell me if you have any questions. We are developing an automatic platform and lotus signature is also a part of the automatic platform.

[galen-mcandrew]

Rather than abandoning completely allocating DataCap through another implementation (self-developed Lotus system), we would much rather see those integrations! It would be great if there are other tools in development that allocators can use, as long as the bookkeeping is still upheld. For example, if your tool still runs through Lotus to construct the message, it should be able to capture the messageID and details. Those could then be pushed to GitHub on the client's issue. The specific integration details would need to be worked out, but generally speaking we would rather see MORE tooling integrations, rather than only having a single platform.

The important thing (as usual) is the transparent bookkeeping. If DataCap is distributed to a client, it's important that we have a consistent audit trail to follow.

Overall, given the diligence evidence and retrieval we are seeing, we are requesting an additional 10 PiB of DataCap from RKH to support this allocator increasing their compliance and alignment.

[TOPPOOL-LEE]

@galen-mcandrew Thank you for your valuable suggestions.

[Kevin-FF-USA]

DataCap has been refilled.
https://datacapstats.io/notaries/f03004870