DePIN DCDN / BT distribution

Maturity: Under development. CoNET has published protocol components that this application may reuse, but there is no published end-to-end DCDN / BitTorrent client, live swarm service, or finalized seeding-settlement protocol described by this page.

Public site: https://gitbook.conet.network/applications/bt-dcdn.html

Product role

DePIN DCDN is the proposed bulk-content application for the CoNET stack. Its intended role is to combine:

• wallet-addressed discovery instead of exposing a stable IP:port as the application-level peer identity;
• content hashes and piece hashes so downloaders can verify received bytes;
• Layer Minus request routing so a client can reach a seeder through an entry rather than treating the seeder’s physical address as the public product name;
• incentivized seeding so storage and bandwidth can be compensated rather than relying only on volunteer availability.

“BT” describes the useful piece and swarm concepts borrowed from BitTorrent. It does not mean that the current BitTorrent protocol has already been ported to L0, that existing torrent clients are compatible, or that CoNET currently operates a decentralized CDN.

This is an application on L0 and a potential consumer of settlement capabilities. It is not a fourth protocol layer.

Protocol dependencies

The DCDN client must define its own application protocol. Existing L0 packages do not automatically provide torrent manifests, swarm scheduling, piece exchange, seeding proofs, or content policy.

How protocol capability could become an application

The target flow is:

Publisher
  │  split content into pieces
  │  publish manifest + content root + piece hashes
  ▼
Wallet-addressed discovery
  │  find seeders advertising the content hash
  ▼
Downloader
  │  request selected pieces through Layer Minus entries
  │  verify every piece hash
  │  assemble and verify the complete content root
  ▼
Delivery accounting
  │  produce fraud-resistant evidence of useful service
  ▼
Settlement
     compensate eligible seeders under a defined policy

Each stage needs an explicit specification:

Wallet-addressed discovery

A wallet address can be the stable application identifier while physical routing remains behind Layer Minus. This can keep a seeder’s home address out of the public swarm roster, but it does not make the underlying network address cease to exist. Entries, routed nodes, and network observers still process network connections and metadata.

The discovery design must define:

• who may advertise a content hash;
• how advertisements expire and are refreshed;
• how a client distinguishes live seeders from stale records;
• how Sybil identities, poisoned advertisements, and eclipse attacks are limited;
• whether discovery is on-chain, off-chain, DHT-like, mailbox-based, or hybrid.

None of those choices should be inferred from wallet addressing alone.

Content hash and piece verification

The manifest should commit to the exact content and its pieces. A downloader accepts a piece only when its hash matches the manifest and accepts the final file only when the complete content commitment matches.

Content addressing provides integrity, not:

• confidentiality;
• publisher authenticity unless the manifest is also signed;
• proof that content is safe, legal, or correctly licensed;
• availability when no honest seeder retains the bytes.

The hash algorithm, manifest serialization, publisher signature, piece size, versioning, and magnet / torrent compatibility remain design work.

Incentivized seeding

The intended economic loop is to reward storage and useful delivery, particularly for cold content. A viable protocol must prove more than “a wallet claimed to seed”:

• a requester received correct, previously unavailable bytes;
• the seeder did not manufacture both sides of the exchange;
• duplicate, replayed, or trivial transfers are not paid repeatedly;
• accounting cannot be amplified cheaply through Sybil wallets;
• settlement cost does not exceed the delivered value;
• publisher budgets, downloader charges, and node rewards have explicit limits.

Micropayments, batched tips, publisher bounty pools, and proof-of-transfer accounting are candidate mechanisms, not shipped DCDN features.

What exists today

The reusable public substrate is:

What does not exist as a published DCDN product today:

• a public DCDN / BT client repository or npm package;
• a released swarm-discovery implementation;
• a finalized manifest and content-hash format;
• a production piece scheduler and verifier;
• a documented live seeder market;
• finalized delivery-proof, fee, reward, fraud, or slashing rules;
• measured production throughput or availability.

The presence of L0 packages is evidence of dependencies, not evidence that the DCDN application is online.

What remains in development

1. Specify manifest serialization, content roots, piece hashes, publisher signatures, and version negotiation.
2. Implement torrent / magnet ingest or explicitly define a non-BitTorrent-compatible format.
3. Design wallet-addressed seeder discovery, freshness, routing, and Sybil resistance.
4. Implement parallel piece scheduling, retries, rare-piece selection, local verification, resume, and final assembly.
5. Define privacy-preserving session identity without claiming that a wallet address is anonymous.
6. Design measurable, fraud-resistant proofs of useful storage and delivery.
7. Define payment assets, batching, fees, budgets, disputes, and settlement finality.
8. Add content-policy, abuse-reporting, malware, copyright, operator, and jurisdiction controls.
9. Benchmark throughput, latency, path overhead, cold-content availability, and entry / seeder capacity.
10. Publish client source, interoperability tests, threat models, and independent security review before describing the service as available.

Trust and security boundary

Hiding a stable peer IP from a swarm roster would be a useful property, but it must not be described as guaranteed anonymity, immunity from blocking, or immunity from lawful process.

Related

• Applications
• SilentPass VPN — a public privacy-access product on parts of the same L0 substrate
• HTTP mimicry & Fetch-and-Close
• Wallet-address P2P
• TCP/IP privacy threats
• UDP forward
• CoNET-DLE
• Use case: creator economy
• Resources