User Guide
Two ways to use the network: send for free, or subscribe to receive complete, numbered, self-repairing delivery over a connection whose keys never leave your hands.
Sending: always free
There is nothing to set up. A standard BSV transaction handed to the network at its nearest entry point is numbered, sorted into a delivery lane by a fixed public rule, and broadcast once; subscribed receivers everywhere get it. You pay only the miner fee the transaction itself carries. No account, no configuration.
Operating infrastructure that originates significant volume? Get in touch about a direct submission arrangement.
Two kinds of receiver
The receiving side has two main profiles, and the network shapes delivery to each. Choose the one that fits at signup; a service-provider profile is also available for infrastructure operators that sit between the two.
Targeted at block production
The transaction flow (full, or sharded across your own cluster), plus the settlement lanes: subtree data and block data for assembly and validation at speed, with the earliest possible view of the network. Settlement lanes are gated to miner accounts on both sides: only miner accounts receive them, and only miner accounts may publish blocks, coinbase and subtree data into the network (block announcements are additionally validated by proof-of-work).
Built to serve everyone
Oriented around your end users: subscribe to overlay object (BEEF) topics, complete transactions carried with their Merkle proofs, and to a compact block-header feed to verify them against. Your users get SPV-grade certainty without you running mining infrastructure, and your bandwidth tracks your users' interest, not chain volume: an application account never carries the raw transaction stream, whose volume is sized for mining operations.
The lane mapping is strict by design. Need settlement-layer transaction delivery without operating mining infrastructure? That will be supported through a separate tier offering as demand requires: get in touch.
Becoming a receiver
Receivers (miners, transaction processors, exchanges, service providers) take delivery of the network's streams as a paid service. Onboarding is self-service with one approval step.
Sign up and request access
Create a login for your 1BSV account console and request access: pick your profile (miner, service provider, or application) and how you want to be billed. We review and activate the account.
Generate your keys, and keep them
Create a WireGuard keypair on your own machine
(wg genkey | tee privatekey | wg pubkey). The
private key never leaves you; only the public half is ever
submitted. We cannot see, hold, or recover it, by design.
Request a tunnel
From the console, choose the traffic slices you want, the delivery lanes to receive (for applications, this includes the overlay topics to subscribe to), and where delivery should land in your network, and attach your public key. We approve and provision it, placed on a primary and a separate standby delivery point from the start.
Connect
Download the generated WireGuard configuration, paste in your private key locally (the file ships with a placeholder), and bring the interface up. When the tunnel handshakes, your elected streams start arriving. The console shows live status and the exact delivery addresses throughout.
What gets delivered
Delivery is by election within your tier: each lane arrives as its own stream inside your tunnel, and the lane-to-tier mapping is strict.
The settlement stream
The network's transaction stream, delivered as extended-format transactions, full or filtered to the shard slices you subscribed to. Traffic splits across independent lanes by a fixed, verifiable rule, so a mining cluster can spread the load. This stream is sized for mining operations, which is why it is a miner lane.
Subtree & block data
Block announcements, block contents, and subtree data as the network carries them, for assembly and validation at speed.
BEEF, by topic (early access)
Subscribe by named topic; each object arrives complete (the transaction together with its Merkle proof ancestry), ready for SPV verification against the header feed. Single-topic publishing through the public door is free; multi-topic publishing is available on authenticated connections. Published as open standards: BRC-148 & BRC-149.
The reference to verify against
A compact feed of block headers as the chain advances: what your application checks overlay proofs against.
Complete, numbered, repaired. Every stream is numbered: a gap is detected the instant it is skipped and recovered automatically. What you receive is complete, with ordering recoverable per flow. Anything you didn't elect is never sent, and never billed.
Your tunnel, your keys
- Two paths, automatic failover Every tunnel has a primary and a standby side. If the active side fails, delivery moves to the other automatically, and you can switch sides yourself from the console at any time, instantly and reversibly. It is safe to rehearse.
- Self-service key replacement Generate a fresh pair and submit the new public half. Keep the old interface up until the new one handshakes; the old key keeps working for the few minutes the change takes to reach the network's edge.
- Revocation Revoking a tunnel is self-service too, and immediate.
Usage, statements & billing
Volume-only: you pay for what is delivered to you, and nothing else.
- Never billed Traffic you send into the network (measured and shown to you, but free), and the network's own repair retransmissions.
- Usage Selectable windows from an hour to a year on your console, with CSV export, per tunnel, per interval: bytes, packets, transactions, rates.
- Statements Every billing period, one per tunnel, in the currency of your chosen billing rail.
- If an account falls behind Delivery is suspended but the tunnel stays up and connected: keys, addresses, and placement are all kept, and delivery resumes automatically once the balance clears. Nothing needs to be rebuilt.
For current rates and terms, contact 1bsv@lightweb.net.
Troubleshooting
Three things explain almost every “my tunnel doesn't work”.
The wrong key in the config
The most common WireGuard mistake anywhere: pasting the public key into PrivateKey =. Both halves look identical, and WireGuard accepts either silently. Verify with wg pubkey < privatekey; it must print the public key you registered (also embedded in your config's comments).
Testing with your own traffic
By default the network does not echo your own submissions back down your own tunnel: sending a transaction and watching your own feed shows nothing, by design. Test from a second machine, or ask us to adjust the setting.
Reading the wrong signal
The tunnel's health signal is its WireGuard handshake age, not ping: delivery endpoints don't answer ICMP even when healthy. A handshake older than a couple of minutes means the path is down; a recent one means it is up.
Ready to receive?
Guaranteed delivery, keys you control, and a bill that only ever reflects what arrived.