WIP: RevenueSharer predeploy #115
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,80 @@ | ||
| # Revenue Sharing | ||
| <!-- START doctoc generated TOC please keep comment here to allow auto update --> | ||
| <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> | ||
| **Table of Contents** | ||
|
|
||
| - [Overview](#overview) | ||
| - [Definitions](#definitions) | ||
| - [`RevenueSharer` predeploy](#revenuesharer-predeploy) | ||
| - [Invariants](#invariants) | ||
| - [Deploying `RevenueSharer`](#deploying-revenuesharer) | ||
| - [Existing Chains](#existing-chains) | ||
| - [Execution](#execution) | ||
| - [Simplified L1 Data Fee Expenditure](#simplified-l1-data-fee-expenditure) | ||
|
|
||
| <!-- END doctoc generated TOC please keep comment here to allow auto update --> | ||
|
|
||
| # Overview | ||
|
|
||
| Revenue sharing is the process by which chains in the superchain contribute a portion of their revenue or profit to a beneficiary such as the Optimism collective. They may do this in return for support with the OP Stack and/or other benefits. | ||
|
|
||
|
|
||
| ## Definitions | ||
tynes marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| | Term | Name | Definition | | ||
| | -------|--------------| ----------- | | ||
| | $d$ | L1 Data Fee Revenue | ETH transferred to the sequencer with L2 transactions to cover estimated L1 Data Fees(see below). Accumulates to `L1FeeVault`. | ||
| | $e$ | L1 Data Fee Expenditure| ETH spent by the batcher on L1 to make transaction data available | ||
| | $b$ | L2 Base Gas Revenue | Base fee portion of L2 Gas Fee (ETH transferred to the sequencer to cover execution of L2 transactions). Accumulates to `BaseFeeVault`. | ||
| | $q$ | L2 Priority Gas Revenue | Priority fee portion of L2 Gas Fee (ETH transferred to the sequencer to cover execution of L2 transactions). Accumulates to `SequencerFeeVault`. | ||
| | $g$ | L2 Gas Revenue | $b + q$ | ||
| | $r$ | Sequencer Revenue | $d + b + q$ | ||
| | $p$ | Sequencer Profit | $r - e$ | ||
| | $s$ | Revenue share due to `BENEFICIARY`| $\max(0.15r,0.025p)$ | ||
| | `BENEFICIARY` | e.g. Optimism Collective | | ||
| | `REMAINDER_BENEFICIARY` | e.g. Chain Operator | | ||
|
|
||
|
There was a problem hiding this comment. Should add definitions for
I spotted this line on #111, so I guess we should follow that pattern here ( |
||
| ## `RevenueSharer` predeploy | ||
| Revenue sharing is achieved through an L2 [predeploy](./predeploys.md) contract `RevenueSharer` with address `0x4200000000000000000000000000000000000024`. | ||
|
There was a problem hiding this comment. Perhaps giving a simple interface + description of |
||
|
|
||
| ### Invariants | ||
|
There was a problem hiding this comment. The vaults must be configured to withdraw to this predeploy? There was a problem hiding this comment. This is relevant to your other comment. The model I initially had in mind was to hardcode the
We can make a different choice and make the the output of the FeeVaults freely configurable. This represents a somewhat lesser enshrinement of revenue sharing. The downside could be that:
There was a problem hiding this comment. From slack thread: would be nice to have a simple way to opt out of revenue sharing via a flag in the deploy configuration. When opting out, the existing/legacy behaviour can prevail. |
||
| * The `RevenueSharer` contract should not accumulate any ETH or Tokens itself. | ||
|
There was a problem hiding this comment. There should be a "Security Considerations" section at the bottom with responses to questions around the security, ie "what if a user sends ether or a token to the contract directly?" Will this mess with its accounting? There was a problem hiding this comment. @geoknee let me know if you want input on this section 👍🏻 |
||
| * It should share revenue in the propotions `s, r-s` when the `execute()` function is called, to `BENEFICIARY` and `REMAINDER_BENEFICIARY` respectively. | ||
| * It should emit an event when `execute()` is called. | ||
|
|
||
| ### Deploying `RevenueSharer` | ||
|
There was a problem hiding this comment. Thoughts on There was a problem hiding this comment. I don't have super strong opinion. I think having the Other options are There was a problem hiding this comment. I have a preference to just call it There was a problem hiding this comment. Slack poll so far indicating a preference for |
||
|
|
||
| The `RevenueSharer` contract is now included in the L2 genesis and is not scheduled to be part of a hardfork. | ||
|
|
||
| #### Existing Chains | ||
| For chains without the `RevenueSharer` in their genesis, the following transactions may be executed to deploy it | ||
| : | ||
| 1. The `RevenueSharer` should be deployed manually to an arbitrary address `REVENUE_SHARER_IMPLEMENTATION_ADDRESS` | ||
| 2. For EACH of the three FeeVault contracts ({name} = BASE, L1, SEQUENCER): | ||
|
|
||
| a. A new version should be deployed with the `RECIPIENT` variable set to `0x4200000000000000000000000000000000000024` in the constructor, and other constructor parameters set to existing values. This contract has an arbitrary address `NEW_{name}_FEE_VAULT_ADDRESS`. | ||
| b. The ProxyAdminOwner should call `ProxyAdmin.upgrade({name}_FEE_VAULT, NEW_{name}_FEE_VAULT_ADDRESS)` | ||
|
|
||
| ### Execution | ||
| Revenue sharing is executed periodically, and can be configured to send funds to L1 or to L2. | ||
| The `RevenueSharer` is responsible for computing $s$ and sending it to a predetermined address controlled by the Optimism Collective. At the end of execution, `SequencerFeeVault`, `L1FeeVault` and `BaseFeeVault` and `RevenueSharer` should be completely depleted of ETH. This allows the contract to be stateless. | ||
|
|
||
| ```mermaid | ||
| flowchart TD | ||
| SequencerFeeVault | ||
| BaseFeeVault | ||
| L1FeeVault | ||
| BeneficiaryWallet | ||
| RemainderWallet | ||
| RevenueSharer | ||
| SequencerFeeVault-->|q|RevenueSharer | ||
| L1FeeVault-->|d|RevenueSharer | ||
| BaseFeeVault-->|b|RevenueSharer | ||
| RevenueSharer-->|s|BeneficiaryWallet | ||
| RevenueSharer-->|r-s|RemainderWallet | ||
| ``` | ||
|
|
||
| The execution of Revenue Sharing is achieved by calling `RevenueSharer.execute()`. | ||
|
|
||
| ## Simplified L1 Data Fee Expenditure | ||
| As a part of a gradual rollout of protocol enshrined revenue sharing, the `RevenueSharer` uses a fixed value of $e=0$. The sequencer makes a profit on data availability of $d-e$. Note that a negative profit, i.e. a loss, is possible. By assuming $e=0$, the simplification implies that data availability revenue is all profit. This will be addressed in a future protocol upgrade. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that we should be too specific here on the behavior of the
FeeVault. This is free software, it can be configured howeverThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a suggested wording? Can we just replace "are" with "may"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps something like "based on FeeVault, to collect fees"
simple and not opinionated on where the fees go