Allocator-Pathway-EF

Notary Allocator Pathway Name : EF

🚀 EF渠道分配提案 | EF Allocation Proposal

GitHub Issue: filecoin-project/notary-governance#1056

---

📌 一、组织信息 | Organization Information

• 组织名称 | Organization Name: EF
• 联系方式 | Contact Info:
  • GitHub: Lind111
  • Email:[email protected]

---

🧭 二、客户定位 | Client Positioning

中文说明：
EF是一条新途径。这个拟议的渠道旨在让我们能够接触并支持我们了解并能够有效参与在 Filecoin 网络上存储数据的 web2 和 web3 企业数据所有者。

EF是一个公有云聚合平台，我们聚合到公有云的客户都有真实且大量的数据存储需求。因此，该渠道的客户将是高效的，数据存储的教育成本低，并且是长期可持续的。

English Description:
EF is a new pathway. This proposed channel is designed to allow us to reach and enable web2 and web3 enterprise data owners whom we understand and can effectively engage to store data on the Filecoin network. EF is a public cloud aggregation platform, and the clients we aggregate to the public cloud have real and substantial data storage needs. Therefore, the clients in this channel will be highly efficient, with low educational costs for data storage, and sustainable over the long term.

---

🔍 三、审核规则 | Audit Requirements

1. ✅ 完成 KYC 或 KYB 身份认证
   ✔️ Complete KYC (Know Your Customer) or KYB (Know Your Business) process
2. 🌍 提供协作存储节点列表并审核其地理分布
   ✔️ Provide a list of cooperating storage providers (SPs) and review geographic distribution
3. 🧪 提供数据样本并进行数据合规审查
   ✔️ Submit data samples for compliance review
4. ⚙️ 封装节点与披露节点一致，不一致需提前披露
   ✔️ Match between sealing and disclosure nodes; discrepancies must be pre-reported
5. 🔎 检查检索率与数据备份机制
   ✔️ Verify retrieval rate and data redundancy
6. 🎯 数据封装过程中执行随机抽样
   ✔️ Conduct random sampling during storage operations

---

💾 四、数据要求 | Data Requirements

1. 💠 至少进行 4 份数据备份
   • At least 4 data backups
2. 🌐 节点地理位置分布 ≥4 个地区
   • Nodes must span at least 4 distinct geographic regions
3. 📊 单轮中每个 SP 分配不超过 25%
   • Each SP receives no more than 25% of DataCap per round

---

📦 五、DataCap 分配机制 | DataCap Allocation Strategy

1. 🟡 初次分配：最多5%（≤256 TiB）

   • First Allocation: max 5% (≤256 TiB)

2. 🟠 第二次分配：10%

   • Second Allocation: 10%

3. 🔵 第三次分配：15%

   • Third Allocation：15%

4. 🔵第四次分配：20%

   • Fourth Allocation：20%

5. 🟠 第五次分配和以后：25%

   • Fifth Allocation：25%

🟡 任何一部分的规模都不能超过前一部分的2倍。

🟡 No tranche can exceed 2× the size of the previous one.

---

🛡️ 六、风险缓解机制 | Risk Mitigation Strategy

1. 🧾 每轮额度发放前重新审核封装情况
   • Re-audit client sealing status before each new allocation
2. 🤖 启动 check bot 实时监控 DataCap 使用情况
   • Activate check bot during working hours to monitor client activity
3. 🛠️ 客户若违规，最多给予三周调整时间
   • Allow a maximum of 3 weeks for rectification in case of non-compliance
4. ⛔ 超期未整改或违规严重，终止后续 DataCap
   • Failure to comply will lead to termination of future DataCap allocations

---

⚖️ 七、争议处理机制 | Dispute Resolution Mechanism

📁 类型一：渠道内部争议 | Type 1: Internal Disputes (Client vs. Client)

• ⏱️ 响应时间：1–2 天
  • Response Time: 1–2 days
• 📂 双方提交证据链，由分配者决定是否公开
  • Both parties submit evidence; Allocator determines transparency
• 🧾 问责方式 | Accountability Measures:
  • 暂停 DataCap，整改后恢复
    • Suspend DataCap; resume upon compliance
  • 回收未使用的 DataCap 配额
    • Reclaim unused quotas
  • 标记客户或 SP，不再进行分配
    • Blacklist Client/SP from future allocations

---

📂 类型二：外部对渠道客户或 SP 的争议 | Type 2: Third-Party Disputes (Against Channel Clients/SPs)

• ⏱️ 响应时间：1–2 周
  • Response Time: 1–2 weeks
• 📄 各方提交证据，由 分配者 组织对话并裁定透明程度
  • All parties provide evidence; Allocator facilitates dialogue and determines transparency
• ✅ 问责机制与类型一一致
  • Same accountability as Type 1

---

🧭 类型三：外部对渠道运营方本身的争议 | Type 3: Third-Party Disputes (Against the Allocator/Pathway)

• ⏱️ 分配者支持实时响应
  • Allocator supports real-time responses
• 🔍 高透明度原则，在不影响自身利益的前提下最大限度公开
  • High transparency is supported, provided Cyberport's interests are protected
• 🧾 问责机制 | Accountability:
  • 暂停通道资格，整改后可恢复
    • Suspend channel access, restore after adjustment
  • 回收所有未使用的配额
    • Reclaim all unused DataCap quotas