• White Paper: A Bitcoin-Native Physical Onion-Routing Network for Privacy-Preserving Commerce
  • Abstract
  • 1. Problem Statement
  • 2. Bitcoin-Native Design Principle
  • 3. Conceptual Analogy: Tor for Parcels
  • 4. Basic User Flow
    • Buyer flow
    • Merchant flow
    • Router flow
  • 5. Core System Goals
  • 6. Main Actors
    • Buyer
    • Merchant
    • Entry Router
    • Middle Router
    • Exit Router
    • Coordinator
    • Insurance Fund
    • Bitcoin Payment Layer
  • 7. Routing Model
    • 7.1 One-hop route
    • 7.2 Two-hop route
    • 7.3 Three-hop route
    • 7.4 Pickup-point route
  • 8. Bitcoin Payment Architecture
    • 8.1 Buyer routing invoice
    • 8.2 Payment settlement states
    • 8.3 Router payout ledger
    • 8.4 Payout methods
    • 8.5 Custody model
    • 8.6 Hot wallet and reserve policy
    • 8.7 Router bonds
  • 9. Router Performance Rating System
    • 9.1 Required router actions
    • 9.2 Time standards
    • 9.3 Scoring dimensions
    • 9.4 Suggested scoring formula
    • 9.5 Compensation multiplier
    • 9.6 Route-selection priority
  • 10. Tracking and Verification
    • 10.1 Minimum tracking requirements
    • 10.2 Valid tracking event
    • 10.3 Handling tracking delays
    • 10.4 Fraud controls
  • 11. Insurance Model
    • 11.1 Standard insurance fund
    • 11.2 Optional buyer-purchased coverage
    • 11.3 Bitcoin volatility handling
    • 11.4 Claims process
    • 11.5 Router liability and bond claims
    • 11.6 Insurance exclusions
  • 12. Penalty and Ban System
    • 12.1 Three-business-day penalty
    • 12.2 Five-business-day ban
    • 12.3 Emergency rerouting
  • 13. Compliance and Legal Risk
    • 13.1 Safer launch posture
    • 13.2 Router identity
    • 13.3 Bitcoin compliance considerations
  • 14. Restricted Goods Policy
  • 15. Privacy Design
    • 15.1 What privacy the system can provide
    • 15.2 What privacy the system cannot fully provide
    • 15.3 Bitcoin payment privacy
    • 15.4 Metadata minimization
    • 15.5 Router knowledge boundaries
  • 16. Repackaging Policy
  • 17. Fee Model
    • 17.1 Example fee structure
    • 17.2 Compensation based on score
    • 17.3 Exchange-rate policy
  • 18. Dispute Model
    • 18.1 Evidence hierarchy
    • 18.2 Fault classification
    • 18.3 Bitcoin refund policy
  • 19. MVP Implementation
    • 19.1 MVP scope
    • 19.2 MVP payment stack
    • 19.3 MVP route design
    • 19.4 MVP category restrictions
  • 20. Technical Architecture
    • 20.1 Backend
    • 20.2 Carrier integration
    • 20.3 Bitcoin integration
    • 20.4 Nostr integration
    • 20.5 Data model sketch
    • 20.6 Shipment hop state machine
    • 20.7 Payment state machine
    • 20.8 Router penalty automation
  • 21. Protocol Sketch
    • 21.1 Shipment request
    • 21.2 Buyer invoice
    • 21.3 Router assignment
    • 21.4 Proof of forwarding
    • 21.5 Router score update
    • 21.6 Router payout
  • 22. Open Problems
    • 22.1 The final hop still sees something
    • 22.2 Timing correlation remains hard
    • 22.3 Router supply will be hard
    • 22.4 Bad users will test the system
    • 22.5 The coordinator is powerful
    • 22.6 Lightning has physical-shipping limitations
  • 23. Recommended Development Roadmap
    • Phase 1: Bitcoin-native private forwarding MVP
    • Phase 2: Router marketplace
    • Phase 3: Two-hop routing
    • Phase 4: Bitcoin insurance and bond hardening
    • Phase 5: Bitcoin commerce integrations
    • Phase 6: Privacy hardening
  • 24. Product Positioning
  • 25. Conclusion

§White Paper: A Bitcoin-Native Physical Onion-Routing Network for Privacy-Preserving Commerce

§Abstract

Bitcoin and Lightning reduce the amount of financial information exposed during online commerce, but physical delivery reintroduces a major privacy leak: the buyer must normally give a merchant a real-world shipping address.

This paper proposes a Bitcoin-native physical onion-routing delivery network: a compensated network of parcel routers who receive, validate, relabel, and forward lawful packages through multiple hops before final delivery. The system is designed from the ground up around Bitcoin payments, with buyer routing fees, router compensation, insurance reserves, penalties, and optional higher coverage all denominated and settled in Bitcoin or Lightning.

The goal is not to create an unaccountable contraband network. The goal is to let legitimate buyers purchase lawful physical goods with Bitcoin while avoiding permanent exposure of their home address to every merchant.

The system would use entry nodes, intermediate routers, exit routers, tracking-number verification, router performance ratings, automatic Lightning payouts, Bitcoin-denominated insurance reserves, and strict timeout penalties. Routers would earn more when they perform reliably and be penalized or banned when they fail to forward packages on time.

The strongest implementation is not a pure “physical Tor clone.” The strongest implementation is a Bitcoin-native, compliance-aware, privacy-preserving fulfillment layer for lawful commerce.

§1. Problem Statement

Bitcoin commerce has a privacy contradiction.

A buyer may use Bitcoin, Lightning, Nostr, BTCPay, LNbits, self-custodial wallets, or another privacy-conscious payment and identity stack, but the moment they buy a physical item, they often must provide:

• legal name;
• home address;
• phone number;
• email address;
• carrier delivery metadata;
• order history;
• tracking information.

That data may be stored by:

• the merchant;
• marketplace software;
• payment/order software;
• third-party shipping software;
• helpdesk systems;
• analytics tools;
• fulfillment providers;
• email systems;
• breached databases later.

