Payment protocols in a multi-registry construction

Nobody has claimed this yet.

In a multi-registry construction, each service registry can define its own payment contract which specifies the rules of how an orchestrator can settle payments sent by a broadcaster. Examples of payment contract implementations include:

- A probabilistic micropayment TicketBroker that allows orchestrators to redeem winning tickets
- A payment channel manager that allows orchestrators to use the most recent payment message for on-chain settlement as a part of a hub-and-spoke payment channel architecture

Some benefits of having separate payment protocols for each service registry include:

- Not tying the broader Livepeer protocol to a single global payment protocol
- Allowing payment protocols to evolve faster without requiring global coordination for an upgrade
- Allow broadcasters and orchestrators to opt-in to payment protocols based on their own preferences. Broadcasters and orchestrators that want the simplest setup with no additional infrastructure operated by third parties could use a service registry that uses PM for payments. Broadcasters that want to avoid capital lock up costs, that are willing to rely on additional infrastructure operated by third parties and that want to pay in an alternative currency (perhaps not even a cryptocurrency and instead a fiat currency like the US dollar) could use a service registry that uses a payment channel hub that offers currency exchange services

Below is an initial sketch of what the integration of different payment protocols in different service registries might look like:


No files, tests, or implementation entry points are identified in the issue. It presents an initial architectural sketch for registry-specific payment protocols, but does not define a concrete change or completion criteria; further design discussion would be needed before implementation can begin.

Written by the indexing model from the issue text.