# Altruistic Mode Proposal – Codex Storage

## Goals

The proposed altruistic mode aims to enable broader participation and improved resilience in the Codex Storage network while minimizing engineering overhead. The key objectives are:

- **Minimal divergence** from the current protocol architecture.
- **Seamless integration** with Logos Core and other related modules (e.g., Waku).
- **Lightweight economic design** for altruistic participants, without requiring full token launch or complex economic infrastructure.

---

## Current Design


The diagram above outlines the current architecture of Codex Storage. While functional, it presents the following limitations:

- **On-chain proof verification overhead:**
Storage providers submit zk-proofs at regular intervals for all active storage slots. Each slot requires an individual proof to be validated on-chain. This becomes prohibitively expensive for small files, effectively preventing support for them. To partially mitigate this, we increased the slot size, which adversely affects the usage and durability guarantees.

- **Storage client resource requirements:**
Storage clients manage coordination for storage buy/sell operations and temporarily cache user files. Running a storage client requires decent computational and network resources, making it infeasible for low-powered or mobile devices thereby limiting the network's accessibility and decentralization.

- **Token dependency for economics:**
The current incentive design hinges on the Codex token: users pay in Codex tokens, and providers stake them as collateral. While aligned with the long-term vision, this creates a bottleneck by making the protocol dependent on the token launch something influenced by external variables.

> 💡 _There are additional implementation challenges that further impact the protocol’s scalability and performance._

---

## Proposed Enhancements

### 1. Sentinel Validator Network

Following the design discussions with Dmitry, Mark, and others, we propose moving zk-proof validation off-chain to a sentinel validator set. The initial concept is [documented here](https://hackmd.io/@dryajov/rJtll1-Eee). While still in draft, this design shows strong promise in significantly reducing on-chain costs while maintaining data integrity.

> _Note: The viability and engineering complexity of implementing sentinel validators must be thoroughly analyzed._

---

### 2. Light Client Support

Inspired by IPFS and similar systems, we propose developing a browser-compatible **light client** for Codex. This client would:

- Participate in Codex P2P using lightweight DHT operations for peer and content discovery.
- Communicate with other nodes over RPC to support uploads and downloads via storage clients.
- Require minimal hardware, making it suitable for mobile and browser-based use cases.

> _This facilitates seamless integration with other Logos components, broadens network participation, and significantly improves the user experience._

---

### 3. Collateral & Reputation Mechanism

To mitigate abuse and Sybil attacks while avoiding full token-based incentives, I propose a hybrid collateral and reputation-based model:

#### Storage Clients

- Stake SNT or supported tokens to gain access to a defined amount of storage capacity.
- May cancel storage contracts and withdraw staked tokens at **any time**.
- A small exit fee (as service charge) is deducted upon withdrawal.

#### Storage Providers

- Must stake a fixed amount of SNT (or equivalent) to join the network. This acts as an **entry deposit**, fully refundable.
- Earn **reputation points** for each successfully honored storage contract.
- Reputation points can later be redeemed for Codex tokens at a rate defined by the Codex DAO/Foundation.

> _This design encourages participation while locking protocol liquidity, strengthening our position with prospective investors and aligning incentives for future decentralization._

---

## Rollout Plan

This phased rollout plan can be refined based on internal feedback:

### Phase 1: Protocol Hardening & Token-less Onboarding

- Refactor and stabilize core modules: `BlockExchange`, `RepoStore`, etc.
- Implement staking logic and reputation point issuance.
- Use a **private Ethereum network** for marketplace operations and proof verification.

### Phase 2: Validator Network & Light Client

- Launch a **permissioned Sentinel Validator Network** for off-chain proof validation.
- Release a browser-compatible **Codex Light Client** for storage and retrieval.

As the network matures and engineering capabilities improve, we can progressively migrate from a permissioned setup to a **public validator and marketplace architecture** supporting full decentralization over time.

> The core storage network which includes Storage Providers/Storage Clients will be **QUASI** permissioned from day one.

---