The proposed system separates:

• merchant identity
• buyer address
• payment identity
• shipping route
• router compensation
• insurance coverage
• final delivery endpoint

The merchant should be able to fulfill a lawful sale without learning the buyer’s final address.

The buyer should be able to pay for private fulfillment directly with Bitcoin.

Routers should be able to earn Bitcoin for performing reliable forwarding work.

§2. Bitcoin-Native Design Principle

Bitcoin payments are not an optional later integration. They are part of the system’s foundation.

The network should be designed around Bitcoin from the beginning:

• buyer routing fees are paid in Bitcoin or Lightning;
• router compensation is denominated in sats;
• router payouts are made through Lightning where practical;
• insurance reserves are accounted for in Bitcoin-denominated units;
• optional higher insurance coverage is purchased in Bitcoin;
• penalties, forfeitures, and bond claims are accounted for in Bitcoin terms;
• merchant integrations should support BTCPay Server, LNbits, Nostr Wallet Connect, and other Bitcoin-native infrastructure;
• the system should avoid dependence on card processors as a core payment rail.

The purpose of this is not merely ideological. Bitcoin-native payments fit the use case:

1. The user base is likely to be privacy-conscious Bitcoin users.
2. Router micro-compensation is better suited to Lightning than card payouts.
3. Global settlement can be simpler when using sats instead of multiple fiat payout systems.
4. Bitcoin commerce should not require falling back to legacy payment rails for the private fulfillment layer.
5. A Bitcoin-native model aligns the incentives of buyers, merchants, routers, and infrastructure providers.

§3. Conceptual Analogy: Tor for Parcels

Tor uses multiple relays so that no single relay sees the full communication path. A physical parcel network can borrow that basic structure:

Merchant → Entry Router → Middle Router(s) → Exit Router → Buyer

Each router only receives the information needed for its own hop.

The merchant knows only the entry address.

The entry router knows only the merchant origin and the next hop.

A middle router knows only the previous hop and next hop.

The exit router sees the final destination or final delivery endpoint, but does not necessarily know whether that endpoint is the buyer or another routing destination.

This analogy is useful, but imperfect. Internet packets are cheap, fast, uniform, and cryptographically wrapped. Physical packages are expensive, slow, visible, trackable, stealable, insured, and legally regulated.

The design must account for that physical reality.

§4. Basic User Flow

§Buyer flow

1. Buyer creates an account with the routing service.

2. Buyer creates or selects a private delivery profile.

3. Buyer chooses a privacy tier.

4. Buyer chooses standard or increased insurance coverage.

5. System quotes the total routing cost in sats.

6. Buyer pays the routing invoice using Bitcoin or Lightning.

7. Buyer receives:

   • an entry-node shipping address;
   • a shipment validation code;
   • optional merchant instructions.

8. Buyer gives the entry-node address and validation code to the merchant.

9. Buyer receives tracking updates as the parcel moves through the routing network.

10. Buyer receives final delivery.

§Merchant flow

1. Merchant receives an ordinary shipping address.
2. Merchant ships the package to the entry node.
3. Merchant does not receive the buyer’s home address.
4. Merchant can verify delivery to the entry node or first network-controlled address.
5. Merchant does not need to understand the full route.

§Router flow

1. Router enrolls with a Bitcoin payout address, Lightning address, LNURL-pay endpoint, or Nostr Wallet Connect-compatible payout method.
2. Router receives package assignment.
3. Router receives a package.
4. Router enters the validation code or scans a network code.
5. Router sees only the next-hop shipping instruction.
6. Router purchases or prints a tracked label.
7. Router submits the outbound tracking number.
8. Network verifies shipment.
9. Router earns Bitcoin compensation after proof of forwarding.
10. Router rating updates based on promptness, tracking compliance, and dispute history.

§5. Core System Goals

The system should provide:

1. Merchant address minimization The merchant should not receive the buyer’s home address.

2. Bitcoin-native payment flow Buyer fees, router compensation, insurance, penalties, and reserves should be denominated and settled through Bitcoin-native infrastructure.

3. Compartmentalized routing No router should need the full route.

4. Tracked chain of custody Every hop should produce a tracking number and timestamp.

5. Economic accountability Routers should earn more for reliable service and lose access for poor performance.

6. Insurance-backed buyer protection A portion of routing fees should fund a standard insurance pool, with optional higher buyer-purchased coverage.

7. Compliance-aware operation The network should reject prohibited, restricted, suspicious, or high-risk categories.

8. Practical deployability The MVP should be usable without solving every possible privacy problem on day one.

§6. Main Actors

§Buyer

The person purchasing lawful goods and seeking to keep their address away from the merchant.

§Merchant

The seller of lawful goods. The merchant ships to the network entry address.

§Entry Router

The first network participant to receive the package from the merchant.

§Middle Router

An optional intermediate router that forwards the package deeper into the network.

§Exit Router

The final network router before the buyer or final delivery endpoint.

§Coordinator

The software system that manages route selection, validation codes, tracking, fees, Bitcoin invoices, router payouts, insurance reserves, ratings, penalties, and disputes.

§Insurance Fund

A Bitcoin-denominated reserve funded by a percentage of routing fees and optional buyer-purchased extra coverage.

§Bitcoin Payment Layer

The payment infrastructure used for:

• buyer invoice generation;
• Lightning payments;
• on-chain fallback payments;
• router payouts;
• refund handling;
• payout holds;
• penalty accounting;
• insurance fund accounting.

This could be implemented through BTCPay Server, LNbits, a self-hosted Lightning node, Nostr Wallet Connect, LNURL, or a combination of these tools.

§7. Routing Model

§7.1 One-hop route

Merchant → Router → Buyer

This is the simplest version.

It protects the buyer’s address from the merchant, but the router sees the buyer’s final address.

Use case:

• low-risk purchases;
• low-cost goods;
• first MVP;
• users who mainly care about merchant database exposure.

§7.2 Two-hop route

Merchant → Entry Router → Exit Router → Buyer

This is likely the practical default.

