[Allocator Application] <Fil+ Governance team>< Manual Pathway MetaAllocator> PR #288

[martapiekarska]

Allocator Application

Application Number

rec0W1NofW745qQYQ

Organization Name

Fil+ Governance team

Organization On-chain Identity

0x2e25A2f6bC2C0b7669DFB25180Ed57e07dAabe9e

Allocator Pathway Name

Manual Pathway MetaAllocator

Github PR Number

288

Region of Operation

Africa,Europe,Greater China Region,North America,Oceania,South America,Asia minus GCR

GitHub ID

Kevin-FF-USA

On-chain address

I have a multisig I want to provide now
f410fw325e6novwl57jcsbhz6koljylxuhqq5jnp5ftq

Type of Allocator

RFA

Filecoin Community Agreement

As a member in the Filecoin Community, I acknowledge that I must adhere to the Community Code of Conduct, as well other End User License Agreements for accessing various tools and services, such as GitHub and Slack. Additionally, I will adhere to all local & regional laws & regulations that may relate to my role as a business partner, organization, notary, allocator, or other operating entity
Acknowledge

Type of Allocator and RFA List

Other

Allocator Description

This is an application for the Manual Pathway Meta Allocator as proposed by the Governance Team in Github Issue . As per the application:
The governance team is proposing the creation of a Manual Pathway MetaAllocator to streamline DataCap allocation for Manual Allocators. This new system aims to increase the speed of datacap refresh, reduce the back and forth in diligence reviews, and improve accountability by placing all Manual Allocators under a unified governance structure. To begin this process, proposing 100 PiBs from Root Key Holders, while will allocate DataCap that is available for audits and ongoing allocation refresh distributions.
Currently every Manual Allocator application as well as applications for Data Cap are reviewed by the governance team who then requests the Root Key Holders to approve DataCap allocation for that Manual Allocator. This creates additional level of complexity and opportunities for delays. This proposal is for those Manual Allocators that are ready receive refresh to receive DataCap from a shared pool held by the Manual Pathway MetaAllocator, which will be managed by the governance team. The goal is faster processing time for Datacap refresh to meet community needs.
Details
In the design of (v5 cycle) which created the Allocator process for Fil+, the intention was to create a tree structure with groups of allocators being governed by MetaAllocators, with the responsibility structure of parent (MetaAllocator) being held accountable for managing and holding accountable the children (allocators). This was first raised by FIDL in a Blog from April 2024 outlining the application process blog post]
Until 2025, creating MetaAllocators was not possible due to the lack of the Smart Contract code to run MetaAllocators. Over the course of 2024, FIDL has been in development of such a Smart Contract, which in now ready. This Smart Contract has been [audited by Composable Security] and [tested out in the automated allocator] on [[faucet.allocator.org (http://faucet.allocator.org/)]. Based on reported success in testing now proposing rollout of this framework to create a new MetaAllocator to govern current and future Manual Allocators.
Proposing

1. Feedback from the allocator community. (via this issue or on the upcoming Governance Calls for Fil+)
2. FIDL to deploy an instance of the Smart Contract that will hold the DataCap Allocation.
3. Root Key Holders to approve a transfer of an initial 100PiBs of DataCap to this contract. This amount will allow us to conduct refresh of Data Cap for outstanding audits.

Contributions to EcosystemBuild better data onboarding pathway

Monetization and Fee structure

None.

Target Clients

Web3 developers,Nonprofit organizations,Commercial/Enterprise,Individuals,Open/Public

Client Diligence Check

Manual verification

Description of client diligence

This is a MetaAllocator, and the clients here will be the allocators who choose manual operations. The MetaAllocator will conduct audits to verify that the Allocators adhere to the rules they set out for themselves.

Type of data

Public, open, and retrievable,Private encrypted with on-chain deal pricing

Description of Data Diligence

This is a metaallocator, and the clients here will be the allocators who choose manual operations. The Metaallocator will conduct audits to verify that the Allocators adhere to the rules they set out for themselves.

Data Preparation

None

Replicas required, verified by CID checker

1+

Distribution required

Equal distribution of deals across regions

Number of Storage Providers required

1+

Retrieval Requirements

Data retrievable over other standard. There isn't a requirement on retrievability, as the Allocators decide it themselves - depending on the type of clients they serve

Allocation Tranche Schedule TypeManual or other allocation schedule.

Will you use FIDL tooling, such as allocator.tech and other bots?

Yes, all available tools

GitHub Bookkeeping Repo Link

https://github.com/filecoin-project/Allocator-Governance

Success metrics

Number of clients,Amount of data onboarded, daily & aggregate,Speed of allocations (TTD),Number of returning client customers

Timeline to begin allocating to clients

1 week from RKH approval

Funnel: Expected DataCap usage over 12 months

200PiB

Risk mitigation strategies

Every allocator undergoes an audit when they run out of DC, meaning we can remove them from the pathway

Dispute Resolutions

Governance Calls and dicussions in Github are the current mode of disputing resolutions

Compliance Audit Check

compliance.allocator.tech

Compliance Report content presented for audit

Success metric: Proof of Payments from clients,Success metric: onchain data report,Client Diligence: Financial Audits and Credit Check reports,Success metric: onchain report of data onboarded,Client Diligence: Client statements, client provided verification,Client Diligence: Legal Review documents,Client Diligence: KYC/KYB report on clients,Data Compliance: Proof of provenance report,Data Compliance: Manual report,Data Compliance: Data Samples,Compliance: CID report,Client/Data Compliance: external third-party audit ,Contributions: Educational Materials Developed,Contributions: Github repos with the tools developed.

Connections to Filecoin Ecosystem

Previous notary

Slack ID

[Kevin-FF-USA]

As proposed in #282

[galen-mcandrew]

PR to create JSON merged and closed. filecoin-project/Allocator-Registry#385

[galen-mcandrew]

The GovTeam is approving this application, and requesting the RKH create this new node in the system structure.

We are requesting 200PiB of DataCap to initialize this meta-allocator. This will cover the most recent round of allocator compliance refresh audits, and still carry a buffer forward. Depending on audit timelines, the rate of requests from the GovTeam to RKH may fluctuate, but the goal will be quarterly action.

[galen-mcandrew]

Contract address: f410ffys2f5v4fqfxm2o7wjiyb3kx4b62vpu66gmu7ia

ETH Address: 0x2e25A2f6bC2C0b7669DFB25180Ed57e07dAabe9e

Robust Address: f27sxjbnrqlp7mo2xkwjsczvq4dxeanoxsje3yaia

[martapiekarska]

@galen-mcandrew Looks like the application did not collect correctly the smart contract address. I have now edited the application and including information here. The Smart Contract that is deployed to manage this Manual DataCap pathway details are as follows:

Contract address: f410fw325e6novwl57jcsbhz6koljylxuhqq5jnp5ftq
ETH Address: 0xB6F5d279AEad97dFA45209F3E53969c2EF43C21d

The address you put in your comment is for the multisig that is able to manage the Smart Contract and trigger DC allocations to allocators when the Governance team does reviews.

[galen-mcandrew]

Updated contract address for meta allocator:

https://filfox.info/en/address/f275ucxlogvchvfuxmft6pze7qevhphkextdmjmnq?t=0
Address: f410fw325e6novwl57jcsbhz6koljylxuhqq5jnp5ftq
ID: f03358620
ETH Address: 0xB6F5d279AEad97dFA45209F3E53969c2EF43C21d
Robust Address: f275ucxlogvchvfuxmft6pze7qevhphkextdmjmnq