[Allocator Application] <Akave Inc>< Akave> PR #164

martapiekarska commented 6 days ago

Allocator Application

Application Number

recCN2kBWn6R6DdSA

Organization Name

Akave Inc

Organization On-chain Identity

f1j44hd5rxindqftcnp2einqvei4wjrlk5mcgutey

Allocator Pathway Name

Akave

Github PR Number

164

Region of Operation

North America,Europe

GitHub ID

@stef-sf

On-chain address

I will provide an address on a later date

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

RFA: Market-based - Proof of payment

Allocator Description

Contributions to EcosystemBuild better data onboarding pathway

Monetization and Fee structure

Client fees.

Target Clients

Web3 developers,Commercial/Enterprise,Nonprofit organizations

Client Diligence Check

Manual verification

Description of client diligence

Akave delivers enterprise services that help enterprises onboard data to the network. Following steps are taking to perform client diligence:

Manual verification of identity through verifying and collecting address, email, names, and government operating business ID (EID in the US etc) and corresponding email correspondence.
Setup a legal contract with stipulated end user license agreements between the client and Akave inc, enforcing terms and conditions including ownership of data, illegal content etc.
Proof of payment from entity to Akave Enterprise

Type of data

Private encrypted with on-chain deal pricing,Proof of concept, network utilities,Public, open, and retrievable

Description of Data Diligence

We require paying customers to sign the end user license agreements that stipulate the need to comply with local and regional requirements, similar to how cloud providers protect themselves today from liability when storing data for businesses. Information that we can share under an audit are:

Proof of customers having confirmed they are allowed to store the datasets
Proof of paying customers having signed the end user license agreement
Share the license agreement details

Data Preparation

Go-CAR

Replicas required, verified by CID checker

1+

Distribution required

Single region of SPs

Number of Storage Providers required

1+

Retrieval Requirements

Private data not retrievable.

Allocation Tranche Schedule TypeSingle size allocation.

10000

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

Yes, all available tools

GitHub Bookkeeping Repo Link

https://github.com/stef-sf/Allocator-Registry

Success metrics

Number of clients,Number of returning client customers,Number of paid deals,Amount of data onboarded, daily & aggregate

Timeline to begin allocating to clients

1 week from RKH approval

Funnel: Expected DataCap usage over 12 months

5-50PiB

Risk mitigation strategies

We have the following processes in place for data stored through Akave.

Akave enterprise has a well established list of services defined to set the right customers expectations and users Users need to sign the end user license agreement These agreements outline acceptable behavior Akave supports access control in the product stack allowing for limited access and a more secure environment Akave supports client side encryption so users can protect their datasets Monthly billing cycles and monitoring ensure users continue to pay for the service Real-time monitoring of data onboarded and identify anomalous activity on the Akave hosted nodes. Regular software updates are rolled out to support the Akave network to fix bugs and security issues. Incident response protocols In case an incident is identified there is a defined process on how to respond to Training and awareness Detailed documentation is made available on docs.akave.ai describing how to securely connect and onboard data to the network. Akave supports end-user encryption to protect user assets

Dispute Resolutions

The Akave team will provide evidence over email or a sync call
Meeting will organized to discuss resolutions
On agreement resolution will be implemented
Process will be repeated until problem has been resolved

Compliance Audit Check

A report will be provided that summarizes:

of paid customers onboarded
Total capacity of onboarded data
Potential forecasted capacity for the next 6 months
Public customer references (if available)
Storage Provider IDs utilized to onboard

Compliance Report content presented for audit

Success metric: Proof of Payments from clients,Success metric: onchain data report,Client Diligence: Client statements, client provided verification,Compliance: CID report,Contributions: Educational Materials Developed,Contributions: Github repos with the tools developed,Client Diligence: Legal Review documents,More. EUL signed documents from clients

Connections to Filecoin Ecosystem

Developer,Storage provider

Slack ID

@stefaanvervaet

Kevin-FF-USA commented 1 day ago

Hi @stefaanvervaet,

Thanks for applying to serve as an Allocator in the Filecoin Plus Program. In looking at this application, the TYPE OF ALLOCATOR is currently set to REQUEST FOR ALLOCATOR (RFA). Can you please describe what type of Allocator pathway you wish to operate as?

For more details on the types of Allocators please check out this blog. https://blog.allocator.tech/2024/04/allocator-tech-blog.html

Kevin-FF-USA commented 1 day ago

For MANUAL pathways, would like to make you aware that these types of applications are being processes as the network need becomes available. Currently there are ~50 pathways available for Manual reviews, so the priority for onboarding new Allocators is to pathways doing something novel to support the network.

stef-sf commented 22 hours ago

Hi,

I selected the following allocator:

Type of Allocator and RFA List.: RFA: Market-based - Proof of payment

As this is one of the selected paths as described in the blog.

We do business development and bring paying customers online. I assume that's what the Filecoin network is prioritizing now. Can you elaborate on why this type of allocator is not being prioritized?

Thanks Stefaan

stef-sf commented 20 hours ago

I'm adding some more context on the reason why I chose the market-based proof of payment as the type of datacap allocator. Let me share our approach.

The Akave's team goal is to bring paid customers to the Filecoin network. As part of delivering a good user experience our goal is to automate the payment process through smart contracts and implement on-chain paid deals from end-user to storage provider.

As part of the deal-making process our goal is to automate the datacap allocation too. We are currently working with the FVM and the Curio team to build an automated on-chain deal flow.

Our approach is the following:

Phase 1: run manual qualifications to learn how to better automate datacap allocations and build our reputation as a datacap allocator in the community
Phase 2: Implement an automated process to assign data cap allocations and collaborate with other community teams to successfully scale this. (e.g. FVM, Curio etc)

As we are building out the processes, we believe it will be important we can manually allocate in the first phase. We can share our findings back to the community.

filecoin-project / Allocator-Governance