The entry router sees the merchant origin, but not the buyer address. The exit router sees the final address or endpoint, but not the merchant.

Use case:

• ordinary privacy-conscious commerce;
• better address separation;
• moderate cost and latency.

§7.3 Three-hop route

Merchant → Entry Router → Middle Router → Exit Router → Buyer

This better resembles onion routing, but cost and delay increase sharply.

Use case:

• higher-value privacy-sensitive lawful purchases;
• users willing to pay more;
• mature network only.

§7.4 Pickup-point route

Merchant → Entry Router → Exit Router → Locker / CMRA / Pickup Point

This may be stronger than home delivery because the exit router does not see a residential address.

Use case:

• stronger buyer privacy;
• users with PO boxes, parcel lockers, commercial receiving addresses, or trusted pickup endpoints.

§8. Bitcoin Payment Architecture

Bitcoin payments are a core part of the MVP.

The system should support two payment paths:

1. Lightning-first payment
2. On-chain Bitcoin fallback

Lightning should be the default because routing fees and router compensation are likely to be relatively small. On-chain payment should be available for larger route fees, insurance deposits, router bonds, and cases where Lightning liquidity is insufficient.

§8.1 Buyer routing invoice

When the buyer creates a shipment request, the system quotes a Bitcoin-denominated routing fee.

The quote should include:

carrier postage estimate
+ router handling compensation
+ insurance fund contribution
+ optional extra insurance
+ platform fee
+ dispute reserve
+ Lightning/network fee buffer

The buyer receives a Lightning invoice or on-chain address.

Example:

{
  "shipment_request_id": "random-id",
  "privacy_tier": "two_hop",
  "declared_value_sats": 250000,
  "standard_insurance": true,
  "extra_insurance_sats": 0,
  "routing_fee_sats": 42000,
  "expires_at": "2026-05-01T18:00:00Z",
  "payment_method": "lightning",
  "invoice_status": "pending"
}

The route should not become active until the invoice is paid.

§8.2 Payment settlement states

quote_created
invoice_issued
invoice_paid
route_reserved
entry_address_released
merchant_shipped
routing_in_progress
completed
claim_window_open
settled
refunded
disputed

The buyer should receive the entry-node address only after the routing invoice is paid or otherwise funded.

This prevents unpaid route reservations and reduces spam.

§8.3 Router payout ledger

Each router task should create a pending payout.

Example:

{
  "router_id": "router-id",
  "shipment_hop_id": "hop-id",
  "base_compensation_sats": 6000,
  "score_multiplier": 1.25,
  "expected_compensation_sats": 7500,
  "status": "pending_tracking_verification"
}

Router payout should only be released after the router has submitted valid outbound tracking and the system has verified carrier acceptance or next-hop receipt.

§8.4 Payout methods

Routers should be able to choose from Bitcoin-native payout methods:

• Lightning invoice submitted by router;
• Lightning Address;
• LNURL-pay;
• Nostr Wallet Connect;
• internal sats balance with withdrawal;
• on-chain payout for larger balances;
• batched on-chain payout for lower fee overhead.

The MVP should prioritize Lightning payouts because router compensation will usually be small.

§8.5 Custody model

There are two possible custody models.

§Model A: Custodial coordinator ledger

The coordinator receives the buyer’s routing payment, credits internal shipment balances, and pays routers as tasks complete.

Advantages:

• simpler MVP;
• easier insurance reserve accounting;
• easier dispute handling;
• easier partial payouts;
• easier penalty enforcement.

Disadvantages:

• custodial risk;
• regulatory complexity;
• wallet security burden;
• user trust burden.

§Model B: Non-custodial or minimized-custody flow

The buyer payment is split or conditionally routed through smart accounting, escrow-like invoices, or multiparty payout mechanisms.

Advantages:

• reduced custody exposure;
• better alignment with Bitcoin self-custody norms.

Disadvantages:

• harder to implement;
• harder to handle disputes;
• harder to insure;
• harder to coordinate many small payouts;
• Lightning hold-invoice limitations may not fit long physical shipping timelines.

Practical recommendation:

The MVP may need a custodial or semi-custodial coordinator ledger for routing fees, but it should be designed with strict accounting separation, proof-of-reserves practices where possible, withdrawal limits, hot/cold wallet separation, and a long-term path toward reduced custody.

§8.6 Hot wallet and reserve policy

The coordinator should separate funds into logical buckets:

hot wallet
router payout wallet
insurance reserve
platform revenue
refund reserve
cold storage reserve
bond reserve

Suggested policy:

• keep only near-term payout liquidity in hot wallets;
• sweep excess to cold storage;
• maintain a Lightning liquidity buffer for router payouts;
• keep insurance reserve accounting separate from operating revenue;
• require multisig for large reserve movements;
• maintain internal audit logs for all fund movements.

§8.7 Router bonds

High-volume routers or routers handling higher-value packages should post a Bitcoin-denominated bond.

Router bonds can be used for:

• lost package claims;
• confirmed theft;
• repeated non-shipment;
• false tracking submissions;
• policy violations;
• insurance deductible recovery.

Bond requirements should scale with:

• package value;
• route volume;
• router rating;
• history length;
• insurance tier eligibility.

Example:

Low-value router: no bond, limited package eligibility
Standard router: 250,000 sats bond
Preferred router: 1,000,000 sats bond
High-value router: custom bond requirement

Bond seizure should require a defined dispute process, not arbitrary platform action.

§9. Router Performance Rating System

The router rating system is the enforcement layer that makes the network usable.

A router who receives a package becomes responsible for forwarding it promptly. Compensation, priority, and network access should depend on measurable performance.

§9.1 Required router actions

For every assigned package, a router must:

1. confirm receipt;
2. inspect exterior condition;
3. photograph exterior package condition;
4. validate the shipment code;
5. obtain the next-hop label or address;
6. ship with tracking;
7. submit outbound tracking number;
8. upload proof of carrier acceptance;
9. complete the hop within the required time window.

§9.2 Time standards

Suggested baseline:

The three-business-day rule gives routers practical room for weekends, work schedules, weather, and carrier access.

