I’m glad to see a proposal like this making its way to the DAO. Between this post and the call, it’s clear there is a lot of thought going into this - which is great because I think fragmentation is huge area of concern to address as Ethereum grows more L2 dependent. So I don’t have much to really add to this other then I look forward to this going forward, as this is something to address sooner then later.
I will echo one question brought up by @karpatkey (see below). I saw a reply by @offchainlabs below, however I wasn’t 100% sure if that was the official account (I saw it was created like 2 months ago). Regardless, it seems even if that response is the official team then I don’t see indication Offchain labs has made a final decision on how they want to handle this.
I don’t think delaying the timeline here is a good idea, but I also think were in a situation where we can spin up all this work only to find out Offchain labs is wanting to handle this in house. Is there any indication a decision on this matter would be determined prior to December?
Are Offchain Labs and the Arbitrum Foundation onboard with the DAO leading this initiative? and, are they open for collaboration with whoever the DAO selects?
Up to this point, all major technical upgrades have come from the core team. As this would be a main change in how Arbitrum works, this initiative needs to be in close collaboration with Offchain Labs and the Arbitrum Foundation. A disjointed effort would lead to suboptimal results, other than waste of resources.
Thank you @maxlomu for sharing this proposal. Your comparative analysis of the rollup space was valuable and painted a clear picture of the competitive landscape . Echoing others, it’s clear that Arbitrum needs to enhance interoperability and improve the user experience across its ecosystem of Orbit chains.
Since the proposal doesn’t include a budget or the names of technical contributors committed to joining the working group, it seems the Snapshot that you plan to create tomorrow is primarily intended as a sentiment check to gauge the DAO’s interest in forming a working group to explore Orbit chain interoperability.
If this assumption is correct, then our ability to make an informed decision on whether to move forward with this initiative is limited. We would need to see commitments from at least a few technically-skilled DAO contributors who have the time and desire along with commitment from OCL and the Foundation to join your proposed working group.
We are glad to see Offchain Labs join the discussion on the forum and share that their teams are exploring approaches to enhancing interoperability. However, without a hard commitment from OCL to collaborate with the DAO’s efforts, we are cautious of the value and impact that the working group will bring.
Do we have a full commitment from the other entities?
I assume that we are talking about the ARDC here. Does the current timeline fit into the ARDC v2 timeline?
What exactly would go up to a vote by the 31st?
What is the budget for it?
I assume that the second item is Open application, correct? What is the profile we are looking for?
Thanks everyone for the extensive feedback. As we continue investigating the fastest and most efficient ways to implement this, I’ll try to clarify some points and how the mental model is evolving.
All of this Chain Abstraction stack sits on top of Arbitrum - meaning that there is no strict need for OCL to do anything. All solutions are independent providers, some of them are already deployed on Arbitrum One in a permissionless way. OCL wants to and will get involved in any decision making, in particular we will follow their guidelines if they identify specific EIP/standards that should be embraced by the selected solutions.
Then what is the purpose of this initiative? Enable builders to deliver the best experience on Arbitrum with the right tools
Example of outputs:
If you are a DEX (gm Camelot), you should be able to easily implement an any to any swap across all Orbit chains
If you have a vault, you should be abe to implement a “deposit from anywhere” flow
This should happen across all the (major?) Orbit chains
We received 2 recurring questions so far:
Why is this not happening already?
Will this move the needle for apps?
We are conducting interviews with major apps and chains to gather a better understanding.
As of now I believe there are 3 requirements:
Education: as @Bobbay was suggesting, builders need to be aware of what is possible to do, and how do it
Solution packaging: what solutions are available for an app deployed on an Orbit chain? This may take the shape of a marketplace, possibly incorporated within what the APDC is working on.
Infrastructure enablement
Deployment & availability of the right lego pieces (service providers) on those chains
Profitability of solvers: there needs to be enough volume or incentives or liquidity lent for the system to be sustainable (in the short and then long term.
There are different forms this could be shaped.
A custodial loan to a selected number of solvers with DAO owned liquidity that will earn interest
A non custodial loan to a pool where collateralized solvers could borrow DAO owned liquidity
Incentives towards bridging/rebalancing protocols to deploy and/or bring solvers with liquidity
Building a new Orbit-focused bridge UI may not be the optimal approach.
Bridge UI will gradually disappear as apps will integrate that functionality within their UI (deposit from anywhere experience)
There are already several aggregators we could partner with (Socket, LiFi, ecc) who already built everything and provide a great experience
In the short term, the objective is to have the shortest path to MVP defined and implemented:
5 top builders that commit to enable a chain abstracted experience
A solution package ready to go for this projects to implement it
This must be concluded in the next few weeks - we want to test it fast.
I want to reduce bureaucracy to the minimum - Snapshot timeline will not be met today.
In the long term, we should focus on a comprehensive package that is
Open: Avoid centralization/custodial risk.
Efficient: Support cheap transfers & higher ROI for DAO liquidity.
Secure and aligned with our mission to deliver the best UX.
We think this is a good initiative by @MaxLomu, as better interoperability between Orbit Chains and Arbitrum itself could potentially make it much easier for Arbitrum users to explore the various Orbit Chains available.
As Max has rightly pointed out, the research and development of the plans surrounding this proposal has to be aligned with ARDC, Offchain Labs and Arbitrum Foundation in light of the Ethereum-wide interop plans that may be running in parallel with Ethereum Foundation.
It would be prudent for us to consider various aspects, not only the impact of interoperability within Arbitrum and its Orbit Chains but also how interoperability with the broader Ethereum ecosystem would align and flow.
We also agree with @Bobby’s assessment that an interim solution may be required during the potentially longer implementation process of Chain Abstraction solutions. Depending on the development timelines needed for a Chain Abstraction strategy, an interim solution should also be scoped out and explored in parallel if a need is determined.
One key thing we would like to see from the committee exploring chain abstraction is feedback on the needs of protocols and orbit chains within our ecosystem. It is, after all, prudent for us to focus on things that meet the needs of projects building on Arbitrum.
Castle is in favor of exploring this topic further, and we will vote in support of this proposal.
Thank you for the detailed answers and explanations.
I think this initiative will give a large number of new users with no experience in crypto the opportunity to come to Arbitrum and stay there.
What worries me most is the security of the implementation of the abstraction layer above Arbitrum. At the moment, we encounter errors at one level, and now they can be at two or the problem can be in the combination of levels. It is very important that this is thought out to avoid users fleeing us.
I think this proposal is solid on the technical side, but if Orbit wants to attract developers like Superchain has, it’s going to take more than just the stack. Superchain has a clear narrative and strong identity that attracts people who want an aligned community. Without something similar, Orbit chains might keep feeling a bit fragmented.
I have seen other initiatives, like the Orbit Ecosystem Fund and the Orbit Stimulus Pilot. These programs help to boost growth and are great as a foundation, but to keep up the momentum long-term, it’s probably going to take more than just funding.
Also, the intent-based architecture is powerful, but it’s going to need education and some incentives for people to really get on board. We know that new technologies like cross-chain liquidity solutions tend to struggle at the start without good support strategies. Orbit would benefit a lot from offering educational resources and grants to help developers understand and use the new stack.
About incentives, Superchain has stayed in the spotlight because they’re consistent with their support for developers (RetroPGF, Build). Orbit already kicked off with funds and initiatives like the Stimulus Pilot, but I agree that a structured and steady approach would help secure that long-term growth.
Finally, making Orbit attractive to developers isn’t just about incentives. Improving the onboarding process with things like an easy deployment template and tutorials could make a huge difference. For devs who value decentralization, Orbit has an opportunity to emphasize interoperability without enforcing centralized chain configurations, setting it apart from Superchain’s centralized approach. Overall, I think that a well-defined narrative and clear resources for developers could make Orbit the place for those looking for flexibility and support.
After reading and discussing this proposal, we believe Chain Abstraction can be a strong play that Arbitrum DAO should adopt to increase its presence in the ecosystem with a strong vision for Arbitrum’s future. However, a few questions came up during our review:
First, we are curious about how the proposal plans to handle the integration of Orbit Chains, which involves complex and sensitive technology. Specifically, what safety measures and testing protocols will be in place to ensure stability and security during implementation?
Additionally, while we appreciate the comparison with Stylus Sprint, we feel that having a developed budget is crucial for our voting decision. Understanding the estimated costs, including any administrative expenses, would help us better assess the proposal’s financial scope. It would also be nice to know the estimated timeline for implementing these changes if approved.
While we recognize that the proposal aims to simplify the user experience, we are concerned that introducing these interoperability layers might add complexity for developers. We are not devs, so some confusion might arise on this last point.
Questions:
1. Difficulty of practical realization of interoperability:
- The proposal mentions that chain abstraction requires “intent-based design”, are there any concrete solutions or prototypes in terms of technology and implementation?
- When optimizing the interoperability of Orbit chains, how to take into account the compatibility with other L2/L3 to avoid the formation of new “island effect”?
Suggestions:
1. In the pilot phase, clear indicators can be set up, such as:
- How many interoperability tests between Orbit chains have been completed?
- How many new chains are deployed through chain abstraction?
- How many new chains will be deployed through chain abstraction? What is the target to increase TVL or transaction volume of chains in the eco-system?
2. It is recommended to prioritize inter-chain UX improvements, such as reducing the number of steps and time costs for users to cross chains on Orbit chains, and launching a unified user interface or SDK.
We find this proposal to be comprehensive and forward-looking in its approach to positioning the ecosystem at the center of chain interoperability. The initiative effectively identifies current ecosystem gaps while proposing very concrete solutions that could meaningfully differentiate Arbitrum from competing L2 ecosystems.
The analysis of Arbitrum’s current positioning relative to competitors, particularly Optimism’s Superchain narrative, shows a clear understanding of the underlying dynamics and accentuates the need for improved ecosystem cohesion. The proposal is proficient in recognizing that merely catching up to competitors through technical improvements is insufficient - and hence Arbitrum must lead through innovation.
The emphasis on Arbitrum One as a trusted liquidity hub is particularly appealing, as it leverages existing ecosystem strengths while creating a clear value proposition for both builders and users. This approach could create a powerful flywheel and activate network effects that benefit both Arbitrum One and Orbit chains.
One aspect that the proposal could benefit from would be further clarification and specification of the proposed architecture.
We are in support of this proposal as it presents a compelling vision for enhancing Arbitrum’s competitive position while delivering meaningful improvements to builder and user experience across the ecosystem.
This feels like a really solid initiative. I’m thinking we can support on the App layer by aggregating insights about builders decision-making models so the comms/packaging of these solutions is as sharp as possible
I’d like to share the findings of many conversations at DevCon.
Market makers have a cost of capital which can be used to support chain abstraction. Capital for Orbit - Orbit or for Orbit - Arbitrum One is a higher cost than for Superchain - Superchain. Basically, with shared governance, they consider it to have one risk variable where as with two unique chain governance, they consider it 2 risk factors.
Because of this higher cost of capital for market makers to ensure fast solving transactions, they are going to prioritize our network transactions last.
This project is needed to not only ensure we aren’t last to gain the features, but to acquire them at all. The DAO can supply this capital at competitive rates ensuring prioritization of the Orbital Liquidity Network.
