Dob/delta: Initial draft LIP submission for Livepeer Delta. #88
Conversation
…mentation section.
…ity_conventions can be voted on together.
…ecurity committee.
LIPs/LIP-livepeer_treasury.md
Outdated
|
|
||
| **Execution** | ||
|
|
||
| Upon the end of the `Voting Period`, it will be determinable on chain whether the proposal passed or did not pass. If it passed, then there is an `execute` transaction callable by anyone, that will execute the associated transaction associated with the proposal. By default, initially the only transaction type will be to send LPT from the treasury to the specified receive address. If the proposal did not pass or did not reach quorum, then the `execute` function will revert and no action will be taken. |
There was a problem hiding this comment.
I might've missed it, but from skimming the spec I don't see mention of any onchain restrictions on the logic that is allowed in proposals despite this section noting that the logic of proposals should be restricted to LPT transfers.
There was a problem hiding this comment.
@victorges Yes I was thinking about this as well. When proposals are submitted, do we have the ability to enforce that the only txn type is a transfer of LPT from the treasury to a receive address? In the future we can update this to enable other types of governance actions?
There was a problem hiding this comment.
That would be possible to be implemented if we override the Governor.propose function and make a few checks. The only change would be that we probably want to allow any of the "governance" proposals as well (e.g. updating voting delay, period, timelock delay, etc).
The implementation can have a list of allowed calldatas / targets. Would need to add this to the spec and implementation though, which might be a 0.5-1 day effort. Let me know if we do want this behavior and I can give it a shot on livepeer/protocol#615 !
There was a problem hiding this comment.
@victorges Yes I think this is a good idea. But I would like to better understand the process for updating this overrided Governor.propose function in the future to allow greater flexibility in what can be done via governance actions. Is it upgradeable...and if so who has permission to upgrade it? I guess this would be solved if the valid Governor.propose actions are:
- Token transfers from the treasury
- Updates to the governance parameters
- Updates to the function that performs these checks...so that a different one can be selected in the future?
| @@ -0,0 +1,41 @@ | |||
| --- | |||
| lip: governable_security_committee | |||
There was a problem hiding this comment.
I don't think there is sufficient information in this LIP for it to be merged as a draft yet so I recommend fleshing out the empty sections before submitting a PR to merge it as a draft.
|
Thanks. What I'll do is address the open micro comments and debatable points here in this PR, and then resubmit individual PRs for each LIP. |
…estrators, and added links to governor frameworks.
… rather than paying an amount to make a proposal.
assets/treasury_technical_spec.md
Outdated
There was a problem hiding this comment.
FTR I've used the Notion doc [1] during the final steps of the implementation and made some comments there about changes that needed to be made and incorporated here. Haven't made the changes there either, only made comments as reminders.
|
Ok, the PRs are now broken up into individual PRs for each LIP, and there's two new forum discussion threads. One for the treasury bundle and one for the treasury contribution percentage discussion. I'll leave this PR open for a bit for reference on the ongoing discussion, but let's move any future updates to the spec or PRs themselves into the individual LIP based PRs, rather than here. cc @victorges @yondonfu |
|
@dob should we close this one? |
This is the initial PR for the set of LIPs that incorporates the Livepeer Delta decentralization upgrade. It includes Livepeer treasury, contribution percentage, social conventions, and a placeholder for security committee governance.
Notes to reviewers
Pre-reqs for moving these LIPs from Draft to Last Call would be further community discussion in the forums, technical review of the candidate implementation and spec.