The five-business-day rule should be severe. A router who receives someone else’s package and fails to forward it within five business days should normally be removed from the network unless there is an approved emergency or verifiable carrier-related issue.

§9.3 Scoring dimensions

Router score should be based on:

A simple rating could begin at 100 and adjust downward for failures.

§9.4 Suggested scoring formula

Router Score =
  100
  - late_forwarding_penalties
  - missing_tracking_penalties
  - proof_failure_penalties
  - dispute_penalties
  - loss_or_damage_penalties
  - policy_violation_penalties
  - bond_deficiency_penalties
  + reliability_bonus

Example penalties:

§9.5 Compensation multiplier

Higher-rated routers should earn more.

Example:

This aligns incentives correctly. Prompt, accurate routers get more packages and higher Bitcoin compensation. Slow or unreliable routers become uneconomical or are removed.

§9.6 Route-selection priority

The coordinator should prefer routers with:

• high score;
• low median forwarding time;
• low dispute rate;
• sufficient capacity;
• strong tracking compliance;
• good geographic position;
• category eligibility;
• suitable insurance/bond level;
• valid Bitcoin payout method;
• sufficient reputation for the selected insurance tier.

Low-rated routers should receive fewer assignments or only low-value packages until they recover.

§10. Tracking and Verification

Tracking is mandatory.

A router cannot simply say, “I shipped it.” They must submit a valid outbound tracking number.

§10.1 Minimum tracking requirements

Each hop must include:

• inbound carrier;
• inbound tracking number;
• inbound delivery timestamp;
• router receipt confirmation;
• outbound carrier;
• outbound tracking number;
• outbound acceptance timestamp;
• package exterior photo;
• proof of label or receipt;
• next-hop confirmation when available.

§10.2 Valid tracking event

The system should not release Bitcoin compensation merely because a router typed a number.

The tracking number must resolve through carrier APIs or shipping-label provider APIs.

Valid outbound proof should include one of:

• carrier acceptance scan;
• drop-off receipt;
• label provider acceptance confirmation;
• next-router receipt confirmation;
• delivery scan to next hop.

§10.3 Handling tracking delays

Carrier tracking sometimes lags. The system should allow a short pending state.

Example:

Router submits tracking number.
System checks carrier API.
If tracking is not live yet, status = pending verification.
If tracking becomes live within 24 hours, status = verified.
If tracking does not become live, router must provide receipt or reshipment proof.

§10.4 Fraud controls

The system should detect:

• reused tracking numbers;
• tracking numbers unrelated to the route;
• tracking numbers with wrong origin/destination region;
• tracking numbers created but never accepted;
• label purchased but package never dropped off;
• repeated “lost after my hop” patterns;
• suspiciously delayed submissions near penalty deadlines;
• payout method changes immediately before high-value tasks;
• routers attempting to route packages to themselves or colluding accounts.

§11. Insurance Model

The network should include a standard coverage amount funded by routing fees, plus optional buyer-purchased additional coverage.

The insurance system should be Bitcoin-native in accounting and funding. A portion of every paid routing invoice should be allocated to a Bitcoin-denominated insurance reserve.

A private routing network should not rely only on carrier insurance. It should maintain its own reserve because losses can occur between carrier scans, during router custody, or through router misconduct.

§11.1 Standard insurance fund

Every routed shipment should contribute a portion of the routing fee into an insurance pool.

Example:

Routing fee allocation:
- carrier postage reimbursement
- router handling compensation
- platform fee
- standard insurance fund contribution
- dispute reserve
- Lightning/network fee buffer

The standard fund might cover, for example:

Standard coverage: up to 250,000 sats per shipment

The exact amount should depend on economics, claims history, Bitcoin price volatility, carrier coverage, and legal review.

§11.2 Optional buyer-purchased coverage

Buyer can purchase extra coverage at checkout using Bitcoin.

Example tiers:

Higher insurance tiers should require:

• higher-rated routers;
• shorter route length or professional nodes;
• better proof requirements;
• stronger package photos;
• declared item category;
• merchant invoice upload;
• router bond eligibility;
• additional reserve contribution.

§11.3 Bitcoin volatility handling

Bitcoin-denominated insurance creates a volatility question.

There are two possible models:

§Model A: sats-denominated coverage

The policy covers a fixed number of sats.

Example:

Coverage: 500,000 sats

Advantages:

• simple;
• Bitcoin-native;
• no fiat dependency;
• clear settlement.

Disadvantages:

• purchasing-power value changes with BTC price.

§Model B: fiat-indexed, Bitcoin-paid coverage

The policy is priced and paid in sats, but coverage is indexed to fiat value at purchase time.

Example:

Coverage: USD $250 equivalent
Paid in sats at invoice time
Claim paid in sats at claim-resolution time

Advantages:

• easier for buyers to understand value;
• easier merchant invoice matching.

Disadvantages:

• requires price feeds;
• adds exchange-rate risk;
• less purely Bitcoin-denominated;
• requires reserve management.

Practical recommendation:

The MVP should support clear fiat-equivalent display for user comprehension while maintaining Bitcoin payment and accounting internally. Over time, advanced users can select sats-denominated coverage.

§11.4 Claims process

A claim should require:

• buyer order proof;
• merchant shipment proof;
• inbound tracking;
• router receipt confirmation;
• outbound tracking;
• carrier acceptance proof;
• delivery/non-delivery evidence;
• package photos from each hop;
• declared value support;
• insurance tier selected and paid.

The insurance fund should not automatically pay claims without evidence. Otherwise, buyer fraud becomes easy.

§11.5 Router liability and bond claims

If a package is lost while in router custody, the platform should determine whether the router:

• received the package;
• failed to forward it;
• submitted invalid tracking;
• delayed beyond allowed windows;
• violated policy;
• caused damage;
• appears to have stolen the package.

High-volume or high-value routers should have a Bitcoin-denominated bond or rolling reserve. If a router fails catastrophically, claims should first hit:

1. carrier insurance if applicable;
2. router bond/reserve if router fault is likely;
3. network insurance fund;
4. platform discretionary reserve.

