├── .github └── ISSUE_TEMPLATE │ ├── Allocator application.md │ ├── datacap-removal-proposal.yml │ ├── deprecated-notary-application.md │ ├── ldn-application-exception.md │ └── modification.md ├── README.md ├── images ├── governance-layers.jpg └── interaction-diagram.jpg ├── notaries ├── README.md └── templates │ ├── README.md │ ├── client-evaluation.md │ ├── sample-client-application.md │ └── sample-notary-application.md ├── quality-tracking-metrics.md └── root-key-holders └── README.md /.github/ISSUE_TEMPLATE/Allocator application.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Notary Allocator Application 3 | about: Application to become a Notary Allocator and recieve DataCap for v5 election cycle 4 | title: 'v5 Notary Allocator Application:' 5 | labels: Notary Application 6 | assignees: '' 7 | 8 | --- 9 | # v5 Notary Allocator Application 10 | 11 | To apply to be an allocator, organizations will submit one application for each proposed pathway to DataCap. If you will be designing multiple specific pathways, you will need to submit multiple applications. 12 | 13 | Please complete the following steps: 14 | # 1. Fill out the information below and create a new GitHub Issue 15 | 16 | 17 | 18 | 19 | 1. Notary Allocator Pathway Name (This can be your name, or the name of your pathway/program. For example "E-Fil+"): 20 | 3. Organization Name: 21 | 4. On-chain address for Allocator (Provide a NEW unique address. During ratification, you will need to initialize this address on-chain): 22 | 5. Country of Operation (Where your organization is legally based): 23 | 6. Region of Operation (What region will you serve?): 24 | 7. Type of Allocator, diligence process: (Automated/programmatic, Market-based, or Manual (human-in-the-loop at some phase): 25 | 9. DataCap requested for allocator for 12 months of activity (This should be an estimate of overall expected activity. Estimate the total amount of DataCap you will be distributing to clients in 12 months, in TiB or PiB): 26 | 27 | 28 | # 2. Access allocator application (download to save answers) 29 | Click link below to access a Google doc version of the allocator application that can be used to save your answers if you are not prepared to fully submit the application in Step 3. https://docs.google.com/document/d/1-Ze8bo7ZlIJe8qX0YSFNPTka4CMprqoNB1D6V7WJJjo/copy 30 | 31 | # 3. Submit allocation application 32 | Clink link below to access full allocator questionnaire and officially submit your answers: 33 | https://airtable.com/appvyE0VHcgpAkt4Z/shrQxaAIsD693e1ns 34 | 35 | Note: Sections of your responses WILL BE posted back into the GitHub issue tracking your application. 36 | The final section (Additional Disclosures) will NOT be posted to GitHub, and will be maintained by the Filecoin Foundation. 37 | Application information for notaries not accepted and ratified in this round will be deleted. 38 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/datacap-removal-proposal.yml: -------------------------------------------------------------------------------- 1 | name: DataCap Removal Proposal 2 | description: Use this application form to modify/remove DataCap from a certain addresses 3 | labels: DCRemoveRequest 4 | title: "[DataCap Removal Proposal]" 5 | assignees: simonkim0515 6 | body: 7 | - type: markdown 8 | attributes: 9 | value: | 10 | # DataCap Removal Proposal 11 | To modify/remove DataCap from an address on the Filecoin network, please fill out the following form 12 | - type: markdown 13 | attributes: 14 | value: | 15 | # Core Information 16 | - type: input 17 | attributes: 18 | label: Client Application URL or Application Number 19 | validations: 20 | required: true 21 | - type: input 22 | attributes: 23 | label: Client Name 24 | validations: 25 | required: true 26 | - type: input 27 | attributes: 28 | label: Client Address 29 | validations: 30 | required: true 31 | - type: input 32 | attributes: 33 | label: Amount of DataCap to be removed 34 | validations: 35 | required: true 36 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/deprecated-notary-application.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: DEPRECATED Notary Application 3 | about: Application to become a Notary and recieve DataCap to allocation (both new and existing notaries should fill this out) 4 | title: '' 5 | labels: Notary Application 6 | assignees: '' 7 | 8 | --- 9 | # DEPRECATED Notary Application 10 | **Please use the new Allocator Application Template** 11 | 12 | 13 | To apply to be a Fil+ Notary, please review the Notary Overview [here](https://github.com/filecoin-project/notary-governance/tree/main/notaries#overview) and then fill out the following form. 14 | 15 | ## Core Information 16 | - Name: 17 | - Affiliated organization: 18 | - On-chain address to be notarized (recommend using a new address): 19 | - Country of Operation: 20 | - Region of Operation: [North America, South America, Europe, Africa, Greater China Region (GCR), Asia minus GCR, Oceania] 21 | - Use case(s) to be supported: [Please select from [here](https://github.com/filecoin-project/notary-governance/tree/main/notaries)] 22 | - DataCap requested for allocation (10TiB - 1PiB): 23 | - Are you applying on behalf of yourself or an organization?: [Individual, Organization] 24 | 25 | _Please respond to the questions below in paragraph form, replacing the text saying "Please answer here". Include as much detail as you can in your answer!_ 26 | 27 | ## Long Term Network Alignment 28 | ### Time Commitment 29 | Describe the nature and duration of your affiliation with the Filecoin network. Please include relevant GitHub handles, Storage Provider IDs, significant projects or contributions (with links). 30 | ``` 31 | Please answer here. 32 | ``` 33 | 34 | ### Stake Exposure 35 | Please cite total token at stake (currently available, locked as collateral, vesting over time) and any substantiating evidence (i.e., addresses on chain with their corresponding FIL amounts). 36 | ``` 37 | Please answer here. 38 | ``` 39 | 40 | How did you acquire the FIL cited above? 41 | ``` 42 | Please answer here. 43 | ``` 44 | 45 | ## Industry Reputation 46 | ### In-protocol Reputation 47 | Please describe (in detail) your activity and tenure as a member of the Filecoin community. Please note (with links where possible) any contributions made to implementations of Filecoin, the spec, documentation, or to substantially help the Filecoin ecosystem grow. 48 | ``` 49 | Please answer here. 50 | ``` 51 | 52 | ### In-protocol Security 53 | Please describe your contributions to the security of Filecoin and the duration over which you've made contributions. Please also include any links or references that can substantiate your contributions. 54 | ``` 55 | Please answer here. 56 | ``` 57 | 58 | ### Organizational Reputation 59 | Please describe the nature of your organization, including the country of registration, size of the organization, and time since inception. 60 | ``` 61 | Please answer here. 62 | ``` 63 | 64 | Please share any relevant details to help substantiate information about your organization (website, named officers, links to social media profiles). 65 | ``` 66 | Please answer here. 67 | ``` 68 | 69 | Please share any relevant external information regarding your organization (e.g. news articles, social media profiles, etc.) 70 | ``` 71 | Please answer here. 72 | ``` 73 | 74 | ### Individual Reputation 75 | Please share links to at least 2 of your (personal) social media profiles (or accounts that you are able to use) and the approximate size of your audience (i.e., followers, subscribers) for each one. 76 | ``` 77 | Please answer here. 78 | ``` 79 | 80 | Please share any additional relevant information regarding your presence (e.g. news articles, interviews, podcasts, videos, awards, etc.) 81 | ``` 82 | Please answer here. 83 | ``` 84 | 85 | # Allocation Plan [refer to the Rubric to see how this impacts your Notary score](https://docs.google.com/spreadsheets/d/172-sbd5qzdbSofvL_C5FHRyXEsTUpMiKspItygAVJA4/edit?usp=sharings) 86 | ## Concreteness of Allocation Plan 87 | ### Allocation Strategy 88 | How do you plan on allocating the DataCap requested above? Please describe your allocation strategy with as much specificity as you can. This includes the target amount per client and rate at which you'll allocate DataCap. 89 | ``` 90 | Please answer here. 91 | ``` 92 | 93 | How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap? 94 | ``` 95 | Please answer here. 96 | ``` 97 | 98 | ### Client Due Diligence 99 | How will you vet the clients that are applying for DataCap? What questions will you ask to ensure your trust is placed well and that clients can properly handle the DataCap you intend to allocate to them? 100 | ``` 101 | Please answer here. 102 | ``` 103 | 104 | What processes will you employ when granting additional DataCap to a client that has previously been verified? This includes confirming that the client is not improperly using the DataCap they were previously granted, i.e., making deals with a single SP entity. 105 | ``` 106 | Please answer here. 107 | ``` 108 | 109 | ### Bookkeeping Plan 110 | Do you plan on conducting all your allocation decisions in public (e.g. Github repo), private (e.g. over email, Telegram, etc), or both? 111 | ``` 112 | Please answer here. 113 | ``` 114 | 115 | Where do you plan on keeping a publicly accessible record of all your allocation decisions? 116 | ``` 117 | Please answer here. 118 | ``` 119 | 120 | ## Service Level Agreement 121 | ### Engagement in Program 122 | Which level (1-5) of service commitment are you willing to dedicate to participating in the Fil+ program? This includes making DataCap allocations (direct and/or Large Datasets), joining working groups, adding comments on discussion/issues, attendance in governance calls, messages in Slack, etc. For a full list of the service levels and time commitments please review the [rubric](https://github.com/filecoin-project/notary-governance/issues/630) 123 | ``` 124 | Please answer here. 125 | ``` 126 | 127 | 128 | ## Track Record 129 | ### Past allocation 130 | Have you previously received DataCap to allocate before? If so, please link to any previous applications. 131 | ``` 132 | Please answer here. 133 | ``` 134 | 135 | ## Disclosures 136 | Do you/your organization have any relationship(s) with other existing notaries or their organizations? If yes, please list the names of the Notary individuals or organizations you may be related to. 137 | ``` 138 | Please answer here. 139 | ``` 140 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/ldn-application-exception.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: LDN Application Exception Proposal - 3 | about: Application for a non-public/open or a geo-specific dataset that will require a custom LDN with a subset of signing notaries to be created 4 | title: '' 5 | labels: LDN Request 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## Application information 11 | 12 | Link to existing LDN application(s) 13 | - _link to applocation(s) in https://github.com/filecoin-project/filecoin-plus-large-datasets/issues_ 14 | 15 | Are you the data owner? 16 | - [ ] Yes 17 | - [ ] No 18 | 19 | Is the data private i.e., encrypted or not meant to be retrieved by anyone else on the network? 20 | - [ ] Yes 21 | - [ ] No 22 | 23 | ## Data owner information 24 | - Data owner: 25 | - Data owner's website: 26 | - Data owner's social media account(s): 27 | 28 | ### Data owner description 29 | _Details on the data owner background, source of funding, etc._ 30 | 31 | ## Project Description 32 | 33 | ### What is the motivation behind onboarding this data to Filecoin? 34 | _Answer here_ 35 | 36 | ### What organizations are involved in this project? Sources of funding, SPs partnering in onboarding, other service providers, etc.? 37 | _Answer here_ 38 | 39 | ## Transparency in KYC 40 | _If you are not the data owner, please email filplus@fil.org with you and the data owner on a thread so at least the Fil+ governance team can act as a lightweight KYC check._ 41 | 42 | Are you going to offer NDAs to notaries? 43 | - [ ] Yes 44 | - [ ] No 45 | 46 | ## Dataset description 47 | _What is being stored on the network? Please provide as many details as possible on the dataset and its size._ 48 | 49 | ### Why is it useful to the Filecoin network? 50 | _Please share details on how your project may use Filecoin in a novel way, extend or experiment with different use cases, or result in useful development in the ecosystem._ 51 | 52 | ## Storage needs 53 | 54 | Is the data to be stored in a single region, either due to geopolitical constraints or data owner policy? 55 | - [ ] Yes 56 | - [ ] No 57 | 58 | ### Which SPs will you/the data owner be working with to store the data? 59 | _If all the SPs have not been chosen at the time of issue submission, feel free to edit and update the form as they are chosen. If you need support on finding reputable SPs, please check out filgram.io, filrep.io, plus.fil.org/miners, or Filecoin Slack channels: #fil-plus, #fil-deal-market_ 60 | 61 | | SP ID | SP org | SP region | 62 | | --- | --- | --- | 63 | | _minerID_ | _org_ | _region_ | 64 | 65 | ### How were these SPs identified? 66 | _Answer here_ 67 | 68 | 69 | ## Notaries that support the project 70 | _Notaries perform KYC/KYB to validate the legitimacy of data and organizations. To find supporting notaries please view the list of [round 3 notaries](https://github.com/filecoin-project/notary-governance/tree/main/notaries) and post your LDN application in the Filecoin slack channel #fil-plus-application-review. Feel free to update the form as you gain support over time and more notaries are willing to support your application._ 71 | 72 | | Notary name | Notary org | Notary region | 73 | | --- | --- | --- | 74 | | _name_ | _org_ | _region_ | 75 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/modification.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Modification 3 | about: Use this issue to file proposed modifications for discussion 4 | title: 'Modification: [Location of Change] - [Description of Change]' 5 | labels: Proposal 6 | assignees: '' 7 | 8 | --- 9 | ## Issue Description 10 | 11 | ## Impact 12 | 13 | ## Proposed Solution(s) 14 | 15 | ### Timeline 16 | 17 | ### Technical dependencies 18 | 19 | ### End of POC checkpoint (if applicable) 20 | 21 | ## Risks and mitigations 22 | 23 | ## Related Issues 24 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # This Repo is no longer maintained 2 | *This repository for the Fil+ Notaries has been sunset. The updated repositority for ALLOCATORS has been created and is now maintained at [Github Goverance Repo](https://github.com/filecoin-project/Allocator-Governance)* 3 | 4 | 5 | 6 | 7 | To view other updated reference links for the Fil+ program, please see 8 | - For information on the open and pending DataCap deals, please see [FIDL's Allocator.tech](https://allocator.tech) 9 | - For information on support issues or a listing of all current Allocators, please see [Allocator Registry](https://github.com/filecoin-project/Allocator-Registry) 10 | - For getting in touch, please reach out in [SLACK](https://filecoinfoundation.slack.com/archives/C01DLAPKDGX) 11 | - Bi-weekly recorded Fil+ governance meetings on [Youtube](https://www.youtube.com/playlist?list=PLp3zrT1ewY0kYN1hJpERMUxTCbFC4yZwN) 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ________________________ 20 | ________________________ 21 | ________________________ 22 | ________________________ 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | ## Notary Program Overview (Now Sunset) 31 | 32 | The purpose of this repository is to manage the governance and evolution of specific Mechanisms and Operations of the program as insantiated in this [FIP](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0003.md) 33 | 34 | 35 | Within this repository, you will find: 36 | - Increased specification, governance, and evolution for Mechanisms and Operations layers. 37 | - Information on Root Key Holders, available actions, roles and responsibility. 38 | - Information on how to become a Notary, selection rubric, recommended guidelines, active Notaries. 39 | - Information on how to file a Dispute, and the steps for how disputes are resolved. 40 | 41 | #### If you are looking to request DataCap or to find a list of active Notaries please go to the [Filecoin Plus Registry](https://plus.fil.org). 42 | 43 | ## Overview 44 | - Principles 45 | - Decentralization and Diversity 46 | - Tranparency and Accountability 47 | - Community Governance 48 | - Low-Cost Dispute Resolution 49 | - Limited Trust Earned over Time 50 | - Terms of Service 51 | - A Useful Storage Network 52 | - Roles & Responsibilities 53 | - [Root Key Holders](/root-key-holders#overview) 54 | - [Notaries](/notaries#overview) 55 | - Clients 56 | - Interaction Diagram 57 | 58 | interaction-diagram 59 | 60 | ## Dispute / Audit Framework 61 | 62 | Last updated: 2023-05-05 63 | 64 | **The person opening the dispute is referred to as ‘Claimant’ and the stakeholder against which the dispute is opened is referred to as ‘Responder'** 65 | 66 | Overview of the Dispute resolution process: 67 | - Claimant submits [form](https://forms.gle/WTPCxsi12PLVzjWh8) in the [T&T Dispute Tracker](https://www.notion.so/filecoin/T-T-Dispute-Tracker-d28b93677cb544b48e77b585856601cf). 68 | - Responder is notified by the T&T WG Lead and allowed to submit additional details in the [T&T WG slack](https://filecoinproject.slack.com/archives/C0405HANNBT) or present at the [T&T WG Call](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=cXZkdjZ1MThkZ2w3MHFkMTM0YTdoZ2RtbmFfMjAyMzA1MTZUMTUzMDAwWiByYWdoYXYuYWdnYXJ3YWxAcHJvdG9jb2wuYWk&tmsrc=raghav.aggarwal%40protocol.ai&scp=ALL). 69 | - T&T WG reviews all relevant data. 70 | - Repercussions announced and enacted. 71 | 72 | The process for filing a Dispute request is as follows: 73 | 74 | An issue must be filed on the [T&T Dispute Tracker](https://www.notion.so/filecoin/T-T-Dispute-Tracker-d28b93677cb544b48e77b585856601cf)using the [form](https://forms.gle/WTPCxsi12PLVzjWh8) 75 | 76 | *Although the WG prefers and strongly encourage full transparency, we understand some situations may require more discretion, so disputes can be submitted as 'anonymous'.* 77 | 78 | Once a dispute is filed, the T&T WG Lead will discuss it in the WG calls. The average time for a dispute to be resolved is two weeks based on the principles of optimistic governance but some disputes may take longer depending on the complexity and response times of the claimant and responder. The status will be trackable and updated at all times in the public dispute tracker. 79 | 80 | *Claimants are encouraged to cross-post the dispute in the T&T WG channel to bring the community’s attention to the dispute.* 81 | 82 | The claimant is requested to complete all fields including a description of the issue at hand. Notably, some specific abuse must be detailed, such as: 83 | 84 | - A violation of the overarching principles 85 | - A violation of a Notary's own attested allocation plan 86 | - A violation of the agreed-upon [operating guidelines](https://github.com/filecoin-project/notary-governance/blob/main/notaries#operational-guidelines), or some other act of impropriety 87 | 88 | Supporting the dispute with substantiating evidence is highly encouraged, such as links to the relevant transaction ids on-chain, screenshots, or other evidence. 89 | 90 | Claimants are discouraged from making personal attacks against any stakeholder when submitting details in the T&T dispute tracker and follow the [Fil+ Code of Conduct](https://medium.com/filecoin-plus/fil-code-of-conduct-9cd044e7bcaf). 91 | 92 | Based on the evidence, the response to a dispute, and discussions of the situation in the T&T WG calls, some possible repercussions and outcomes may include but are not limited to: 93 | 94 | - Removal from the program 95 | - Losing rights as a notary 96 | - Revoking of allocated DataCap 97 | - Being asked to step away from the Fil+ community 98 | - A warning coupled with restrictions 99 | 100 | 101 | ## Governance, Contributing and Iteration Process 102 | Within this repository are the governing documents, selection criteria, and processes for Notaries and Root Key Holders. Areas for discussion or improvement, should be filed as issues. Please use the Modification template (for proposed improvements) or create a blank issue for topics for discussion! 103 | 104 | After community discussion, pull requests are encouraged where open discussion can happen asynchronously via the community - please be sure to link the relevant issues to the changes in your PR. Similar to a FIP, any proposed changes must be done within the constraints of improving the Mechanisms and Operations to better meet the overarching Principles. 105 | 106 | Please note our community governance calls will take place every other Tuesday - there are (2) calls each day to accomodate time zones. 8am PT // 1400 UTC AND 1800PT // 0000am UTC. Please see the community calendar for the accurate dates/times relative to your local timezone, follow the repo (where agenda issues will be filed), or join our Slack channel! 107 | - [Community Calendar](https://calendar.google.com/calendar/u/1?cid=Y19rMWdrZm9vbTE3ZzBqOGM2YmFtNnVmNDNqMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t) 108 | - [Zoom link](https://fil-org.zoom.us/my/filecoinplus?pwd=VHpNSnd0dkJRdWozNi9Xc3NmeGFhZz09), Passcode: *N*otary 109 | - Please join our Slack channel, #fil-plus, if you have questions. 110 | 111 | ### Previous governance calls 112 | 113 | #### Recordings 114 | - ALL: [Meeting recording](https://www.youtube.com/playlist?list=PL_0VrY55uV1-cwaAU8lcChONxYQ_Bj9hx) 115 | 116 | #### Presentations 117 | - ALL: [Presentation Files](https://drive.google.com/drive/u/0/folders/1zTy6YZWlG0KH6eQCEoKA8nDRP2JZnnp1) 118 | 119 | -------------------------------------------------------------------------------- /images/governance-layers.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/notary-governance/08a20f65a03350e8976537fae85e631f75ad0304/images/governance-layers.jpg -------------------------------------------------------------------------------- /images/interaction-diagram.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/filecoin-project/notary-governance/08a20f65a03350e8976537fae85e631f75ad0304/images/interaction-diagram.jpg -------------------------------------------------------------------------------- /notaries/README.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | Notaries are selected to act as [fiduciaries](https://www.merriam-webster.com/dictionary/fiduciary) for the Filecoin network. Notaries are entrusted to uphold the [Principles](https://github.com/filecoin-project/FIPs/blob/fip-0003/FIPS/fip-0003.md/#principles) of the program - responsibly allocating DataCap to help foster legitimate use cases on Filecoin. This document aims to provide additional specificity to the role/responsibility of Notaries, define the application and selection process, and the process for making changes. 3 | 4 | 5 | # v5 Notary Allocator Election Cycle 6 | *Launching November 2023* 7 | 8 | Following the proposal made [here](https://github.com/filecoin-project/notary-governance/issues/984) for a new Notary Election Cycle focusing on "Meta-Pathways", we will solicit applications from the Filecoin community to become trusted fiduciaries in the Filecoin Plus program. The overall process will be similar to previous Notary Election cycles, with interested parties submiting details to the Governance team for review. We will update this ReadMe section with relevant deatils, checklists, and links to supporting documentation. 9 | 10 | Organizations designing a pathway to DataCap will need to submit ONE application PER pathway. 11 | 12 | ## Checklist: 13 | - [ ] Submit GitHub issue Application: [LINK](https://github.com/filecoin-project/notary-governance/issues/new?assignees=&labels=Notary+Application&projects=&template=Allocator+application.md&title=) 14 | - [ ] Use Google Doc for drafting and async edits of full application: [LINK](https://docs.google.com/document/d/1-Ze8bo7ZlIJe8qX0YSFNPTka4CMprqoNB1D6V7WJJjo/copy) 15 | - [ ] Submit all responses to Airtable Form: [LINK](https://airtable.com/appvyE0VHcgpAkt4Z/shrQxaAIsD693e1ns) 16 | - [ ] Monitor GitHub issue for feedback from Fil+ Governance Team 17 | 18 | ## Broad Timeline: 19 | * Q4 '23: Solicit applications 20 | * Q4 '23: Initial review and feedback from Fil+ Governance Team 21 | * Q1 '24: Public scoring and selections 22 | * Q1 '24: Ratification and onboarding new notary allocators 23 | * Q2 '24: Transition to rolling applications 24 | * Q2 '24: Ongoing compliance checks of pathways, requests for more DataCap from Root Key Holders 25 | 26 | ## Key Dates: 27 | * November 11 - January 20: Applications Open 28 | * January 20, 2024: Deadline for v5 Allocator Application 29 | 30 | 31 | ## Links: 32 | *Updates to follow* 33 | * FIL Istanbul and LabWeek [Videos](https://www.youtube.com/watch?v=57Ua4AEWe_g) 34 | * Application Repo ([filtered for v5 applicants](https://github.com/filecoin-project/notary-governance/issues?q=is%3Aissue+is%3Aopen+v5+Notary+Allocator+Application+label%3A%22Notary+Application%22)) 35 | * Google Doc for drafting [application](https://docs.google.com/document/d/1-Ze8bo7ZlIJe8qX0YSFNPTka4CMprqoNB1D6V7WJJjo/copy) 36 | * v5 Scoring [Rubric](https://docs.google.com/spreadsheets/d/1F5afMkeoJREwzzWDtG5OPTmmzH9L0gLXSQLhW1Gl0TI) 37 | * Tooling resources as of Jan 2024 [Link](https://docs.google.com/spreadsheets/d/1Rml1klPMHUB1PGQZ5yGARGnIEycpJKqh1OEVSLTk4A0/edit?usp=sharing) 38 | * Accepted Allocator Pathways [Link](https://airtable.com/appvyE0VHcgpAkt4Z/shrQXdIfoumF7ZvOn) 39 | 40 | 41 | 42 | 43 | ## Current active notaries 44 | | Organization | Point of Contact Name | Election Round | Status | Location | Notary Application Link | 45 | |--------------------------------------------------------------|--------------------------------|----------------|----------|----------------------------|-------------------------------------------------------------------| 46 | | Meibuy Cloud | | 4th | Active | Africa | https://github.com/filecoin-project/notary-governance/issues/681 | 47 | | 12Ships Foundation | Irene Young | 2nd, 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/677 | 48 | | Antalpha Digital Pte. Ltd. | Xin Jin | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/683 | 49 | | Bewell Technology Limited | Aaron Hu | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/679 | 50 | | BigData Exchange | CB Tan | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/703 | 51 | | Bit Engine Pte Ltd | Reeta | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/692 | 52 | | Bitrise capital | Kivi | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/716 | 53 | | BlockchainWorld | Sounghwan Park | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/648 | 54 | | Blockmaker | Rvo Nagaoka | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/695 | 55 | | CoinSummer Labs | Max | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/669 | 56 | | Define Platform | Alex Kim | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/657 | 57 | | EMO capital | Bruce | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/707 | 58 | | FBG Capital | Gary Gao | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/722 | 59 | | Force Community | Tim Guo (柏礼） | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/668 | 60 | | Greaterheat Pte.Ltd. | Yang Haibo | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/659 | 61 | | IPFS Japan Consortium | Masaaki Nawatani | 2nd, 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/696 | 62 | | ND LABS | Leo | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/697 | 63 | | Pluskit | Wu Xiao | 3rd, 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/694 | 64 | | Protocan | AnthonySmith | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/682 | 65 | | Starboard | Sylvan Zhang | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/745 | 66 | | YuanHe Tech ( Firefly ) | embedsky | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/788 | 67 | | Direction Technology Co., LTD | George Betts | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/717 | 68 | | Fungi Project | Andress Sarria | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/600 | 69 | | N/A | Bobby Choi | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/769 | 70 | | METAVERSE DATA MINING PTE.LTD. | Oliver Lu | 4th | Active | Asia minus GCR | https://github.com/filecoin-project/notary-governance/issues/709 | 71 | | N/A | Carohere/Carolina | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/676 | 72 | | RawTech Ventures | Dalen Johnson | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/661 | 73 | | Speedium / DCENT BV. | Wijnand Schouten | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/678 | 74 | | Twinquasar | Julien NOEL | 2nd, 3rd, 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/739 | 75 | | ZhongYiGuoLian | Patapon | 4th | Active | Europe | https://github.com/filecoin-project/notary-governance/issues/638 | 76 | | 1475 | Simon | 2nd, 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/770 | 77 | | BigFrog Technology | Eunice | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/690 | 78 | | BingHe Web3.0 Lab | MRJAVAZHAO | 2nd, 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/699 | 79 | | ByteBase | Eric | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/689 | 80 | | CodoonHealth | Holiday | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/752 | 81 | | DeFIL | Eden | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/720 | 82 | | Ewesion | Peter Shao | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/740 | 83 | | Fenbushi Capital | Zhehao Chen | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/647 | 84 | | FileDrive Labs | Laura Ren | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/684 | 85 | | FILWallet | Peng Kai | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/644 | 86 | | FogMeta | Leo Zhang | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/772 | 87 | | Genesis | Anne | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/732 | 88 | | Guazi Dynamic | @Fatman13 | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/670 | 89 | | Interstellar Storage（ShenZhen） | Interstellar Storage（ShenZhen） | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/768 | 90 | | IPFS Force | Steven Li | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/667 | 91 | | IPFS.CN | Nic | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/734 | 92 | | IPFSMain | Neo Ge | 2nd, 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/672 | 93 | | mkccstorage | Hunter | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/665 | 94 | | MS Cloud（formerly MatrixStorage） | Tracy | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/719 | 95 | | N/A | Cabrina Huang | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/763# | 96 | | New Web Group | Yuan | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/713 | 97 | | NewToken - Hangzhou Niutong Information Technology Co., Ltd. | jomozz | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/674 | 98 | | NonEntropy Tech. | Junyao Ren | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/700 | 99 | | Pangod | Casey | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/775 | 100 | | POW POWER | Jackson | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/765 | 101 | | STCould | LISA | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/764 | 102 | | StorSwift | coder-lb | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/663 | 103 | | SXX Future Data | Darleen | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/680 | 104 | | TAKI Chain | Smart Dong | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/736 | 105 | | Tianji Studio | Bailey-li | 3rd, 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/687 | 106 | | Tokencan | Joy Lee | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/746 | 107 | | Venus Team | Joss Hua | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/645 | 108 | | ZC LABS | zhongchuang | 4th | Active | Greater China Region (GCR) | https://github.com/filecoin-project/notary-governance/issues/643 | 109 | | Acrontech Inc. | Gendin Han | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/743 | 110 | | Aifabot | Benny | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/698 | 111 | | Banyan | Claudia Richoux | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/742 | 112 | | Filecoin Foundation | Danny O'Brien | 2nd, 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/750 | 113 | | FilSwan | Charles Cao | 2nd, 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/778 | 114 | | Ghost Byte Inc | Trevor K Smith | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/760 | 115 | | Ipollo | Mona | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/721 | 116 | | Kernelogic (sole corporation / self-employed) | Fei Yan | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/658 | 117 | | Koda Inc. | Emma Russell | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/754 | 118 | | LendMi team | Rongze92 | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/730 | 119 | | N/A | Nick Merrick | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/779 | 120 | | Nebula Block Data | Boqian Wang | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/777 | 121 | | New Huo Pool | Bella Huang | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/708 | 122 | | NFTSTAR | Vivian | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/693 | 123 | | ORIGIN Storage | llifezou | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/710 | 124 | | PiKNiK | James Hoang | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/776 | 125 | | Saukibit, Inc. (DBA Canza Finance) | NatoSilue | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/744 | 126 | | SECUREXPERTS Inc. | Darnell Washington | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/756 | 127 | | Tech Greedy | Xinan Xu | 3rd, 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/664 | 128 | | Top Value Limited | Luo Bin | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/729 | 129 | | TopBlocks | Harry Ma | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/675 | 130 | | XnMatrix | Steve Tsou | 4th | Active | North America | https://github.com/filecoin-project/notary-governance/issues/747 | 131 | | Holon Global Investments PTY Ltd | mjroddy | 3rd, 4th | Active | Oceania | https://github.com/filecoin-project/notary-governance/issues/748 | 132 | | OPENGATE TECHNOLOGY INVESTMENT GROUP PTY LTD | TAO YANG | 4th | Active | Oceania | https://github.com/filecoin-project/notary-governance/issues/673 | 133 | | Tenet Data Systems | | 3rd | Inactive | Asia minus GCN | | 134 | | 4Everland | Deon Erda | 3rd | Inactive | Europe | | 135 | | TechHedge (Reiers) | Nicklas Reiersen | 2nd, 3rd | Inactive | Europe | | 136 | | Coffee Cloud | | 3rd | Inactive | Greater China | | 137 | | IPFS Metaverse Community | Nic | 3rd | Inactive | Greater China | | 138 | | Union Labs (formally IPFSUnion) | Jackie Mo | 2nd, 3rd | Inactive | Greater China | | 139 | | Waterdrop Lab | | 3rd | Inactive | Greater China | | 140 | | Gate.io | Fafa | 3rd | Inactive | North America | | 141 | | Infinite Scroll // Glif | | 2nd, 3rd | Inactive | North America | | 142 | | Performive | Tim Williams | 2nd, 3rd | Inactive | North America | | 143 | | Textile | Andrew Hill | 2nd, 3rd | Inactive | North America | | 144 | | Tinfra | | 3rd | Inactive | North America | | 145 | | MetaWave | Jazz Hsiao | 3rd | Inactive | Oceania | | 146 | | West Labs | | 3rd | Inactive | Oceania | | 147 | 148 | 149 | 150 | ### Regional Counts of active notaries 151 | | Region | Number of notaries | 152 | |----------------|--------------------| 153 | | Africa | 1 | 154 | | Asia minus GCR | 21 | 155 | | Europe | 9 | 156 | | Greater China | 33 | 157 | | North America | 22 | 158 | | Oceania | 2 | 159 | 160 | ## Roles & Responsibilities 161 | The base responsibilities of the Notaries are as follows: 162 | - Allocate DataCap to clients in order to subsidize reliable and useful storage on the network. 163 | - Verify that clients receive a DataCap commensurate with the level of trust that is warranted based on information provided. 164 | - Ensure that in the allocation of the DataCap no party is given excessive trust in any form that might jeopardize the network. 165 | - Follow operational guidelines, keep record of decision flow, and respond to any requests for audits of their allocation decisions. 166 | 167 | **Note:** Notaries are given autonomy in their decision making process and encouraged to allocate DataCap based on their best judgement. However, Notaries should expect to answer any questions about previous allocation decisions before receiving future DataCap to distribute. Guidelines for reasonable allocation strategies are supplied in this repository (both a [recommended scoring mechanism for prospective Clients](/notaries/templates/client-evaluation.md), as well as a [sample set of questions to ask of Clients](/notaries/templates/sample-client-application.md)). While not mandatory to use, these documents represent the expected baseline for well-behaved Notaries. 168 | 169 | ## Operational Guidelines 170 | As stated above, Notaries are given a high degree of autonomy in their decision making power. In order to build trust in the stability of this mechanism, below outlined are some basic criteria by which all Notaries are expected to adhere. In the future these restrictions may be reduced or removed, upon approval by the community (going through the standard PR process). 171 | 172 | * **Upfront Disclosures**: Prior to being confirmed as a Notary, Notaries are expected to disclose all relevant addresses which they control, have a financial stake in, or are strongly connected to by other means. For the disclosure, the Notary should state the relevant addresses and the nature of the relationship. 173 | 174 | * **Promoting Client Best Practices**: Notaries agree to educate approved clients about the best practices for using their DataCap (e.g. how to request additonal services from miners, storing data redundantly across many miners, etc). Some reference information can be found [here](https://github.com/filecoin-project/notary-governance/issues/9). 175 | 176 | * **Commitment to effeciently serving the Network**: Notaries agree to serve as fiduciaries of the Network, striving to work towards bringing useful data onto Filecoin and improving the experience for clients to do so. Notaries should generally be able to respond to Client applications and updates within 3 days, and should be comfortable communicating with Clients and Notaries if an application needs to be redirected. 177 | 178 | * **No Self Dealing**: To prevent conflicts of interest, Notaries should not allocate DataCap to Clients over which they control the private keys, or to a Client who intends to specifically spend the allocated DataCap with an address affiliated with the Notary. When in doubt, Notaries should bias towards transparency (i.e. public disclosure) or to getting a different Notary to handle the individual request. 179 | 180 | * **Operating in Good Faith**: Notaries hold a position of trust in the network, and as such it is expected that they operate keeping the Principles of this mechanism in mind. While each form of abuse cannot be exhaustively defined, Notaries are expected to bias towards caution and act in a way that promotes transparency. Notaries should expect to potentially recieve requests or questions for allocation decisions (within reason) - and should make decisions with this in mind. 181 | 182 | * **Community Governance Participation**: It is expected that Notaries regularly attend the scheduled Governance calls. As these calls are a forum to shape this process, it is important to ensure Notaries are present to provide their context, learnings, and input. 183 | 184 | 185 | # Notary Sets Use Cases 186 | Support (1) or more the following, which can be linked to in a separate doc: 187 | - Professional Services (Hosting Reseller, Long-term Backups, Data Warehousing) 188 | - Developer Tools (Package Managers, Automatic Notaries, Web2 to Web3 integrations) 189 | - Decentralized Applications 190 | - User Content (Personal Storage) 191 | - Public or Open Data (Scientific datasets, research data, government or historic 192 | - Media & Entertainment (Videos, photos, NFTs) 193 | 194 | 195 | 196 | ## Removal Process 197 | Notaries that have consistent and substantive issues raised against them and have been found to be legitimately abusing their power will be made ineligible for DataCap allocations. The process for raising and resolving disputes can be found [here](/README.md#dispute--audit-framework). 198 | -------------------------------------------------------------------------------- /notaries/templates/README.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | How to use these rubrics: 3 | - Once a prospective Notary has filed an issue to apply, their application will be publicly graded on the below criteria. 4 | - First, the applicant will be checked to see none of the criteria for [Automatic Disqualification](/notaries/templates#automatic-disqualification). 5 | - Next, the applicant will be ranked based on their merits as a Notary. Note, per row the applicant can get a score 1-5. If an applicant does not provide evidence, they will get a 0 for that row. Definitions for terms used in the criteria can be found below the rubrics. 6 | - Once the applicant has been ranked as a Notary, the outputs are fed into the [Allocation Rubric](/notaries/templates#notary-allocation-plan-rubric). This considers the merits of the applicant as a Notary along with their previous track record, and the robustness of their plan to determine the [final allocation amount](/notaries/templates#final-allocation-amount). 7 | 8 | All scoring decisions should happen in public on the issue as filed, and iteration (e.g. improvements to an allocation plan) may be made within the issue. Editors of the repo will be able to assign the final score based on the merits of the application. On a regular cadence, review of open applications can occur where scoring decisions can be reviewed. When a final score is determined, a label will be set such that Root Key Holders can be made aware action is required. 9 | 10 | ## Notary Rubric 11 | 12 | Link to updated Google Sheet rubric, with calculations: https://docs.google.com/spreadsheets/d/172-sbd5qzdbSofvL_C5FHRyXEsTUpMiKspItygAVJA4 13 | 14 | 15 | 16 | 17 | ## Automatic Disqualification 18 | The following criteria are grounds for automatic disqualification as a Notary: 19 | - Being found to be in violation of Filecoin's [Code of Conduct](https://github.com/filecoin-project/community/blob/master/CODE_OF_CONDUCT.md). 20 | - Severe or consistent acts of impropriety and abuse of one's role as Notary or as a Root Key Holder. Impropriety is defined as violating the Principles of this Mechanism, acting outside the remit of one's role (both as defined in this repository and as self-attested in the application process), or generally abusing the power entrusted to the role. Accusations of impropriety are expected to be filed via the [Disputes Mechanism](/README.md#dispute--audit-framework), where the accused will have an opportuntity to respond and justify their actions to the community. 21 | -------------------------------------------------------------------------------- /notaries/templates/client-evaluation.md: -------------------------------------------------------------------------------- 1 | TBD 2 | -------------------------------------------------------------------------------- /notaries/templates/sample-client-application.md: -------------------------------------------------------------------------------- 1 | # Sample Questions to ask Clients 2 | _Notaries may use these questions at their discretion to gather data about a prospective Client._ 3 | 4 | ## Reputation 5 | _Please respond to the questions below in paragraph form, replacing the text saying "Please answer here". Include as much detail as you can in your answer!_ 6 | 7 | **Please describe the nature of your organization, project, or use case. For organizations, please include your relationship with the organization the size of the organization, and time since inception. For projects and other use cases, please link to relevant web pages or Github. Please include as much relevant detail to provide contextual information (with external links).** 8 | ``` 9 | Please answer here. 10 | ``` 11 | 12 | 13 | 14 | **Have you been approved for a DataCap previously? If so, can you share the details of the last allocation decision (who approved your DataCap, what your plan was for spending it, how you executed on that plan)? ``` 15 | ``` 16 | Please answer here. 17 | ``` 18 | 19 | 20 | ## Allocation Strategy 21 | **Do you intend to store your data in a single geography or many?** 22 | ``` 23 | Please answer here. 24 | ``` 25 | 26 | **Are you aware of and do you intend to use the features you may specify (e.g. Fast Retrieval) with your storage deals?** 27 | ``` 28 | Please answer here. 29 | ``` 30 | **How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap?** 31 | ``` 32 | Please answer here. 33 | ``` 34 | 35 | **Do you plan on allocating a substantial portion of your DataCap to a single miner, or will you spread it across many miners?** 36 | ``` 37 | Please answer here. 38 | ``` 39 | 40 | **For application developers, will you be acting as the client on behalf of your users or you applying as a Notary on behalf of your users? If so, how much DataCap per user are you seeking to have approved?** 41 | ``` 42 | Please answer here. 43 | ``` 44 | 45 | **Do you agree to use the DataCap to only store data that abides by local regulations and in compliance with the recipient miner’s terms of service?** 46 | ``` 47 | Please answer here. 48 | ``` 49 | 50 | 51 | ## Track Record 52 | **Have you previously received DataCap to allocate before? If so, please link to any previous decisions that have been made.** 53 | ``` 54 | Please answer here. 55 | ``` 56 | 57 | **Are there any disputes open against you from your previous DataCap allocations?** 58 | ``` 59 | Please answer here. 60 | ``` 61 | 62 | **Have you ever previously violated:** 63 | - **Your own attested allocation / audit plan?** 64 | - **Been found to be in violation of the Principles of Filecoin Plus?** 65 | ``` 66 | Please answer here. 67 | ``` 68 | 69 | -------------------------------------------------------------------------------- /notaries/templates/sample-notary-application.md: -------------------------------------------------------------------------------- 1 | # Notary Application Template 2 | ***Note: Please only submit PRs for proposed edits to this form. To apply as a Notary, please file an [issue](https://github.com/filecoin-project/notary-governance/issues/new?assignees=&labels=request&template=notary-application.md&title=).*** 3 | 4 | To apply as a notary, please fill out the following form. 5 | 6 | ## Core Information 7 | - Name: 8 | - (Optional) Affiliated Organization: 9 | - Website / Social Media: 10 | - On-chain Address(es) to be Notarized: 11 | - Region of Operation: [North America, South America, Europe, Africa, Greater China, Asia-GCN, Oceania] 12 | - Use case(s) to be supported: [Please select from [here](/notaries/templates/README.md#definitions)] 13 | - DataCap Requested: 14 | 15 | _Please respond to the questions below in pargraph form, replacing the text saying "Please answer here". Include as much detail as you can in your answer!_ 16 | 17 | ## Long Term Network Alignment 18 | ### Time Commitment 19 | Describe the nature and duration of your affiliation with the Filecoin project. Please include relevant Github handles, miner ids, significant projects or contributions (with links). 20 | ``` 21 | Please answer here. 22 | ``` 23 | 24 | ### Stake Exposure 25 | Please cite total token at stake (currently available, locked as collateral, vesting over time) and any substantiating evidence. 26 | ``` 27 | Please answer here. 28 | ``` 29 | 30 | ## Industry Reputation 31 | ### In-protocol Reputation 32 | Please describe (in detail) your activity and tenure as a member of the Filecoin community. Please note (with links where possible) any contributions made to implementations of Filecoin, the spec, documentation, or to substantially help the Filecoin ecosystem grow. 33 | ``` 34 | Please answer here. 35 | ``` 36 | 37 | ### In-protocol Security 38 | Please describe your contributions to the security of Filecoin and the duration over which you've made contributions. Please also include any links or references who might be able to substantiate your contributions (e.g. if you've filed several bugs, please cite who you've communicated with on the Filecoin side). 39 | ``` 40 | Please answer here. 41 | ``` 42 | 43 | ### External Reputation 44 | Please describe the nature of your organization, including the country of registration, size of the organization, and time since inception. 45 | ``` 46 | Please answer here. 47 | ``` 48 | 49 | Please share any relevant details to help substantiate information about your organization (website, named officers, links to social media profiles). 50 | ``` 51 | Please answer here. 52 | ``` 53 | 54 | Please share any relevant external information regarding your organization (e.g. news articles, social media profiles, etc.) 55 | ``` 56 | Please answer here. 57 | ``` 58 | 59 | 60 | ## Diversity and Decentralization 61 | ### Use Case Diversity 62 | (Optional) Any additional information you'd like to share about the use case(s) you plan to support? 63 | ``` 64 | Please answer here. 65 | ``` 66 | 67 | 68 | # Allocation Plan Template 69 | ## Concreteness of Allocation Plan 70 | ### Allocation Strategy 71 | How do you plan on allocating the DataCap requested above? Please describe your allocation strategy with as much specificity as you can. 72 | ``` 73 | Please answer here. 74 | ``` 75 | 76 | Are there any internal processes you plan on impelementing regarding the target, amount, or rate at which you'll allocate DataCap? 77 | ``` 78 | Please answer here. 79 | ``` 80 | 81 | How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap? 82 | ``` 83 | Please answer here. 84 | ``` 85 | 86 | ### Client Due Diligence 87 | How will you vet your Client to ensure they are spending that DataCap responsibly? 88 | ``` 89 | Please answer here. 90 | ``` 91 | 92 | What questions will you ask to ensure the Client can properly handle the DataCap you intend to allocate to them? 93 | ``` 94 | Please answer here. 95 | ``` 96 | 97 | What processes will you employ to confirm that a Client is not improperly over-allocating DataCap to a single entity? 98 | ``` 99 | Please answer here. 100 | ``` 101 | 102 | ### Bookkeeping Plan 103 | Do you plan on keeping records of your allocation decisions? If so, with what level of specificity do you intend to respond to any audit requests? 104 | ``` 105 | Please answer here. 106 | ``` 107 | 108 | Do you plan on conduct your allocation decisions in public (e.g. Github repo), private (e.g. over email, Telegram, etc), or both? 109 | ``` 110 | Please answer here. 111 | ``` 112 | 113 | ## Track Record 114 | ### Past allocation 115 | Have you previously received DataCap to allocate before? If so, please link to any previous applications. 116 | ``` 117 | Please answer here. 118 | ``` 119 | 120 | Cumulatively, how much DataCap have you previously successfully allocated? 121 | ``` 122 | Please answer here. 123 | ``` 124 | 125 | Have there been (or are there still) any disputes raised against you from your previous DataCap allocations? 126 | ``` 127 | Please answer here. 128 | ``` 129 | -------------------------------------------------------------------------------- /quality-tracking-metrics.md: -------------------------------------------------------------------------------- 1 | The current metric of measuring quality data onboarding / potential abuse consists of: 2 | - Data stored in deals where the CID is shared across client DataCap applications 3 | - $(n-1)*\text{size of CID}$, where n is the number of duplicates 4 | - If two clients use the same dataset, but preparation is different, then we are counting them as different CIDs. 5 | - This likely means that the data is being duplicated many times and the client is storing it with the same SP 6 | - Data stored in deals where the CID has been stored more than 2 times with the same SP ID 7 | - $(n-1)*\text{size of CID}$, where n is the number of duplicates 8 | - This likely means that the same data is being shared and stored by different clients 9 | - All data stored by a client address where the client address has used between 10% and 90% of their DataCap allocation, has not made any deals in the last 6 weeks, and has stored everything in unique CIDs 10 | - This likely means that this not being duplicated at all and therefore not being distributed enough 11 | 12 | The following is the a query specifying how we will tag deals under these three flags and its explanation: 13 | 14 | ``` 15 | CREATE OR REPLACE FUNCTION epoch_to_timestamp(epoch INTEGER) 16 | RETURNS INTEGER AS $$ 17 | BEGIN 18 | RETURN epoch * 30 + 1598306400; 19 | END; 20 | $$ LANGUAGE plpgsql; 21 | 22 | CREATE OR REPLACE FUNCTION tag_over_replicated_deals() 23 | RETURNS VOID AS $$ 24 | BEGIN 25 | INSERT INTO deal_tags (deal_id, cid_overreplicated, sector_start, piece_size) 26 | SELECT 27 | cs.deal_id, 28 | cs.row_number > 1 AS cid_overreplicated, 29 | TO_TIMESTAMP(epoch_to_timestamp(cs.sector_start_epoch)), 30 | cs.piece_size 31 | FROM ( 32 | SELECT 33 | *, 34 | ROW_NUMBER() OVER ( 35 | PARTITION BY piece_cid, provider 36 | ORDER BY sector_start_epoch 37 | ) AS row_number 38 | FROM 39 | current_state 40 | WHERE 41 | verified_deal = true 42 | AND sector_start_epoch > 0 43 | ) AS cs 44 | ON CONFLICT (deal_id) 45 | DO UPDATE SET cid_overreplicated = EXCLUDED.cid_overreplicated, 46 | sector_start = EXCLUDED.sector_start, piece_size = EXCLUDED.piece_size; 47 | END; 48 | $$ LANGUAGE plpgsql; 49 | 50 | CREATE OR REPLACE FUNCTION tag_cid_sharing_deals() 51 | RETURNS VOID AS $$ 52 | BEGIN 53 | WITH owner_count AS ( 54 | SELECT 55 | piece_cid, 56 | COUNT(DISTINCT owner) AS owner_count 57 | FROM ( 58 | SELECT 59 | current_state.piece_cid, 60 | COALESCE(github_client_mapping.unique_id::TEXT, current_state.client) AS owner 61 | FROM 62 | current_state 63 | LEFT JOIN github_client_mapping ON current_state.client = github_client_mapping.client_address 64 | WHERE 65 | verified_deal = true 66 | AND sector_start_epoch > 0 67 | ) AS distinct_owners 68 | GROUP BY piece_cid 69 | ) 70 | INSERT INTO deal_tags (deal_id, cid_shared, sector_start, piece_size) 71 | SELECT 72 | cs.deal_id, 73 | (cs.row_number > 1 AND oc.owner_count > 1) AS cid_shared, 74 | TO_TIMESTAMP(epoch_to_timestamp(cs.sector_start_epoch)), 75 | cs.piece_size 76 | FROM ( 77 | SELECT 78 | cs_with_owner.*, 79 | ROW_NUMBER() OVER ( 80 | PARTITION BY piece_cid, owner 81 | ORDER BY sector_start_epoch 82 | ) AS row_number 83 | FROM ( 84 | SELECT 85 | current_state.*, 86 | COALESCE(github_client_mapping.unique_id::TEXT, current_state.client) AS owner 87 | FROM 88 | current_state 89 | LEFT JOIN github_client_mapping ON current_state.client = github_client_mapping.client_address 90 | WHERE 91 | verified_deal = true 92 | AND sector_start_epoch > 0 93 | ) AS cs_with_owner 94 | ) AS cs 95 | JOIN owner_count oc ON cs.piece_cid = oc.piece_cid 96 | ON CONFLICT (deal_id) 97 | DO UPDATE SET cid_shared = EXCLUDED.cid_shared, 98 | sector_start = EXCLUDED.sector_start, piece_size = EXCLUDED.piece_size; 99 | END; 100 | $$ LANGUAGE plpgsql; 101 | 102 | 103 | CREATE OR REPLACE FUNCTION tag_cid_unique_deals() 104 | RETURNS VOID AS $$ 105 | BEGIN 106 | WITH eligible_clients AS ( 107 | SELECT 108 | COALESCE(gcm.unique_id::TEXT, cs.client) AS grouped_client, 109 | SUM(cs.piece_size) AS total_storage, 110 | MAX(cs.sector_start_epoch) AS max_sector_start_epoch 111 | FROM 112 | current_state cs 113 | LEFT JOIN github_client_mapping gcm ON cs.client = gcm.client_address 114 | WHERE 115 | cs.verified_deal = true 116 | AND cs.sector_start_epoch > 0 117 | GROUP BY 118 | grouped_client 119 | HAVING 120 | SUM(cs.piece_size) > (1::BIGINT * 1024 * 1024 * 1024 * 1024) 121 | AND (TO_TIMESTAMP(epoch_to_timestamp(MAX(cs.sector_start_epoch))) + interval '6 weeks') <= NOW() 122 | ), 123 | unique_deals AS ( 124 | SELECT 125 | cs.*, 126 | COALESCE(gcm.unique_id::TEXT, cs.client) AS grouped_client, 127 | ROW_NUMBER() OVER ( 128 | PARTITION BY COALESCE(gcm.unique_id::TEXT, cs.client), cs.piece_cid 129 | ORDER BY cs.sector_start_epoch 130 | ) AS row_number 131 | FROM 132 | current_state cs 133 | LEFT JOIN github_client_mapping gcm ON cs.client = gcm.client_address 134 | WHERE 135 | cs.verified_deal = true 136 | AND cs.sector_start_epoch > 0 137 | ) 138 | INSERT INTO deal_tags (deal_id, cid_unique, sector_start, piece_size) 139 | SELECT 140 | ud.deal_id, 141 | (ud.row_number = 1 AND ec.grouped_client IS NOT NULL) AS cid_unique, 142 | TO_TIMESTAMP(epoch_to_timestamp(ud.sector_start_epoch)), 143 | ud.piece_size 144 | FROM 145 | unique_deals ud 146 | LEFT JOIN eligible_clients ec ON ud.grouped_client = ec.grouped_client 147 | ON CONFLICT (deal_id) 148 | DO UPDATE SET 149 | cid_unique = EXCLUDED.cid_unique, 150 | sector_start = EXCLUDED.sector_start, 151 | piece_size = EXCLUDED.piece_size; 152 | END; 153 | $$ LANGUAGE plpgsql; 154 | ``` 155 | This code defines four PostgreSQL functions using PL/pgSQL, a procedural language for PostgreSQL. These functions are used to tag and process deal data related to file storage. 156 | 157 | epoch_to_timestamp(epoch INTEGER): This function takes an integer epoch as input and returns an integer. It converts the given epoch value to a timestamp by multiplying it by 30 and then adding the constant 1598306400. The returned value represents Unix time. 158 | 159 | tag_over_replicated_deals(): This function tags deals that are over-replicated. It does so by inserting or updating deal tags in the deal_tags table based on the calculated cid_overreplicated value, which indicates whether the deal is over-replicated or not. The function also sets sector_start and piece_size columns for the corresponding deal. 160 | 161 | tag_cid_sharing_deals(): This function tags deals that share content identifiers (CIDs) across multiple clients. It calculates the cid_shared value, which indicates whether the deal shares a CID with other deals, and inserts or updates the deal_tags table with this value. The function also sets sector_start and piece_size columns for the corresponding deal. 162 | 163 | tag_cid_unique_deals(): This function tags deals with unique content identifiers (CIDs) for clients that have stored more than 1 TiB of data and have not added any new storage within the last 6 weeks. It calculates the cid_unique value, which indicates whether the deal has a unique CID or not, and inserts or updates the deal_tags table with this value. The function also sets sector_start and piece_size columns for the corresponding deal. 164 | 165 | In summary, these four functions are designed to process and tag deal data in a PostgreSQL database, which can be useful for tracking and analyzing data storage deals. 166 | -------------------------------------------------------------------------------- /root-key-holders/README.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | The role of the Root Key Holder is not to make subjective decisions - rather to act as an executor for decisions made by the community on-chain. The action space and power of Root Key Holders are also limited by design. Any deviation from this mandate will make the offending Root Key Holders immediately subject to removal through a FIP. 3 | 4 | |Organization|Date Added|Status| 5 | |-|-|-| 6 | |Protocol Labs|15th Oct 2020|active| 7 | |Filecoin Foundation|15th Jan 2021|active| 8 | |Ethereum Foundation|15th Jan 2021|active| 9 | |Soramitsu|17th Sept 2021|active| 10 | 11 | ## Role and Responsibilities 12 | 13 | Root Key Holders are signers to a Multisig on chain with the power to grant and remove Notaries (and associated DataCap amounts). Root Key Holders are selected based on their reputation and alignment with the long term health of the Filecoin network. The responsibilities of the Root Key Holder are to: 14 | - Exercise decisions made by the community governance on-chain. 15 | - Take action on finalized decisions in a timely manner. 16 | 17 | Root Key Holders should expect to meet on a regular cadence to process approved actions from the Governance repository. It is expected that every action taken by a Root Key Holder should be linked to a governance decision and require collective action by a substantial number of Root Key Holders in order to be processed. 18 | 19 | ## Selection Criteria 20 | Candidates will meet the following criteria: 21 | - Root Key Holders are expected to have experience managing private keys. 22 | - Root Key Holders should have experience acting in high trust roles. 23 | 24 | While the individual identities of the Root Key Holders will not be made public for security reasons, the representative organizations will be made known and their actions are public on-chain. Given the limited space of action and ease of rotation, the sensitivity and significance of Root Key Holders have been drastically reduced. 25 | --------------------------------------------------------------------------------