DFINITY Foundation

ICDevs.org

CryptoIsGood

Anvil

ICPL.app

ysyms

The Accumulators’ Neuron

RawTech Venture

Paul Young

ICPMANUAL

8YearGangDAO

Isaac Valadez

Krzysztof

Nicolas.ic

Smaug’s Neuron for Retail Investors

ICLight.io

Taggr Network

Sonic AMM

Rakeoff.io

OpenChat

ELNA AI

GEEKFACTORY

ICP Hub México

ICP Hub Poland

Jerry Banfield

WaterNeuron

ICP Hub Bulgaria

Gold DAO

NeuronPool

LORIMER ♾️ 🐶

B3Pay

ZenithCode

Aviate Labs

D-QUORUM

Yuku AI

CO.DELTA △

DragginCorp

Gwojda

Thyassa

🌮 TACO DAO Neuron

Ωmega-reject

Ωmega-vote

αlpha-vote

Cybersecurity

cyberowl

Dexter Caff/acc

JMVR

Smacker

HashEra

Adopt the direction of a native, headers-only Bitcoin SV (BSV) integration on the Internet Computer — a dedicated BSV subnet that validates proof-of-work and serves longest-chain block headers via new bsv_* management-canister APIs, enabling canisters to verify BSV transactions trustlessly through SPV (Bitcoin whitepaper §8), to be implemented via subsequent scoped NNS proposals.

Propose a text that can be adopted or rejected. No code is executed when a motion is adopted. An adopted motion should guide the future strategy of the Internet Computer ecosystem.

# Native Bitcoin SV (BSV) headers-only integration — a protocol-level, PoW-verified view of the longest chain for on-chain SPV

## 1. Objective

Have the Internet Computer integrate natively with the **Bitcoin SV (BSV)** network in a **headers-only** configuration: a dedicated **BSV subnet** runs a BSV network adapter that connects to the BSV peer-to-peer network, validates **proof-of-work on every block header**, follows the **greatest-cumulative-work valid chain**, and stores **only the 80-byte headers** in replicated state — no UTXO set, no transaction history, no block bodies. New `bsv_*` management-canister APIs expose this authoritative header chain so any canister can perform **Simplified Payment Verification (SPV)** as described in §8 of the Bitcoin whitepaper, trustlessly.

## 2. Background

ICP's existing Bitcoin integration keeps the full **UTXO set** in replicated state. That is viable for BTC because blocks are size-capped. BSV removed the block-size limit (Genesis, Feb 2020) and targets gigabyte-to-terabyte blocks (Teranode), so replicating a BSV UTXO set or block bodies on-chain is infeasible — the standard integration model does not transfer.

It does not have to. A block **header is 80 bytes regardless of block size**; the entire BSV header chain is \~70–80 MB today and grows \~4.2 MB/year. SPV was designed precisely for this: a verifier needs only the longest-chain headers plus a Merkle branch per transaction — never the transactions themselves. Proof-of-work is *inside the header* — double-SHA256 of the 80 bytes must be ≤ the difficulty target encoded in `bits`, and retargeting is checkable from the headers' own timestamps and bits — so the protocol can validate each block's work and follow the heaviest chain **using headers alone**. This is the same validation BTC nodes perform; BSV differs only in block size, which is exactly why bodies are kept out.

This proposal follows a [community discussion on the developer forum](https://forum.dfinity.org/t/native-bsv-integration-on-icp-headers-only-for-on-chain-spv/71048), where the key questions — how this differs from RPC/provider outcalls, whether PoW can be validated from headers alone, and the eclipse/censorship caveat — were raised and addressed.

**Footprint:**

|  |  |
| --- | --- |
| Header size | 80 bytes (size-invariant to block size) |
| Full header chain today | \~70–80 MB |
| Growth | \~4.2 MB/yr |
| UTXO set / tx history / block bodies stored | **None** |

Bounded and trivial — exactly what makes BSV integration possible on ICP where the UTXO-set model is not.

## 3. Why this is important

Today, any dapp can make HTTPS outcalls to external BSV API providers and cache headers in its own canister — that is the status quo, and it is what [**metanet.page**](http://metanet.page) does today. But provider outcalls only give *integrity against a single lying provider*; they remain **provider trust**, perform no independent proof-of-work validation, and route the ecosystem through external operators.

This proposal delivers the opposite: a **protocol-level, PoW-verified, P2P-connected** view of the BSV chain, agreed by ICP consensus and validated by ICP's own replicas — a shared primitive every canister can rely on without trusting any outside party. It turns "the longest BSV chain" from a claim a provider makes into a fact the protocol verifies, and combines BSV's unbounded data/transaction layer with ICP compute, storage, and threshold signing.

## 4. Pros

- **Trustless, not provider-trust:** ICP validators verify PoW directly off the P2P network; no external RPC/API dependency.
- **Feasible where UTXO integration is not:** headers-only keeps the footprint tiny (\~80 MB total, \~4.2 MB/yr), independent of BSV's block size.
- **Whitepaper-faithful SPV:** canisters verify transaction inclusion in the most-work chain and get a confirmation depth to enforce their own security policy.
- **Reuses proven tech:** a fork of the production IC Bitcoin adapter and the same subnet architecture already running in mainnet.
- **Broadly useful primitive:** payments/proof-of-payment, data anchoring/notarisation, cross-chain logic without a trusted bridge oracle, identity/attestation — a trustless drop-in for any dapp currently calling a BSV explorer API.
- **Committed first adopter:** [metanet.page](http://metanet.page) will build on it immediately.

## 5. Cons

- **New subnet + adapter to build, run, and maintain** (development, replica-version election, ongoing checkpoint maintenance, cycle pricing).
- **Headers-only is not a full node:** the protocol validates PoW and header linkage, not transactions — SPV's standard caveat applies (see §8).
- **Eclipse/withholding remains a residual risk** that must be mitigated by peer diversity, checkpoints, and confirmation-depth requirements (see §8).
- **Off-chain dependency for Merkle branches:** callers still source the Merkle proof for a given tx (miner/TSC proof service or own indexer); the subnet provides the authoritative headers, not the proofs.

## 6. Key milestones

Each step would be its own NNS proposal:

1. **This Motion** — ratify direction.
2. Implement the BSV headers-only adapter (fork of the IC Bitcoin adapter; `getheaders`/`headers` only, PoW validation, greatest-cumulative-work selection).
3. Replica-version (IC-OS) election including the adapter + `bsv_*` management-canister endpoints.
4. Provision/designate a dedicated BSV subnet; enable the feature with initial NNS-elected checkpoints.
5. Testnet → mainnet activation; finalize cycle pricing.
6. Ongoing checkpoint-maintenance proposals.

**Proposed management-canister API surface (**`bsv_*`**, mirroring** `bitcoin_*`**):**

```candid
type bsv_network  = variant { mainnet; testnet };
type block_height = nat32;
type block_hash   = blob;   // 32 bytes, internal byte order
type block_header = blob;   // raw 80 bytes

bsv_get_block_headers :
  (record { start_height : block_height; end_height : opt block_height; network : bsv_network })
  -> (record { tip_height : block_height; block_headers : vec block_header });

bsv_get_tip :
  (bsv_network)
  -> (record { height : block_height; header : block_header;
               block_hash : block_hash; cumulative_work : blob });

// optional protocol-side SPV helper
bsv_verify_spv :
  (record { network : bsv_network;
            proof : record { txid : blob; block_hash : block_hash;
                             branch : vec blob; position : nat32 };
            min_confirmations : block_height })
  -> (variant {
        ok  : record { confirmations : block_height };
        err : variant { unknown_block; not_on_longest_chain;
                        bad_merkle_root;
                        insufficient_confirmations : record { have : block_height } };
      });
```

The minimal surface is `bsv_get_block_headers` + `bsv_get_tip` (the canister does its own Merkle math). `bsv_verify_spv` is an optional convenience that recomputes the Merkle root from `txid` + `branch`, checks it against the stored header, confirms the header is on the longest chain, and returns confirmation depth (`tip − height + 1`). Calls are cycle-metered, consistent with the Bitcoin API.

**SPV flow for a dapp:**

1. Off-chain, obtain the BSV tx and its Merkle branch (a TSC/miner Merkle-proof service, or the dapp's own indexer).
2. The canister calls `bsv_verify_spv` (or fetches the header via `bsv_get_block_headers` and verifies the branch itself).
3. The protocol confirms the tx's Merkle root is committed in a header on the most-work chain and reports confirmation depth.
4. The canister applies its own confirmation policy (e.g. ≥6) and acts on the verified payment/anchor. No party is trusted to report chain state — the header set is agreed by ICP consensus.

## 7. Discussion leads

- [**metanet.page**](http://metanet.page) — proposer, committed first adopter, and lead for the forum discussion.
- DFINITY / IC-Bitcoin engineering — invited to assess feasibility of a headers-only fork of the existing Bitcoin adapter.

## 8. Security concerns

- **You cannot forge a heavier chain.** PoW-in-the-header means an attacker would have to out-mine the network; the protocol simply follows greatest cumulative work.
- **Eclipse/censorship is the one real residual risk.** An attacker controlling *all* of a node's peers could *withhold* the true tip and feed a stale-but-valid prefix; they cannot make less work look like more. Mitigations: many diverse peers across a whole subnet of independent replicas (eclipsing all of them ≫ eclipsing one node or trusting one RPC provider), NNS-elected checkpoints, and the API surfacing confirmation depth so callers require enough work to make withholding pointless. Net: this trades "trust a provider's word" for "trust PoW math + peer diversity" — strictly stronger than the RPC/outcall status quo, where censorship is just a provider lying.
- **Standard SPV caveat.** A valid Merkle branch + sufficient confirmations proves *inclusion in the most-work chain*, not the absence of shallower double-spends. The protocol validates PoW and header linkage only; it has no UTXO set and does not validate transactions. This is the caller's responsibility and will be documented prominently in the API.
- **Chain-split resistance.** BSV magic bytes, seeds, and the genesis + checkpoint anchor ensure the adapter cannot be steered onto BTC/BCH or a minority fork.

## 9. What is asked of the community

Review comments, ask questions, give feedback. \
\
Developer forum: <https://forum.dfinity.org/t/native-bsv-integration-on-icp-headers-only-for-on-chain-spv/71048>\
\
Vote accept or reject on the NNS Motion.

Native Bitcoin SV (BSV) headers-only integration — a protocol-level, PoW-verified view of the longest chain for on-chain SPV