§11.6 Insurance exclusions

The insurance fund should exclude:

• prohibited goods;
• undeclared restricted items;
• illegal goods;
• cash;
• precious metals;
• high-value jewelry;
• weapons;
• drugs or controlled substances;
• perishables;
• hazardous materials;
• items above declared value;
• shipments where buyer or merchant lied about contents;
• packages opened or modified outside policy;
• international shipments in MVP.

§12. Penalty and Ban System

The network must be strict because routers physically control other people’s property.

§12.1 Three-business-day penalty

If a router does not ship within three business days of confirmed receipt:

• automatic score penalty;
• Bitcoin compensation reduction;
• route-priority reduction;
• warning notice;
• possible loss of elite/preferred status.

Suggested penalty:

Late but shipped before 5 business days:
-10 score points
25% compensation reduction for that hop
No bonus multiplier for that hop

For repeat late behavior:

Second late shipment in 30 days: temporary probation
Third late shipment in 30 days: suspension review

§12.2 Five-business-day ban

If a router does not ship within five business days:

• immediate suspension;
• no new packages assigned;
• pending payout frozen;
• bond review begins;
• shipment escalated;
• insurance/dispute process begins;
• router may be banned.

Suggested rule:

No outbound carrier acceptance scan within 5 business days
= presumptive network ban unless approved exception exists.

Approved exceptions should be narrow:

• natural disaster;
• hospitalization;
• carrier system failure with evidence;
• law enforcement seizure with documentation;
• platform-directed hold;
• package is suspicious or prohibited and was properly escalated.

§12.3 Emergency rerouting

If a router fails to act:

1. platform contacts router;
2. router must respond within a short window;
3. buyer is notified of delay;
4. if router is unreachable, account is suspended;
5. pending payout is frozen;
6. bond may be locked pending review;
7. platform initiates claim, bond action, or recovery process.

Physical recovery may be difficult, so the system should prevent bad routers from receiving valuable packages in the first place.

§13. Compliance and Legal Risk

This model touches postal forwarding, mail-receiving agency rules, consumer protection, taxes, insurance, marketplace payouts, Bitcoin custody, money transmission analysis, and prohibited-goods policies.

The project cannot ignore mail-receiving rules, shipping regulations, restricted-item laws, insurance rules, tax reporting, custody obligations, or consumer-protection requirements. Legal review should happen before launch.

§13.1 Safer launch posture

The safest MVP should:

• start with domestic parcels only;
• avoid letter mail;
• avoid international shipments;
• use known lawful merchants;
• use verified routers;
• prohibit risky categories;
• maintain clear records;
• use tracked shipments only;
• require item category declarations;
• include insurance and dispute processes;
• support Bitcoin payments from day one;
• use clear custody/accounting policies;
• consult postal, shipping, insurance, tax, and Bitcoin-payments counsel.

§13.2 Router identity

Routers should not be anonymous to the coordinator.

They may be pseudonymous to buyers and merchants, but the platform needs:

• legal identity;
• physical receiving address;
• proof of address;
• signed router agreement;
• compliance training acknowledgment;
• Bitcoin payout method;
• tax information where required;
• bond information where required.

Without this, theft and abuse become unmanageable.

§13.3 Bitcoin compliance considerations

A Bitcoin-native system must consider:

• whether the coordinator has custody of user funds;
• whether router payouts create tax reporting obligations;
• whether insurance reserves require licensing or special structure;
• whether user balances are allowed;
• whether the platform can hold sats for later payout;
• whether bonds are legally enforceable;
• how refunds are handled;
• how abandoned balances are handled;
• whether Lightning routing or wallet infrastructure creates additional obligations.

The system should avoid unnecessary stored balances where possible. If balances are used, they should be clearly accounted for and legally reviewed.

§14. Restricted Goods Policy

A physical privacy network must aggressively reject abuse.

The MVP should prohibit:

• controlled substances;
• weapons;
• ammunition;
• explosives;
• hazardous materials;
• lithium batteries unless properly handled by approved professional nodes;
• alcohol;
• tobacco/nicotine;
• age-restricted goods;
• cash;
• precious metals;
• counterfeit goods;
• stolen goods;
• live animals;
• perishables;
• biological materials;
• medical waste;
• international shipments;
• anything requiring special legal handling.

This system should not depend on routers unknowingly forwarding anything. It should be designed to route only declared, lawful, low-risk goods.

§15. Privacy Design

§15.1 What privacy the system can provide

The system can realistically provide:

• merchant does not receive buyer’s home address;
• routers do not see the full route;
• buyer can use one-time delivery aliases;
• merchant databases do not accumulate buyer addresses;
• package flow is compartmentalized;
• route metadata can expire after completion;
• buyer can pay the routing service with Bitcoin;
• routers can be compensated through Bitcoin-native payouts.

§15.2 What privacy the system cannot fully provide

The system cannot fully hide:

• package weight;
• package dimensions;
• shipment timing;
• carrier scans;
• surveillance footage at shipping locations;
• tracking-number metadata;
• router physical addresses;
• final delivery point from the final shipper;
• package appearance if not repackaged;
• all payment metadata if the user pays from a linkable wallet or custodial Lightning account.

Bitcoin-native does not automatically mean private. Payment privacy requires careful wallet behavior, invoice handling, and metadata minimization.

§15.3 Bitcoin payment privacy

The payment layer should avoid creating unnecessary metadata links.

Recommended practices:

• use unique invoices per shipment;
• avoid reusing on-chain addresses;
• avoid exposing buyer identity in invoice memos;
• avoid putting sensitive route data into payment descriptions;
• avoid public invoice identifiers that reveal shipment details;
• allow Lightning payment where practical;
• support self-custodial wallet payment;
• minimize retained payment metadata;
• separate payment records from route records where possible.

The system should not promise perfect payment anonymity. It should promise address minimization, route compartmentalization, and Bitcoin-native settlement.

§15.4 Metadata minimization

The coordinator should avoid keeping all information in one plaintext record.

