The Service Completion Oracle

A solution to this problem is easier to find if one assumes the existence of a Service Completion Oracle - a hypothetical mechanism that is able to truthfully determine whether the service has been completed.

A relay message sent in one direction would work as follows:

• Alice sends a relay packet to Bob (via the node assigned to Bob), along with a locked payment that can only be unlocked by a key provided by the delivery oracle.

• After some time passes, Bob's assigned node delivers the relay to Bob.

• Bob's assigned node then asks the oracle for the key to Alice’s payment.

• The delivery oracle determines that relay has been successfully completed, and gives Bob's assigned node the key, allowing it to redeem payment.

Sylo Ticket, Front-running, and Penalty Escrow

Probabilistic micropayments, such as our Sylo tickets, neatly fill the role of the locked payment. Escrow posted on-chain by Alice acts as proof of future payment, and the service consumer's random number is a key which enables a ticket to be redeemed (unlocks payment) without further input from the consumer.

Alice must also post a small amount of penalty escrow, which is forfeit if a valid ticket ever fails to be redeemed due to insufficient funds. This acts as a disincentive against Alice withdrawing her funds before Bob's assigned node can claim them - it makes paying for the service the least expensive option for Alice, and ensures that Bob's assigned node will receive the payment it is owed.

This means that the problem of incentivizing any particular decentralized service can be reduced to the problem of filling the role of the service completion oracle for that service. In what follows, we will illustrate this using the Sylo Network's main service, Event Relay, as an example.