Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Network & Protocol

Arcade is helping make one part of the developing Teranode architecture easier to understand: how an application gets a transaction into the network and then follows what happens to it.

The project is a transaction-broadcast service designed specifically for Teranode.

From the application side, Arcade deliberately keeps an Arc-compatible HTTP interface. A developer can submit a transaction through a familiar API rather than redesigning an application around the internal structure of Teranode.

What happens behind that interface is different.

Arcade first receives and locally validates the transaction, then submits it toward Teranode. From there, it follows the transaction through a series of observable states.

A transaction can move from received, to sent to the network, to acknowledged by Teranode. Arcade can then hear the transaction appearing through subtree gossip and later through block gossip when it is mined.

It also listens for rejected-transaction messages, including rejection associated with a double-spend attempt.

That is why the project describes itself as P2P-first.

Rather than relying primarily on a node to call back and report what happened, Arcade listens directly to the network information Teranode nodes are already exchanging about subtrees, blocks, and rejected transactions.

The application does not need to understand those messages itself. Arcade turns them into transaction status information that can be queried through its API or delivered through webhooks and event streams.

The project also connects broadcasting with transaction evidence.

Transactions can be registered with Merkle Service, while Arcade maintains block-header information through go-chaintracks and can validate Merkle proofs against the header chain.

This gives the broadcast layer a wider responsibility than simply forwarding transaction bytes.

An application needs to know whether a transaction was accepted, whether the network has seen it, whether it was rejected, whether it reached a block, and eventually whether the evidence supporting that status can be verified.

Arcade is designed to provide that lifecycle around Teranode while allowing existing Arc-style applications to migrate without replacing their entire broadcast interface.

Its deployment model is also intentionally lighter than Arc. The current implementation can operate as a single Go service with local storage, rather than requiring the PostgreSQL and NATS infrastructure associated with a full Arc deployment.

That does not make Arcade a replacement for Teranode itself.

Teranode remains the node infrastructure processing and propagating transactions. Arcade sits between applications and that infrastructure, handling submission, tracking, notifications, and proof-related services in a form applications can readily consume.

Nor should the project be read as a new Teranode performance result. Its own documentation says broader P2P benchmarking remains future work, with current development focused on correctness and stability.

What Arcade makes visible instead is an architectural transition.

Applications can retain a relatively simple transaction-broadcast interface while the network behind that interface becomes more distributed and Teranode-specific. Transaction status can increasingly be learned from the network’s own P2P activity rather than from a single callback path.

That is a quieter infrastructure change, but an important one if Teranode is to become something applications can use without needing to understand or operate every part of the node architecture themselves.

Source: Arcade — GitHub · Teranode — GitHub

Update — September 9, 2026