Bad design:

buyer_id | merchant | entry_router | middle_router | exit_router | final_address | all_tracking_numbers | payment_hash

Better design:

• separate buyer profile from shipment route;
• separate payment records from route records;
• encrypt final address;
• store hop instructions separately;
• expose only next-hop data;
• delete per-hop instructions after completion;
• delete route metadata after claim window closes;
• use random route IDs, not sequential order IDs;
• use per-hop validation tokens;
• avoid payment memos that expose shipping purpose.

§15.5 Router knowledge boundaries

Each router should see:

- package code
- package category declaration
- next-hop address or label
- required ship-by date
- expected compensation in sats
- insurance tier
- handling restrictions

Each router should not see:

- full route
- buyer account identity
- merchant account identity unless visible on inbound label
- final destination unless they are the final hop
- other routers in the path
- buyer payment details

§16. Repackaging Policy

Repackaging can improve privacy by reducing visual and dimensional correlation, but it introduces risk.

If routers open packages:

• they see contents;
• damage risk increases;
• warranty packaging may be affected;
• hazardous labeling may be lost;
• tamper disputes become harder.

MVP policy should be:

No routine package opening by ordinary routers.
Exterior-only forwarding by default.
Repackaging only by approved professional nodes and only when buyer selects that service.

For higher privacy tiers, professional repackaging nodes could:

• place the original package into a new outer box;
• add tamper-evident seals;
• photograph before/after condition;
• preserve labels and documents where needed;
• follow restricted-item rules.

§17. Fee Model

The buyer’s routing fee should be paid in Bitcoin and should cover:

carrier postage across hops
+ router handling compensation
+ insurance fund contribution
+ optional extra insurance
+ platform fee
+ dispute reserve
+ Lightning/network fee buffer

§17.1 Example fee structure

For a two-hop route:

Entry router handling: 6,000 sats
Exit router handling: 7,500 sats
Postage reimbursement: actual label cost converted to sats
Standard insurance fund: 2,000–5,000 sats
Platform fee: 10–15%
Optional extra insurance: based on declared value
Lightning/network fee buffer: variable

For a three-hop route:

Entry router handling: 6,000 sats
Middle router handling: 6,000 sats
Exit router handling: 7,500 sats
Postage reimbursement: actual label cost x multiple legs, converted to sats
Standard insurance fund: higher contribution
Platform fee: 10–15%
Optional extra insurance: based on declared value
Lightning/network fee buffer: variable

This will not be cheaper than direct shipping. The product is privacy fulfillment, not discount shipping.

§17.2 Compensation based on score

Router compensation should increase with reliability.

Example:

Base router fee: 6,000 sats
Router score: 96
Multiplier: 1.5x
Final router compensation: 9,000 sats

A slow router with a score of 75 might receive:

Base router fee: 6,000 sats
Multiplier: 0.75x
Final router compensation: 4,500 sats

A router who misses the five-business-day shipping deadline receives no compensation and is removed or suspended.

§17.3 Exchange-rate policy

Carrier postage is usually priced in fiat. The system needs a clear conversion policy.

Possible model:

1. At quote time, retrieve BTC/fiat exchange rate.
2. Quote the buyer in sats.
3. Lock quote for a short window, such as 10–20 minutes.
4. Buyer pays invoice.
5. Platform assumes short-term exchange-rate risk after payment.
6. If route costs change materially before merchant shipment, system may require additional payment or downgrade route only before address release.

The quote must be simple for the buyer:

Total due: 42,000 sats
Includes standard insurance up to 250,000 sats
Pay by Lightning invoice within 15 minutes

§18. Dispute Model

Disputes are unavoidable.

The platform must handle:

• merchant shipped late;
• merchant shipped wrong item;
• merchant shipped prohibited item;
• package never arrived at entry router;
• router failed to forward;
• router submitted fake tracking;
• carrier lost package;
• buyer claims non-receipt;
• package arrived damaged;
• package lacked validation code;
• route code was entered incorrectly;
• payment confirmed after invoice expiry;
• Lightning invoice failed;
• refund destination unavailable;
• router payout failed.

§18.1 Evidence hierarchy

The system should prioritize objective evidence:

1. carrier tracking scans;
2. package photos;
3. carrier receipts;
4. label purchase records;
5. next-hop receipt confirmation;
6. buyer delivery confirmation;
7. router communication logs;
8. merchant shipment proof;
9. payment records;
10. payout records.

§18.2 Fault classification

Every failure should be classified:

Insurance payouts should depend on this classification.

§18.3 Bitcoin refund policy

Refunds need special handling.

Lightning refunds are not as simple as card refunds. The system should require the buyer to provide a refund invoice or withdrawal destination.

Refund scenarios:

• buyer overpaid;
• invoice paid after expiration;
• route could not be assigned;
• merchant never shipped within expiration window;
• package was rejected before entering the network;
• claim paid from insurance fund.

Refunds should be documented and linked to the shipment without exposing sensitive route metadata.

§19. MVP Implementation

The MVP should be centralized enough to work and Bitcoin-native from day one.

Do not begin with a fully decentralized, anonymous, trustless router network. That would likely fail operationally and attract abuse.

§19.1 MVP scope

Build:

• buyer accounts;
• router accounts;
• Bitcoin/Lightning routing invoices;
• Bitcoin-native router payout methods;
• admin dashboard;
• shipment request creation;
• entry address generation after payment;
• validation code generation;
• route assignment;
• router task dashboard;
• tracking-number submission;
• carrier tracking verification;
• router score system;
• penalty system;
• sats-denominated compensation ledger;
• standard Bitcoin insurance fund accounting;
• optional Bitcoin-paid insurance purchase;
• refund invoice workflow;
• dispute workflow.

§19.2 MVP payment stack

Recommended MVP stack:

• BTCPay Server for buyer invoices;
• Lightning node for small routing payments;
• on-chain fallback for larger payments;
• LNbits or internal ledger for router payout accounting;
• LNURL-pay / Lightning Address support for router payouts;
• cold wallet reserve for insurance and bonds;
• multisig for larger reserve movements.

The MVP should not require card payments.

§19.3 MVP route design

Start with:

Merchant → Entry Router → Buyer Endpoint

or:

Merchant → Entry Router → Exit Router → Buyer Endpoint

Avoid three-hop routes until the one-hop and two-hop workflows are proven.

§19.4 MVP category restrictions

Start with low-risk goods:

• books;
• clothing;
• stickers/posters;
• hardware-wallet accessories only if battery-free;
• printed material;
• small electronics only after policy review;
• creator merchandise;
• lawful privacy-related goods.

Avoid:

• international shipping;
• high-value goods;
• special handling;
• age-restricted goods;
• hazardous goods.

§20. Technical Architecture

§20.1 Backend

Recommended:

• FastAPI, Go, or similar API backend;
• PostgreSQL;
• Redis or task queue;
• object storage for package photos;
• carrier/shipping API integration;
• BTCPay Server integration;
• Lightning node integration;
• LNbits or internal payout ledger;
• admin dashboard;
• audit logging.

§20.2 Carrier integration

The platform should integrate with shipping APIs for:

• label creation;
• tracking validation;
• carrier acceptance detection;
• insurance purchase;
• address normalization;
• rate quoting.

Possible integration categories:

• USPS-compatible label providers;
• UPS/FedEx/DHL APIs;
• Shippo/EasyPost-style aggregator APIs;
• regional carriers later.

§20.3 Bitcoin integration

The Bitcoin payment layer should support:

• Lightning invoice creation;
• on-chain invoice fallback;
• payment webhooks;
• invoice expiration;
• refund invoice workflow;
• router payout queue;
• payout retry logic;
• hot wallet balance monitoring;
• cold reserve accounting;
• insurance reserve accounting;
• router bond accounting;
• audit trails for all balance movements.

§20.4 Nostr integration

Nostr is not the payment base layer, but it fits naturally as a communication and identity layer.

Useful additions:

• Nostr login;
• NIP-44 encrypted order messages;
• Nostr event-based shipment notifications;
• Nostr Wallet Connect for wallet interactions;
• Nostr marketplace compatibility;
• router reputation attestations;
• merchant shipment-status events.

Nostr should complement the Bitcoin payment layer, not replace it.

§20.5 Data model sketch

users
buyers
routers
router_scores
router_bonds
shipments
shipment_hops
tracking_events
bitcoin_invoices
bitcoin_payments
router_payouts
payout_attempts
insurance_policies
insurance_reserve_movements
insurance_claims
router_penalties
disputes
package_photos
audit_events

§20.6 Shipment hop state machine

assigned
awaiting_inbound
inbound_delivered
router_confirmed_receipt
awaiting_outbound_tracking
outbound_tracking_submitted
tracking_verified
next_hop_delivered
completed
late
suspended
disputed
claim_opened

§20.7 Payment state machine

quote_created
invoice_created
invoice_pending
invoice_paid
invoice_expired
invoice_underpaid
invoice_overpaid
route_funded
payout_pending
payout_eligible
payout_sent
payout_failed
refund_pending
refund_sent
reserve_allocated
claim_paid

§20.8 Router penalty automation

if inbound_delivered and no receipt_confirmation within 24h:
    warning

if inbound_delivered and no verified outbound shipment within 3 business days:
    late_penalty
    reduce_payout
    reduce_score

if inbound_delivered and no verified outbound shipment within 5 business days:
    suspend_or_ban
    freeze_payout
    lock_bond_if_applicable
    open_dispute
    trigger insurance review

§21. Protocol Sketch

§21.1 Shipment request

{
  "shipment_request_id": "random-id",
  "privacy_tier": "two_hop",
  "package_category": "books",
  "declared_value_sats": 250000,
  "standard_insurance": true,
  "extra_insurance_sats": 0,
  "destination_region": "US-CO",
  "merchant_visibility": "entry_address_only",
  "payment_method": "lightning"
}

§21.2 Buyer invoice

{
  "invoice_id": "invoice-id",
  "shipment_request_id": "random-id",
  "amount_sats": 42000,
  "payment_method": "lightning",
  "expires_at": "2026-05-01T18:00:00Z",
  "status": "pending",
  "description": "Private fulfillment routing fee"
}

The invoice description should not include sensitive route data.

§21.3 Router assignment

{
  "hop_id": "random-hop-id",
  "shipment_code": "8F3K-29QX",
  "router_role": "entry",
  "ship_by_business_date": "2026-05-04",
  "late_penalty_after": "2026-05-04",
  "ban_review_after": "2026-05-06",
  "base_compensation_sats": 6000,
  "score_multiplier": 1.25,
  "expected_compensation_sats": 7500,
  "insurance_tier": "standard",
  "next_hop_label_status": "available"
}

§21.4 Proof of forwarding

{
  "hop_id": "random-hop-id",
  "outbound_carrier": "USPS",
  "outbound_tracking_number": "tracking-number",
  "carrier_acceptance_time": "2026-05-01T16:22:00Z",
  "photo_hashes": [
    "sha256-package-front",
    "sha256-package-label"
  ],
  "router_signature": "signature"
}

§21.5 Router score update

{
  "router_id": "router-id",
  "shipment_hop_id": "hop-id",
  "forwarding_time_hours": 31,
  "on_time": true,
  "tracking_valid": true,
  "proof_complete": true,
  "score_delta": 1,
  "new_score": 94
}

§21.6 Router payout

{
  "payout_id": "payout-id",
  "router_id": "router-id",
  "shipment_hop_id": "hop-id",
  "amount_sats": 7500,
  "method": "lightning_address",
  "status": "sent",
  "settled_at": "2026-05-01T17:05:00Z"
}

§22. Open Problems

§22.1 The final hop still sees something

If the final hop ships directly to a home address, someone sees that address. This is still better than the merchant seeing it, but it is not full anonymity.

Best mitigation:

• use pickup points;
• use private mailboxes;
• use compliant mail-receiving services;
• use parcel lockers;
• use trusted final-mile couriers;
• use business addresses where appropriate.

