LIP-73: Confluence - Arbitrum One Migration

Thanks Yondon,

We agree with @Titan-Node and @vires-in-numeris concerning the tradeoff with the snapshot and the delay before delegators can claim.

Thats seems definitively to be the better solution.


hi Vires, I am Amit from Australia and new to LPT. I delegated 255 token on your link but my metamask wallet account got hacked and now all my LPT has been unstacked, which is due to be unbounded in 7 days. The thief has my meta mask key and has stolen $20k worth of token and my only hope is to get some help from you to resolve this. As the thief now has the secret phase therefore can transfer token from LPT to his account as soon as they are available to withdraw. is there anything we can do to stop it. I can prove the token were stolen as I pad around $12k in cash on Coinspot

in Australia. Is there anything you can do to help. My public key is as below.


sorry everyone on this post. I don’t know how to contact Vires in private. Apologies, but i am looking for some support here. I have lost 3 years worth of hard earned money within seconds due to a hack. Is there any community support available. I will truly grateful if someone can please support. The Metamask team is not responding and I guess will not respond as it was hack on their wallet

Hey Amit, sorry that happened to you. Unfortunately, it’s not in my (or the Livepeer team’s) power to do something here. Your tokens are in the staking contract and can only be controlled by your own address.

That said, there might be some solutions for your problem…

For your staked LPT: I see that you rebonded your LPT with this tx: Ethereum Transaction Hash (Txhash) Details | Etherscan
And at the moment, there is not enough ETH left on the account to send another unbond tx. So the attacker would need to send some ETH to the wallet first before he/she/they can initiate the unbond again - which they probably won’t do.
Now the issue is that they might run a bot that automatically scrapes all the ETH that you send to this address, so your LPT is essentially stuck. A possible solution might the the upcoming L2 update. It would automatically move your stake to an L2 (probably Arbitrum) where you’d have to claim it. It’s likely that the attackers don’t know that. So once the update happens, you could recover your LPT on the L2 where the attackers won’t check. Until then you’d have to regularly check that the attackers don’t send another unbond tx.

If they do that (and I see that you also have some GRT that is unbonding…), the second solution could be flashbots:

They have a whitehat service that tries to retrieve tokens from situations like yours: whitehat hotline | Flashbots Docs It basically works by bribing the block producers to execute your tx first. It’s best to fill in the form in the link provided and then join their discord to discuss further.

And for the future please ALWAYS use a hardware wallet as soon as it would hurt you if you lost the $ amount of crypto that you’re handling. If you have any other questions you can find me in the livepeer discord: vires-in-numeris#5324 (check the number as well and watch out for scammers, I won’t DM you first)


If the delay is only a week or two, that’s fine. But we need to make sure that we’re not talking months

The current idea is for the delay to be around 7 days (exact timing TBD, but around this duration).

since O’s can’t receive new stakes (and no new withdrawals can be started?) during the delay.

Just for the sake of clarification - technically, a O that migrates to L2 before the snapshot delay period is over can receive stake delegation if a delegator transfers liquid LPT to L2 and stakes directly in the L2 BondingManager.

Additionally, also worth noting that even with the snapshot based claim on L2 for delegators we’ll need to have support for delegators to submit a L1 tx to migrate their stake to L2 without using the snapshot to handle the scenario where a delegator is a contract (i.e. a multisig). Since L1 contracts do not necessarily exist at the same address on L2, a delegator contract would not be able to claim stake on L2 since the contract does not exist on L2. The solution to this problem is for the delegator contract to submit a L1 tx to migrate stake to L2 with the stake owned by a specified existing address on L2. I mention this because given support for this feature, another way for an O to receive stake delegation before the snapshot delay period is over is if a delegator chooses to migrate its stake to L2 on its own. However, unless a delegator is a contract, it could make sense for most delegators to just wait through the snapshot delay period in order to claim stake directly on L2 which should be cheaper since it doesn’t incur L1 tx costs.

