WIP: RevenueSharer predeploy #115
Conversation
| 0x4200000000000000000000000000000000000022 | ||
| ``` | ||
|
|
||
| ### Deploying `RevenueSharer` |
There was a problem hiding this comment.
Thoughts on RevenueShare vs RevenueSharer? Seems a bit easier to say and gets the same point across
There was a problem hiding this comment.
I don't have super strong opinion. I think having the -er follows existing predeploys such as L2ToL1MessagePasser , L2CrossDomainMessenger and so on. And we do already have some hard-to-say names such as OptimismMintableERC721Factory.
Other options are RevShare and RevSharer. Base are using something they call a FeeDisburser.
There was a problem hiding this comment.
I have a preference to just call it RevenueShare to make it easier to say. the "revenue share predeploy" vs the "revenue sharer predeploy"
There was a problem hiding this comment.
Slack poll so far indicating a preference for RevenueSharer. I'm going to to continue using this name for now, it should be easy to replace down the line if necessary.
|
Thoughts on being more abstract with language as to not enshrine the optimism collective deeply into the protocol itself? its free software that anybody can use, perhaps we can just call the address that funds collect to the "collective address" |
I agree I went with "Beneficiary" here 572b90d and listed Optimism Collective as an example. |
| @@ -81,7 +81,7 @@ The three types of fees are collected in 3 distinct L2 fee-vault deployments for | |||
| fee payments are not registered as internal EVM calls, and thus distinguished better this way. | |||
|
|
|||
| These are hardcoded addresses, pointing at pre-deployed proxy contracts. | |||
| The proxies are backed by vault contract deployments, based on `FeeVault`, to route vault funds to L1 securely. | |||
There was a problem hiding this comment.
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 however
There was a problem hiding this comment.
Do you have a suggested wording? Can we just replace "are" with "may"?
There was a problem hiding this comment.
perhaps something like "based on FeeVault, to collect fees"
simple and not opinionated on where the fees go
| ## `RevenueSharer` predeploy | ||
| Revenue sharing is achieved through an L2 [predeploy](./predeploys.md) contract `RevenueSharer` with address `0x4200000000000000000000000000000000000024`. | ||
|
|
||
| ### 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 RevenueShare(r) as the output of the FeeVaults. To my mind, this represents a greater level of enshrinement of revenue sharing, which I believe is our overarching goal. But it does have some downsides:
- It could be offputting or confusing to any chain operator who isn't sure about doing revenue sharing in the first place. As you say, from an open source perspective it's nice to include this set of users.
- It reduces overall configurability over how fees can flow around. Although we can ensure that the
RevenueShare(r)can still be configured to send all funds to e.g. the chain operator or any other wallet, this approach does tie all three FeeVaults together (not possible to withdraw from one without withdrawing from the others).
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:
- We risk not achieving our overall goal. Chains can easily bypass the
RevenueShare(r)predeploy, leaving it dangling there doing nothing, - There is more opportunity to deploy a "bad" configuration which could lead to incorrect behaviour. Of course this may be addressable through documentation and/or runtime checks.
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.
| | $s$ | Revenue share due to Optimism Collective | $\max(0.15r,0.025p)$ | ||
|
|
||
| ## `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 execute could be useful
| Revenue sharing is achieved through an L2 [predeploy](./predeploys.md) contract `RevenueSharer` with address `0x4200000000000000000000000000000000000024`. | ||
|
|
||
| ### Invariants | ||
| * 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 👍🏻
| | $r$ | Sequencer Revenue | $d + b + q$ | ||
| | $p$ | Sequencer Profit | $r - e$ | ||
| | $s$ | Revenue share due to Optimism Collective | $\max(0.15r,0.025p)$ | ||
|
|
There was a problem hiding this comment.
Should add definitions for BENEFICIARY and REMAINDER_BENEFICIARY (or whatever terms we settle on).
The gas paying token address is network specific configuration, therefore it MUST be set in storage and not as an immutable. This ensures that the same contract bytecode can be used by multiple OP Stack chains.
I spotted this line on #111, so I guess we should follow that pattern here (REMAINDER_BENEFICIARY is chain specific).
and add to table
Co-authored-by: Blaine Malone <[email protected]>
This reverts commit dc1d1b2.
this is broken currently but was only pointing at a WIP. Now when we merge the actual implementation the link should work (up to renaming the file etc).
No description provided.