Blocksense

• Name: Blocksense
• URL: https://blocksense.network/
• Category: oracle / programmable-feed infrastructure / oracle rollup
• Tags: ethereum-ecosystem
• Summary: Blocksense is a custom-feed oracle rollup. The whole point is to make feed creation less curated. It is not a clean escape from oracle politics: sequencers, reporter admission, runtime defaults, and adapter packaging still decide how open the system really is.
• What it does:
  • Lets builders write feed logic as WASM-compatible scripts and deploy custom feeds through the Blocksense SDK
  • Has reporters fetch external data, execute oracle logic, and submit signed reports for aggregation
  • Uses a sequencer layer to assemble batches, gather second-round approvals, and post updates to supported chains
  • Ships Chainlink-style adapter and feed-registry contracts so downstream apps can integrate Blocksense feeds through familiar read paths
  • Extends the pitch beyond price feeds into long-tail markets and verifiable compute, though the present note is mainly about the oracle stack
• Key claims:
  • The docs pitch permissionless feed creation and materially lower posting costs through batching and compression. The real question is whether that survives sequencer and runtime policy.
  • The architecture makes the control surface plain: reporters produce values, sequencers batch them, reporters approve the batch, then the sequencer posts. That is not the same thing as a neutral feed rail.
  • The adapter layer matters because adoption may ride on Chainlink-compatible interfaces as much as on Blocksense-native demand.
  • The current network launches with PoA-style operator selection. The more ambitious zk-SchellingCoin and futarchy story is future trust-model marketing until it exists in production.
  • Useful because it isolates one real design question: can long-tail feed creation be opened up without quietly re-centralizing around sequencers, default runtimes, and operator lists?
• Whitepaper: Blocksense publishes an official litepaper at https://blocksense.network/resources/litepaper, supplemented by official docs and the public monorepo; see ../whitepapers/blocksense-primary-sources-2026-05-10.md.
• Sources:
  • https://blocksense.network/
  • https://blocksense.network/resources/litepaper
  • https://docs.blocksense.network/docs
  • https://docs.blocksense.network/docs/architecture/overview
  • https://docs.blocksense.network/docs/data-feeds/creating-data-feeds
  • https://github.com/blocksense-network/blocksense
  • https://raw.githubusercontent.com/blocksense-network/blocksense/main/README.md
  • https://raw.githubusercontent.com/blocksense-network/blocksense/main/apps/sequencer/README.md
  • https://raw.githubusercontent.com/blocksense-network/blocksense/main/libs/sdk/README.md
  • https://raw.githubusercontent.com/blocksense-network/blocksense/main/libs/ts/contracts/README.md

Internal linkages

• Strongest upward reads: chainlink, pyth-network, and api3.
• Keep the question narrow: does Blocksense really open feed creation, or does the curation just move into sequencers, operator admission, and familiar adapter defaults?

Control surface

• Power sits in sequencer selection, reporter admission, runtime defaults, adapter packaging, and which integration paths become the practical default for downstream apps.

• The design is only interesting if long-tail feed creation stays open after those choke points harden. Until then it is a small oracle rollup, not a category center.

• Last reviewed: 2026-06-15 UTC