Cubiq Network Whitepaper

3.1. Execution Layer (zkEVM)

An EVM-compatible runtime environment optimized for zero-knowledge provability. It supports Solidity smart contracts with modifications to ensure efficient constraint generation for ZKPs.

• Solidity Compatibility: Supports standard Solidity 0.8.x opcodes.
• ZK-Optimization: Opcodes are carefully selected and optimized for efficient proving in Plonky3.
• State Management: Utilizes sparse Merkle trees for efficient state proofs.

3.2. Proving Layer (Cloud Prover Network)

This layer is responsible for generating zero-knowledge proofs of state transitions. It is a network of specialized, high-performance cloud-based provers.

• Plonky3 Integration: Leverages recursive STARK proofs for efficient and scalable proof generation.
• Horizontal Scaling: Designed to scale horizontally to meet demand.
• Proof Aggregation: Aggregates multiple transactions into single, verifiable proofs.

3.3. Consensus & Networking Layer (Mobile Qubes)

Managed by lightweight mobile-based validators ("Qubes") using a Delegated Proof of Stake (DPoS) consensus mechanism and gossip-based P2P networking.

• Lightweight Validation: Qubes verify ZKPs, not re-execute transactions.
• Gossip-based P2P: Efficient block and transaction propagation.
• DPoS Consensus: Enables broad participation in network security.

5.1. Transaction Inclusion

1. User submits a transaction through a wallet or dApp.
2. The transaction enters the pending mempool of a Qube or relay node.
3. A validator Qube (block proposer) bundles a set of valid transactions.
4. The block proposal is broadcast via Cubiq’s P2P network.

5.2. Proof Generation (Cloud Prover Role)

Once a block is proposed:

1. The cloud prover listens for proposed blocks via pub-sub.
2. It simulates all transactions using a zkEVM interpreter.
3. The execution trace is encoded into Plonky3 circuits.
4. A recursive ZK proof is generated for the block, including:
   • Merkle root transition
   • EVM state consistency
   • Public inputs (block number, state root, gas, etc.)
   • Signature verifications

This phase is computationally intensive and is offloaded to dedicated GPUs or TPU-based prover clusters.

5.3. Proof Packaging and zkURL Publication

Once the proof is generated:

• It is compressed and signed by the prover.
• Published to a zkURL endpoint, e.g.:
  

  zk://prover.cubiq.org/proof/123456

• The proof bundle includes:
  • The ZK proof
  • Public input data (encoded as JSON or binary)
  • Metadata: timestamp, prover ID, block hash
  • Fallback IPFS hash for decentralized availability

5.4. Proof Verification by Qubes

Qube clients (running on mobile) perform the following:

1. Fetch proof using zkURL.
2. Verify validity using:
   • Embedded Plonky3 verifier (WASM optimized)
   • Consistency of public inputs (gas, root hash, block hash)
3. If valid, the Qube votes on the block as part of DPoS consensus.

Even on mid-range phones, verification takes <500ms with <2MB memory footprint due to recursive proof compression.

5.5. Consensus and Finality

1. Qubes that have verified the proof broadcast votes in favor of the block.
2. Once 2/3 of weighted Qubes (by stake) have validated:
   • The block is finalized.
   • State root and block hash are stored.
3. Finality is deterministic — no fork resolution logic required.

5.6. Storage and Availability

1. Finalized blocks are pinned on:
   • Cubiq L1 storage (pebble-backed or IPFS)
   • zkURL mirrors and CDN
   • Merkle hash anchors on Ethereum L1 (optional future milestone)
2. Finality is deterministic — no fork resolution logic required.

5.7. Error Handling and Fraud Protection

1. If a Qube fails proof verification:
   • It does not vote, and alerts are raised.
   • If >1/3 of Qubes dispute a block, the block is rejected.
2. Malicious provers are slashed and blacklisted.
3. Qubes only accept proofs that:
   • Match expected block height
   • Have correct signatures from the registered prover ID
   • Pass all ZK verification rules

6.1. Purpose of zkURL

The zkURL is to Cubiq what http is to the Web, or ipfs:// is to decentralized storage. It:

• Decouples proof retrieval from verification
• Standardizes the way clients fetch proofs
• Supports redundancy and verifiability
• Enables modular backends (CDN, IPFS, on-chain, or DNS-based)

6.2. zkURL Format

