You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have a list of all OP Collective Receiver Addresses
Track all transfers to and from those addresses, regardless of counterparty
Build a list of all known Superchain member sender addresses, and tag transactions accordingly.
Build a processes with Partnerships/Finance to ensure that we are as up to date as possible, leading up to revshare contract enshrinement (which we then integrate to)
Address lists
The known list exists in the Dune query (originally planned to do this in the GH repo lists, so you'll see some existing files, but we never used them and they fell out of date).
Data Schema
Transfers are infrequent and require audit-ability. So we should preserve all transaction & transfer level data, which we then build our aggregations on top of.
Other Considerations
Some transfers will come from a generic RaaS address, and not be clearly attributable by Superchain member. We should have some method for (later on) manually attributing / splitting a transfer by the appropriate Superchain member (i.e. RaaS A sends 1 ETH, we need to split 0.3 for Chain B's revshare, and 0.7 for Chain C's revshare.
The text was updated successfully, but these errors were encountered:
Requirement on having ETH transfers for L1 and L2s.
Existing Notebook: https://github.com/ethereum-optimism/op-analytics/blob/main/op_collective_economics/opcollective_feesplit/op_collective_revenue.ipynb
Existing Dune Query: https://dune.com/queries/3046107
Ideal set-up is we:
Address lists
The known list exists in the Dune query (originally planned to do this in the GH repo lists, so you'll see some existing files, but we never used them and they fell out of date).
Data Schema
Transfers are infrequent and require audit-ability. So we should preserve all transaction & transfer level data, which we then build our aggregations on top of.
Other Considerations
Some transfers will come from a generic RaaS address, and not be clearly attributable by Superchain member. We should have some method for (later on) manually attributing / splitting a transfer by the appropriate Superchain member (i.e. RaaS A sends 1 ETH, we need to split 0.3 for Chain B's revshare, and 0.7 for Chain C's revshare.
The text was updated successfully, but these errors were encountered: