Open reference implementation · Apache-2.0

Verifiable data custody and relay settlement on BSV

A layer for moving data across intermittent, multi-hop links you do not control, and proving, later and offline, that it arrived intact, in order, through a known chain of custody, and was paid for. Built on delay-tolerant networking, settled on BSV.

See it run

A real run, start to finish, in about a minute

Nothing staged: the acceptance suite, the full pipeline, a real Linux netem blackout, real Bundle Protocol v7 custody across a contact gap, and delivery bound to a real on-chain settlement. It closes by reading the anchor transaction live from the chain.

  1. npm test 27 passing, offline, deterministic
  2. npm run demo the whole pipeline over the simulator
  3. make spike real tc netem links, a 3s 100%-loss blackout, all 19 chunks survive
  4. make r2 real BPv7 (µD3TN), bundles held in storage across a contact gap
  5. make live delivery bound to a real BSV settlement, root anchored on chain

The problem

Trust what comes out of a link no one is watching

Between a sensor and a server, data often crosses relays, store-and-forward hops, and links that go dark. You still need to trust what comes out the other end.

Verify without a round-trip

Content-addressed, signed data is checked locally, later, with nobody on the other end. No callback to the source.

Custody across relays

Each hop leaves a signed, content-addressed receipt, forming a verifiable chain across parties you do not operate.

Paid and provenanced

Delivery is bound to a real on-chain BSV settlement, and the data's root is anchored on chain for tamper-evident provenance.

How it works

Standard BPv7 for transport, custody and payment on top

Bundle Protocol v7 (µD3TN) carries the bundles. DTN standardizes how bundles move, but not who paid or how you prove custody later, and that is the gap this layer fills. The custody, verification, and payment work sits on top as an application-layer agent, using the same content-addressed receipt route as the BSVKey x402 client.

chunk + Merkle BPv7 custody hops gap across blackout out-of-order verify settle + anchor sourcedestination

Rail- and medium-agnostic

The same content-addressing route as @bsvkey/x402-bsv-client. It works over any link and any settlement rail; the reference uses BSV.

Not the physical layer

By design it does not touch RF, optical, coding, or FEC. It is the trust and settlement layer over whatever carries the bits.

Proven on real infrastructure

Not a diagram, it runs

The reference implementation runs end to end against real systems, one command each.

LayerWhat runs
make spikeReal Linux tc netem links with a real 100%-loss link blackout; the payload survives and reassembles.
make r2Real Bundle Protocol v7 (µD3TN), bundles held in µD3TN storage across a scheduled contact gap, genuine DTN bundle custody.
make liveDelivery bound to a real on-chain BSV settlement, and the manifest root anchored on chain in an OP_RETURN.

On-chain settlement

5,942 sats to the seller, confirmed.

77030c61…ec83c6

Provenance anchor

Manifest root committed in an OP_RETURN, confirmed.

d49777e4…89e8ca

The boundary

What it proves, and what it does not

Authentic evidence can still be insufficient for the claim asked of it. The boundary is stated per field.

EvidenceProvesDoes not prove
content addressthe record is intact and addressed by its contentthat the numbers describe a real event
signature recoverythe signer authored these exact bytesthat the payload is correct
Merkle branchthis chunk belongs at this position under the rootthat the whole payload is complete on its own
custody chainthe record passed this ordered set of hopswhat happened between the observed hops
settlement on chainmoney moved from that payer to that payeethat it was your payment, until you bind it

Where it is useful

Any intermittent, multi-hop, untrusted-relay link

Delay-tolerant networking was designed for exactly these regimes, including deep space, where the same constraints appear in the extreme.

Subsea sensors and an AUV relaying to a surface buoy and satellite

Ocean

  • Subsea sensors and AUVs over acoustic links
  • Offshore energy telemetry provenance
  • Maritime cargo and cold-chain custody
A drone relaying through a satellite and ground station across contact windows

Sky

  • BVLOS and swarm drone relay + delivery proof
  • Stratospheric / HAPS relay networks
  • Aviation data provenance across custodians
A store-and-forward mesh of relay nodes across remote terrain

Earth

  • Disaster and remote store-and-forward mesh
  • Evidence and audit chain-of-custody
  • Environmental MRV and content provenance

Quickstart

Clone it and run the proofs

Node 18+. The core is dependency-free; Docker is only needed for the real BPv7 and netem runs.

# clone
git clone https://github.com/BSVKey/dtn-custody-demo
cd dtn-custody-demo

npm test          # acceptance criteria, offline, deterministic
npm run demo      # the full pipeline over the in-process simulator

make spike        # real veths + tc netem + a real link blackout   (Docker)
make r2           # custody chain over real µD3TN BPv7              (Docker)
make live         # delivery bound to a real on-chain BSV settlement

FAQ

Questions, answered plainly

What this is, what it proves, and where the honest edges are.

What is this, in one sentence?
A layer that lets you move data across intermittent, multi-hop links you do not control, and prove later, offline, that it arrived intact, in the right order, through a known chain of custody, and was paid for. It rides delay-tolerant networking and settles on BSV.
Do I really need a blockchain just to move data?
No, and it does not move the data for you. The transport is standard Bundle Protocol v7. What BSV adds is the settlement and provenance: delivery is bound to a real payment, and the data's root is anchored on chain so anyone can later verify what was delivered and paid, without trusting the relays or a central server.
What does this add that DTN itself doesn't?
The Bundle Protocol standardizes how data moves through intermittent networks, but it defines no native payment, incentive, or economic model, and only limited trust verification (largely against link-layer attacks). It does not answer who paid for a delivery, or how you prove offline, a session later, the custody chain the data passed through. That settlement and verifiable-custody layer is exactly what this adds, on top of the standard, not instead of it.
Does it replace the radio, satellite, or sonar?
No. The physical link (RF, optical, acoustic, coding, FEC) is explicitly out of scope. This is the trust, custody, and settlement layer that sits on top of whatever carries the bits. That boundary is the point, it makes the layer rail- and medium-agnostic.
What does a verifier actually check?
Four things, and it refuses if any fail: the content address recomputes, the signature recovers to the expected key, each delivered chunk verifies against the Merkle root, and delivery is bound to the settlement you paid. That last part matters: a receipt is a bearer object until you check its settlementRef against the transaction you actually paid. An unbound check refuses rather than passing.
How is this different from BPv7's built-in custody?
BPv7 custody signals are inconsistent across implementations and are not cryptographically verifiable offline. Here, custody is an application-layer, content-addressed, signed receipt per hop. It is portable across DTN stacks and verifiable a session late, which is exactly what a link with no live return path requires.
Is it only for space?
No. Delay-tolerant networking was built for intermittent, disrupted links generally. The same constraints appear in the ocean (subsea and AUVs), the sky (drones and stratospheric relay), and on Earth (disaster mesh, evidence chain-of-custody, environmental measurement). Deep space is just the extreme case.
What does the on-chain anchor prove?
That a specific data root existed and was committed at a point in time, tamper-evidently, independent of every relay the data crossed. Re-derive the Merkle root from the delivered payload and it matches the value in the transaction's OP_RETURN. It does not prove the data is correct, only that it is the data that was anchored.
How much does settlement cost?
A BSV micropayment, on the order of a few satoshis for a delivery or an anchor. That low, fixed floor is what makes per-bundle and per-delivery settlement practical, which is not feasible when a single transfer costs more than the data is worth.
Which DTN stack does it use?
The reference uses µD3TN (D3TN's BPv7 implementation, with flight heritage), attached over its Application Agent Protocol. The custody agent does not depend on µD3TN specifically, any BPv7 bundle agent works behind the same contract.
Is DTN a real standard, or just research?
Both, and it is deployed. The term was coined by Kevin Fall in 2002, growing out of Vint Cerf's Interplanetary Internet work with ARPA/DARPA lineage. Bundle Protocol v7 is an IETF standard: RFC 9171, with BPSec security (RFC 9172), default security contexts (RFC 9173), and the TCP convergence layer (RFC 9174), updated by RFC 9713 (2025); BPv6 was RFC 5050 and the architecture RFC 4838. It runs operationally on the International Space Station (the DTNME engine), first flew in space on UK-DMC in 2008, was demonstrated deep-space by NASA JPL's DINET (Deep Impact / EPOXI), and is used by NASA's PACE mission. This layer sits on top of that standard.
Is it production-ready?
It is a reference implementation, proven end to end on real infrastructure, not an audited production system. Review it and run your own assessment before relying on it. You hold your own keys and funds; nothing here custodies keys or broadcasts on your behalf.
What is open source, and what is not?
The protocol, agent library, DTN adapters, verifiers, and on-chain checks are open under Apache-2.0. A hosted BSV settlement facilitator and relay marketplace, managed key custody, and the BSVKey brand are operated separately. The open core settles on BSV; the production service is the hosted offering.
How do I try it?
Clone the repo and run the proofs (see Quickstart). npm test and npm run demo need only Node; make spike, make r2, and make live exercise the real netem, real BPv7, and real on-chain paths.

Open core

Open protocol, hosted rail

The protocol, agent library, DTN adapters, verifiers, and on-chain checks are open under Apache-2.0. A hosted BSV settlement facilitator and relay marketplace, managed key custody, and the BSVKey brand are operated separately. The open core settles on BSV; running a production relay-payment service on top of it is the hosted offering.