A zkURL is a compact URI that encodes:

zk://[proverID]@[domain_or_hash]/[proof_id]#[metadata]

Example:

zk://prover01@prover.cubiq.org/block/8472934#v1

Components:

• proverID: Registered identity of prover (mapped to pubkey)
• domain_or_hash: Domain name or content hash of the proof
• proof_id: Unique identifier for the proof (e.g., block number or hash)
• metadata: Optional fragment for additional context (e.g. version, compression format)

6.3. zkURL Protocol Flow

1. Fetch
   • Clients initiate a fetch request using the zkURL.
   • Requests are routed to the appropriate prover or storage backend.
   • Supports retries and fallback sources for high availability.
2. Parse
   • Metadata is parsed (e.g. Plonky3 version, circuit format).
   • Signature and merkle root are decoded.
3. Verify
   • Qube verifies proof using embedded Plonky3 verifier.
   • Public inputs (e.g. block root, gasUsed) are cross-validated.
4. Cache
   • Verified proofs are cached on-device with TTL for efficiency.
   • Cached proofs can be served to other peers (optional).

6.4. zkURL Security Design

1. Proof Authentication
   • All proofs are signed by the registered prover keypair.
   • Qubes check against the on-chain ProverRegistry.
2. Integrity
   • Proof bundles include Merkle root and Keccak hash.
   • Qubes verify both hash integrity and Plonky3 consistency.
3. Replay Protection
   • Proofs include block.number, timestamp, and nonce.
   • Any replays are rejected if timestamp has expired or block mismatch occurs.
4. DoS Protection
   • Proof size limits (e.g. < 5MB)
   • Signature checks and throttled fetch rate per Qube

6.5. zkURL Redundancy & Availability

To ensure reliability in poor network conditions (e.g. mobile users):

1. Multi-source resolution
   • zkURL resolver falls back to:
   • Local cache (if available)
   • CDN mirrors (Cloudflare, AWS)
   • Alternative resolver endpoints
2. Compression support:
   • gzip / brotli encoded bundles
   • Optional WASM-decoded chunked fetching
3. Optional future: zkTorrent
   • P2P proof seeding by Qubes, with DHT-based lookup
   • zkURL could map to a content hash served by other mobile nodes

6.5. Example zkURL Bundle Schema (JSON)

{
  "proof": "base64_zkp_data",
  "publicInputs": {
    "blockHash": "0xabc...",
    "stateRoot": "0xdef...",
    "gasUsed": 123456
  },
  "signature": "0x...",
  "proverID": "prover01",
  "timestamp": 1728129993,
  "metadata": {
    "version": "v1.0",
    "compression": "gzip"
  }
}

7.1. Design Goals

• Run on Android/iOS phones (2GB+ RAM, quad-core)
• No full state storage or EVM execution
• Trustless verification of proofs
• Network gossip and consensus participation
• Offline-capable block validation
• Low bandwidth (≤ 10MB/day)

7.2. Roles Played by Qubes

7.3. Qube System Modules

• zkURL Resolver
  • Pulls zk-proofs from CDN, IPFS, or peer Qubes
  • Authenticates signatures and timestamps
• Proof Verifier (WASM)
  • Runs embedded Plonky3 verifier
  • Stateless execution of zkSNARKs
  • Verifies against public inputs (state root, gas, logs)
• Consensus Agent
  • Submits DPoS votes signed with local key
  • Monitors validator proposals
  • Optional fallback to light committee voting
• Header Sync Client
  • Syncs block headers and Merkle roots
  • Does not download full EVM state
  • Uses sparse Merkle proofs (future: Verkle)
• Storage Adapter
  • Compact local database (e.g., SQLite, RocksDB)
  • Caches recent zkURLs, header roots, balance snapshots

7.4. Qube-to-Chain Trust Model

Mobile Qubes maintain full trustlessness using:

• Proof-of-state via Plonky3 zkSNARK
• Validator public key root inclusion in proofs
• Merkle paths for receipts and logs
• Cached anchor headers and nonces for replay resistance

Even without running a full EVM, Qubes can verify:

• Sender balance
• Contract bytecode hash
• Gas used and logs
• State transitions

7.5. Performance Profile

7.6. Optional Features

These are optional enhancements for Qube functionality:

