Engineering papers
The analysis behind the network: how transaction and block delivery actually scales, where the pull model breaks, and what the 1BSV multicast fabric does instead. Written for Teranode operators and engineers; grounded in stated, checkable arithmetic.
Pushed delivery into a Teranode cluster
The delivery contract: how the sharded multicast fabric feeds a multi-node Teranode cluster over unicast TCP with no hardware load balancer. Push frame formats (BRC-143 subtree, BRC-144 block), distribution and failover mechanics, and the Teranode-side ingest work, gap by gap.
The Asset service at scale
Why fronting DataHubURL with a CDN extends the gossip
problem instead of solving it. Walks the announce-then-pull model up
the throughput ladder from 10 k to 1B TPS, shows where origin
egress, concurrency, and the block race break, prices the CDN offload
network-wide, and sets out the multicast-fabric alternative with
white-label co-branded anycast ingress.
The cost of being reachable
Transaction-intake economics for Teranode miners. Prices every route to global reachability: self-built anycast, DNS steering, and rented edge reach by the gigabyte or the megabit, then sets out the 1BSV model where admission is free, delivery is the paid product, and identity survives every tier, up to your own address block announced on your behalf.
Landing in Kubernetes
The Kubernetes-native shape of pushed delivery: the consumer end of the tunnel terminates inside the delivery bridge's own pod and reaches Teranode over ordinary ClusterIP Services. No routers, no BGP session, no load balancer, no inbound firewall rule, and Teranode itself unmodified; closes with the cases where a separate landing box is still the better answer.
Shard bit extraction
How a transaction finds its multicast group: the one-line big-endian top-bits derivation, why it beats a modulo (widening splits groups instead of reshuffling them), the BRC-129 address layout the index lands in, and the BRC-148 generalization that runs the same rule on every object plane.
The overlay object plane
Publish a BEEF object once and every overlay host subscribed to its topic receives it at the same moment, verbatim, proofs intact. A dedicated multicast plane for overlay objects (BRC-148 and BRC-149): topics as the delivery primitive, loss repaired by the network, verification kept at every subscriber, and what an application architecture stops carrying. Closes with the 1BSV early-access lane and where the meter sits.
Arcade on the multicast fabric
Running the unmodified Arcade v2 broadcaster stack with the fabric
as its transport. One submit reaches every miner on the fabric
instead of a POST per datahub, and merkle-service's proof ingest is
served on the landing machine instead of pulled across the wide
area. Covers the open arcade-bridge, deliver-once
co-location, upstream asks, and when stock Arcade over unicast
remains the right answer.
The overlay bridge
Running an unmodified overlay services engine with the object
plane as its transport. Delivered objects enter the engine as the
submit it already serves, publication goes out once through a
facade instead of the engine's host-by-host propagation, and the
header lane becomes the chain tracker the engine verifies against.
Covers the open overlay-bridge, the pre-flight
checklist, the two ways of switching propagation off, when stock
propagation remains the right answer, and the upstream changes
that would tighten the fit.
The bstack: publish once, prove everything, and let users ride free
The pattern language behind a family of applications we call the bstack. State travels as Bitcoin transactions that prove themselves, a multicast network publishes each one once to every subscribed host, and hosts become interchangeable replicas that compete on service instead of custody. Covers the open BRC standards the patterns compose, the transaction and delivery shapes, and the economics: free participation at the edge, delivery metered like a utility in the middle, revenue at every tier that serves an audience. The plain-language overview is the quick read; the paper is the rigorous one.
Sharding the object plane
Every application's overlay objects can ride one multicast plane, and no application wants more than a sliver of it. The leading bits of a topic's hash turn that one firehose into lanes the network itself can forward, prune, police and peer, and a lane nobody joined is never sent. Covers why the object plane is sharded, the join budget that keeps it narrow, why nothing in the network scales with the number of topics, topics as addresses a receiver computes, and how operators peer the plane at the network, tunnel or application layer. The companion to Shard bit extraction.
The data carrier
Data published with Bitcoin can be checked by anyone, whether or not it was ever mined. This paper walks through that check one picture at a time: what simplified payment verification actually proves, the difference between data verifiable on chain and off chain, where payments attach to each, and why a network that delivers every publication to many recipients at once may carry data only in transactions that cannot be mined. Closes with a complete third-party verification, eleven steps laid out one by one, and with what SPV cannot tell you. No Bitcoin background is assumed.
These papers build on the open BRC specifications listed under Standards. Each application built on the bstack patterns has a short brief in the bstack pattern series, under Patterns. Questions, corrections, or integration conversations: 1bsv@lightweb.net.