§22.2 Timing correlation remains hard

A package of similar size and weight moving through the network at predictable intervals can be correlated.

Mitigations:

• route batching;
• randomized forwarding delays;
• standardized outer boxes;
• professional repackaging nodes;
• decoy volume;
• many routers.

These should come later. They add cost.

§22.3 Router supply will be hard

Good routers must be:

• trustworthy;
• available;
• near shipping access;
• willing to handle packages;
• responsive;
• comfortable with compliance;
• economically motivated;
• capable of receiving and spending Bitcoin;
• able to maintain a reliable payout method.

This is not as easy as recruiting digital relays.

§22.4 Bad users will test the system

The system will attract people trying to move prohibited goods, stolen goods, fraud purchases, or chargeback schemes.

The design must be ready from day one:

• identity verification;
• merchant allowlist;
• category restrictions;
• compliance holds;
• strong audit logs;
• insurance exclusions;
• package rejection rules;
• payment and refund controls;
• router bond controls.

§22.5 The coordinator is powerful

If centralized, the coordinator may know too much.

Long-term improvements:

• encrypted per-hop instructions;
• minimized route logs;
• automatic data deletion;
• blinded tokens;
• no full-route exposure to ordinary employees;
• split-key access to final address;
• strict admin audit logs;
• separated payment and route records;
• multisig reserve controls;
• reduced-custody payment architecture.

§22.6 Lightning has physical-shipping limitations

Lightning is excellent for fast payments and small payouts, but physical shipping is slow.

Challenges:

• hold invoices may not safely span long shipment windows;
• channel liquidity may constrain large payout batches;
• failed payouts require retry logic;
• refund invoices require buyer cooperation;
• on-chain fallback may be needed for larger amounts;
• routing fees may fluctuate;
• hot wallet exposure must be limited.

The system should use Lightning for payment and payout convenience, not assume Lightning alone solves escrow or long-duration fulfillment risk.

§23. Recommended Development Roadmap

§Phase 1: Bitcoin-native private forwarding MVP

Goal: prove demand with Bitcoin payments from day one.

Features:

• buyer creates delivery alias;
• buyer pays routing fee by Lightning or on-chain Bitcoin;
• system assigns entry router after payment;
• merchant ships to entry address;
• router forwards with tracking;
• buyer receives package;
• router gets paid in Bitcoin after tracking verification;
• standard Bitcoin-denominated insurance pool exists;
• router score system active;
• refund invoice workflow exists.

§Phase 2: Router marketplace

Goal: scale supply.

Features:

• router onboarding;
• identity verification;
• Bitcoin payout setup;
• performance dashboard;
• payout history;
• capacity settings;
• score-based compensation;
• penalties and bans;
• proof upload;
• dispute workflow.

§Phase 3: Two-hop routing

Goal: improve privacy.

Features:

• entry and exit router separation;
• route planner;
• per-hop instruction packets;
• next-hop-only visibility;
• route metadata minimization;
• separate payment records from route records.

§Phase 4: Bitcoin insurance and bond hardening

Goal: improve trust.

Features:

• standard sats-denominated coverage;
• optional higher Bitcoin-paid coverage;
• router bonds;
• claim adjudication;
• actuarial pricing;
• high-value router eligibility;
• reserve accounting;
• multisig reserve controls.

§Phase 5: Bitcoin commerce integrations

Goal: plug into existing Bitcoin commerce ecosystems.

Features:

• BTCPay plugin;
• LNbits extension;
• Nostr marketplace compatibility;
• merchant API;
• Lightning invoice hooks;
• Nostr Wallet Connect support;
• NIP-44 encrypted buyer/router/merchant messaging.

§Phase 6: Privacy hardening

Goal: reduce metadata leakage.

Features:

• blinded route tokens;
• optional professional repackaging;
• pickup-point integrations;
• randomized timing;
• batching;
• route metadata expiry;
• stronger final-hop obfuscation;
• reduced-custody payment flows.

§24. Product Positioning

Do not market this as:

• anonymous shipping;
• untraceable delivery;
• postal Tor;
• anything-goes private mail.

Market it as:

• Bitcoin-native private fulfillment;
• merchant address minimization;
• lawful privacy delivery;
• Bitcoin commerce delivery privacy;
• one-time delivery aliases;
• compartmentalized parcel forwarding;
• sats-based router marketplace.

Suggested positioning:

A Bitcoin-native private fulfillment network that lets buyers receive lawful physical goods without giving every merchant their home address.

§25. Conclusion

A physical onion-routing network for parcels is technically plausible, but it cannot perfectly duplicate Tor. Physical packages are not packets. They have weight, volume, labels, timestamps, carrier scans, legal restrictions, insurance considerations, theft risk, payment risk, and human handlers.

A viable system must therefore be designed as a Bitcoin-native logistics marketplace with privacy guarantees, not merely as an anonymity protocol.

The essential operating principles are:

• Bitcoin payments are native from the MVP onward;
• buyer routing fees are paid in Bitcoin or Lightning;
• routers are compensated in Bitcoin;
• routers are accountable;
• tracked shipping is mandatory;
• payment is tied to proof of forwarding;
• late behavior is penalized;
• non-shipping triggers suspension or bans;
• high-performing routers earn more sats;
• buyers receive baseline insurance protection;
• optional Bitcoin-paid insurance supports higher-value use cases;
• router bonds can be denominated in Bitcoin;
• prohibited goods are excluded;
• route data is compartmentalized;
• payment data is minimized;
• the merchant does not receive the buyer’s home address.

The strongest first version should provide a narrow, useful privacy guarantee:

The merchant does not receive the buyer’s home address, every forwarding hop is tracked, scored, insured, and economically accountable, and the entire routing-fee and router-compensation system is Bitcoin-native from the beginning.

That is a realistic foundation. From there, multi-hop routing, Nostr coordination, BTCPay/LNbits integrations, pickup endpoints, stronger metadata protection, Bitcoin-denominated router bonds, professional repackaging, and reduced-custody payment flows can be added incrementally.