• Push-based zkProof delivery (via FCM / APNs)
• Encrypted gossip between Qubes (libp2p / noise)
• Partial prover fallback (if cloud is unavailable)
• Geographic proof clustering to reduce latency

8.1. Role of Qubes in Consensus

Qubes (mobile nodes) perform:

• Block proposal voting
• zkProof verification
• Staking and slashing enforcement
• Fetching and validating proofs via zkURL

Qubes do not need to generate zkProofs — instead, they verify them using efficient WASM circuits.

8.2. Consensus Overview

Cubiq consensus follows a 2-stage approach:

This design removes the need for heavy EVM execution on chain, relying instead on verifiable execution.

8.3. Voting and Finality

• Voting Rounds: Every N seconds (e.g., 12s), a block proposal enters voting phase.
• Supermajority Threshold: ≥66% staked Qubes must verify and vote for finalization.
• Finality Gadget: Inspired by Tendermint's BFT round voting with fast-finality.

graph TD
    A[Block Proposal + zkProof] --> B[Qubes verify]
    B --> C[Qubes vote on-chain]
    C -->|≥66%| D[Block Finalized]
    C -->|<66%| E[Timeout or Re-propose]

8.4. Staking Mechanics

8.5. Slashing Logic

Qubes can be slashed if they:

• Sign an invalid proof
• Fail to vote repeatedly
• Attempt double-voting or equivocation

Slashing is enforced on-chain, with cryptographic evidence (e.g., signed votes).

8.6. Prover Selection

• Any Prover may generate a zkProof
• Only first valid proof accepted
• Priority optionally given to Provers with bonded stake or reputation
• In future, proof auctions may allow economic prioritization

8.7. Epoch System

• Epoch length: 10 minutes (configurable)
• At each epoch:
  • Rewards distributed
  • Slashing enforced
  • Validator set updated

8.8. Security Properties

9.1. Token Specification

9.2. Token Roles in the Ecosystem

• 🛠 Utility
  • Pay gas fees on transactions and smart contract execution
  • Stake to become a validator or Qube delegate
  • Pay for ZK services: proof generation, zkURL fetch credits
  • Access network resources: storage, bandwidth
• 💰 Incentives
  • Earn staking rewards for delegating to honest Qubes
  • Block proposer rewards for validators
  • Mobile verifier rewards for verifying proofs locally
  • Developer grants for zk-native applications

9.3. Monetary Policy

9.4. Distribution Breakdown (Illustrative)

All allocations are proposal-bound and may evolve post-launch.

9.5. Gas and Fee Design

Cubiq uses a dual-tier fee system:

• Base Fee (Burned): Similar to EIP-1559, this regulates congestion and deflates supply.
• Priority Fee (Tips): Given to Qube proposers to incentivize fast inclusion.

Mobile Qubes only verify; they do not produce blocks directly but participate in weighted voting, and earn a portion of the proposer’s reward via delegation share.

9.6. Qube Mining via Participation

Instead of PoW mining, Cubiq introduces "Proof of Participation" mining, where:

Mobile Qubes are rewarded for:

• Being online and verifying zkURL proofs
• Voting on blocks and consensus proposals

Rewards are distributed based on:

• Verified proof count
• Delegation stake
• Device uptime and performance

9.7. zk-Incentive Balancing

To ensure healthy network economics, we introduce zk-Weighted Rewards:

• ZK Cost Credit Pool is algorithmically adjusted
• Proofs that are reused via zkURL are subsidized
• Cloud provers are paid per-verified-proof, not just per-generation

This balances incentives between:

• Provers
• Qube validators
• Lightweight mobile devices
• Developers (who generate ZK circuits)

9.8. Economic Security Model

Cubiq relies on delegated PoS slashing for economic alignment:

Qubes or Provers can be slashed for:

• Serving invalid zk proofs
• Participating in consensus fraud

• Stakeholders must bond Qube tokens to participate
• Validators are elected based on delegated stake + historical honesty

9.9. Governance via Qube DAO

• Each 1 QUB = 1 vote in governance proposals
• Proposals include:
  • Emission rate changes
  • ZK verifier upgrades
  • Network fee schedule
  • Treasury allocation decisions

Governance is implemented via zkSNARK-voting + snapshot in Phase 2.

🧪 10.1. Phase 0: Bootstrapping & Testnets (Q3 2025)

Objective: Deploy core infrastructure, finalize mobile node behavior, test zkURL mechanics

