TL:DR;
Send ARC extended format transactions, it will validate
locally and then broadcast over the p2p network, managing
state. It will ping you when tx is seen by a peer, and again
when mined.

If you’re looking for a new way to process transactions on the Bitcoin network, look no further than ARC. ARC is a transaction processor that uses a new, yet straightforward Extended Format to make transaction validation faster.

The new service covers 3 use cases: Miners running ARC instances as an on-ramp for transactions, Applications integrating with the endpoints to submit transactions, and, in the future, the possibility to build a transaction processing service. To learn more about using ARC as a service provider, head over here.

In this article, we’ll go through the steps required to implement ARC in your application.

What does ARC change for BSV app devs?

At first glance from an application developers perspective, sending transactions to ARC may seem a lot like mAPI. However, there are a few key differences which will become important as we scale.

Firstly, when you send your transactions to ARC it will broadcast them using p2p protocol messages over the node network itself. This is different from mAPI, where transactions are sent to a single SVnode instance via json-rpc. That bottleneck in mAPI is currently only apparent when the node is performing a deep reorg, but it’s there waiting to reveal itself at a certain tx/s. ARC circumvents this bottleneck entirely by acting like an ingress buffer around the nodes.

ARC maintains a database of transactions it has been sent. It will rebroadcast them if not explicitly acknowledged by SVnode peers, updating their state as they propagate the network, and eventually get mined. This allows applications to focus on their own business logic, rather than having to worry about ambiguous transaction state.

ARC uses a new transaction encoding format called Extended Format. Its purpose is to allow transaction validation using provided data only. The standard raw transaction format is extended by including the satoshi value and locking script for each input. This allows ARC to evaluate each script and check fees, prior to broadcast, without having to request additional data from a node. This makes the broadcast service faster, and much more scalable.

How can my app use it?

Fundamentally you can just switch to an ARC endpoint for broadcast, and send Extended Format rather than rawtx. Both TAAL and Gorilla Pool currently run instances on mainnet. TAAL also run a testnet instance. There is a TypeScript client available which is a good way to get started.

For Go developers the extended format is built into go-bt already. If you are working with JavaScript or TypeScript, there is a new library you can use for conversion between formats – grabbing any missing data from WhatsOnChain.

ARC is currently in public beta, so please expect occasional unexpected behaviour, and raise any issues discovered in the public repo for resolution.

Should I run my own ARC instance for my app?

The vision is for businesses that submit large volumes to run their own ARC instances. Today this is not advisable as the peering logic within the SVnode in practice does not prioritize ARC peers. SVnode does not currently distinguish between full nodes and SPV nodes which it connects to. Because they do not produce their own blocks, ARC nodes aren’t ranked high on a peer priority list and so will be dropped as more peers fill the available bandwidth.

Additionally, a single invalid transaction sent over the p2p network is grounds for the originating peer to be banned by others. In future we anticipate a performant UTXO lookup service which would allow for full tx validation prior to broadcast, at which point there would be no such risk.

For now, ARC instances are hosted by miners on the BitcoinSV network who whitelist the peer connection to their own nodes, which allows the architecture to be rigorously tested in a public beta phase while further developments are made in SVnode to allow for persistent SPV peer connectivity.