Network

The Network is built around a few fundamental concepts which are key to using the protocol correctly.

Core Concepts

• DIDs (did:pkh) — Wallet‑based, chain‑agnostic identifiers.

• Verifiers — Modular verification logic that proves claims programmatically. Day‑one: ownership-basic, nft-ownership, token-holding, ownership-licensed.

• qHash — Quantum‑resistant identifier for each verification event.

• Proofs — Signed attestations of verifier results; stored off‑chain with optional IPFS snapshot.

• Vouchers (ERC‑7683) — Minimal on‑chain messages enabling cross‑chain availability.

Protocol Architecture

• Hub‑and‑Spoke

  • Hub: Base Sepolia (84532) performs verification.

  • Spokes: optional spokes receive vouchers for local verification.

• Main building blocks

  • API & Verification Service

  • Verifier Framework (modular checks)

  • Proof Storage (off‑chain + optional IPFS)

  • Voucher Hub/Spoke contracts (ERC‑7683)

  • Relayer (batched delivery to destination chains)

Diagram – System Architecture Overview

• User Layer: wallet‑based DID, signs requests.

• Modular Verification Engine: orchestrates verifiers (ownership, identity, compliance, platform, asset).

• Cryptographic Layer: quantum‑resistant anchoring, optional conditional ZK.

• Storage Layer: distributed proof records; optional immutable snapshots (IPFS when enabled).

• Cross‑Chain Layer: universal voucher system (ERC‑7683), hub‑and‑spoke topology.

• Blockchain Networks: Hub (Base L2) + optional Spokes (Any) for local verification.

• Key innovations: trust delegation, modular verifiers, quantum‑resistant IDs, cross‑chain native, conditional privacy.

Verification Lifecycle

1. Submit — Client calls POST /verification with verifierIds, data, walletAddress, signature, signedTimestamp.

2. Compute — API derives qHash, records pending status, invokes verifier(s).

3. Evaluate — Verifiers perform checks (e.g., on‑chain reads) and return result; optional ZK may run asynchronously.

4. Finalize — Status persisted; optional IPFS snapshot when enabled and privacy allows.

5. Propagate (optional) — Successful proofs create ERC‑7683 vouchers; Relayer batches and delivers to Spokes.

6. Use Anywhere — dApps verify qHash on destination chains via Spoke contracts or API/SDK.

Principles

• Chain‑agnostic — did:pkh + hub‑and‑spoke; mainnet reads, spoke availability.

• Modular — API, verifiers, relayer, contracts can evolve independently.

• Async & batched — Background ZK (when applicable) and grouped relays keep cost low and throughput high.

Notes

• ZK is optional and verifier‑dependent (some partner‑gated).

• IPFS and public exposure are opt‑in and respect privacy controls.

• Use the standardize → sign → verification flow to avoid newline/encoding issues.