Deliverables:

• ✅ Launch of Cubiq DevNet (testnet with mocked ZK proofs)
• ✅ zkURL Protocol Draft finalized and audited
• ✅ Mobile Qube Client MVP for Android
• ✅ Cloud Prover running Plonky3 prover in TypeScript/WebAssembly mode
• ✅ zkRelay gateway that delivers proofs via https://zk.cubiq.io/proof/{block_hash} endpoint
• ✅ Initial implementation of staking + rewards (mock token)

🔁 10.2. Phase 1: Mainnet Launch (Q4 2025)

Objective: Go live with minimal viable mainnet and cloud prover federation

Deliverables:

• ✅ Cubiq Mainnet Genesis with Qube native token
• ✅ zkEVM runtime with Polygon Zero stack
• ✅ Qubes verify blocks using zkURL + light client
• ✅ Cloud Prover Federation for block generation
• ✅ Full Proof-of-Participation consensus
• ✅ Web3.js and Ethers.js compatible RPC gateway
• ✅ Explorer integration and public zkProof viewer
• ✅ Mobile wallet with zkURL subscription

📱 10.3. Phase 2: zkDAO & Decentralized Governance (Q1 2026)

Objective: Shift to community-controlled upgrades and emissions

Deliverables:

• ✅ zkDAO contract deployed on Cubiq with native voting
• ✅ Snapshot-based governance portal using ZK identity proofs
• ✅ On-chain proposal system for upgrading runtime, slashing, treasury
• ✅ zk-SNARK voting logic (off-chain proof, on-chain verification)
• ✅ DAO-native dev fund allocation and bounty system
• ✅ Developer incentives for building zk-native DApps

🔗 10.4. Phase 3: Interoperability Layer (Q2 2026)

Objective: Enable Cubiq to bridge and verify proofs from other ecosystems

Deliverables:

• ✅ zkBridge module with Ethereum and Polygon proof ingestion
• ✅ zkURL Subnet Integration (e.g., Qube could verify other chains’ blocks)
• ✅ Cubiq ↔ Ethereum light client proof sync
• ✅ zkIBC (inter-blockchain consensus) experimentation
• ✅ MetaProofs: Proof-of-proof architecture
• ✅ zkAggregator to batch cross-chain data

🛠️ 10.5. Phase 4: Decentralized Provers & In-Browser ZK (Q3 2026)

Objective: Democratize proof generation and storage

Deliverables:

• ✅ Browser-based Plonky3 verifier & prover via WASM
• ✅ Open Prover Marketplace — anyone can bid to generate proofs
• ✅ zkProof caching on IPFS/Filecoin or zkURL-CDN
• ✅ Support for mobile provers (experimental Qube Prover mode)
• ✅ EIP-4844 (blob) integration for ZK rollup data availability
• ✅ zkProof attestation for third-party apps

♻️ 10.6. Phase 5: Scalability & Rollup-as-a-Service (Q4 2026)

Objective: Turn Cubiq into a zk-native Layer 2 as a service

Deliverables:

• ✅ Launch of "MiniQubes": Custom app-specific zkRollups using Cubiq's stack
• ✅ zkRollup SDK for developers
• ✅ zkNFTs, zkPayments, zkSocial primitives
• ✅ zkFi: Native DeFi apps that don’t require full nodes
• ✅ Decentralized storage hooks for mobile Qubes

🚀 10.7. Long-Term Vision

Cubiq will become the first zk-native blockchain where everyday devices participate securely, verifiably, and with economic incentives. The mobile-first zkURL protocol and lightweight Qube architecture will enable:

• A truly global, low-cost validator network
• Massive DApp adoption with minimal barrier to entry
• Robust privacy, composability, and cross-chain compatibility

🧩 11.1. Comparative Summary Table

🔍 11.2. Key Differentiators

• ✅ Mobile-first Design
  • Cubiq is the only chain enabling mobile devices (Qubes) to act as first-class citizens in consensus and verification.
  • Proofs are small and easily fetched from the cloud using the zkurl:// protocol.
• 🧪 Modular Proof Offloading
  • Cloud-based Plonky3 Prover can be upgraded independently.
  • No dependency on single sequencers or centralized actors.
