Pay & Protect

Payment demands

Peers participating in a transaction deposit their funds into a shared multi-signature account—one that requires two out of three possible signatures to authorize a payment. This shared account serves as a secure escrow, ensuring that no single party can unilaterally release or claim the funds without cooperation. A scheduled transaction tied to this account can include payments to various involved parties, such as the service provider, the network’s treasury accounts, and any designated validator or group of validators who oversee the transaction’s fairness.

When one party wishes to draw from the shared account, they create a scheduled transaction and then request the other party’s signature. This request is communicated via the other party’s standard input topic, signaling that the funds are ready to be released pending their agreement. If the other party believes the terms of the Service License Agreement (SLA) have not been met, they may refuse to sign. In such a case, the validator—having the third signature—can step in, verify the claims against the SLA by inspecting message flows, and provide the remaining signature if the transaction is indeed valid. In this manner, the multi-sig structure, coupled with scheduled transactions and validator oversight, ensures transparent and fair fund distribution in line with agreed-upon contract terms.

Protect

Validators play a critical role in ensuring the integrity and fairness of the network. They continuously monitor network traffic to verify that peers are following the agreed-upon protocols and SLAs. In cases where disputes arise—such as disagreements over whether certain messages were sent on time or whether the correct sequence of steps was followed—validators can perform targeted, on-demand reviews of the message logs. Through this continuous and conditional oversight, validators help maintain trust, as all parties know that an impartial, verifiable mechanism exists to confirm what actually transpired on the network.

At a minimum, every validator must be equipped to handle the core set of messages related to connectivity and basic operations. This foundational messaging layer is uniform across all dApps, ensuring that validators can reliably assess network health and peer availability. The underlying SDK provides this capability out of the box, simplifying the validator’s role in basic network oversight. For any additional, dApp-specific monitoring requirements—such as custom SLA checks or specialized transaction verifications—dApp developers must implement and integrate their own logic. This division of responsibilities ensures that all participants share a consistent baseline of network assurance, while still allowing each dApp to tailor validation to its unique needs.

Consensus

Consensus in this system is not rooted in a complicated, stand-alone mechanism; rather, it emerges naturally from the shared ledger of messages. When participants select a validator or a set of validators, the process can be as simple as choosing a single trusted party or electing a group of validators. In the case of a validator group, they rely on majority consensus to make decisions. Crucially, the ledger of topic messages provides a reliable and tamper-evident record, allowing all honest validators to reach the same conclusions by independently inspecting the message history and applying the same agreed-upon interpretation defined in the SLA.

Because the topic functions like a ledger—complete with ordered messages, timestamps, and running hashes—validators do not need to operate their own consensus protocol. They simply observe the topic, apply the SLA rules, and derive consistent interpretations of events. This means that coordination between validators becomes minimal. If all honest validators use the same SLA logic and message interpretation, they will arrive at the same outcomes with no need for extensive inter-validator communication. They can trust the topic’s structure and data to guide their conclusions, reducing overhead and complexity.

When it comes time to finalize decisions, validators only need to record their conclusions or sign off on a scheduled transaction. Even in a group setting, this step is not about reaching a shared interpretation—since that should already be guaranteed by following the same SLA rules—but about securing and publishing their collective signatures. Each validator independently forms a view of the situation, and if the SLA requires it, they all sign a scheduled message. This signature collection step ensures that the decision is verifiably endorsed by the required majority, but it does not demand the validators coordinate their reasoning or debate the correctness of their interpretations.

It is also important to note that validators do not have to “sound the alarm” at every breach of an SLA. In many business scenarios, participants may prefer to continue working together or pay out as normal, even if some conditions were not perfectly met. The validator’s role is to provide a reliable mechanism for resolution if and when the parties choose to enforce the SLA. Until then, participants can agree to overlook minor discrepancies and carry on, knowing that the system remains transparent and that the option to involve validators is always available if disputes escalate.