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.
Three kinds of receiver
The receiving side has three profiles, and the network shapes delivery to each. Choose the one that fits at signup.
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. Publishing into the settlement layer is miner-gated: only miner accounts may publish blocks, coinbase and subtree data into the network, and block announcements are additionally validated by proof-of-work. The settlement lanes themselves are a miner-tier product; a service that builds on settlement data without mining is the service-provider profile beside this one.
Built on settlement data, without mining
Infrastructure that consumes what miners produce: a transaction broadcaster with its own proof service (an Arcade v2 stack, for instance), a wallet backend, an explorer or API, or an SPV service that needs only the header feed. It receives the whole transaction stream and subtree data, which is what a proof service builds from, plus the block-header feed to verify against. It holds no settlement privileges: it can never publish blocks, coinbase or subtree data into the network, and it submits transactions on the same free public path everyone else uses. Block contents are not on its menu; a broadcaster whose proof service also needs them arranges that with us when its tunnel is provisioned, with no right to publish them.
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.
You pick your profile at signup, and the lane mapping is strict by design: a lane outside your profile is not delivered to you, and is not billed. If none of the three fits what you are building, 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 delivery lanes to receive (the console offers only the lanes your profile carries, and miner accounts also pick the shard slices of the transaction stream) and where delivery should land in your network, and attach your public key. Overlay topics are not part of the request: the request elects lanes, and topics are joined afterwards from your own console. 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. A miner account may take it whole or filtered to the shard slices it subscribed to: traffic splits across independent lanes by a fixed, verifiable rule, so a mining cluster can spread the load. A service-provider account takes it whole. This stream is sized for mining operations, which is why an application account never carries it.
The proof input
Subtree data as the network carries it: for assembly and validation at speed on the mining side, and as the input a proof service builds from on the service-provider side.
Announcements & contents
Block announcements and block contents as the network carries them. A broadcaster's proof service on a service-provider account receives them by arrangement, without the right to publish them.
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. Which topics ride your object lane is not asked for on the request. You join and leave them yourself, at any time and without re-provisioning, from the Topics box on your tunnel in the console. That box is the whole list rather than a queue of changes: whatever is in it is what gets delivered, so removing a line and saving is how you leave a topic, and saving it empty is how you stop object delivery altogether. Until your first topic is joined, the lane delivers nothing and bills nothing. Publishing through the public door is free and needs no account. A published object may name up to 15 topics and every name travels with it; the public door delivers it on the first topic and an authenticated connection on the first three, the rest riding along as labels. There is no charge for naming topics. Published as open standards: BRC-148 & BRC-149; the design is in The overlay object plane.
The reference to verify against
A compact feed of block headers as the chain advances: what your service checks proofs against. A miner assembles blocks and already holds them.
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 moves back once the original side has been healthy for a few minutes.
- Switching sides Switch the active side yourself from the console at any time. The switch takes effect within about a minute, needs no new config and no rebuild, and is fully reversible, so it is the safe way to rehearse a failover.
- Re-key and revoke Both are self-service on the tunnels page of your console, and we hold only your public key. To re-key, generate a fresh pair and submit the new public half; keep the old interface up until the new one handshakes, since the old key keeps working for the few minutes the change takes to reach the network's edge. Revoking a tunnel is immediate.
Run your existing stack on it
You don't have to build against the network to use it. Delivery lands beside software you already run, through small open-source bridges that turn a delivery lane into the interface your stack already speaks. Both are Apache-2.0 and change nothing inside the upstream software.
teranode-bridge
Runs beside an unmodified Teranode cluster: the settlement lanes terminate on the landing machine and are pushed into the cluster the way it expects, on a normal box or inside Kubernetes.
arcade-bridge
Runs beside an unmodified Arcade v2 and merkle-service stack, in two halves: proofs come down the tunnel, and broadcast goes up once.
- Proofs come down the tunnel The subtree and block objects the network delivers (block data by arrangement on a service-provider account) feed merkle-service's own announce-and-fetch pipeline on your own machine, so the ingest it would otherwise pull across the wide area is served locally. Discovery stays on: if the bridge stops, your stack falls back to its ordinary peer-to-peer and datahub paths with no proofs lost.
- Broadcast goes up once The bridge presents the same submission interface Arcade's propagation already speaks, so a batch enters the network as a single submit and reaches every miner on the fabric instead of one copy per datahub. Pointing Arcade at it is one configuration line; its per-transaction verdicts, retries, and lifecycle are unchanged.
- You pay for delivery, never the bridge No license check, no metering inside it, and a bridge with no delivery lane to receive on has nothing to do. The full design, including where a stock broadcaster over ordinary unicast remains the right answer, is in Arcade v2 on a multicast delivery fabric.
Usage, statements & billing
Volume-only: you pay for what is delivered to you, and nothing else.
- What counts as delivered We count each object as we write it to your tunnel, and we count the bytes you receive: the transaction, the object, the block header. Our own framing is not counted, and neither is anything we could not deliver to you, so the bytes your side records are the bytes you are billed for. If a connection drops and we re-send an object you may already have had, you are not billed for the repeat.
- 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: it stays connected and keeps handshaking, and only the traffic stops. Keys, addresses, and placement are all kept, and delivery resumes automatically once no invoice is overdue. 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.