band-protocol-primary-sources-2026-05-12

Band Protocol primary sources

Collected: 2026-05-12 UTC

Primary sources reviewed

• https://bandprotocol.com/
  • Official homepage
  • Used to anchor current project identity and product framing
• https://docs.bandchain.org/
  • Official documentation portal
  • Used to confirm the current framing of Band as a cross-chain data platform and the live docs surface for BandChain
• https://github.com/bandprotocol/whitepaper
  • Official whitepaper repository
  • Used to confirm the current Band V3 whitepaper is maintained as a living protocol document
• https://raw.githubusercontent.com/bandprotocol/whitepaper/master/doc.md
  • Whitepaper source
  • Used as the main mechanism source for the Signaling Hub, validator price submission, weighted-median aggregation, and data-tunnel architecture
• https://bandprotocol.github.io/whitepaper/doc.pdf
  • Published whitepaper artifact
  • Used to confirm the live rendered whitepaper endpoint
• https://github.com/bandprotocol/bandchain
  • Official BandChain repository
  • Used to anchor BandChain as the reference implementation and inspect the surrounding module layout
• https://raw.githubusercontent.com/bandprotocol/bandchain/master/README.md
  • BandChain repo README
  • Used to confirm BandChain’s self-description as a decentralized data delivery network and to inspect the module split around chain, bridges, helpers, OBI, and oracle-script tooling
• https://github.com/bandprotocol/registry
  • Official registry repository
  • Used to preserve the signal-registry workflow as an explicit protocol layer even when the most detailed mechanics were described in the whitepaper
• https://github.com/bandprotocol/bothan
  • Official reference implementation for validator-side price sourcing
  • Used to keep source acquisition visible as a separate lower layer rather than collapsing it into BandChain itself

Key takeaways from primary sources

• Band is most useful when modeled as an oracle-specific chain, not just as a feed brand. The whitepaper makes block timing, update scheduling, signal support, and delivery routing all part of the protocol surface.
• The Signaling Hub is the standout mechanism. BAND delegators allocate demand by voting for signals, and that stake-weighted demand determines feed eligibility and frequency rather than leaving market creation entirely to a foundation or an operator cartel.
• The whitepaper’s language around signals is broader than a simple price-feed framing. Signals can represent any priced asset or data series the community wants validators to maintain.
• Signal expansion depends on a public registry workflow, which is important because it makes the source-definition and signal-admission layer visible rather than hiding it behind validator black boxes.
• Validator source trust is managed more through disclosure, delegation choice, and weighted-median robustness than through direct slashing for inaccurate prices. That is a meaningful design difference from oracle systems centered on punitive reporting games.
• Data tunnels add a separate delivery-control layer: a developer chooses the signals, interval, deviation thresholds, and funding posture for cross-chain publication instead of treating delivery as a generic default service.
• Band therefore helps separate three questions that many oracle discussions flatten together: who wants a market, who reports it, and who pays to carry it across chains.

Why this entry belongs in the corpus

• It strengthens the oracle cluster with a chain-native design that differs from both first-party source models and request/response oracle models.
• It adds a strong comparison point for signal-admission governance, feed-frequency voting, and fee-funded cross-chain delivery.
• It helps keep source-definition, validator disclosure, and delivery-route choice visible as separate control surfaces.