SQD sqd

Subsquid (now branded SQD) is an open blockchain-data infrastructure project and the SQD Network is its decentralized data layer. Official documentation describes SQD Network as a distributed query engine and data lake for 200+ blockchains, serving historical chain data through SQD Portal. Data is split into chunks, distributed across workers, and queried in parallel.

The project provides several developer-facing access paths: managed Portal HTTP endpoints, self-hosted Portal, Pipes SDK for TypeScript data pipelines, and Squid SDK for full indexers with database/GraphQL tooling. Portal exposes streaming queries with filtering and batch processing rather than requiring each application to run expensive archival RPC infrastructure.

SQD Network is permissionless: independent operators can run workers or delegate SQD to workers, while applications access data through Portal. The current site says the network spans 190+ networks and 2,000+ workers; docs describe supported families including EVM, Substrate, Solana, Fuel and Starknet.

SQD is also the ERC-20 protocol token of the network. It is used for worker incentives, delegation/curation, resource-rate allocation through locked tokens, and governance; current network materials additionally describe Portal Pools where locked SQD backs capacity and can receive USDT enterprise-fee distributions.

Blockchain applications need large-scale historical and near-real-time data, but direct RPC access is optimized for individual node calls rather than broad extraction. The official whitepaper identifies growing transaction/state data, decoded application data and off-chain data as difficult and expensive to query and aggregate at scale.

A centralized data lake or single API provider creates gatekeeping, vendor-dependence, censorship and correctness risks. SQD's stated design goals are horizontal scalability, permissionless access, credible neutrality, trust-minimized/verifiable queries and low query cost, while avoiding the need for every developer to maintain archival nodes.

Data providers ingest blockchain data, validate it, split it into compressed chunks and place it in persistent storage. A scheduler assigns chunks to worker nodes; workers download and store their assigned chunks and use a local query engine (DuckDB in the whitepaper) to execute requests. SQD Network's Rust implementation uses libp2p for peer-to-peer communication among workers, schedulers and Portals.

Portal is the client-facing access layer. It routes a request to workers holding relevant chunks, collects partial results, and exposes a streaming HTTP API. Documentation says Portal handles pagination, finality tracking and reorg compensation; the current public product combines archival network data with low-latency hotblocks for recent data.

Workers must register/bond SQD and can receive rewards based on liveness, data served, delegated stake and fairness. SQD holders may delegate to workers and share in rewards. Consumer Portals can lock SQD to obtain query capacity/rate limits; the whitepaper describes locked tokens as virtual compute units.

Responses can be signed by the executing worker and challenged/validated on-chain. The whitepaper outlines proof-by-authority, optimistic on-chain challenges and zero-knowledge validation as possible mechanisms; cryptographic checks and cross-checking are intended to detect incorrect data, with provable violations potentially slashing worker bonds.