Aragon DAO Backed Transcoders

Nobody has claimed this yet.

At the moment, a transcoder is commonly represented by an EOA that delegates LPT towards itself and is a registered in the transcoder pool maintained by the BondingManager contract. However, a transcoder can also be represented by a contract that implements an ACL that controls which EOAs can trigger actions within the BondingManager on behalf of the contract. In fact, this contract can be an application that is a part of an [Aragon DAO](https://hack.aragon.org/docs/aragonos-ref.html#2-kernel).

This issue will serve as the basis for initial designs to enable an Aragon DAO backed transcoder.

## Use Cases

- Transcoders can withdraw their earnings (LPT/ETH) into a DAO and DAO stakeholders can use a voting application to determine how to spend the funds.
- A DAO can designate an EOA to "act" on behalf of the DAO in the Livepeer network (since transcoders need to execute automated actions such as call `reward()` to mint inflationary rewards and the claim-verify workflow in order to earn transcode jobs fees) and DAO stakeholders can use a voting application to change the designated EOA if one is performing poorly.
- Following the previous point - experiment with mechanisms to select service providers. One example that has been proposed is a [Vickrey auction](https://research.aragon.org/t/staking-pool-daos/136).
- Encourage the building of a local ecosystem/community around a single DAO backed transcoder.

## Required DAO Applications

- Generic [Actor](https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/12): From the BondingManager's point of view, this contract would represent the transcoder. An approved EOA would submit a transaction to this contract which then forwards (after first checking with the ACL if the EOA has the proper permissions) the function call to the BondingManager (with the actor as the transaction sender).
- Vault: Holds the DAO's valuable assets i.e. LPT/ETH
- Voting: Allows DAO stakeholders to create and execute votes for certain proposals i.e. transferring tokens from the Vault to some destination address.
- ACL: Maintains permissions for EOAs that can submit transactions through the Actor.

## Workflow

Suppose the ACL is set up such that Alice's EOA is allowed to execute all function calls on the BondingManager through the Actor.

The DAO moves the required LPT for staking from the Vault to the Actor (which could inherit from the Vault such that it is able to manage tokens). Alice constructs the calldata for the following function calls:
- `LivepeerToken.approve(BondingManager.address, N)`
- `BondingManager.bond(N, Actor.address)`
- `BondingManager.transcoder(rewardCut, feeShare, pricePerSegment)`

The entire data payload is then submitted to the Actor app which executes each of the function calls represented by the individual calldata payloads. Each function call is executed with the Actor as the sender. Before executing the function call, the Actor checks with the ACL that the provider of the calldata (Alice) is allowed to forward the function call through the Actor. If so, the function call is executed. If not, the entire transaction will revert. The entire transcoder registration workflow can be completed within a single atomic transaction.

After registration, whenever Alice's transcoder node needs to perform an automated operation such as as call `reward()` or execute the claim-verify workflow, instead of submitting the transactions directly to the BondingManager, the node will construct the calldata for the transaction and submit it to the Actor which will forward the function call to the BondingManager.

When Alice's either calls `BondingManager.unbond()` + `BondingManager.withdrawStake()` or `BondingManager.withdrawFees()`, the LPT/ETH will be sent to the Actor. The LPT/ETH in the Actor can then be used for continued operations on the Livepeer network or DAO stakeholders can use the Voting app to initiate a vote to withdraw the LPT/ETH from the Actor to the Vault. The ACL could also have special permissions for `BondingManager.unbond()`, `BondingManager.withdrawStake()` and `BondingManager.withdrawFees()` such that DAO stakeholders can use the Voting app to initiate a vote to trigger one of these functions instead of relying on Alice to do so.

## MVP

The simplest way to build an MVP of this design would entail:
- Create a generic Actor app along the lines of what is described [here](https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/12)
- Import contract bindings for the Actor app into go-livepeer so that the node knows how to submit transactions to the Actor
- Add a flag in go-livepeer `--daoActorAddr` which specifies the Actor address for a DAO. If this flag is used, the node should construct calldata that is submitted to the Actor instead of submitting transactions to the Livepeer contracts directly. By default, this would be disabled.

A first step would be to try out this MVP with a fork of go-livepeer that is usable on Rinkeby.

One thing to note is that an open problem is how to deal with designated signers (see https://research.aragon.org/t/dynamic-permissions-for-organization-actions-with-signer-integration/116/20). This is not a problem for transcoders in the Livepeer protocol today because transcoder signatures do not need to be validated on-chain, but it is something to consider in future updates to the protocol if support for DAO backed transcoders is to be continued.

Start by reviewing the proposed generic Actor app and the go-livepeer transaction paths that would need to use it. Then assess the contract bindings and the proposed --daoActorAddr flag, with the Rinkeby fork MVP as the completion target.

Written by the indexing model from the issue text.