5.6. Watchtower and Book aggregator
The order package preceding a swap is a message that might need to be relayed throughout the network before reaching a match. This would take time and resources and expose the relayer nodes to spam attacks. For this reason, nodes may subscribe to “watchtower” services, which perform a quality check for their subscribers. A watchtower stores the DHT and a few additional pieces of information provided by nodes connected to them to report the latest status of orders.
A watchtower checks the status and the frequency of the operations to create a rank, which increases according to the number of finalized operations, i.e., when both users involved confirm that a swap was successfully achieved. The watchtower cross-checks the DHT order book with the subscribers’ data, proving that the transactions are successfully executed. If the trade happens through an atomic swap, the watchtower also performs blockchain analysis to determine each user’s reliability.
A watchtower ranks the user and their associated orders, communicating information to each subscriber about the estimated reliability of a particular order/node, reporting spam, and notifying closed or pending orders from inactive peers. It may also relay orders to the subscriber after they have already been filtered according to their interests and sorted according to ranking. Wallets can accept or reject connections with other peers based on their reported reputation. This way, users syncing the DHT may leave aside useless data or decide not to initiate a particular swap transaction if the counterparty is not “verified” by the watchtower.
A watchtower could require a payment fee for its services. However, in theory it could also operate for free if, for example, it is operated by an entity that somehow benefits from developing a reliable DEX, like a service provider that monetizes complimentary services connected to the DEX. Moreover, given that the watchtower privately gathers data from users, it also disposes of more resources for elaborating DEX statistics, which may have an economic value or grant reputational value, allowing further monetization through advertising, for example.
A watchtower also collects information such as price and timestamp about orders that led to successful swaps. Keeping track of this data may facilitate the calculation of each pair’s price ratio on the DEX: not only estimated values from the order book but actual prices of the last exchange performed on-chain.
Relying on a watchtower’s services does not require much trust: even if it is shut down, communication between peers is not interrupted, nor does the watchtower influence the swaps that are going to be performed; it only facilitates communication between peers. The trade-off is some loss of privacy since the watchtower can distinguish on-chain transactions associated with atomic swaps in the DEX, thus flagging them as belonging to a particular owner and tracking down each ownership transfer.
A more invasive solution to avoid the drawbacks of a DHT constructed in a peer-to-peer fashion is to trust special relayer nodes that act as book aggregators, store the DHT and broadcast the orders on behalf of the users. This would be particularly helpful for light node/mobile wallet users as they may not have time and resources to sync many megabytes of orders or sort and filter them.
When users intend to exchange tokens, a Sequentia wallet can use bloom-filters to ask a book aggregator for orders matching a specific trading pair. Then, relayer nodes provide an answer – a list of all the orders in the network that may be of interest (in terms of price and amount), already filtered or ordered according to rankings. It also combines matches between simultaneous online users, directly suggesting how to initiate atomic swap transactions and what parties can be involved. When a wallet finalizes an order for an entire amount, the book aggregator is notified so that no more matches are proposed.
Book aggregators can be paid using three specific fields in the order package:
feeRecipient: the address of the book aggregator;
feeToken: the token used to pay the book aggregator;
feeAmount: the fee amount sent to the relayer.
Given that book aggregators centralize the communication system in a single entity, no exchange can happen if the aggregator is shut down until nodes find an alternative book aggregator or start syncing the DHT on their own. However, aggregators might also be highly efficient in finding matches and achieving a prolific market of exchange transactions.
The essential difference between a book aggregator and a centralized exchange is that:
It is a non-custodial solution;
the trading engine remains a trustless atomic swap or lightning swap;
users identify themselves using pseudonyms.
There is no correct choice between a DHT synchronized independently or a book aggregator; the best solution depends on the degree of trust the user is willing to give third parties and the confidentiality required for their trades.
Last updated