DePINs About en / zh

Purpose

DePINs (Decentralized Physical Infrastructure Networks) depend on trust minimization: users should contribute resources (bandwidth, compute, storage, sensing, etc.) without sacrificing privacy or control. This page explains the overall architecture shown in the diagram and the design choices that keep user configuration and private data isolated from the public coordination layer.

System Architecture Overview

The diagram illustrates a split between the Depins Web Platform (catalog + orchestration guidance) and the User Local / Self-Controlled Execution Environment where miners or resource agents actually run. The platform never ingests private runtime credentials, wallets, or machine-level data used by miner processes.

Privacy & Data Separation

• Configuration entered on the Depins website remains limited to general project selection, non-sensitive preferences, and internationalized descriptive metadata.
• Sensitive runtime material (wallet keys, node tokens, local environment variables, OS level metrics) stays exclusively in the user's local environment or their chosen secure vault.
• No transmission of private miner credentials to the Depins server—design explicitly avoids custody or proxying of user secrets.

Execution Model

The web platform provides:

1. Discovery & evaluation of DePIN projects (status, introduction, categories).
2. Human readable setup guidance and internationalized UI strings.
3. Optional structured metadata to help users script or template their local deployments.

All actual mining / resource contribution runs in a user-controlled runtime (local machine, container, home lab, VPS or edge device).

Open Source Miner Assurance

Miner / agent code is open source so users (or independent auditors) can inspect that it does not exfiltrate private data to the Depins platform. This transparency reinforces the claim that the server cannot access user secrets, because there is no embedded channel or hidden collection logic.

• User can review network calls: only protocol-required submissions (proofs, work shares, reward claims) go to the target DePIN network—not to the catalog server.
• Forking / reproducible builds enable verification of binaries against the published source.

High Level Data Flow

1. User browses catalog and picks a project.
2. Server returns descriptive metadata and non-sensitive parameters.
3. User locally prepares environment (keys, wallets, tokens)—never sent to server.
4. User launches open source miner / agent with local config.
5. Miner communicates directly with the project's decentralized network / protocol APIs.
6. Rewards / proofs handled at protocol level; catalog may later show public status (if user opts in with anonymized signals).

Design Principles

• Isolation - Strict boundary between presentation (server) and execution (local).
• Transparency - Open source miner code; reproducible verification path.
• Minimal Trust - Server never needs secrets; compromise of catalog does not leak user keys.
• Extensibility - New projects added by publishing metadata—not rewriting core logic.
• Portability - Users can migrate miners across machines without depending on centralized state.
• Localization - Early i18n improves global accessibility and adoption.

Why This Architecture

• User Sovereignty - Avoids custodial handling of private keys or machine telemetry.
• Security Reduction - Catalog server attack surface does not include sensitive credential stores.
• Auditability - Open miner logic + clear boundary supports independent security review.
• Scalability - Server scales mainly on read traffic (catalog queries), not on user workload execution.
• Interoperability - Loose coupling allows supporting heterogeneous DePIN project tooling.

Future Enhancements

Planned directions include optional local helper scripts, privacy-preserving aggregate statistics, contributor submission workflows, richer categorization and automated update notifications—always preserving the core separation of sensitive runtime data.

Verification & Trust

Users are encouraged to inspect the miner repository, review network traffic, and validate build hashes. This reinforces confidence that the architecture's stated boundaries are real and enforceable.