Will it be a problem in the long run that we’ll probably have some LPT in those contracts for a long time (due to inactive stakers)? Thinking about increased tx costs since additional stake calculations are necessary?

I think the main impact in the current design of having LPT held by contracts on L2 on behalf of inactive/passive delegators whose Os do not migrate from L1 is that the LPT would be unstaked and thus not count toward the L2 participation rate (which influences the per round inflation rate adjustment). If an inactive/passive delegator’s orchestrator does migrate from L1 then the delegator’s stake would count toward the L2 participation rate since the orchestrator migrated its entire delegated stake (includes the delegator’s stake) to L2.

The additional calculations will only be necessary for a delegator once when it claims its stake on L2 and will not impact the tx costs of other users.

1 Like

The requirement for state in the L1 contracts to be frozen in this design has the following implications:

  • Protocol inflation on L1 is completely disabled
    • Reason: Otherwise, the stake of accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2
  • Protocol inflation on L2 is supported
    • Reason: Otherwise, there is less of an incentive to migrate to L2
  • No fees can be earned on L1 and fees can only be earned on L2
    • Reason: Otherwise, the fees earned by accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2

Given these implications, the following questions are important to answer:

  • How will protocol inflation be disabled on L1 and enabled on L2?
  • How will work distribution transition to L2 once fees are disabled on L1?

The below sections aim to answer these questions.

Protocol Inflation

Let LIP_73_ROUND be the round at which the changes in LIP-73 go into effect.

  1. Before LIP_73_ROUND begins, the RoundsManager contract is upgraded such that starting at LIP_73_ROUND the initializeRound() function will be disabled meaning that rounds cannot be initialized. As a result, the round prior to LIP_73_ROUND will be the last round in which Os can call reward and redeem tickets
  2. Before LIP_73_ROUND begins, all protocol contracts (with required changes [1] for stake migration) will be deployed to L2 and will begin in a paused state meaning that no protocol transactions can be processed yet
  3. LIP_73_ROUND begins. As of this round, Os will not be able to call reward and redeem tickets on L1
  4. The L1 Minter will be upgraded to support transferring LPT + ETH cross-chain to the L2 Migrator to support the stake migration process
  5. The L1 Minter will transfer LPT + ETH cross-chain to the L2 Migrator
  6. The L2 Minter will set the starting inflation rate on L2 as the last inflation rate in the L1 Minter. As a result, the inflation schedule on L2 essentially picks up where the inflation schedule on L1 left off
  7. All protocol contracts on L2 are unpaused allowing protocol transactions to be processed

Steps 4-7 should happen in quick succession during a very short time period. We’re also looking into the possibility of executing these steps in a single action to minimize the length of the time period.

At this point, the stake migration process described in the previous post can begin. Note that since the protocol currently requires an O to wait until the next round after it stakes/registered to become active, after migrating an O will need to wait until the next round before it can call reward and redeem tickets.


  • Os will be able to call reward and redeem tickets on L1 up until a designated round
  • From that round on, no protocol transactions will be processed on L1
  • The inflation schedule on L2 will pick up where the inflation schedule on L1 left off
  • Once the steps are complete, stake migration from L1 can start and anyone is also free to directly submit protocol transactions on L2
  • Once Os migrate to L2 they will need to wait until the next round in order to become active after which they will be able to call reward and redeem tickets

[1] A full list of contract level changes to be enumerated separately.

Work Distribution

Once fees are disabled on L1, Os will not be able to redeem tickets on L1. So, any work received by Os after this point and before migrating to L2 would be performed for free (since any winning tickets received would not redeemable).

At the moment, Livepeer Inc. expects to start operating Bs on L2 immediately after the LIP-73 upgrade is executed which will only distribute work to Os on L2. Additionally, there are no plans to add simultaneous support for L1/L2 in go-livepeer. So, if other B operators wish to operate a L1 B and a L2 B they can choose to do so, but the recommendation will be to just operate a L2 B.

