Protocol Update Idea

Research & Protocol Improvements
1

Moving from: Transferrable ownership of an O (reversable) · Issue #2648 · livepeer/go-livepeer · GitHub

I had submitted an issue on github and was directed to post it over here.

Below is what was in the issue but the gist of it is that the idea would be to enable orchestrator ownership transfers, either through minting an NFT for ownership (Similar to ENS ownership) or a protocol function similar to “TransferBond” but with the Withdraw stake reversable cooldown. The idea behind this is with the uptick in users being hacked, Orchestrators having to abandoned hacked addresses, if we can implement a function where there is a way to transfer the ownership of the O to a new address it could help the Orchestrator from having to start from scratch. Earlier in the year I was unfortunately one of those people and as such I had to abandon the address and start a new Orchestrator. At the time I had 64K LPT Staked to me and that never returned. I believe this change would be a beneficial addition to help the community that supports the network.

Is your feature request related to a problem? Please describe.

With a few O’s being hacked on their O wallets it puts the O in a position where they have to abandon the orchestrator completely and start over. This has happened to O’s such as myself and a few others.

Describe the solution you’d like

I would like to propose that ownership of the registered O is tokenized into an NFT which can be transferrable (similar to ENS ownership) or just transferrable (like contract #18 transferBond) and apply a 7 day reversable cooldown similar to the unstaking function.

Describe alternatives you’ve considered

  • Generate an NFT signaling ownership of the O that can be transferred.
  • Implement a contract function to transfer ownership with a locking period that can be reversable (similar to the withdraw stake locking mechanism)

Thank you,
Ryan

2

If the account is hacked, how would you defend against the ownership NFT just being transfered by the hacker to an address they control?

I think something like this would need to be coupled with the idea of an offline “cold” account being the owner of the O, and just resolving the actual signing of txns to a hot wallet address on the O machine itself. If the hot wallet gets hacked, then the offline owner could update the address that the hot O resolves to (with the 7 day period as you suggest).

3

I like this better actually, if you compare it to the ENS model where theres the registrant and the controller, a similar idea but the registrant can be a hardware wallet or the offline “cold” account as you suggest and the controller can be an account that can do reward calls, ticket redemptions etc.

It’s been a discussion for a long time to want to have the ability to have a hardware wallet secure the O but the requirement of having the primary address do the reward calls was the limiting factor. We can do ticket redemptions from dummy addresses but we just cant do reward calls. @dob