blocksense-primary-sources-2026-05-10

Blocksense primary-source snapshot

Fetched: 2026-05-10 UTC

1) Official homepage

Source: https://blocksense.network/

Selected excerpts from the official site:

Blocksense is a zkRollup-based oracle network for verifiable data and compute.

Oracle reporters fetch off-chain data, reach consensus via hidden SchellingCoin voting, and publish ZK-verified results with minimal on-chain cost.

Blocksense offers programmable feeds, SDK-based deployment (with full self-serve coming soon), and ZK-powered batching that reduces on-chain publishing costs by up to an order of magnitude.

Additional signals from the source:

• The homepage is explicit that Blocksense wants to be categorized as more than a price-feed service; it is selling a verification layer for data and compute.
• The phrase “without gatekeeping or centralized curation” is a key categorization clue because Blocksense is framing feed creation itself as the thing to decentralize.
• The homepage also exposes a tension worth tracking: it advertises permissionless programmability, but the roadmap language still points to staged rollout and future self-serve rather than fully mature permissionless deployment today.

2) Official litepaper

Source: https://blocksense.network/resources/litepaper

Selected excerpts from the litepaper:

Blocksense introduces a novel, service-oriented blockchain architecture designed to systematically dismantle these barriers.

We present a universal verification layer capable of securely processing both objective and intersubjective truths at a scale previously thought unattainable.

The Intersubjective Truth Machine: We solve the oracle problem with zkSchellingCoin, a bribery-resistant consensus mechanism that uses zero-knowledge proofs (ZKPs) to ensure voter secrecy.

For high-stakes disputes, we employ Futarchy as an ultimate arbiter…

The Boundless Throughput Engine: We implement a Decoupled State Machine Replication (DSMR) architecture…

Additional signals from the source:

• The litepaper materially expands the project scope from “oracle network” to a universal verification layer for subjective and objective claims.
• zkSchellingCoin plus futarchy is the most distinctive mechanism claim in the paper; it is much more ambitious than the narrower current docs surface.
• The litepaper matters because it reveals the intended security model and economic imagination even if the shipping product is still earlier-stage and more operationally centralized.

3) Docs introduction

Source: https://docs.blocksense.network/docs

Selected excerpts from the docs:

Blocksense is the rollup for verifiable data and compute…

builders can permissionlessly deploy oracle scripts on the network, which is secured by a Schelling Coin-based consensus protocol.

The initial offering focuses on creating and reading price feeds to serve the needs of the growing DeFi ecosystem, and is available on EVM chains.

We are already releasing our SDK for permissionless data feed creation on a Proof of Authority (PoA) network, secured by a hand-picked set of reputable node operators.

In phase two … consensus on the Blocksense network will be achieved through the SchellingCoin game … enabled for the first time through ZK proofs, which facilitate the vote secrecy vital to ensuring collusion and bribery resistance in the network.

Additional signals from the source:

• This page is the clearest current statement of the gap between present and target architecture: current PoA operation versus future zk-SchellingCoin consensus.
• The docs position oracle-script deployment, not just oracle consumption, as the user-facing product.
• The migration strategy matters: the docs say interfaces are designed to be drop-in compatible with major incumbent oracle providers.

4) Architecture overview

Source: https://docs.blocksense.network/docs/architecture/overview

Selected excerpts from the docs:

Reporters: Nodes in the Blocksense network fetch, process, and report data from these sources.

Sequencer: Aggregates reports from multiple reporters and produces a batch of values to be posted to the contracts in multiple supported networks based on a quorum of reports.

Reporters: Validate and potentially approve the batch to be posted to supported networks by participating in signature share (second round of consensus).

New data feeds can be written easily using the Blocksense SDK. Oracle scripts can be bootstrapped with initial funds and become self-sufficient through on-chain data access fees.

Additional signals from the source:

• This is the best high-level source for the current operational control plane.
• The two-round structure is important: reporter values are first collected, then reporters approve the aggregated batch before publication.
• “Self-sufficient through on-chain data access fees” suggests a feed-level economic model worth tracking alongside the protocol-level token/security model.

5) Creating data feeds / SDK surface

Source: https://docs.blocksense.network/docs/data-feeds/creating-data-feeds

Selected excerpts from the docs:

The oracle macro’s main purpose is to wrap everything related to WASM and WIT…

Currently we support request/response oracle scripts…

Settings provide you with … an array of data feed IDs … and an array of capabilities…

Payload is the Oracle result which is an array of data feed results.

Additional signals from the source:

• The SDK page shows that “programmable oracle” is literal product surface, not just branding.
• The use of WebAssembly/WIT and HTTP-capable scripts suggests Blocksense is building a standardized runtime for fetching and transforming external data.
• This page is especially useful when comparing Blocksense with older oracle systems where feed creation depends on vendor-operated pipelines rather than user-authored scripts.

6) Monorepo README

Source: https://raw.githubusercontent.com/blocksense-network/blocksense/main/README.md

Selected excerpts from the README:

Blocksense is a permissionless oracle network that enables builders to bring real-world data on-chain with maximum flexibility and efficiency.

Our WebAssembly-based SDK enables the seamless creation of blockchain oracles that can leverage arbitrary internet sources and complex CPU and GPU computations.

SchellingCoin-based consensus & ZK-proof-secured reporting.

Additional signals from the source:

• The monorepo corroborates the same positioning seen in the official site and docs.
• The README broadens the compute story by explicitly mentioning CPU and GPU computations, which matters for the “oracle versus verification-compute layer” categorization.
• Public repos for the sequencer, SDK, and contracts make this a protocol/tooling surface rather than a closed oracle API.

7) Sequencer README

Source: https://raw.githubusercontent.com/blocksense-network/blocksense/main/apps/sequencer/README.md

Selected signals from the README:

• The sequencer is a distinct operational component with its own config file, runtime, HTTP endpoints, and contract-deployment/testing flow.
• The README shows the sequencer currently has meaningful operational responsibility for publishing feed updates to destination contracts.
• That makes sequencer design a primary control surface to watch in future reviews, especially if Blocksense continues to market itself as permissionless feed infrastructure.

8) Contracts README / compatibility layer

Source: https://raw.githubusercontent.com/blocksense-network/blocksense/main/libs/ts/contracts/README.md

Selected excerpts from the README:

The cl-adapters folder contains the Chainlink aggregator contract - CLAggregatorAdapter.sol.

The registries folder contains the CLFeedRegistryAdapter contract which is used to register new data feeds.

The AggregatedDataFeedStore.sol contract (ADFS) is where data is stored and read from.

Additional signals from the source:

• Blocksense is intentionally building Chainlink-compatible ingestion surfaces, not asking integrators to learn an entirely new oracle-consumer pattern.
• The OnlySequencerGuard and access-control surfaces are analytically important because they show who gets to write to the store in the current design.
• The adapter layer is one of the most interesting comparison points for future oracle-cluster work: compatibility may be as strategically important as consensus design.

Notes

• Blocksense is worth cataloging because it makes “permissionless oracle creation” the product, not just “oracle consumption.”
• The most important comparison axis is not generic oracle accuracy; it is how feed creation, batching, interface compatibility, reporter selection, sequencer control, and future private-voting consensus interact.
• The biggest caveat from current primary sources is that the network still appears staged: today’s operator and sequencing surfaces are much more concrete than the future universal-verification-layer vision.