Pre-Proposal: Confluence Protocol Upgrade


One of the biggest problems facing the Livepeer network today is high gas fees on L1 Ethereum which has made it difficult for orchestrators to earn/distribute LPT rewards, for delegators to delegate stake to orchestrators and for broadcasters to use the network without locking up a large amount of capital (the amount of capital that needs to be locked up by a broadcaster for the current probabilistic micropayment protocol implementation rises with gas fees).

This post outlines ideas for a protocol upgrade with the top priority goal of reducing gas fees on the Livepeer network by migrating protocol contracts from L1 Ethereum to a lower cost domain (i.e. L2). The current proposed name for this protocol upgrade is Confluence which is also the name of the next network phase after Streamflow described in the original Livepeer network phases blog post.

Confluence Updates

The list of candidate updates for Confluence currently includes:

The rationale for bundling multiple updates into Confluence is that completing these updates together in a single protocol upgrade can create a bigger impact than executing the updates separately and because a migration to L2 will require a new contract deployment anyway so we can take advantage of the opportunity to make updates to contracts that would otherwise be more technically difficult to do if we had to upgrade already deployed contracts.

Please direct feedback for the individual updates to their respective pre-proposal forum threads. Any feedback on the scope of updates to include in Confluence can be included in this forum thread.

Next Steps

  • Get community feedback on the scope of the updates to include in Confluence
  • Get community feedback on the individual Confluence updates via the pre-proposal forum threads for each of the updates
  • If the ideas for the pre-proposals are validated and receive community support, create draft LIPs for the individual updates and a draft bundle LIP for Confluence

In the OP, I noted the following:

The rationale for bundling multiple updates into Confluence is that completing these updates together in a single protocol upgrade can create a bigger impact than executing the updates separately and because a migration to L2 will require a new contract deployment anyway so we can take advantage of the opportunity to make updates to contracts that would otherwise be more technically difficult to do if we had to upgrade already deployed contracts.

After some consideration, I think it could make sense to exclude the new StakingManager (and thus multi-delegation, improved earnings accounting implementation, etc.) from Confluence and instead consider it as a part of a post-Confluence LIP. The main reason I am suggesting this change is that the new StakingManager would increase the technical scope of Confluence pretty substantially since it would include multi-delegation support as well as a refactored earnings accounting implementation. For a security audit, it will likely need to be treated as a completely new contract which not only increases the surface area for bugs, but also increases the amount of time/effort that should go into the audit. If the focus of Confluence is instead the L1 <> L2 migration then, while there would still be new code introduced, the majority of the already audited code used on L1 could be re-used on L2. As a result, the amount of new code that would need to be audited would be substantially reduced relative to if the new StakingManager is included in Confluence. Of course, the proper steps to make sure the Confluence upgrade is performed security would still be undertaken, but less new code to audit would just reduce the required time for these steps.

With this in mind, the current upcoming milestones I see:

Note: The work for the “Complete Implementation w/ L2”, “Confluence LIP” and “Benchmarking” milestones will occur in parallel since the implementation w/ L2 will inform the final content of the Confluence LIP and will also enable benchmarking.

Complete Implementation w/ L2

The goal here is to complete an implementation that supports:

  • L1 <> L2 stake migration
  • All protocol transactions on L2 including rewards/fees distribution and probabilistic micropayment ticket redemption

For more details on the above, see this forum post.

One of the most commonly asked questions is which L2 will be used? This milestone will establish the L2 to be used.

While finalizing the L2 to use for Confluence will not occur until sufficient progress is made on the implementation for this milestone, the candidates that will be considered can be narrowed down based on not only their security/performance properties and adoption, but also on the following criteria:

  • EVM compatibility. The reason for focusing on this is to support as much developer tooling as possible so that we can reduce the engineering effort and thus time required to access cost savings from L2
  • Project roadmap. The reason for focusing on this is to ensure that the L2 used will be continuously improved to continue to bring cost savings for protocol transactions
  • Expected level of maturity + amount of production usage by the time Confluence launches. The reason for focusing on this is that while there are a lot of exciting new advancements in the L2 being made consistently, there is a non-trivial chance of outages + breakage in the early days immediately following the beginning of production usage

Given the current L2 landscape and the above criteria, the two main L2s that are being considered closely are Optimism and Arbitrum (and initial prototyping has already occurred with Arbitrum). The main reason that the choice of L2 hasn’t been top priority previously is because extra attention was paid to how the migration process would work and identifying a process that could potentially be re-used in the future to allow the protocol to continue to adapt to the evolving blockchain scaling landscape (meaning that any additional cost savings available in the future can continue to be accessed).

Work here is underway.

Confluence LIP

In order for the Confluence protocol upgrade to be executed, a Confluence LIP must be approved by the community. The first step here is to create a draft LIP. Then, as the implementation is worked on, the content of the LIP will be finalized. From there, the LIP will move through the rest of the LIP process i.e. the Last Call period followed by a poll that orchestrators and delegators can vote in to approve or reject the LIP.

Work here is underway.


As the implementation is worked on, we should be able to use the gas usage benchmarks for the contracts based on execution on the L2 along with historical gas price data from the L2 mainnet in order to estimate the expected transaction cost for the contracts if they were deployed on the L2 mainnet. The goal will be to re-run benchmarks as implementation continues and share them so that we can get a sense of the transaction cost savings to expect on the L2 even if they are just initial estimates.

Work here to commence soon with some more progress on implementation.

Public Testnet

Once the implementation is feature complete, a public testnet can be launched. This will be an opportunity to thoroughly test the implementation not only via formal test procedures, but also through the open participation of all community members. Once the public testnet is up and running, broadcasters, orchestrators and delegators will be able to test the L1 <> L2 stake migration and also submit L2 transactions in order to become familiar with how everything will work after mainnet launch. As the launch of the public testnet gets closer, there would be additional communication and coordination to support the participation of community members.

Security Audit

As testing occurs on the public testnet, a security audit would be completed for the contracts in order to ensure that user funds are safe for a mainnet launch.


After sufficient confidence in the security of the implementation is established via the public testnet and security audit, the mainnet launch would occur if the Confluence LIP is approved by the community.


Since the update to the Confluence roadmap to focus on L2, there has been some additional design discussion for the L2 migration design in Pre-Proposal: L1 <> L2 Migration Workflow - #6 by NicoV.

Additionally, I’ve created two draft LIPs based on the ideas in that linked thread and I’m including the links to their respective discussion threads below:

1 Like

Simple question: will this upgrade help to prioritise the work to upgrade the protocol on rinkeby testnet to align with what is deployed on mainnet right now? I can envisage some kind of community “bridgenet” emerging, and if so, I am keen to support activity in launching and testing this.

Yep once the initial implementation is complete, the plan is to setup a testnet with contracts deployed on L1 (which would align with what is deployed on mainnet today), contracts deployed on L2 and a bridge that facilitates token transfers as well as stake migration. Stay tuned for more updates!

1 Like