• 🧠 zkURL Architecture
  • Abstracts proof distribution away from chain logic.
  • Enables trustless proof fetching over DNS-like endpoints (e.g., zkurl://mainnet.cubiq/872541).
• 🔄 Interoperability
  • Native zkEVM compatibility with Solidity, Hardhat, Foundry.
  • Designed for bridges, multi-chain messaging, and decentralized applications that span rollups.
• 🏗️ Decentralized Infrastructure
  • Optional use of IPFS or Cubiq CDN for proof caching.
  • Qubes participate in staking, governance, and data availability.
• 🚫 What Cubiq Does Not Do
  • No on-chain proof generation on mobile — computation stays offloaded.
  • No dependency on centralized sequencer — blocks can be proposed by Qubes.
  • No proprietary language barrier — standard Solidity and zkURL.

🔧 12.1. Sprint 1–2: Core Setup & Infra (Weeks 1–2)

• ✅ Set up dev repos, CI/CD, and devnet bootstrapping.
• 🔹 Fork Polygon Zero stack and strip unnecessary layers.
• 🔹 Scaffold CubiqChain primitives.
• 🔹 Prepare cloud prover environment (Plonky3 sandbox).
• 🔹 Write initial specs for zkURL resolver.

Deliverable: Running minimal chain in devnet with stubbed prover.

🧠 12.2. Sprint 3–4: zkURL Protocol & Proof Handling (Weeks 3–4)

• 🔹 Implement zkurl:// resolver in Rust (NodeJS proxy for testing).
• 🔹 Define zkURL DNS format: zkurl://mainnet.cubiq/slot/blockhash.
• 🔹 Design Qube-side proof fetcher/verifier (native or JS via WebView).
• 🔹 Start cloud proof upload tool.

Deliverable: zkURL proof retrieval working on desktop + mobile.

📱 12.3. Sprint 5–6: Qube Light Client (Weeks 5–6)

• 🔹 Build mobile verifier prototype (React Native + Rust WASM).
• 🔹 Integrate with zkURL fetcher.
• 🔹 Benchmark proof verification time & memory.
• 🔹 Start QubeKit SDK for dev onboarding.

Deliverable: Mobile Qube node verifying zkURL proof.

🧪 12.4. Sprint 7–8: Proof Generation & State Validation (Weeks 7–8)

• 🔹 Integrate Plonky3 cloud prover with Cubiq block state.
• 🔹 Finalize block -> proof mapping logic.
• 🔹 Add light verification logic to Qubes.
• 🔹 Test invalid/fake proof rejection.

Deliverable: Proof-verified block sync between cloud & Qube.

🧭 12.5. Sprint 9–10: Consensus & Tokenomics Integration (Weeks 9–10)

• 🔹 Implement DPoS consensus with Qube voting.
• 🔹 Stake + Unstake flow using Qube token.
• 🔹 Add slashing logic for provably invalid votes.
• 🔹 Integrate basic token transfer, balances.

Deliverable: Token-backed consensus with slashing.

🧑‍🔬 12.6. Sprint 11–12: Ecosystem Tools & Explorer (Weeks 11–12)

• 🔹 Launch Cubiq faucet, devnet block explorer.
• 🔹 Deploy GraphQL indexer for Qube states.
• 🔹 Package QubeKit SDK: account mgmt, zkURL fetcher, proof checker.
• 🔹 Integrate Remix / Foundry toolchain.

Deliverable: Dev tooling and web explorer for Cubiq testnet.

🛰️ 12.7. Sprint 13–14: Devnet Launch & Validator Onboarding (Weeks 13–14)

• 🔹 Open devnet to external testers.
• 🔹 Distribute initial Qube tokens to validators.
• 🔹 Launch zkURL gateway CDN.
• 🔹 Publish testnet roadmap, docs, GitBook.

Deliverable: Live Devnet with external Qubes and validators.

🧠 13.1. Governance via QUBE Token

• Proposal System: Any QUBE holder can propose protocol upgrades, parameter changes (e.g., staking ratio, reward curve), or feature integrations via governance contracts.
• Voting: Token-weighted voting is used. Qubes (mobile validators) can delegate voting rights to trusted representatives or DAOs.
• Enactment Delay: Approved proposals are subject to a time-lock mechanism to allow for auditing and rollback if malicious.

💠 13.2. QUBE: Staking & Roles

Exact stake thresholds are defined by the community and parameterized via governance.

📲 13.3. Qubes — Block Proposers and Verifiers (on mobile)

Qubes, running on mobile devices, are lightweight yet critical participants in consensus:

Proposal Flow:

• Qubes monitor the mempool and aggregate valid transactions.
• They construct a tentative block body and submit it to the Cloud Prover or any community-run prover.
• Once the zero-knowledge proof is returned via zkURL, they attach it to the block header and broadcast the block.

Verification Flow:

• All other Qubes fetch the zkURL and verify the proof locally.
• A consensus vote (DPoS-based) is initiated.
• Once 2/3+ of selected validators vote to finalize, the block is added to the canonical chain.

Key Properties:

• No full blockchain sync needed.
• Proofs are verified in under 500ms on modern mobile hardware.
• All critical consensus checks are zero-knowledge validated.

☁️ 13.4. Decentralized Prover Network

Cubiq’s prover infrastructure is permissionless and incentivized.

Anyone can run a Prover node by:

• Setting up Plonky3 and Cubiq circuits.
• Connecting to the Cubiq Prover Registry smart contract.
• Offering proof services on-demand via zkurl endpoints.

Proof Job Lifecycle:

• A Qube submits a block to the Prover Registry.
• Available provers bid or accept jobs based on latency and stake.
• Once a proof is submitted, the contract verifies and releases the reward in QUBE.

Anti-Centralization:

• The protocol favors geo-distributed and low-latency provers by rewarding performance.
• Provers can be slashed for submitting invalid proofs or exceeding timeout windows.

Optional zk-Rollup Provers:

• Provers may opt into bundling multiple Qube blocks for aggregated proving (micro-rollups), optimizing cost.

📈 13.5. Staking Rewards

Dynamic Inflation Model:

• Total QUBE supply increases at a controlled, decaying inflation curve.
• Block rewards are distributed among:
  • Proposing Qube
  • Participating Qubes (verifiers)
  • Prover Engine operator
  • Delegators (optional)

Slashing Conditions:

• Submitting an invalid block or fake proof
• Double-signing proposals
• Failing to respond within deadline

All penalties are enforced via smart contracts using on-chain dispute resolution with hash commitments.

14.1. Ubiquitous Mobile Participation

• Mobile devices (Qubes) will form the majority of active network participants.
• With increasing smartphone penetration and local proof validation, Cubiq will unlock mass adoption in regions previously excluded from traditional Web3 participation due to hardware or bandwidth limitations.

14.2. Marketplace for Proof Generation

The Prover Network will evolve into a permissionless marketplace:

• Anyone with sufficient compute can run a cloud prover node, register via a smart contract, and earn Qube tokens for generating timely and valid zkProofs.
• This introduces competitive proving, driving down latency and creating an economy around validity proofs.

14.3. Modular Execution Layers

• Cubiq will remain execution-layer agnostic:
• • Future releases may support zkEVM, zkVM, or even Move-based virtual machines using proof adaptors.
  • This modularity allows developers to build cross-chain zk bridges or deploy application-specific rollups (appQubes) using the Cubiq stack.

14.4. zkURL as an Open Standard

• zkURL will be standardized and adopted beyond Cubiq:
• • Chains like Celestia, zkSync, and Polygon CDK may leverage zkURL endpoints for decentralized light client verification.
  • A zkURL resolver registry and DNS-like naming scheme will enable trusted, auditable access to proof snapshots.

14.5. Decentralized Governance

Through progressive decentralization:

• Qube holders will gain voting rights on upgrades, prover reward curves, and protocol parameters.
• The governance DAO will fund ecosystem grants, community bounties, and core R&D.

14.6. AI + zk Synergy

Cubiq will explore integrations with AI-generated zero-knowledge circuits, enabling:

• zkML inference proofs verified on Qubes
• Generative AI on-chain outputs with verifiable computation proofs
• This may unlock AI-powered rollups with integrity guarantees.

14.7. Global zkProof CDN

• A geo-aware zkProof content delivery network (CDN) will serve light clients across the globe.
• • Edge nodes validate and cache recent proofs
  • zkURL clients receive the nearest verified copy
  • Prover reputations are tracked on-chain for availability

With these long-term ambitions, Cubiq aims to become the backbone of verifiable, lightweight, and interoperable Web3 infrastructure — bringing zk-powered trust to billions of users, starting with the smartphone in your hand.