<aside> đź’ˇ
The Payments Clearinghouse is Part 1 of the Livepeer: Weir proposal.
</aside>
This document proposes a payment proxy mechanism for Livepeer, here called a clearinghouse. This clearinghouse would work on top of the existing Livepeer probabilistic micropayment (PM) system, signing PM tickets on behalf of gateways, while maintaining a running balance on behalf of those gateways. The clearinghouse could then settle the balance with its users in currencies such as USD, or draw down an account for grant recipients or other special-purpose entities. There would be no change to the core gateway-to-orchestrator payment flow, which would still happen with PM and settle via Eth. This approach also improves gateway security by separating out the payment signing key from untrusted media flows.
How is it done today, and what are the limits?
The Livepeer probabilistic micropayments (PM) system has been a success since its introduction in 2019, securing millions of dollars of value transfer on the Livepeer network. While PM has been proven at scale, there are a few issues with the scheme that have slowed wider adoption of Livepeer:
PM is built on top of Ethereum smart contracts, with Eth as the underlying currency of exchange.
Cryptocurrency still has a stigma among the wider public: individual developers who would otherwise be interested in Livepeer might find the crypto aspects unappealing.
Crypto is difficult for organizations to adopt from an operational perspective, because crypto does not easily fit into existing purchasing flows, and many organizations are not equipped to properly manage hot wallets.
The design of PM is intricate and there are good reasons for its complexity, however this makes it harder for ordinary developers to integrate, even if these developers are crypto-friendly. There are many concepts to learn when setting up a Livepeer gateway with PM: the reserve and deposit amount, calculating expected value of tickets, the impact of gas, etc. At volume and as the network grows, the PM reserve balance may grow large, and this idle capital cannot easily be put towards other uses. Moreover, the friction in committing and withdrawing funds due to the unlock period discourages PM usage for one-off scenarios.
The factors of cryptocurrency and PM complexity, among others, have led the Livepeer network to centralize around a few large “gateway providers” that smooth over integration with the Livepeer network, including payments. Providers can then run customer billing in local currencies. However, these gateway providers are not structurally aligned with the network, and could just as easily take traffic away from the network as they could bring it. They may not always support the payment schemes that customers prefer. Customers also cannot control where a gateway provider is located or the features that they support.
Currently, the gateway must hold the payment signing key in the same process that manages untrusted media coming from users. This is a security risk, as an exploit stemming from processing untrusted input could result in the compromise of the payment signing key and lost gateway funds. Moreover, the design of PM leads gateway providers to share a common key for all gateway instances, which increases the blast radius of any compromise.
Livepeer special-purpose entities often request LPT from a community Treasury for the purposes of funding network usage. This is places an additional integration burden for SPEs that prefer to operate their own gateways: they must perform LPT → ETH conversion (including managing any tax liability from that), and locks up some of their funds via PM reserve / deposit, and manage Eth secret keys. Moreover, the community has limited visibility into how this granted LPT is spent and how much actually goes to network usage.
And how it will be successful