SQD

SQD: The Token Behind Subsquid’s Decentralized Blockchain Data Network

SQD supports a data infrastructure network that stores, validates, and serves blockchain data to developers. Its role extends beyond payments: the token is used for worker bonds, delegation, query capacity, rewards, and protocol governance, while the system still depends on data providers, gateways, software, and operational coordination.

What Subsquid is building

SQD Network is designed as a distributed data lake and query engine for blockchain data. Rather than asking developers to maintain archival nodes or repeatedly query conventional RPC endpoints, the system stores compressed data chunks across worker nodes and makes them available through Portal, an HTTP interface intended for batch extraction and streaming. The current documentation presents the network as supporting more than 140 blockchain networks, while the public website and repository describe a broader product stack that includes Portal, indexing SDKs, managed hosting, and the decentralized Network itself.

The intended users are developers building indexers, analytics products, wallets, DeFi applications, compliance tools, and data pipelines. Portal can be used as a managed endpoint, self-hosted with a local infrastructure setup, or accessed through the Squid and Pipes TypeScript SDKs. This makes SQD closer to infrastructure for applications than to a consumer-facing blockchain with its own execution environment.

How the network handles data

The documented architecture separates several roles. Data providers ingest and publish datasets; a scheduler distributes data chunks; workers store and query their assigned portions; gateways receive requests from data consumers; and a rewards manager calculates claims. Portal gathers data from multiple workers and returns it through a streaming API. The current documentation also describes handling for pagination, finality, and reorganisation compensation, which are practical concerns for applications reading live blockchain data.

SQD’s validation model combines technical checks with economic penalties. The whitepaper describes worker-signed responses and a process through which suspicious responses can be submitted for on-chain validation. Depending on the dataset and implementation, the proposed validation approaches include authority-based checks, optimistic challenge mechanisms, or zero-knowledge proofs. These are design mechanisms rather than a guarantee that every query is individually verified on-chain; routine use still depends on the network’s software, data providers, gateways, and challenge procedures functioning as intended.

What SQD does inside the system

SQD is an ERC-20 protocol token used to coordinate network participation. Workers must bond tokens to register and can be penalised for provable protocol violations. Token holders can delegate SQD to workers, providing a curation signal and sharing in rewards. Data consumers can lock SQD to obtain query capacity or higher rate limits, while token holders are also described as participants in governance over protocol changes and other proposals.

This creates several distinct demand channels, but they should not be treated as interchangeable. A worker bond secures infrastructure participation; delegation expresses a preference for a worker; and gateway locking determines access capacity. The token therefore links security, resource allocation, and rewards, but the strength of those use cases depends on actual network traffic, worker economics, available datasets, and the rules implemented by the contracts and network software.

Rewards, supply, and incentives

The published token economics allocate 10% of total supply to worker rewards, alongside allocations for backers, the team, treasury activities, and liquidity. The documentation describes an initial rewards pool and a three-year bootstrapping period with a capped supply and reward schedule. It also states that future issuance and the inflation schedule may be determined through governance after that period. That design leaves the long-term monetary policy partly dependent on future decisions rather than fixing every issuance parameter permanently at launch.

Worker rewards are described as depending on factors including liveness, traffic served, stake, tenure, and network capacity. Delegators receive a portion of a worker’s reward allocation, while workers retain incentives linked to their bond and performance. These formulas are intended to discourage idle or unreliable infrastructure, but they also mean that returns depend on network utilisation and operational performance rather than on token ownership alone.

Governance and control points

SQD documentation assigns token holders a governance role, including voting on protocol changes and other proposals. The public repository identifies Solidity contracts for worker bonds, delegated staking, gateway registration, and on-chain rewards on Arbitrum. However, the available materials do not establish a complete, independently auditable description of voting thresholds, proposal execution, delegation rules, emergency powers, or the exact scope of token-holder control. Those details should be verified from the deployed contracts and any current governance documentation before treating SQD as broadly community-controlled.

There is also a meaningful distinction between the project’s current network overview and the older whitepaper. The overview presents a permissionless network in mainnet, while the whitepaper describes an earlier bootstrap phase in which Subsquid Labs acted as the sole data provider and retained certain operational responsibilities. The whitepaper itself says its material is a broad overview and not a commitment to deliver particular functionality. Readers should therefore treat decentralisation as an implementation state to monitor, not simply as a label.

Practical limitations and dependencies

SQD depends on more than the token contract. Reliable service requires accurate source data, functioning workers, schedulers, gateways, storage, query software, and contract infrastructure. The project’s open-source repositories reduce some vendor-lock-in concerns, but self-hosting still requires technical capacity and appropriate hardware. Managed Portal access introduces a separate dependency on the operator providing the endpoint, even when the underlying data network is permissionless.

The Arbitrum token page identifies the SQD contract as a verified ERC-20 and shows bridge-related functions, but it also reports that no contract security audit had been submitted on that explorer page. That is not proof that no audit exists anywhere, but it is a reason to distinguish source-code verification from a completed independent security review. Cross-chain deployments also create address, bridge, custody, and liquidity risks that users must check separately on each network.

Key takeaways

• SQD is primarily an infrastructure token for a blockchain-data network, not the native gas asset of a general-purpose execution chain.
• The token is used for worker bonds, delegation, query-capacity locking, rewards, and stated governance participation.
• The architecture combines distributed storage and query workers with Portal, SDKs, gateways, schedulers, and on-chain contracts.
• Reward outcomes depend on worker performance, network utilisation, stake, traffic, and the rules governing the rewards pool.
• The project’s current decentralisation claims should be evaluated against the older bootstrap assumptions described in the whitepaper.
• Official pages use different supported-network counts, so network coverage should be checked against the current documentation rather than treated as a fixed figure.

Risks and open questions

• Governance powers, voting thresholds, proposal execution, and emergency controls are not fully specified in the reviewed public materials.
• The network depends on accurate data providers and operational components, including workers, schedulers, gateways, storage, and Portal software.
• The long-term issuance policy may change through governance after the initial rewards period.
• Worker and delegator economics depend on actual query demand, traffic distribution, liveness, stake concentration, and reward parameters.
• Cross-chain token use introduces contract-address, bridge, custody, liquidity, and network-specific operational risks.
• The reviewed Arbitrum explorer page verifies the token source code but reports no submitted contract security audit on that page.