Security Model

Design Philosophy#

Gao DePIN security rests on one principle: fraud must be more expensive than honest participation. The system is designed so that:

Fake service delivery requires real resource expenditure to evade detection
Sybil attacks are economically irrational at scale
Collusion between nodes and validators is penalized with collateral slashing
No single party can unilaterally approve or block compensation

Threat Model#

In-Scope Threats#

Threat

Mitigation

Fake service receipts (node claiming delivery without delivering)

Cryptographic proofs required; validator challenge-response; pattern analysis

Replay attacks (submitting old receipts)

Receipt IDs are unique and time-windowed; validators check for duplicates

Sybil nodes (one operator running many fake nodes)

Geographic diversity requirements; challenge-response correlation; collateral requirements

Validator collusion with nodes

Multi-validator quorum required; collateral slashing for provable collusion

Timing attacks on availability proofs

Random challenge timing; on-chain randomness; 60-second freshness window (MVP default — subject to governance)

Storage proof forgery

Merkle proof cryptography; random segment selection; validator verification

Compute result manipulation

Output hash commitment; GAR v1 sandbox isolation; deterministic execution

Governance capture via token accumulation

Governance weight is contribution-based, not token-based; non-transferable

Rating manipulation (fake reputation)

Reputation derived from validator-verified receipts only; self-reports not accepted

Out-of-Scope Threats

Physical compromise of hardware running node software → operator responsibility
Compromise of the $GAO smart contract → independent audit scope
L4 (Payment) settlement failures → Layer 4 security model
L8 (AI OS) sandbox escape → Layer 8 security model
Internet-level BGP hijacking → Layer 6 (Network) threat model

DePIN Security Invariants (Protocol invariants — not subject to governance change)#

Invariant

DEP-INV01

No compensation is released without a quorum-verified receipt

DEP-INV02

No single validator can unilaterally approve or block a receipt

DEP-INV03

All challenge randomness is on-chain verifiable; no party can predict challenge timing

DEP-INV04

Governance weight is bound to node identity; non-transferable, non-purchasable

DEP-INV05

Rail A scoring inputs are validator-verified only; self-reported data is not accepted

DEP-INV06

Epoch scores are Merkle-anchored on-chain; immutable after the dispute window

DEP-INV07

Validator collateral slashing requires on-chain evidence and multi-validator consensus

DEP-INV08

Storage nodes never receive decryption keys; all stored data is pre-encrypted by client

DEP-INV09

Compute nodes execute inside GAR v1 sandbox; cannot access cross-workload data

DEP-INV10

Settlement flows through Layer 4 (non-custodial); DePIN layer holds no funds

Sybil Resistance#

A Sybil attack is when one operator creates many fake node identities to game the reputation or Rail A scoring system. Gao DePIN mitigates this through four mechanisms: Validator challenge correlation. If many nodes share unusual response timing patterns, geographic IP clusters, or identical performance fingerprints, the validator network flags them for investigation. Economic cost scaling. Each node requires hardware resources to pass validator challenges. Creating N fake nodes requires N times the hardware — there is no shortcut. At scale, the cost of Sybil attacks exceeds the potential Rail A gain. Collateral requirements for validators. The validator layer cannot be Sybil-attacked cheaply because validators must post collateral that is at risk for malicious behavior. Governance weight decay. Even if a Sybil cluster accumulates governance weight in early epochs, the decay mechanism means maintaining influence requires ongoing real infrastructure contribution — which scales linearly with hardware cost.

Fraud Economics#

Expected fraud gain = P(undetected) × compensation_amount
Expected fraud cost = P(detected)   × (collateral_slashed + reputation_lost + ban_penalty)

The detection probability approaches 1 over time because:

Validators issue random challenges continuously
Pattern analysis improves with network scale
Honest nodes are incentivized to report fraudulent neighbors (competing for the same workloads)
On-chain receipts create a permanent audit trail For fraud to be profitable, P(undetected) must be high. The system is designed so that this becomes increasingly unlikely as the validator network grows.

Compute Workload Privacy#

Compute nodes execute workloads but are isolated from workload content by the GAR v1 sandbox:

┌──────────────────────────────────────────────┐
│ Compute Node Hardware                         │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │ GAR v1 Supervisor                    │    │
│  │ (receipt generation, policy)         │    │
│  │                                      │    │
│  │  ┌────────────────────────────────┐  │    │
│  │  │ Workload Sandbox               │  │    │
│  │  │ - No host filesystem access    │  │    │
│  │  │ - No cross-workload memory     │  │    │
│  │  │ - No private key access        │  │    │
│  │  │ - Output: hash only (to node)  │  │    │
│  │  └────────────────────────────────┘  │    │
│  └──────────────────────────────────────┘    │
└──────────────────────────────────────────────┘

The compute node sees the input hash and the output hash. It does not see the input content or the output content. The GAR v1 supervisor manages the sandbox and generates the execution receipt — the compute node hardware provides cycles, not intelligence. This is enforced by DEP-INV09.

Storage Privacy#

Storage nodes store pre-encrypted chunks. They have no access to decryption keys:

Client encrypts data (client-side) → encrypted_chunk
  ↓
Storage node receives encrypted_chunk
  ↓
Storage node stores opaque bytes
  ↓
Availability proof: node proves it holds the bytes (not that it can read them)
  ↓
Client retrieves encrypted_chunk → client decrypts (client-side)

Even if a storage node is compromised, the attacker obtains only encrypted data. Key management is the client's responsibility, enforced by Layer 5 (Domain) and Layer 1 (Workspace) key architecture. This is enforced by DEP-INV08.

Responsible Disclosure#

Security vulnerabilities in Gao DePIN infrastructure:

Email: security@gao.systems
Response SLA: 24 hours for critical, 5 business days for others
Scope: Validator receipt verification, PoC scoring, node collateral, Sybil resistance mechanisms The DePIN security model operates on top of the Layer 4 (Payment) and Layer 5 (Domain) security models. See each layer's security documentation for the invariants they enforce independently.