Previously, the intent was for Bs to be able to distribute work to Os on either L1 or L2 as outlined in this post. The benefit of this hybrid work distribution approach was that it allows for a smoother network transition where Bs could fallback to Os on L1 if the active Os on L2 have insufficient capacity. However, the reasons for not using this hybrid approach at this time are:

  • In this latest design, Os on L1 cannot earn fees after the upgrade so they can only do work for free
  • Given the above, it feels unnecessarily complex to support such a hybrid approach as opposed to as a community focusing on moving to L2

With all that being said, such an approach could be considered in the future if another migration is needed in a scenario where fees are not disabled on the origin chain. In this case, the choice of disabling fees (and other protocol transactions) on L1 in order to support a snapshot based claim on L2 that lowers costs for delegators feels like a worthwhile tradeoff.

The current planned changes in go-livepeer to make this transition easier:

  • Allow Os to receive tickets if they are pending activation as opposed the current requirement where they need to be active to receive tickets. The reason for this change is to allow Os that are scheduled to be active in the next round after they migrate to L2 to immediately be able to accept work on L2 in order to minimize the period where an O cannot receive work at all. Since the O is pending activation and since tickets are valid for at least 2 rounds (the current ticket validity period), the O will be able to redeem any winning tickets as soon as the next round.

Question: will operating on a L2 enable Broadcasters to have smaller deposits / reserves?

IIUC, a Broadcaster must have enough funds deposited to be able to pay out the face value of a winning ticket to all Orchestrators in the active set, i.e. faceValue * 100 in the current case that there are 100 Os in the active set. Given a face value of e.g. 0.18 ETH, this requires 18 ETH, or ~$72,000.

Further, the faceValue needs to be higher if the cost of redemption is higher, in order to not lose too much transcoding fees to redemption fees.

If operating on a L2 reduces the cost of redemption, will this reduce the typical faceValue of a PM ticket (and assuming the number of Orchestrators in the active set remains constant), will this enable Broadcasters to have smaller deposits / reserves, thus lowering the barrier to entry for Broadcasters?

The LIP has been updated in this PR to include the latest designs described in the following comments:

The title of the LIP has also been updated to “Confluence - L2 Stake Migration” to reflect the updated scope.


Also, another practical question: how do people expect to connect their nodes to the L2?

I’m assuming that the -ethUrl will need to pass in an RPC endpoint for the L2 network, and then I guess the options are:

  1. Infura-like provider - which introduces a third-party dependency

  2. Self-hosted gateway - which I have no idea how it works.

Does anyone have any wisdom on self-hosting gateways on L2s like Arbitrum?


If operating on a L2 reduces the cost of redemption, will this reduce the typical faceValue of a PM ticket (and assuming the number of Orchestrators in the active set remains constant), will this enable Broadcasters to have smaller deposits / reserves, thus lowering the barrier to entry for Broadcasters?

The reduced cost of redemption on L2 can help reduce reserve requirements by a bit for Bs, but I also think medium/long term updates to the payment protocol will also be desirable to further reduce the barrier to entry for Bs.

For now, an example to illustrate how lower redemption costs can impact reserve requirements:

At a gas price of 100 gwei, I estimate that the redemption cost should be somewhere around 0.02-0.03 ETH [1]. Suppose the ticket redemption cost is 0.025 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~13%. If the gas price drops to 2 gwei on L2, then the ticket redemption cost should be somewhere around 0.0005 ETH. Then, given the current typical faceValue of ~0.18 ETH, the overhead for redemption would be ~0.2%. As this is less than the target overhead of 1% that is currently set by Os, a B could reduce its reserve in this scenario while still being able to cover lower faceValue tickets that still have an overhead of around 1% for redemption. In fact, given a redemption cost of 0.0005 ETH, a faceValue of 0.05 ETH would achieve an overhead of 1% and this would translate to a 0.05 * 100 = 5 ETH reserve for the B.

[1] I am assuming gas usage of 250000 for ticket redemption. In practice, the gas usage might be slightly different.

I’m assuming that the -ethUrl will need to pass in an RPC endpoint for the L2 network, and then I guess the options are:

Yep that’s right. The -ethUrl flag will be able to accept an L2 RPC endpoint which could be backed by a self-hosted L2 node or a hosted service like Infura/Alchemy. There are docs for running a L2 node. Since the Arbitrum stack is not as mature as the L1 Ethereum stack, there will be some kinks to work out for those that intend to run self-hosted L2 nodes (for example, the additional storage requirements for the L2 node given that there haven’t been many optimizations implemented yet targeting storage and connections with L1 nodes). So, for those that are interested in starting to experiment with running self-hosted L2 nodes would be interested in hearing about the experience and any learnings. The core team is also currently experimenting with running L2 nodes as well and will aim to share learnings from the experience.

1 Like

LIP-73 has been moved into the 10 day Last Call phase during which additional remaining comments/feedback will be accepted!

1 Like

So this equates to a reduction in the financial barrier to entry from 18 ETH to 5 ETH, which is a sizeable reduction in the barrier to entry for new Broadcasters!

This >72% reduction effectively makes it ~4 times easier to become a Broadcaster on Livepeer.

This would be great news for the public network, as it seeks to increase the diversity of Broadcasters on Livepeer!

Also, am I right in thinking that if my Dad is delegated to my O, and I migrate my stake to L2, then their LPT will move to L2 as well, with no LPT left on L1?

His stake would be migrated when your O migrates to L2 since an O will migrate with its entire delegated stake. Then, his stake would begin accruing rewards and fees if your O calls reward and redeems ticket on L2. Technically, his stake would be managed by a delegator pool contract on L2. Later on, he would be able to submit a transaction on L2 to claim his stake from the delegator pool as well as any owed rewards and fees.

  1. Are there any plans for migrating undelegated tokens to L2?

  2. What do we see as being the main pain points / confusion for people - e.g. users who are accustomed to things working in a certain way, and then being confused when this changes? Asking so that we can be prepared with some FAQs to send people to when they come to ask what’s going on :slight_smile:

  1. Are there any plans for migrating undelegated tokens to L2?

A tokenholder will be able to move unstaked LPT to L2 using which will use the LPT gateway contracts on L1 and L2 under the hood to facilitate the transfer.

1 Like

A tokenholder will be able to move unstaked LPT to L2 using which will use the LPT gateway contracts on L1 and L2 under the hood to facilitate the transfer.

From a cursory look, it seems like using the bridge to migrate will require two transactions: an approve and a deposit.

So then, I guess there would be a marginal advantage for an undelegated tokenholder to:
a) approve and bond on L1, and then be migrated to L2 when their O migrates (two L1 txns),
b) approve and deposit on L1, then approve and bond on L2 (two L1 txns + two L2 txns).

I wonder whether there’s some value in communicating this to undelegated tokenholders, to “get on board” before Livepeer moves to L2?

I’m curious whether this is actually an advantage given relative gas usage.

Scenario A would still require one L2 transaction (claim).

If deposit in Scenario B is notable cheaper than bond in Scenario A, then Scenario A might be more expensive. But I’m not sure whether that’s the case or not. Any insights @yondon?

The amount of txs don’t really matter. It’s the total amount of gas that those tx use that matters.

Approve txs on L1 use roughly the same amount of gas, so can be neglected. The txs on L2 in b) can also be neglected since they’re on L2 where fees are cheap :slight_smile:

Bonding costs anywhere from 275k up to 400k gas. Depositing into the Arbitrum bridge costs ~200k gas (Arbitrum: L1 Custom Gateway | 0xcee284f754e854890e311e3280b767f80797180d).

So bridging the tokens instead of bonding and getting bridged is at least 25% cheaper

1 Like

OK, thanks for the responses.

In general, I wonder how it might be possible to make life less difficult for the owners of the 2.6m addresses which received ~2.4 LPT in the MerkleMine. I guess the gas on L1 might get cheaper if more projects migrate transactions to L2s (??), but I think it’s worth considering whether this migration might effectively cut loose around 6m tokens, or ~25% of current supply, and if so, whether this is appropriate.

1 Like