A specification for a privacy-respecting bandwidth marketplace settled in Bitcoin.
ARFL is an open protocol for buying and selling network bandwidth without accounts, subscriptions, or logs. Users pay per-gigabyte over Lightning. Node operators earn on capacity they already own. The coordinating hub cannot link a buyer to their traffic — not by policy, but because the construction does not give it the information.
This repository is the protocol specification: architecture, wire format, and the economic invariants the system is built to preserve. The reference implementation is maintained separately.
Three requirements that normally fight each other:
- Settlement must be trustworthy — operators need to know they will be paid for bandwidth already delivered.
- The coordinator must not become a surveillance point — it sees every payment, so it is the natural place for buyer identity to leak.
- No accounts — there is no identity layer to hang authorization on.
ARFL resolves these with blind-signed bearer tokens for authorization, an append-only ledger for settlement, and nested tunnels so that no single relay holds both halves of the identifying pair.
┌──────────┐ Lightning ┌──────────┐ Nostr relays ┌──────────┐
│ Client │ ──── pay ────────► │ Hub │ ◄── announcements ── │ Nodes │
│ │ ◄── Cashu tokens ─ │ (mint) │ │ │
└─────┬────┘ └──────────┘ └────┬─────┘
│ │
│ NIP-44 encrypted token │
└────────────────── WireGuard tunnel ────────────────────────────►│
(entry → exit → internet)
| Property | Mechanism |
|---|---|
| Buyer–session unlinkability | Cashu BDHKE blind signatures |
| Token delivery privacy | NIP-44 end-to-end encryption |
| Entry node cannot see destinations | Nested WireGuard inner tunnel |
| Exit node cannot see client IP | Sees only the entry node's NAT address |
| No identity required | Lightning payment carries no personal data |
Each property is derived from a construction, not from an operator promise. The architecture document states what each participant can observe and — equally important — what the design does not protect against.
Settlement correctness is specified as invariants that any conforming implementation must hold. If code violates one, the code is wrong.
- Conservation of value — total operator payouts can never exceed total buyer purchases. Checked every settlement cycle; settlement halts and alerts on violation.
- Append-only ledger — no record is updated or deleted. Balances are derived by replaying events, never stored. The ledger is the reconstruction source of truth.
- Single redemption — a token is spendable exactly once. Double-spend is defined as total system failure, not a recoverable error.
- Atomic tickets — a ticket is fully consumed or not at all. Partial spend is deliberately forfeited: it costs at most a fraction of a sat and eliminates an entire class of accounting bugs.
- Traceable path — every payout traces purchase → issuance → redemption → usage report → settlement entry → payout, with no gaps.
Full text: Economic Invariants.
| Document | Contents |
|---|---|
| Architecture | Nested two-hop tunnel design, threat model, participant visibility |
| API Specification | Hub endpoints, Cashu NUT-01→07, discovery, payment flow |
| Economic Invariants | Ledger, ticket, and settlement rules |
| Whitepaper | Full protocol rationale |
Transport: WireGuard (nested two-hop) · Discovery: Nostr (kind 30078) · Settlement: Bitcoin Lightning · Privacy: Cashu ecash (BDHKE) · Token delivery: NIP-44 · Signatures: BIP-340 Schnorr
Specification published. Reference implementation in Go, maintained privately. Interoperable implementations are welcome — the wire format and invariants here are sufficient to build against.
MIT — Radi Labs