Making the Call

The Tech Behind Our PolySwarm Arbiter




PolySwarm is a threat detection marketplace where antivirus companies and enterprises can expand and improve their protection coverage against new threats, based on Ethereum smart contracts. In our previous blog Making the Call: The First PolySwarm Arbiter described how Hatching became PolySwarm’s first arbiter and we took a high-level look at arbitership in general. In this blog we will dive deeper into the technical side of our arbitership. We will describe the process all the way from listening for bounties through to casting our vote.

This blog assumes that the reader has basic knowledge on how a blockchain functions. If you feel like your knowledge is a bit rusty, you might want to check this article on blockchain first.

Technical Side of Arbitership

The Hatching Arbiter interacts with PolySwarm via a web service called polyswarmd. This service acts as an interface to the blockchain so that our arbiter does not directly need to deal with implementation details. It does so by providing a REST-like API that fetches and helps to publish the data. Blockchain events are sent in real-time using a WebSocket using simple JSON messages.

Event-based processing is an important part of the Hatching Arbiter implementation, since there are many asynchronous processes occurring at the same time. Many of the events described in the workflow below are both time-based (based on blockchain block progression) and dependent on the completion of a previous step. And since (network) errors are inevitable in a distributed system, retry logic is required to ensure smooth operation.

The Workflow of a bounty

A new bounty is announced the via WebSocket and is recorded by the Arbiter.

Visually, the workflow of the arbiter looks something like this:

All blockchain interactions (e.g., voting and settling) require a cryptographically signed transaction to take place. Only the Arbiter has access to the signing key. The Arbiter uses polyswarmd to format JSON-based requests as proper blockchain transactions. The transaction is then signed by the Arbiter and sent to for publishing.


The event-driven architecture of the Hatching Arbiter ensures a smooth operation, as it can deal with processes that are time-based as well as processes that are dependent on the completion of a previous step.

Because we can rely on polyswarmd to handle the implementation details, our arbiter can be much leaner than it could have otherwise been. This also lowers the entry barrier for other arbiters that want to join PolySwarm’s movement and help out. The last blog of this series will, therefore, focus on how one can become an arbiter, as we believe it is important for the development marketplace to have multiple arbiters.

You may also like: