zkPass Verifiable Internet Data Network

1. Introduction

Modern digital systems are fundamentally dependent on external data. Smart contracts rely on APIs, AI agents consume web services, and financial systems depend on off-chain computation. Yet the internet was never architected to provide cryptographic guarantees of data authenticity — APIs can return tampered responses, servers can fabricate computation results, and data provenance cannot be independently verified.

As decentralized finance, autonomous agents, and automated governance systems mature, these trust assumptions are rapidly becoming systemic infrastructure risks.

The internet requires a new primitive:

Proof-of-Internet-Data

zkPass is purpose-built for this challenge.

zkPass introduces an entirely new infrastructure layer — the Verifiable Internet Data Layer. By unifying three cryptographic paradigms — zkTLS, zero-knowledge proof verification, and Trusted Execution Environments (TEE) — zkPass enables applications to verify data provenance, computational integrity, and the correctness of verification outcomes.

Data is no longer trusted — it is cryptographically proven to be authentic.

The zkPass Node Network is the cornerstone of this vision. It is a decentralized verification infrastructure where pool nodes perform zkProof verification and secure computation, while watcher nodes provide network-wide oversight and dispute arbitration. All core protocol logic is executed through on-chain smart contracts, leveraging the Transparent Proxy Pattern, OpenZeppelin security primitives, and on-chain RBAC access control to ensure protocol transparency, security, and upgradeability.

2. How It Works

2.1 Tri-Layer Verification Architecture

The zkPass Node Network employs a tri-layer architecture that achieves the unification of decentralized execution and decentralized oversight:

• Execution Layer: Pool nodes perform zkProof verification, zkTLS attestation validation, verification task scheduling, and TEE-secured computation. Pools operate as non-hierarchical, horizontally scalable units.
• Protocol Layer: On-chain smart contracts manage staking, reward distribution, dispute arbitration, and fund escrow. All state transitions are fully transparent and publicly auditable.
• Oversight Layer: Watcher nodes independently monitor network-wide node behavior and file on-chain disputes upon detecting anomalies.

2.2 Off-Chain Consensus and Task Execution

zkPass implements a cryptographic signature-based off-chain consensus protocol for task distribution, execution, and result aggregation. The Operator generates signed task messages; nodes return signed acknowledgments. Upon completion, nodes submit signed results and commitments. The Operator aggregates batch reports and submits on-chain. The Resolver runs independent verification off-chain and executes adjudication via on-chain transactions.

2.3 Batch Execution Model

The network operates on batch-based settlement cycles:

• Step 1 — Operator submits batch report (per-node uptime, task completion).
• Step 2 — Contract computes rewards (uptime, task completion, node status).
• Step 3 — Rewards credited to pool (ACTIVE), escrowed (SUSPENDED), or none (BANNED).
• Step 4 — Pool operators claim settled task rewards and staking yields.

2.4 Staking Yield Mechanism

Pools accrue staking yields based on aggregate effective stake. Yields accumulate per block; upon node status transitions they are automatically settled. Staking yields operate independently of task rewards.

2.5 Security Model: Triple-Layered Guarantees

2.6 Dispute Resolution Protocol

Watcher nodes perform continuous surveillance. On anomaly: watcher files on-chain dispute → target node auto-suspended → rewards escrowed → Resolver adjudicates (valid → escrow disposition / ban threshold; invalid → watcher penalized, node restored). This achieves bilateral economic constraints: nodes risk suspension and slashing; watchers risk forfeiture for false disputes. The equilibrium: all participants act honestly.

3. Node Types

3.1 Pool Nodes

Pool nodes perform zkProof verification, zkTLS attestation processing, verification task execution, and secure computation. Nodes verify cryptographic proofs about data, never plaintext — preserving privacy and integrity.

Nodes are organized into pools as the fundamental unit. Node status lifecycle: Register → PENDING → (stake threshold) → ACTIVE; reported → SUSPENDED; ban threshold → BANNED; unstaking → cooldown → EXIT.

Beyond executing verification tasks, nodes inherently possess monitoring capabilities similar to Watchers. By participating in task execution and observing batch reports, nodes gain visibility into network activity and can detect inconsistencies or abnormal behavior from other nodes. Dedicated Watchers extend this mechanism by acting as the formal dispute layer, responsible for submitting challenges and triggering the protocol’s arbitration process.

3.2 Watcher Nodes

Watchers form the security oversight layer. They monitor uptime, verification behavior, and batch reports, filing on-chain disputes on anomalies. Watchers operate under a multi-tier system: higher tiers require greater stake and yield higher reward multipliers. Tier is based on computation capacity, network reliability, economic commitment, and performance; only ACTIVE watchers may file disputes and claim rewards.

4. Economics

4.1 Pool Node Revenue

4.2 Watcher Revenue

Watchers earn per-block rewards by tier multiplier and active duration; computation is non-dilutive. Claims: direct on-chain or Delegated Claim (signature-based).

4.3 Slashing Mechanism

All slashing rules are hardcoded and publicly queryable:

• Node unstaking with valid disputes: proportional penalty (capped).
• Node ban: stake locked at ban threshold.
• Watcher false dispute: portion of rewards and stake deducted.

5. Node Requirements

5.1 Hardware Specifications

Each pool node runs both a Validator Node and a TEE Node:

5.2 Staking and Cooldown Period

All nodes and watchers must meet the protocol-mandated stake before activation. Unstaking triggers a cooldown period before withdrawal; no new rewards accrue during cooldown.

6. Permissioned Access (Beta)

The zkPass Node Network is in Beta under a permissioned allowlist model. Controlled admission maintains verification quality and mitigates systemic risks until decentralized governance matures. Admission will be progressively relaxed toward permissionless participation.

To join the zkPass Node Network, please send an email to info@zkpass.org.

7. Roadmap

• Phase 1 — Foundation (Current)
  Core contract deployment: pool node registration, batch reward settlement, watcher oversight, dispute arbitration, staking-slashing economics.
• Phase 2 — Network Expansion
  Permissionless node and pool onboarding, dynamic staking yields, automated watcher evaluation, cross-pool task scheduling.
• Phase 3 — Decentralized Governance
  On-chain voting, community-driven dispute arbitration, permissionless admission, cross-chain verification.
• Phase 4 — Ecosystem Maturity
  Fully decentralized autonomy, secondary market stake liquidity, advanced TEE ecosystem, open developer SDK.