What can OP Chains do or configure that wouldn’t break homogeneity?
Their specific ask is for CSR, but in general they’re asking for more clarity on what would / wouldn’t break compatibility
this question keeps coming up for multiple teams
right now anything that's execution (geth changes) and settlement (bridging, deriving, 7-day withdrawal) breaks compatibility
Where do OP Chains need to update info in OP Stack repo (eg. token list)
Base told them there are a “dozen places” that Base had to update and they’re trying to find out what all those places are
this might be an eng question but feels like low hanging fruit to have a list to share with OP Chains
devX has a project that seeks to automate this! we'll start by compiling a list first, but on our minds
Super rough list: chainlist, ethers/viem, OP SDK, wallets (Metamask especially), various configs (superchain-registry to start)
Can we have some kind of bridge shared liquidity pool for OP Chains?
They are talking to teams like Hop but need to front liquidity. If there were a shared liquidity pool, it would reduce costs for fronting the liquidity
They are excited about LayerSwap bc they jumped on building out L2 to L2 bridging
The solution here is likely not exactly what people are thinking of. We'd want to be careful with the design and how we pay for that liquidity!
Stablecoin availability?
current thinking around this: either we create L2 to L2 messaging and they integrate with 1 hub chain (e.g OP Mainnet)
Or they integrate a seamless wrapped version that they own and can easily migrate once they deploy native. They said the Law of Chains is a blocker for this.
Is CSR something that has to be breaking protocol level changes?
devs can implement CSR out of protocol! there's a tweet around how (can find if it's helpful); this is a hackathon submission [https://ethglobal.com/showcase/shadow-rollup-k712d] implementing it in a slightly different way
What can OP Chains do or configure that wouldn’t break homogeneity?
Their specific ask is for CSR, but in general they’re asking for more clarity on what would / wouldn’t break compatibility
this question keeps coming up for multiple teams
right now anything that's execution (geth changes) and settlement (bridging, deriving, 7-day withdrawal) breaks compatibility
Where do OP Chains need to update info in OP Stack repo (eg. token list)
Base told them there are a “dozen places” that Base had to update and they’re trying to find out what all those places are
this might be an eng question but feels like low hanging fruit to have a list to share with OP Chains
devX has a project that seeks to automate this! we'll start by compiling a list first, but on our minds
Super rough list: chainlist, ethers/viem, OP SDK, wallets (Metamask especially), various configs (superchain-registry to start)
Can we have some kind of bridge shared liquidity pool for OP Chains?
They are talking to teams like Hop but need to front liquidity. If there were a shared liquidity pool, it would reduce costs for fronting the liquidity
They are excited about LayerSwap bc they jumped on building out L2 to L2 bridging
The solution here is likely not exactly what people are thinking of. We'd want to be careful with the design and how we pay for that liquidity!
Stablecoin availability?
current thinking around this: either we create L2 to L2 messaging and they integrate with 1 hub chain (e.g OP Mainnet)
Or they integrate a seamless wrapped version that they own and can easily migrate once they deploy native. They said the Law of Chains is a blocker for this.
Is CSR something that has to be breaking protocol level changes?
devs can implement CSR out of protocol! there's a tweet around how (can find if it's helpful); this is a hackathon submission [https://ethglobal.com/showcase/shadow-rollup-k712d] implementing it in a slightly different way
this thread on CSR that would require an L3 on PGN? https://twitter.com/kelvinfichter/status/1624975097537654786
can reimburse periodically or “manual” reimbursement, may be cumbersome with scale