# BlockSource A source of Bitcoin blockchain data for driving a [`ChainstateManager`](/documentation/BitcoinKernel/ChainstateManager). ``` protocol BlockSource : Sendable ``` ## Overview Hash-addressed per LDK’s [`lightning-block-sync`](https://docs.rs/lightning-block-sync/latest/lightning_block_sync/) convention and Bitcoin Core’s own internal `interfaces::Chain` API: every block lookup uses the block’s 32-byte hash, not its height. Height lookup ([`blockHash(atHeight:)`](/documentation/BitcoinKernel/BlockSource/blockHash(atHeight:))) is reserved for the one place the sync engine genuinely needs it — computing the fork point when resuming a partially synced chainstate — because height is a reorg hazard everywhere else. Conformers deliver blocks via whatever transport they like: HTTP ([`EsploraBlockSource`](/documentation/BitcoinKernel/EsploraBlockSource)), a bundled test fixture (in-memory mocks), or — in a future phase — a direct Bitcoin P2P peer over `swift-event`. The [`BlockchainSync`](/documentation/BitcoinKernel/BlockchainSync) engine treats all conformers identically. ### Hash orientation All `Data` hashes crossing this protocol are in **internal (kernel) byte order** — matching [`hash`](/documentation/BitcoinKernel/BlockHeader/hash) and [`hash`](/documentation/BitcoinKernel/Block/hash) throughout [`BitcoinKernel`](/documentation/BitcoinKernel). Implementations speaking to external services that use display-order hex (Esplora, most block explorer APIs) are responsible for reversing bytes at the HTTP boundary. ### Threading Conformers are `Sendable` so they can be shared across tasks and actors. Individual methods are `async` and may suspend on network I/O; conformers should not hold locks across suspension points.