Identity connects the two sides
A worker or Portal generates a libp2p keypair. The public peer ID derived from that key identifies the node on the peer-to-peer network. Registration or allocation transactions associate that peer ID with an onchain account and locked SQD. The private key stays with the node operator. It is used for peer identity and signed network messages; it is not stored in a smart contract.Contracts coordinate participation
The current Network contracts include separate responsibilities:WorkerRegistrationrecords worker peer IDs, bonds, registration epochs, and deregistration state.NetworkControllerstores parameters such as epoch length, worker bond amount, expected worker storage, target capacity, and reward limits.Stakingrecords SQD delegated to each worker and accounts for each delegator’s share of distributed rewards.- allocation contracts account for the query capacity associated with SQD locked by data consumers or Portal operators.
- reward contracts accept approved reward batches and make worker and delegator rewards claimable.
Offchain services carry the data
Chunks can be much larger than an onchain transaction and queries need low-latency streaming. The archive, scheduler, worker, and Portal services therefore operate offchain:- ingestion writes finalized chunks to persistent storage;
- the scheduler publishes a chunk-to-worker assignment;
- workers download their assigned chunks;
- Portal sends queries to workers over libp2p and returns the results over HTTP;
- collectors record heartbeats and logs used for operations and analysis.
Run a worker
Follow the worker setup and registration procedure.
Delegate SQD
Follow the current delegation and withdrawal procedure.
Run Portal
Choose a hosted or self-hosted Portal path.
Network contracts
Read the deployed addresses, contract responsibilities, and Solidity source.